From brent.christian at oracle.com Mon May 1 18:59:33 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 1 May 2017 11:59:33 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> Message-ID: <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> Hi, Joe The typical run time of this test is ~18s (on my modestly-equipped laptop). So the test does run within a reasonable amount of time, IMO - under normal circumstances, anyway. The increased timeout is to cover the less seldom test run configurations involving Xcomp. Judging by when the test was added and the dates of the failed runs, I think this test has timed out since it was introduced, and there has not been an Xcomp regression. The test checks for a recursive initialization issue (8168075), and so needs to launch JVMs using various combinations of system classloader/security manager+policy/various module types. For this reason I think Xcomp hits this test particularly hard, recompiling the startup code on every VM launch. I think we want to maintain thorough test coverage here, though. Looking more into the failures, the worst case looks to be getting not quite halfway through the test. We should be able to get away with a more modest increase to the timeout (600, instead of 1200), and still have the test pass, if you would prefer. Thanks, -Brent On 4/27/17 2:25 PM, joe darcy wrote: > I understand the interest in having test pass reliably, but I don't > think giving the test very large timeouts is the preferred way of > accomplishing that. > > For all configurations, the test can now run for up to 20 minutes, up > from 4 minutes. We want to run the entire test suite, thousands of > tests, in about 20 minutes. The the timeout factor used for Xcomp run, > the test would probably now be able to run for over an hour before > timing out. > > I suggest making the test run faster, or seeing if there has been a > regressions in Xcomp to make test perform more poorly there. > > Thanks, > > -Joe > > > On 4/27/2017 12:08 PM, Brent Christian wrote: >> Hi, >> >> This test times out under our automated testing configurations that >> include -Xcomp. >> >> Please review my change to increase the timeout for this test. It is >> sufficient for the test configurations in question to pass on two >> different local machines (Mac & Linux). >> >> diff -r 7c04ab31b4d6 >> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> Wed Apr 26 09:37:23 2017 -0700 >> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >> Thu Apr 27 12:03:33 2017 -0700 >> @@ -29,7 +29,7 @@ >> * @library /lib/testlibrary >> * @modules java.base/jdk.internal.module >> * @build JarUtils CompilerUtils >> - * @run main/timeout=240 ClassLoaderTest >> + * @run main/timeout=1200 ClassLoaderTest >> */ >> >> Thanks, >> -Brent > From mandy.chung at oracle.com Mon May 1 19:41:15 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 May 2017 12:41:15 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> Message-ID: <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Looks like this test execs a new VM for 66 times to exhaust the combination of with and without security manager, with a valid or malformed policy, client & custom loader in unnamed, named, automatic module. I think we could take out the automatic module case as named module would verify it. One refactor you can consider by separating them in several @run actions. The timeout will apply to each action but that does not help shorten the test execution time. Mandy > On May 1, 2017, at 11:59 AM, Brent Christian wrote: > > Hi, Joe > > The typical run time of this test is ~18s (on my modestly-equipped laptop). So the test does run within a reasonable amount of time, IMO - under normal circumstances, anyway. > > The increased timeout is to cover the less seldom test run configurations involving Xcomp. Judging by when the test was added and the dates of the failed runs, I think this test has timed out since it was introduced, and there has not been an Xcomp regression. > > The test checks for a recursive initialization issue (8168075), and so needs to launch JVMs using various combinations of system classloader/security manager+policy/various module types. For this reason I think Xcomp hits this test particularly hard, recompiling the startup code on every VM launch. I think we want to maintain thorough test coverage here, though. > > Looking more into the failures, the worst case looks to be getting not quite halfway through the test. We should be able to get away with a more modest increase to the timeout (600, instead of 1200), and still have the test pass, if you would prefer. > > Thanks, > -Brent > > On 4/27/17 2:25 PM, joe darcy wrote: >> I understand the interest in having test pass reliably, but I don't >> think giving the test very large timeouts is the preferred way of >> accomplishing that. >> >> For all configurations, the test can now run for up to 20 minutes, up >> from 4 minutes. We want to run the entire test suite, thousands of >> tests, in about 20 minutes. The the timeout factor used for Xcomp run, >> the test would probably now be able to run for over an hour before >> timing out. >> >> I suggest making the test run faster, or seeing if there has been a >> regressions in Xcomp to make test perform more poorly there. >> >> Thanks, >> >> -Joe >> >> >> On 4/27/2017 12:08 PM, Brent Christian wrote: >>> Hi, >>> >>> This test times out under our automated testing configurations that >>> include -Xcomp. >>> >>> Please review my change to increase the timeout for this test. It is >>> sufficient for the test configurations in question to pass on two >>> different local machines (Mac & Linux). >>> >>> diff -r 7c04ab31b4d6 >>> test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> Wed Apr 26 09:37:23 2017 -0700 >>> +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java >>> Thu Apr 27 12:03:33 2017 -0700 >>> @@ -29,7 +29,7 @@ >>> * @library /lib/testlibrary >>> * @modules java.base/jdk.internal.module >>> * @build JarUtils CompilerUtils >>> - * @run main/timeout=240 ClassLoaderTest >>> + * @run main/timeout=1200 ClassLoaderTest >>> */ >>> >>> Thanks, >>> -Brent >> From brent.christian at oracle.com Mon May 1 19:47:59 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 1 May 2017 12:47:59 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Message-ID: On 5/1/17 12:41 PM, Mandy Chung wrote: > Looks like this test execs a new VM for 66 times to exhaust the > combination of with and without security manager, with a valid or > malformed policy, client & custom loader in unnamed, named, automatic > module. Right. > I think we could take out the automatic module case as named > module would verify it. OK, I can do that. I'm pretty sure an increase to the timeout will still be needed, though. > One refactor you can consider by separating > them in several @run actions. The timeout will apply to each action > but that does not help shorten the test execution time. I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. Thanks, -Brent From mandy.chung at oracle.com Mon May 1 19:50:40 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 May 2017 12:50:40 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Message-ID: <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> > On May 1, 2017, at 12:47 PM, Brent Christian wrote: > > >> One refactor you can consider by separating >> them in several @run actions. The timeout will apply to each action >> but that does not help shorten the test execution time. > > I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. I think it would make the test easier to read and understand the cases it cover. Mandy From Roger.Riggs at Oracle.com Mon May 1 20:22:27 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 1 May 2017 16:22:27 -0400 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> Message-ID: <09168fe0-b5ae-171e-e637-77c32c3baf91@Oracle.com> Hi, Also, should it not be the case that running with -Xcomp should increase the timeout factor to avoid such issues? I'm not sure how that can be assured though. Roger On 5/1/2017 3:47 PM, Brent Christian wrote: > On 5/1/17 12:41 PM, Mandy Chung wrote: >> Looks like this test execs a new VM for 66 times to exhaust the >> combination of with and without security manager, with a valid or >> malformed policy, client & custom loader in unnamed, named, automatic >> module. > > Right. > >> I think we could take out the automatic module case as named >> module would verify it. > > OK, I can do that. I'm pretty sure an increase to the timeout will > still be needed, though. > >> One refactor you can consider by separating >> them in several @run actions. The timeout will apply to each action >> but that does not help shorten the test execution time. > > I had the same thought, and concluded that without a reduction in > overall execution time, the benefit of such a refactor is pretty limited. > > Thanks, > -Brent From brent.christian at oracle.com Mon May 1 20:44:08 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 1 May 2017 13:44:08 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <09168fe0-b5ae-171e-e637-77c32c3baf91@Oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <09168fe0-b5ae-171e-e637-77c32c3baf91@Oracle.com> Message-ID: <03fdc902-b144-ee3f-0435-3cce5dbd1e73@oracle.com> The test runs in question are using an increased timeout factor, but this test still needs more time than its current timeout provides. Thanks, -Brent On 5/1/17 1:22 PM, Roger Riggs wrote: > Hi, > > Also, should it not be the case that running with -Xcomp should increase > the timeout factor > to avoid such issues? I'm not sure how that can be assured though. > > Roger > > > On 5/1/2017 3:47 PM, Brent Christian wrote: >> On 5/1/17 12:41 PM, Mandy Chung wrote: >>> Looks like this test execs a new VM for 66 times to exhaust the >>> combination of with and without security manager, with a valid or >>> malformed policy, client & custom loader in unnamed, named, automatic >>> module. >> >> Right. >> >>> I think we could take out the automatic module case as named >>> module would verify it. >> >> OK, I can do that. I'm pretty sure an increase to the timeout will >> still be needed, though. >> >>> One refactor you can consider by separating >>> them in several @run actions. The timeout will apply to each action >>> but that does not help shorten the test execution time. >> >> I had the same thought, and concluded that without a reduction in >> overall execution time, the benefit of such a refactor is pretty limited. >> >> Thanks, >> -Brent > From brent.christian at oracle.com Mon May 1 21:16:05 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 1 May 2017 14:16:05 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> Message-ID: <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> On 5/1/17 12:50 PM, Mandy Chung wrote: >> On May 1, 2017, at 12:47 PM, Brent Christian wrote: >>> >>> One refactor you can consider by separating >>> them in several @run actions. The timeout will apply to each action >>> but that does not help shorten the test execution time. >> >> I had the same thought, and concluded that without a reduction in overall execution time, the benefit of such a refactor is pretty limited. > > I think it would make the test easier to read and understand the cases it cover. > True. I'll see what I can do, then. -Brent From jonathan.gibbons at oracle.com Mon May 1 22:21:17 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 01 May 2017 15:21:17 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: Message-ID: <5907B4DD.70200@oracle.com> A timeout of 1200 seconds (20 minutes) is pretty extreme. If you are testing configurations with -Xcomp. you might do better to use the jtreg command-line option -timeoutfactor instead. -- Jon On 04/27/2017 12:08 PM, Brent Christian wrote: > Hi, > > This test times out under our automated testing configurations that > include -Xcomp. > > Please review my change to increase the timeout for this test. It is > sufficient for the test configurations in question to pass on two > different local machines (Mac & Linux). > > diff -r 7c04ab31b4d6 > test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > --- a/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Wed Apr 26 09:37:23 2017 -0700 > +++ b/test/java/lang/ClassLoader/securityManager/ClassLoaderTest.java > Thu Apr 27 12:03:33 2017 -0700 > @@ -29,7 +29,7 @@ > * @library /lib/testlibrary > * @modules java.base/jdk.internal.module > * @build JarUtils CompilerUtils > - * @run main/timeout=240 ClassLoaderTest > + * @run main/timeout=1200 ClassLoaderTest > */ > > Thanks, > -Brent From jonathan.gibbons at oracle.com Mon May 1 22:23:35 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 01 May 2017 15:23:35 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <03fdc902-b144-ee3f-0435-3cce5dbd1e73@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <09168fe0-b5ae-171e-e637-77c32c3baf91@Oracle.com> <03fdc902-b144-ee3f-0435-3cce5dbd1e73@oracle.com> Message-ID: <5907B567.9030907@oracle.com> So how long does the test typically take to run, with and without -Xcomp. If you are running with -Xcomp /and/ a timeoutfactor, that timeout of 1200s is going to be multiplied by the timeout factor! -- Jon On 05/01/2017 01:44 PM, Brent Christian wrote: > The test runs in question are using an increased timeout factor, but > this test still needs more time than its current timeout provides. > > Thanks, > -Brent > > On 5/1/17 1:22 PM, Roger Riggs wrote: >> Hi, >> >> Also, should it not be the case that running with -Xcomp should increase >> the timeout factor >> to avoid such issues? I'm not sure how that can be assured though. >> >> Roger >> >> >> On 5/1/2017 3:47 PM, Brent Christian wrote: >>> On 5/1/17 12:41 PM, Mandy Chung wrote: >>>> Looks like this test execs a new VM for 66 times to exhaust the >>>> combination of with and without security manager, with a valid or >>>> malformed policy, client & custom loader in unnamed, named, automatic >>>> module. >>> >>> Right. >>> >>>> I think we could take out the automatic module case as named >>>> module would verify it. >>> >>> OK, I can do that. I'm pretty sure an increase to the timeout will >>> still be needed, though. >>> >>>> One refactor you can consider by separating >>>> them in several @run actions. The timeout will apply to each action >>>> but that does not help shorten the test execution time. >>> >>> I had the same thought, and concluded that without a reduction in >>> overall execution time, the benefit of such a refactor is pretty >>> limited. >>> >>> Thanks, >>> -Brent >> From brian.goetz at oracle.com Tue May 2 00:38:22 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 1 May 2017 20:38:22 -0400 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> Message-ID: <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Or use multi-release JARs. On 4/25/2017 3:14 AM, Jeremy Manson wrote: > I guess I can call it reflectively. From mandy.chung at oracle.com Tue May 2 02:37:08 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 1 May 2017 19:37:08 -0700 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke Message-ID: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ The big hammer check disallowing MethodHandles::lookup be called by system classes defined by the bootstrap class loader was added as defense-in-depth to prevent this caller-sensitive method being called from JDK internal classes via Method::invoke. It was intended as a point fix and to be replaced with a long-term approach. Lookup.privateLookupIn() returns a Lookup object and IAE is thrown if the lookup class is almost all java.* and sun.* [1]. We should fix this in JDK 9. This patch replaces this restriction and now allow MethodHandles::lookup to be called statically by any code. But disallow Method::invoke of MethodHandles.lookup from system classes defined by the bootstrap class loader e.g. java.base. It is expected that no reflective call to MethodHandles::lookup is made by the system classes and so this approach would provide a better mechanism as a defense-in-depth. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012267.html From jeremymanson at google.com Tue May 2 06:50:55 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 1 May 2017 23:50:55 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Message-ID: Maybe when there's something breaking in Java 10 or 11, I can do that. Right now, that approach requires me to have a fork of my code, have special build goop, rely on yet another Java 9 feature, and make my relatively widely used OSS project require Java 9 to build *prior to Java 9's release -* just so I can save maybe 15-20 lines of code. Meanwhile, I'm not having a lot of luck - adding what seems to be the right reflective call doesn't seem to allow me to modify classes like ArrayList. Trying to create a boiled down repro (in 30 minute chunks between management tasks - sigh). OffTopic, but possibly of interest to you: it has also been challenging to figure out how we're going to migrate our users away from features like Xbootclasspath. Our standard operating procedure (which has worked from 5 to 6 to 7 to 8) is to get the codebase into a state where it can work both with the previous version and the new version of the JDK, and then throw the switch. If we follow this path, before we migrate to Java 9, we would need to make sure all of our code builds and the tests pass with Java 9 and Java 8. We can't make all of the code build and the tests pass with Java 9 as-is, because many of them use options like Xbootclasspath, which have been dropped. We can't migrate those tests to use the new command line flags before we migrate to Java 9, because if we do, they will stop working with Java 8. Due to the size of our code base, it's pretty much impossible to migrate all of the users to a new set of command line flags at the same time as we migrate to Java 9. Between that and the amount of reflective access we do into the JDK, we'll probably just end up re-adding features like Xbootclasspath in our fork and enabling the big kill switch for everyone, and then removing it gradually over the lifetime of Java 9. We've had to do that for some minor stuff before, but nothing this big. I'm glad we have options like that, and don't envy people with large codebases who don't. That said, we probably abuse the ability to crack open the JDK more than most people. I've been dealing with some of the concerns about upgradability for some of Google's open-source projects lately, and I am insisting that we have a rule that there is always an intermediate version that provides backwards compatibility for any desired change, so that users can always perform stepwise migrations. Thanks for the inspiration. :) Jeremy On Mon, May 1, 2017 at 5:38 PM, Brian Goetz wrote: > Or use multi-release JARs. > > > On 4/25/2017 3:14 AM, Jeremy Manson wrote: > >> I guess I can call it reflectively. >> > > From Alan.Bateman at oracle.com Tue May 2 07:48:52 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 May 2017 08:48:52 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Message-ID: On 02/05/2017 07:50, Jeremy Manson wrote: > : > > If we follow this path, before we migrate to Java 9, we would need to > make sure all of our code builds and the tests pass with Java 9 and > Java 8. We can't make all of the code build and the tests pass with > Java 9 as-is, because many of them use options like Xbootclasspath, > which have been dropped. We can't migrate those tests to use the new > command line flags before we migrate to Java 9, because if we do, they > will stop working with Java 8. Due to the size of our code base, it's > pretty much impossible to migrate all of the users to a new set of > command line flags at the same time as we migrate to Java 9. So I'm curious about -Xbootclasspath as that completely overrides the runtime classes. Is this static instrumentation or combining the VM/launcher from one build with the classes from a different JDK build? In any case, and as you have found, -Xbootclasspath and -Xbootclasspath/p are meaningless now, a consequence of moving all the core APIs to modules. The -Xbootclasspath/a option works as before with the caveat that not all platform classes are visible to the boot class loader now (a consequence of ongoing security work to move non-core components away from the fully privileged boot loader). It might be that you mean the `javac -bootclasspath, this works as before when you target 8 or older. -Alan From amy.lu at oracle.com Tue May 2 09:19:32 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 2 May 2017 17:19:32 +0800 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows Message-ID: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Please review this test-only change. Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. bug: https://bugs.openjdk.java.net/browse/JDK-8023897 webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ Thanks, Amy From adinn at redhat.com Tue May 2 09:40:29 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 May 2017 10:40:29 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> Message-ID: <06d99b2d-2140-7c22-a8a0-612de7d83b5d@redhat.com> On 25/04/17 09:19, Andrew Dinn wrote: > This discussion really ought to be happening on the Byteman forum but > anyway ... > > Yes, Alan is right that this is exactly what is going on. Byteman on > jdk9 (the 4.0.0-BETA release series) now uses method handles in place of > reflection. Unfortunately, it is limited by a slightly arbitrary > restriction on the use of method handles in java.* and sun.* packages (a > blunt instrument to provide some security guarantees). > > This is being addressed on two fronts. I am in the process of adding > unit tests to complete a workaround which remedies this problem by > falling back to reflection in the specific cases where the restriction > applies (yes, that means there is probably going to be another > 4.0.0-BETA release before jdk9 goes live %-/ ). Just wanted to post a heads-up that this fall-back behaviour has now been implemented in Byteman release 4.0.0-BETA5. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From peter.levart at gmail.com Tue May 2 10:14:30 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 May 2017 12:14:30 +0200 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> Message-ID: <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> Hi Mandy, On 05/02/2017 04:37 AM, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ > > The big hammer check disallowing MethodHandles::lookup be called by system > classes defined by the bootstrap class loader was added as defense-in-depth > to prevent this caller-sensitive method being called from JDK internal classes > via Method::invoke. It was intended as a point fix and to be replaced > with a long-term approach. Lookup.privateLookupIn() returns a Lookup object > and IAE is thrown if the lookup class is almost all java.* and sun.* [1]. > We should fix this in JDK 9. > > This patch replaces this restriction and now allow MethodHandles::lookup to > be called statically by any code. But disallow Method::invoke of > MethodHandles.lookup from system classes defined by the bootstrap class loader > e.g. java.base. It is expected that no reflective call to > MethodHandles::lookup is made by the system classes and so this approach > would provide a better mechanism as a defense-in-depth. > > Mandy > [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-April/012267.html I don't quite understand the need for bypassing the inflation of native into generated method accessor when the reflected method is a @CallerSensitive method which has a substitute method declared to be called by reflection (like with the MethodHandles.[reflected$]lookup() pair), in the following fragment of ReflectionFactory: 179 public MethodAccessor newMethodAccessor(Method method) { 180 checkInitted(); 181 182 boolean noInflation = ReflectionFactory.noInflation; 183 if (Reflection.isCallerSensitive(method)) { 184 Method altMethod = findMethodForReflection(method); 185 if (altMethod != null) { 186 method = altMethod; 187 noInflation = true; // in this case only 188 } 189 } 190 191 if (noInflation && !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())) { 192 return new MethodAccessorGenerator(). 193 generateMethod(method.getDeclaringClass(), 194 method.getName(), 195 method.getParameterTypes(), 196 method.getReturnType(), 197 method.getExceptionTypes(), 198 method.getModifiers()); 199 } else { 200 NativeMethodAccessorImpl acc = 201 new NativeMethodAccessorImpl(method); 202 DelegatingMethodAccessorImpl res = 203 new DelegatingMethodAccessorImpl(acc); 204 acc.setParent(res); 205 return res; 206 } 207 } Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is? Regards, Peter From adinn at redhat.com Tue May 2 10:25:19 2017 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 2 May 2017 11:25:19 +0100 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> Message-ID: <9eb93fd8-2e40-cb0e-e1b3-cfca002f8702@redhat.com> Hi Mandy, On 02/05/17 03:37, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.00/ > > . . . Not an official review, I am afraid, but the patch looks good and is much appreciated! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From pavel.rappo at oracle.com Tue May 2 11:15:26 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 2 May 2017 12:15:26 +0100 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: Hi Amy, Thanks a lot for doing this! I personally think it's a beginning of a very valuable refactoring to our test base. It turns out this little piece of functionality, namely, checking that a particular exception is thrown from code is error-prone. I have seen many buggy implementations defective in one way or another. What's worse is that sometimes many of them coexist in the same code base. Even in the JDK this beast has many names: tryCatch, verifyException, expectThrows, checkException, expectThrow, assertThrows, THROWS, check, uncaughtException, testThrowException, assertSecurityException, ... This list does not include countless ad-hoc bare try-catch constructs. After this has been done, I would go even further, and in some cases change tests that use @Test(expectedException=...) annotation to use this method instead. Looks good. Wait for a Reviewer and you are good to go. Thanks, -Pavel > On 2 May 2017, at 10:19, Amy Lu wrote: > > Please review this test-only change. > > Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows > > Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8023897 > webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ > > Thanks, > Amy > From Roger.Riggs at Oracle.com Tue May 2 14:21:03 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 2 May 2017 10:21:03 -0400 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: <815b5533-b9c0-8fc4-7d10-897af15508cb@Oracle.com> Hi Amy, Yes, a good cleanup. - EmptyNavigableMap.java in assertThrows(class, runnable, message) will be a bit awkward to debug since the stack trace of the real cause will be buried in the cause of the new AssertionError thrown. Without re-implementing the TestNG.expectThrows[1] method, I would be more inclined to print the message and then re-throw the exception. Still not best, but doesn't require knowing to look in the exception cause to find the location of the original throw. Ditto EmptyNavigableSet.java:72 The messages are useful when debugging to know the reason for the exception without having to reverse engineer the code. - java/util/Map/Defaults.java:167 The {}'s around the lambda value are not necessary (like 166). Thanks, Roger [1] https://github.com/cbeust/testng/blob/master/src/main/java/org/testng/Assert.java : 1119 On 5/2/2017 7:15 AM, Pavel Rappo wrote: > Hi Amy, > > Thanks a lot for doing this! I personally think it's a beginning of a very > valuable refactoring to our test base. It turns out this little piece of > functionality, namely, checking that a particular exception is thrown from code > is error-prone. I have seen many buggy implementations defective in one way or > another. What's worse is that sometimes many of them coexist in the same code > base. Even in the JDK this beast has many names: > > tryCatch, verifyException, expectThrows, checkException, expectThrow, > assertThrows, THROWS, check, uncaughtException, testThrowException, > assertSecurityException, ... > > This list does not include countless ad-hoc bare try-catch constructs. After > this has been done, I would go even further, and in some cases change tests that > use @Test(expectedException=...) annotation to use this method instead. > > Looks good. Wait for a Reviewer and you are good to go. > > Thanks, > -Pavel > >> On 2 May 2017, at 10:19, Amy Lu wrote: >> >> Please review this test-only change. >> >> Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows >> >> Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023897 >> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ >> >> Thanks, >> Amy >> From brian.goetz at oracle.com Tue May 2 14:51:19 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Tue, 2 May 2017 10:51:19 -0400 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Message-ID: <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> 8 can deal with multi-release JARs. The extra goop is ignored. So a 7/8/9 MRJar is perfectly possible (and in fact, the whole point of doing them in the first place, so library writers could publish JARs that span 7/8/9.) On 5/2/2017 2:50 AM, Jeremy Manson wrote: > Maybe when there's something breaking in Java 10 or 11, I can do > that. Right now, that approach requires me to have a fork of my code, > have special build goop, rely on yet another Java 9 feature, and make > my relatively widely used OSS project require Java 9 to build /prior > to Java 9's release -/ just so I can save maybe 15-20 lines of code. > > Meanwhile, I'm not having a lot of luck - adding what seems to be the > right reflective call doesn't seem to allow me to modify classes like > ArrayList. Trying to create a boiled down repro (in 30 minute chunks > between management tasks - sigh). > > OffTopic, but possibly of interest to you: it has also been > challenging to figure out how we're going to migrate our users away > from features like Xbootclasspath. Our standard operating procedure > (which has worked from 5 to 6 to 7 to 8) is to get the codebase into a > state where it can work both with the previous version and the new > version of the JDK, and then throw the switch. > > If we follow this path, before we migrate to Java 9, we would need to > make sure all of our code builds and the tests pass with Java 9 and > Java 8. We can't make all of the code build and the tests pass with > Java 9 as-is, because many of them use options like Xbootclasspath, > which have been dropped. We can't migrate those tests to use the new > command line flags before we migrate to Java 9, because if we do, they > will stop working with Java 8. Due to the size of our code base, it's > pretty much impossible to migrate all of the users to a new set of > command line flags at the same time as we migrate to Java 9. > > Between that and the amount of reflective access we do into the JDK, > we'll probably just end up re-adding features like Xbootclasspath in > our fork and enabling the big kill switch for everyone, and then > removing it gradually over the lifetime of Java 9. We've had to do > that for some minor stuff before, but nothing this big. I'm glad we > have options like that, and don't envy people with large codebases who > don't. > > That said, we probably abuse the ability to crack open the JDK more > than most people. > > I've been dealing with some of the concerns about upgradability for > some of Google's open-source projects lately, and I am insisting that > we have a rule that there is always an intermediate version that > provides backwards compatibility for any desired change, so that users > can always perform stepwise migrations. Thanks for the inspiration. :) > > Jeremy > > On Mon, May 1, 2017 at 5:38 PM, Brian Goetz > wrote: > > Or use multi-release JARs. > > > On 4/25/2017 3:14 AM, Jeremy Manson wrote: > > I guess I can call it reflectively. > > > From misterm at gmail.com Tue May 2 16:45:12 2017 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 2 May 2017 13:45:12 -0300 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> Message-ID: On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > 8 can deal with multi-release JARs. > I missed that. Starting with what update? Is there any link I could use to share this info? Regards, Michael From jeremymanson at google.com Tue May 2 16:46:14 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Tue, 2 May 2017 09:46:14 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> Message-ID: Brian: Bit of a miscommunication on my part: I know 8 can deal with multirelease JARs. I just can't build them with 8 (although maybe I could with enough build magic). When I said "rely on another 9 feature", I just meant that I would be building something else in that required 9, which would be bad because I would require a pre-release 9 to build. I'm not going to inflict that on my users (many of whom have forked it and build it themselves). (This project isn't Guava or Dagger or something - it's just a small-ball instrumentation agent.) Alan: Most of our code runs with our home-grown launcher (so we can take advantage of JEP 178) and an OpenJDK-based JVM, although we also still build and distribute the OpenJDK launcher, and many people use it. People are using Xbootclasspath for a variety of things. We use it in various non-OpenJDK libraries configurations (like with GWT and j2objc) to run with their class libraries, which are not OpenJDK-based. We also have folks using Jetty ALPN, which requires it. We also have a bunch of people using it for instrumentation agents (it's a little tricky to get X-Boot-Class-Path to work in our environment), but there should be workarounds for that. We have a few people using it for... not-immediately-obvious reasons. I didn't realize that bootclasspath/a still partially worked - that might be enough for some of these use cases. We'll have to see when we get to it. And see what happens when the stuff hits the fan. We don't actually use javac at all - we have our own wrapper around the javac API. Anyway, I can see we have an interesting upgrade path ahead of us. I'm glad that we solved so many recurring problems permanently (like our hash randomization change). Jeremy On Tue, May 2, 2017 at 7:51 AM, Brian Goetz wrote: > 8 can deal with multi-release JARs. The extra goop is ignored. So a > 7/8/9 MRJar is perfectly possible (and in fact, the whole point of doing > them in the first place, so library writers could publish JARs that span > 7/8/9.) > > > On 5/2/2017 2:50 AM, Jeremy Manson wrote: > > Maybe when there's something breaking in Java 10 or 11, I can do that. > Right now, that approach requires me to have a fork of my code, have > special build goop, rely on yet another Java 9 feature, and make my > relatively widely used OSS project require Java 9 to build *prior to Java > 9's release -* just so I can save maybe 15-20 lines of code. > > Meanwhile, I'm not having a lot of luck - adding what seems to be the > right reflective call doesn't seem to allow me to modify classes like > ArrayList. Trying to create a boiled down repro (in 30 minute chunks > between management tasks - sigh). > > OffTopic, but possibly of interest to you: it has also been challenging to > figure out how we're going to migrate our users away from features like > Xbootclasspath. Our standard operating procedure (which has worked from 5 > to 6 to 7 to 8) is to get the codebase into a state where it can work both > with the previous version and the new version of the JDK, and then throw > the switch. > > If we follow this path, before we migrate to Java 9, we would need to make > sure all of our code builds and the tests pass with Java 9 and Java 8. We > can't make all of the code build and the tests pass with Java 9 as-is, > because many of them use options like Xbootclasspath, which have been > dropped. We can't migrate those tests to use the new command line flags > before we migrate to Java 9, because if we do, they will stop working with > Java 8. Due to the size of our code base, it's pretty much impossible to > migrate all of the users to a new set of command line flags at the same > time as we migrate to Java 9. > > Between that and the amount of reflective access we do into the JDK, we'll > probably just end up re-adding features like Xbootclasspath in our fork and > enabling the big kill switch for everyone, and then removing it gradually > over the lifetime of Java 9. We've had to do that for some minor stuff > before, but nothing this big. I'm glad we have options like that, and > don't envy people with large codebases who don't. > > That said, we probably abuse the ability to crack open the JDK more than > most people. > > I've been dealing with some of the concerns about upgradability for some > of Google's open-source projects lately, and I am insisting that we have a > rule that there is always an intermediate version that provides backwards > compatibility for any desired change, so that users can always perform > stepwise migrations. Thanks for the inspiration. :) > > Jeremy > > On Mon, May 1, 2017 at 5:38 PM, Brian Goetz > wrote: > >> Or use multi-release JARs. >> >> >> On 4/25/2017 3:14 AM, Jeremy Manson wrote: >> >>> I guess I can call it reflectively. >>> >> >> > > From daniel.fuchs at oracle.com Tue May 2 16:53:12 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 2 May 2017 17:53:12 +0100 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: <636fd5fc-bf6b-bdd7-d2b6-195a8a74bcd3@oracle.com> Hi Amy, Looks good generally - there are a couple of cases where the description that was passed to the AssertionError in the original file is dropped (for instance http://cr.openjdk.java.net/~amlu/8023897/webrev.00/test/java/util/Map/Defaults.java.frames.html) Is that going to be an issue when analyzing test logs in case of failure? IIRC testng prints the parameters passed to the test method (which includes the description - so maybe that's OK). Is that why you decided to drop the description? best regards -- daniel On 02/05/2017 10:19, Amy Lu wrote: > Please review this test-only change. > > Some java/util tests use a function executeAndCatch which essentially > asserts that an exception is thrown, while some other tests use > assertThrows for doing the same work. For both cases, with jtreg > upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage > TestNG Assert.assertThrows > > Please review the patch to update executeAndCatch and assertThrows to > Assert.assertThrows for java/util testng tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8023897 > webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ > > Thanks, > Amy > From mandy.chung at oracle.com Tue May 2 16:56:49 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 09:56:49 -0700 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> Message-ID: > On May 2, 2017, at 3:14 AM, Peter Levart wrote: > > I don't quite understand the need for bypassing the inflation of native into generated method accessor The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and so we ensure this be called via the generated bytecode for Method::invoke rather than going through the VM native reflection which reduces startup overhead. > Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is? As this case is forced not to go through VM reflection support, unless I miss something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to be changed. I will double check with the VM runtime team. Mandy From paul.sandoz at oracle.com Tue May 2 17:15:24 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 2 May 2017 10:15:24 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> Message-ID: <1D3520A6-FFCD-4253-ABD6-CE9E7B7BFA44@oracle.com> > On 2 May 2017, at 09:45, Michael Nascimento wrote: > > On Tue, May 2, 2017 at 11:51 AM, Brian Goetz wrote: > >> 8 can deal with multi-release JARs. >> > > I missed that. Starting with what update? Is there any link I could use to > share this info? > There have been no modifications to the Java 8 runtime, it will just ignore stuff in the META-INF/versions/{N} directories. At one point we were mulling back porting the Java 9 runtime changes to Java 8 and therefore we could go back to Java 7, but we decided not to proceed with that, which is what i suspect you may be thinking about. Paul. From misterm at gmail.com Tue May 2 17:18:06 2017 From: misterm at gmail.com (Michael Nascimento) Date: Tue, 2 May 2017 14:18:06 -0300 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <1D3520A6-FFCD-4253-ABD6-CE9E7B7BFA44@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <1D3520A6-FFCD-4253-ABD6-CE9E7B7BFA44@oracle.com> Message-ID: On Tue, May 2, 2017 at 2:15 PM, Paul Sandoz wrote: > At one point we were mulling back porting the Java 9 runtime changes to > Java 8 and therefore we could go back to Java 7, but we decided not to > proceed with that, which is what i suspect you may be thinking about. > > Yes, I was hopeful about the last bit. Thank you for the clarification! Regards, Michael From kirk.pepperdine at gmail.com Tue May 2 17:50:50 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Tue, 2 May 2017 19:50:50 +0200 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Message-ID: Hi Alan, One of the techniques that I?ve used in the past for troubleshooting is to prepend modified classes to the bootstrap class path. I fear all this mucking about with modularization is going to leave the road to diagnostics littered with a ton of tools that will not longer work. As it is, 8 broke all the techniques and tooling used to diagnose class loader leaks? without fixing the fundamental problems that caused them to leak in the first place..and added a new sources for performance regressions for which there is little in the way of tooling and certainly much less of an understanding of the fundamental issues out in the general developer population. The availability of high quality tooling is a huge bonus in the Java eco structure?. Please, don?t send us back to the Stone Age. Kind regards, Kirk Pepperdine > On May 2, 2017, at 9:48 AM, Alan Bateman wrote: > > On 02/05/2017 07:50, Jeremy Manson wrote: >> : >> >> If we follow this path, before we migrate to Java 9, we would need to make sure all of our code builds and the tests pass with Java 9 and Java 8. We can't make all of the code build and the tests pass with Java 9 as-is, because many of them use options like Xbootclasspath, which have been dropped. We can't migrate those tests to use the new command line flags before we migrate to Java 9, because if we do, they will stop working with Java 8. Due to the size of our code base, it's pretty much impossible to migrate all of the users to a new set of command line flags at the same time as we migrate to Java 9. > So I'm curious about -Xbootclasspath as that completely overrides the runtime classes. Is this static instrumentation or combining the VM/launcher from one build with the classes from a different JDK build? In any case, and as you have found, -Xbootclasspath and -Xbootclasspath/p are meaningless now, a consequence of moving all the core APIs to modules. The -Xbootclasspath/a option works as before with the caveat that not all platform classes are visible to the boot class loader now (a consequence of ongoing security work to move non-core components away from the fully privileged boot loader). > > It might be that you mean the `javac -bootclasspath, this works as before when you target 8 or older. > > -Alan > From forax at univ-mlv.fr Tue May 2 18:00:05 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 2 May 2017 20:00:05 +0200 (CEST) Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> Message-ID: <1143221410.1116799.1493748005687.JavaMail.zimbra@u-pem.fr> Hi Kirk, --patch-module both at compile time and at runtime is what your are looking for. cheers, R?mi ----- Mail original ----- > De: "Kirk Pepperdine" > ?: "Alan Bateman" > Cc: "jigsaw-dev" , core-libs-dev at openjdk.java.net > Envoy?: Mardi 2 Mai 2017 19:50:50 > Objet: Re: Accessing module internals from bytecode rewriting agent > Hi Alan, > > One of the techniques that I?ve used in the past for troubleshooting is to > prepend modified classes to the bootstrap class path. I fear all this mucking > about with modularization is going to leave the road to diagnostics littered > with a ton of tools that will not longer work. As it is, 8 broke all the > techniques and tooling used to diagnose class loader leaks? without fixing the > fundamental problems that caused them to leak in the first place..and added a > new sources for performance regressions for which there is little in the way of > tooling and certainly much less of an understanding of the fundamental issues > out in the general developer population. The availability of high quality > tooling is a huge bonus in the Java eco structure?. Please, don?t send us back > to the Stone Age. > > Kind regards, > Kirk Pepperdine > >> On May 2, 2017, at 9:48 AM, Alan Bateman wrote: >> >> On 02/05/2017 07:50, Jeremy Manson wrote: >>> : >>> >>> If we follow this path, before we migrate to Java 9, we would need to make sure >>> all of our code builds and the tests pass with Java 9 and Java 8. We can't >>> make all of the code build and the tests pass with Java 9 as-is, because many >>> of them use options like Xbootclasspath, which have been dropped. We can't >>> migrate those tests to use the new command line flags before we migrate to Java >>> 9, because if we do, they will stop working with Java 8. Due to the size of >>> our code base, it's pretty much impossible to migrate all of the users to a new >>> set of command line flags at the same time as we migrate to Java 9. >> So I'm curious about -Xbootclasspath as that completely overrides the runtime >> classes. Is this static instrumentation or combining the VM/launcher from one >> build with the classes from a different JDK build? In any case, and as you have >> found, -Xbootclasspath and -Xbootclasspath/p are meaningless now, a >> consequence of moving all the core APIs to modules. The -Xbootclasspath/a >> option works as before with the caveat that not all platform classes are >> visible to the boot class loader now (a consequence of ongoing security work to >> move non-core components away from the fully privileged boot loader). >> >> It might be that you mean the `javac -bootclasspath, this works as before when >> you target 8 or older. >> >> -Alan From deepak.ramana at anthem.com Mon May 1 19:16:08 2017 From: deepak.ramana at anthem.com (Ramana, Deepak) Date: Mon, 1 May 2017 19:16:08 +0000 Subject: AppCDS in OpenJDK? Message-ID: <118d09d837d94cd6b7ab56fbad448b2c@DM2PR2801MB0143.056d.mgd.msft.net> Hello, I am not sure if this is the right forum to ask this question. Apologies in advance, if this is not the correct place. We want to use the AppCDS feature that is available in the commercial release of Java 8 update 40. Is this feature available in OpenJDK? If so, can we use this in production for commercial use ? Regards, Deepak CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or may otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachment thereto. From lance.andersen at oracle.com Tue May 2 18:33:20 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 2 May 2017 14:33:20 -0400 Subject: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism Message-ID: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> Hi all, The above issue adds a test to verify that a module based JDBC driver works via the service-provider loading mechanism. The webrev can be found at http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From paul.sandoz at oracle.com Tue May 2 19:15:04 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 2 May 2017 12:15:04 -0700 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: Hi, Looks good. Preserving the messages where possible would be good as raised by Roger and Daniel. ? As a follow on it would be nice to avoid the duplication of the assertThrowsNPE etc. I wish by default for TestNG jtreg would include an additional general helper library in scope that we control. (We should not have to update tests to use such a library.) Paul. > On 2 May 2017, at 02:19, Amy Lu wrote: > > Please review this test-only change. > > Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows > > Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. > > bug: https://bugs.openjdk.java.net/browse/JDK-8023897 > webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ > > Thanks, > Amy > From kumar.x.srinivasan at oracle.com Tue May 2 19:40:48 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 02 May 2017 12:40:48 -0700 Subject: RFR: JDK-8179538: Update jdk.jdi to be HTML-5 friendly Message-ID: <5908E0C0.1050100@oracle.com> Hello, Please review changes to make jdk.jdi HTML5 friendly, table cell padding has not been addressed and will be fixed separately, this takes care of others. Note: Some of the errors were due to incorrect at throws but in all cases there is the correct one further down, please use sdiffs in these cases. @throws {@link InvalidTypeException} if any.... before:jdk.jdi {error=42, warning=1} after: jdk.jdi {error=1} http://cr.openjdk.java.net/~ksrini/8179538/webrev.00/index.html https://bugs.openjdk.java.net/browse/JDK-8179538 Thanks Kumar From peter.levart at gmail.com Tue May 2 20:17:28 2017 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 2 May 2017 22:17:28 +0200 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> Message-ID: <08f27f02-2585-9544-7b70-fb55d9062dc2@gmail.com> On 05/02/2017 06:56 PM, Mandy Chung wrote: >> On May 2, 2017, at 3:14 AM, Peter Levart wrote: >> >> I don't quite understand the need for bypassing the inflation of native into generated method accessor > The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and so we ensure this be called via the generated bytecode for Method::invoke rather than going through the VM native reflection which reduces startup overhead. I don't think VM native reflection implementation needs to know anything about this alternate `reflected$XXX` mechanism. The NativeMethodAccessorImpl is constructed with the Method argument. In case of `reflected$XXX` mechanism, it is given the alternate Method object that points to the alternate method, so NativeMethodAccessorImpl.invoke0 is called with this alternate Method object. It is like reflecting over the alternate method itself, isn't it? Am I missing something? >> Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is? > As this case is forced not to go through VM reflection support, unless I miss something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to be changed. I will double check with the VM runtime team. I was asking because I suspected that this might be the reason for skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl. But if it is not the reason (and anyway it would be a bug because other @CallerSensitive methods would behave erratically if this was the case), then I still don't see a reason for skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl and proceeding directly with generated method accessor. Regards, Peter > Mandy > From Alan.Bateman at oracle.com Tue May 2 20:46:40 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 2 May 2017 21:46:40 +0100 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <1143221410.1116799.1493748005687.JavaMail.zimbra@u-pem.fr> References: <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <1143221410.1116799.1493748005687.JavaMail.zimbra@u-pem.fr> Message-ID: <4fde39fa-bc73-5400-8e81-b6508c7447d4@oracle.com> On 02/05/2017 19:00, Remi Forax wrote: > Hi Kirk, > --patch-module both at compile time and at runtime is what your are looking for. > > Right, and more details in the "Patching module content" section of JEP 261 [1]. -Alan [1] http://openjdk.java.net/jeps/261#Patching-module-content From pavel.rappo at oracle.com Tue May 2 20:51:20 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 2 May 2017 21:51:20 +0100 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: I'm not sure I fully understand the points mentioned by Roger, Daniel and Paul. Nevertheless I will kindly disagree with all of them, just for the sake of having a constructive discussion :-) My understanding is that org.testng.Assert.assertThrows provides a rich message explaining what has happened. Here is what I have just seen: No exception: assertThrows(NullPointerException.class, () -> { }); outputs: Exception in thread "main" java.lang.AssertionError: Expected NullPointerException to be thrown, but nothing was thrown at org.testng.Assert.expectThrows(Assert.java:1018) at org.testng.Assert.assertThrows(Assert.java:989) at MessageTest.main(MessageTest.java:10) Wrong exception: assertThrows(NullPointerException.class, () -> { throw new IllegalArgumentException("Hey!");}); outputs: Exception in thread "main" java.lang.AssertionError: Expected NullPointerException to be thrown, but IllegalArgumentException was thrown at org.testng.Assert.expectThrows(Assert.java:1013) at org.testng.Assert.assertThrows(Assert.java:989) at MessageTest.main(MessageTest.java:9) Caused by: java.lang.IllegalArgumentException: Hey! at MessageTest.lambda$main$0(MessageTest.java:9) at org.testng.Assert.expectThrows(Assert.java:1005) ... 2 more I believe that it is as good as it gets in these situations. And might, just might, be a tiny bit better than the previous more ahem...cryptic... message: should throw NPE I would also disagree with Roger that having the wrong exception in the cause of a thrown one is "a bit awkward". I think it's more straightforward and leaves the original exception's message intact and provides even more information. I would however agree with Paul on having a bunch of shortcuts for standard exceptions like: assertThrowsNPE, assertThrowsIAE, assertThrowsISE, etc. -Pavel >> On 2 May 2017, at 02:19, Amy Lu wrote: >> >> Please review this test-only change. >> >> Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows >> >> Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023897 >> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ >> >> Thanks, >> Amy >> > From Roger.Riggs at Oracle.com Tue May 2 21:02:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 2 May 2017 17:02:13 -0400 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> Message-ID: <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> Hi Pavel, In one case, 'should throw NPE' is not a useful message; for example in parallelPrefix. If the test was being written new I would advocate to add messages that reflect the semantics of the test case, not the exception message. But ": Must throw ClassCastException for parameter which is not Comparable." in Empty navigableMap is much more useful. And wrapping exceptions in exceptions makes debugging much harder, because it requires unwrapping the context and figuring out what the test was trying to do and which was the relevant source line. Here I would advocate for the test author to make sure the diagnostic information is direct and informative and not obscured by stack traces and too much irrelevant detail. So, in many cases I would give a pass to the changes proposed but wanted to observe that there are improvements possible if they were worth the effort and accept that we don't all use the same style or rigor. I should probably try to file a bug against TestNG.assertThrows to add a variant with a message. Many/most of the TestNG asserts have variants with messages. Regards, Roger On 5/2/2017 4:51 PM, Pavel Rappo wrote: > I'm not sure I fully understand the points mentioned by Roger, Daniel and Paul. > Nevertheless I will kindly disagree with all of them, just for the sake of > having a constructive discussion :-) > > My understanding is that org.testng.Assert.assertThrows provides a rich message > explaining what has happened. Here is what I have just seen: > > No exception: > > assertThrows(NullPointerException.class, () -> { }); > > outputs: > > Exception in thread "main" java.lang.AssertionError: Expected NullPointerException to be thrown, but nothing was thrown > at org.testng.Assert.expectThrows(Assert.java:1018) > at org.testng.Assert.assertThrows(Assert.java:989) > at MessageTest.main(MessageTest.java:10) > > Wrong exception: > > assertThrows(NullPointerException.class, () -> { throw new IllegalArgumentException("Hey!");}); > > outputs: > > Exception in thread "main" java.lang.AssertionError: Expected NullPointerException to be thrown, but IllegalArgumentException was thrown > at org.testng.Assert.expectThrows(Assert.java:1013) > at org.testng.Assert.assertThrows(Assert.java:989) > at MessageTest.main(MessageTest.java:9) > Caused by: java.lang.IllegalArgumentException: Hey! > at MessageTest.lambda$main$0(MessageTest.java:9) > at org.testng.Assert.expectThrows(Assert.java:1005) > ... 2 more > > I believe that it is as good as it gets in these situations. And might, just > might, be a tiny bit better than the previous more ahem...cryptic... message: > > should throw NPE > > I would also disagree with Roger that having the wrong exception in the cause of > a thrown one is "a bit awkward". I think it's more straightforward and leaves > the original exception's message intact and provides even more information. > > I would however agree with Paul on having a bunch of shortcuts for standard > exceptions like: assertThrowsNPE, assertThrowsIAE, assertThrowsISE, etc. > > -Pavel > >>> On 2 May 2017, at 02:19, Amy Lu wrote: >>> >>> Please review this test-only change. >>> >>> Some java/util tests use a function executeAndCatch which essentially asserts that an exception is thrown, while some other tests use assertThrows for doing the same work. For both cases, with jtreg upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage TestNG Assert.assertThrows >>> >>> Please review the patch to update executeAndCatch and assertThrows to Assert.assertThrows for java/util testng tests. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023897 >>> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ >>> >>> Thanks, >>> Amy >>> From mandy.chung at oracle.com Tue May 2 21:27:54 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 14:27:54 -0700 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: <08f27f02-2585-9544-7b70-fb55d9062dc2@gmail.com> References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> <08f27f02-2585-9544-7b70-fb55d9062dc2@gmail.com> Message-ID: <9D028093-0C38-438A-9634-837718F87890@oracle.com> Hi Peter, Looking at it again, you are right that no need to skip inflation. The change is simplified. I have verified with and without -Dsun.reflect.noInflation=true. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.01/ thanks Mandy > On May 2, 2017, at 1:17 PM, Peter Levart wrote: > > > On 05/02/2017 06:56 PM, Mandy Chung wrote: >>> On May 2, 2017, at 3:14 AM, Peter Levart wrote: >>> >>> I don't quite understand the need for bypassing the inflation of native into generated method accessor >> The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and so we ensure this be called via the generated bytecode for Method::invoke rather than going through the VM native reflection which reduces startup overhead. > > I don't think VM native reflection implementation needs to know anything about this alternate `reflected$XXX` mechanism. The NativeMethodAccessorImpl is constructed with the Method argument. In case of `reflected$XXX` mechanism, it is given the alternate Method object that points to the alternate method, so NativeMethodAccessorImpl.invoke0 is called with this alternate Method object. It is like reflecting over the alternate method itself, isn't it? > > Am I missing something? > >>> Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is? >> As this case is forced not to go through VM reflection support, unless I miss something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to be changed. I will double check with the VM runtime team. > > I was asking because I suspected that this might be the reason for skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl. But if it is not the reason (and anyway it would be a bug because other @CallerSensitive methods would behave erratically if this was the case), then I still don't see a reason for skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl and proceeding directly with generated method accessor. > > Regards, Peter > >> Mandy >> > From pavel.rappo at oracle.com Tue May 2 21:43:12 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 2 May 2017 22:43:12 +0100 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> Message-ID: <865E3752-8459-4BE7-98E5-353F70B90DB6@oracle.com> > On 2 May 2017, at 22:02, Roger Riggs wrote: > > If the test was being written new I would advocate to add messages that reflect the semantics of > the test case, not the exception message. > > But ": Must throw ClassCastException for parameter which is not Comparable." > in Empty navigableMap is much more useful. Well, okay. I think it's a fair point to have this option available. I for one once agreed and fully accepted Joshua Bloch's passage [1] on this: "...While it is critical to include all of the pertinent "hard data" in the detail message of an exception, it is generally unimportant to include a lot of prose. The stack trace is intended to be analyzed in conjunction with the source files and generally contains the exact file and line number from which the exception was thrown, as well as the files and line numbers of all other method invocations on the stack. Lengthy prose descriptions of the failure are generally superfluous; the information can be gleaned by reading the source code. The detail message of an exception should not be confused with a user-level error message, which must be intelligible to end users. Unlike a user-level error message, it is primarily for the benefit of programmers or field service personnel for use when analyzing a failure. Therefore, information content is far more important than intelligibility..." > And wrapping exceptions in exceptions makes debugging much harder, because > it requires unwrapping the context and figuring out what the test was trying to > do and which was the relevant source line. Here I would advocate for the test author > to make sure the diagnostic information is direct and informative and not obscured > by stack traces and too much irrelevant detail. I think a stacktrace is an enormously valuable piece of information to have in logs of a test run. It shows you where exactly a thing happened without any effort on your side. One more thing. I don't know much about TestNG, but IIRC JUnit used java.lang.AssertionError (or its subclass) for the framework's internal mechanics. So to a various utilities (test report generators, test report analyzers, etc.) an AssertionError thrown from inside a test meant a specific thing. Quite different from what any other Throwable meant. I'm not saying I agree with this design (it probably should've been a separate private exception) I'm just saying. TestNG might use a similar approach. > I should probably try to file a bug against TestNG.assertThrows to add a variant with > a message. Many/most of the TestNG asserts have variants with messages. +1 Thanks. -------------------------------------------------------------------------------- [1] Effective Java(TM), Second Edition, Item 63 From jiangli.zhou at oracle.com Tue May 2 21:50:18 2017 From: jiangli.zhou at oracle.com (Jiangli Zhou) Date: Tue, 2 May 2017 14:50:18 -0700 Subject: AppCDS in OpenJDK? In-Reply-To: <118d09d837d94cd6b7ab56fbad448b2c@DM2PR2801MB0143.056d.mgd.msft.net> References: <118d09d837d94cd6b7ab56fbad448b2c@DM2PR2801MB0143.056d.mgd.msft.net> Message-ID: <5D75F30C-F991-41B1-AC7F-84B3CCEDB42A@oracle.com> Hi Deepak, In JDK 8u40, AppCDS is an experimental (i.e can not be used in production) feature and is not available in OpenJDK. Following is related info from release notes for 8u40 : Application Class Data Sharing (AppCDS): Application Class Data Sharing (AppCDS) extends CDS (see Class Data Sharing ) to enable you to place classes from the standard extensions directories and the application class path in the shared archive. This is an experimental feature and not licensed for commercial use. See the -XX:+UseAppCDS option in the java launcher tool page. Regards, Jiangli > On May 1, 2017, at 12:16 PM, Ramana, Deepak wrote: > > Hello, > > I am not sure if this is the right forum to ask this question. Apologies in advance, if this is not the correct place. > > We want to use the AppCDS feature that is available in the commercial release of Java 8 update 40. > > Is this feature available in OpenJDK? If so, can we use this in production for commercial use ? > > Regards, > Deepak > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information or may otherwise be protected by law. Any > unauthorized review, use, disclosure or distribution is prohibited. If you > are not the intended recipient, please contact the sender by reply e-mail > and destroy all copies of the original message and any attachment thereto. From mandy.chung at oracle.com Tue May 2 23:23:06 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 2 May 2017 16:23:06 -0700 Subject: RFR: JDK-8179538: Update jdk.jdi to be HTML-5 friendly In-Reply-To: <5908E0C0.1050100@oracle.com> References: <5908E0C0.1050100@oracle.com> Message-ID: <19AEFC8E-F440-4FAA-9A39-F06164A3C575@oracle.com> Looks fine to me. Mandy > On May 2, 2017, at 12:40 PM, Kumar Srinivasan wrote: > > Hello, > > Please review changes to make jdk.jdi HTML5 friendly, > table cell padding has not been addressed and will be fixed > separately, this takes care of others. > > Note: Some of the errors were due to incorrect at throws but > in all cases there is the correct one further down, please use > sdiffs in these cases. > > @throws {@link InvalidTypeException} if any.... > > before:jdk.jdi {error=42, warning=1} > after: jdk.jdi {error=1} > > http://cr.openjdk.java.net/~ksrini/8179538/webrev.00/index.html > https://bugs.openjdk.java.net/browse/JDK-8179538 > > Thanks > Kumar > From serguei.spitsyn at oracle.com Tue May 2 23:56:05 2017 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 2 May 2017 16:56:05 -0700 Subject: RFR: JDK-8179538: Update jdk.jdi to be HTML-5 friendly In-Reply-To: <19AEFC8E-F440-4FAA-9A39-F06164A3C575@oracle.com> References: <5908E0C0.1050100@oracle.com> <19AEFC8E-F440-4FAA-9A39-F06164A3C575@oracle.com> Message-ID: Hi Kumar, It looks fine to me too. Thanks, Serguei On 5/2/17 16:23, Mandy Chung wrote: > Looks fine to me. > > Mandy > >> On May 2, 2017, at 12:40 PM, Kumar Srinivasan wrote: >> >> Hello, >> >> Please review changes to make jdk.jdi HTML5 friendly, >> table cell padding has not been addressed and will be fixed >> separately, this takes care of others. >> >> Note: Some of the errors were due to incorrect at throws but >> in all cases there is the correct one further down, please use >> sdiffs in these cases. >> >> @throws {@link InvalidTypeException} if any.... >> >> before:jdk.jdi {error=42, warning=1} >> after: jdk.jdi {error=1} >> >> http://cr.openjdk.java.net/~ksrini/8179538/webrev.00/index.html >> https://bugs.openjdk.java.net/browse/JDK-8179538 >> >> Thanks >> Kumar >> From huizhe.wang at oracle.com Wed May 3 00:34:42 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 2 May 2017 17:34:42 -0700 Subject: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism In-Reply-To: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> References: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> Message-ID: <4e69622b-2112-4fa3-6804-16bc6f52eeef@oracle.com> Hi Lance, In DriverManagerModuleTests, at line 83, did you mean to assign the result of DM::getDriver to d2 although an Exception is expected? Otherwise, the patch looks good to me. Best, Joe On 5/2/2017 11:33 AM, Lance Andersen wrote: > Hi all, > > The above issue adds a test to verify that a module based JDBC driver works via the service-provider loading mechanism. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Wed May 3 00:49:25 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 2 May 2017 20:49:25 -0400 Subject: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism In-Reply-To: <4e69622b-2112-4fa3-6804-16bc6f52eeef@oracle.com> References: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> <4e69622b-2112-4fa3-6804-16bc6f52eeef@oracle.com> Message-ID: <0067F614-0CF4-423D-AB3B-A7EB32A7977A@oracle.com> Hi Joe, > On May 2, 2017, at 8:34 PM, huizhe wang wrote: > > Hi Lance, > > In DriverManagerModuleTests, at line 83, did you mean to assign the result of DM::getDriver to d2 although an Exception is expected? I must have accidentally deleted that and never noticed it due to the SQLException being thrown. I will add it prior to pushing. > > Otherwise, the patch looks good to me. Thank you Best Lance > > Best, > Joe > > On 5/2/2017 11:33 AM, Lance Andersen wrote: >> Hi all, >> >> The above issue adds a test to verify that a module based JDBC driver works via the service-provider loading mechanism. >> >> The webrev can be found at http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html >> >> Best >> Lance >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From rick.hillegas at gmail.com Wed May 3 02:08:49 2017 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Tue, 2 May 2017 19:08:49 -0700 Subject: tutorial on using Cleaner-based finalization Message-ID: When I compile Apache Derby using JDK 9 build 167, I see several instances of the following warning: warning: [deprecation] finalize() in Object has been deprecated The javadoc for java.lang.Object.finalize() suggests that affected classes should migrate their finalization to a coding pattern based on the newly introduced java.lang.ref.Cleaner class. I am hesitant to try my hand at this without more guidance. Can you point me at a tutorial or list of best practices for implementing Cleaner-based finalization? Thanks, -Rick From amy.lu at oracle.com Wed May 3 04:18:47 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 3 May 2017 12:18:47 +0800 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> Message-ID: <4f9d8e7d-97e8-3a59-5aca-4c48dd0341a9@oracle.com> Thank you Pavel, Paul, Roger and Daniel for your reviewing. On 5/3/17 5:02 AM, Roger Riggs wrote: > But ": Must throw ClassCastException for parameter which is not > Comparable." > in Empty navigableMap is much more useful. > > And wrapping exceptions in exceptions makes debugging much harder, > because > it requires unwrapping the context and figuring out what the test was > trying to > do and which was the relevant source line. As the message and exception trace are all kept, it won't make debugging harder. For example for EmptyNavigableMap.java: No exception case: assertThrowsCCE( () -> {}, description + ": Must throw ClassCastException for parameter which is not Comparable."); The output: test EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", {}): failure java.lang.AssertionError: emptyNavigableMap().descendingMap().descendingMap(): Must throw ClassCastException for parameter which is not Comparable. Expected ClassCastException to be thrown, but nothing was thrown at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76) at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82) at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227) ... Caused by: java.lang.AssertionError: Expected ClassCastException to be thrown, but nothing was thrown at org.testng.Assert.expectThrows(Assert.java:1018) at org.testng.Assert.assertThrows(Assert.java:989) at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74) ... 17 more Wrong exception case: assertThrowsCCE( () -> { throw new NullPointerException(); }, description + ": Must throw ClassCastException for parameter which is not Comparable."); The output: test EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", {}): failure java.lang.AssertionError: emptyNavigableMap().descendingMap().descendingMap(): Must throw ClassCastException for parameter which is not Comparable. Expected ClassCastException to be thrown, but NullPointerException was thrown at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76) at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82) at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227) ... Caused by: java.lang.AssertionError: Expected ClassCastException to be thrown, but NullPointerException was thrown at org.testng.Assert.expectThrows(Assert.java:1013) at org.testng.Assert.assertThrows(Assert.java:989) at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74) ... 17 more > > I should probably try to file a bug against TestNG.assertThrows to add > a variant with > a message. Many/most of the TestNG asserts have variants with messages. Good point! > - java/util/Map/Defaults.java:167 The {}'s around the lambda value > are not necessary (like 166). I'll remove it when push. Thanks, Amy From amy.lu at oracle.com Wed May 3 04:19:32 2017 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 3 May 2017 12:19:32 +0800 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <636fd5fc-bf6b-bdd7-d2b6-195a8a74bcd3@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> <636fd5fc-bf6b-bdd7-d2b6-195a8a74bcd3@oracle.com> Message-ID: <73b96e4b-b59c-6934-5185-093bf4f68cc7@oracle.com> On 5/3/17 12:53 AM, Daniel Fuchs wrote: > Hi Amy, > > Looks good generally - there are a couple of cases where the > description that was passed to the AssertionError in the original > file is dropped (for instance > http://cr.openjdk.java.net/~amlu/8023897/webrev.00/test/java/util/Map/Defaults.java.frames.html) > > > Is that going to be an issue when analyzing test logs in case of > failure? IIRC testng prints the parameters passed to the test > method (which includes the description - so maybe that's OK). > > Is that why you decided to drop the description? I tried best to keep the useful message, EmptyNavigableMap EmptyNavigableSet are examples. For Map/Defaults.java, most cases' message are test's description and/or "should throw NPE", such information already in the output. For example: The old Defaults.java (modified), in case of failure of no exception thrown 162: assertThrows( 163: () -> { /* map.replaceAll(null); */ }, 164: NullPointerException.class, 165: description); The output: test Defaults.testReplaceAllNoNullReplacement("Collections.synchronizedMap(ConcurrentHashMap)", java.util.Collections$SynchronizedMap at 65162892): failure java.lang.AssertionError: Collections.synchronizedMap(ConcurrentHashMap) Failed to throw java.lang.NullPointerException expected [true] but found [false] at org.testng.Assert.fail(Assert.java:94) at org.testng.Assert.failNotEquals(Assert.java:496) at org.testng.Assert.assertTrue(Assert.java:42) at Defaults.assertInstance(Defaults.java:1010) at Defaults.assertThrows(Defaults.java:994) at Defaults.testReplaceAllNoNullReplacement(Defaults.java:162) The new Defaults.java changed this to: 166: assertThrowsNPE(() -> map.replaceAll(null)); [ change this to demo the failure of no exception: assertThrowsNPE(() -> {}); ] The output: test Defaults.testReplaceAllNoNullReplacement("*Collections.synchronizedMap(ConcurrentHashMap)*", java.util.Collections$SynchronizedMap at 15502cc3): failure java.lang.AssertionError: *Expected NullPointerException to be thrown, but nothing was thrown* at org.testng.Assert.expectThrows(Assert.java:1018) at org.testng.Assert.assertThrows(Assert.java:989) at Defaults.assertThrowsNPE(Defaults.java:972) at Defaults.testReplaceAllNoNullReplacement(Defaults.java:166) The only exception is for testReplaceAllNoNullReplacement, the message " should not allow replacement with null value" for case map.replaceAll((k,v) -> null) is dropped. I just think that it might not worth with extra function for just this one usage only. I?ll make this message as a one-line comment when push. Thanks, Amy > > best regards > > -- daniel > > On 02/05/2017 10:19, Amy Lu wrote: >> Please review this test-only change. >> >> Some java/util tests use a function executeAndCatch which essentially >> asserts that an exception is thrown, while some other tests use >> assertThrows for doing the same work. For both cases, with jtreg >> upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage >> TestNG Assert.assertThrows >> >> Please review the patch to update executeAndCatch and assertThrows to >> Assert.assertThrows for java/util testng tests. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8023897 >> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ >> >> Thanks, >> Amy >> > From peter.levart at gmail.com Wed May 3 08:33:51 2017 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 3 May 2017 10:33:51 +0200 Subject: Review Request: JDK-8020801: Apply the restriction of invoking MethodHandles.lookup to j.l.r.Method.invoke In-Reply-To: <9D028093-0C38-438A-9634-837718F87890@oracle.com> References: <29B7C781-3834-4603-95B3-8900644EDA71@oracle.com> <59f18652-cb90-bb90-e316-c0efb70fb173@gmail.com> <08f27f02-2585-9544-7b70-fb55d9062dc2@gmail.com> <9D028093-0C38-438A-9634-837718F87890@oracle.com> Message-ID: <2985685f-eabf-41ed-804f-2a2a7a71f9c5@gmail.com> Hi Mandy, On 05/02/2017 11:27 PM, Mandy Chung wrote: > Hi Peter, > > Looking at it again, you are right that no need to skip inflation. The > change > is simplified. I have verified with and without > -Dsun.reflect.noInflation=true. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8020801/webrev.01/ > Looks good. The following line is not needed now in ReflectionFactory (but is harmless): 182 boolean noInflation = ReflectionFactory.noInflation; Regards, Peter > > thanks > Mandy > >> On May 2, 2017, at 1:17 PM, Peter Levart > > wrote: >> >> >> On 05/02/2017 06:56 PM, Mandy Chung wrote: >>>> On May 2, 2017, at 3:14 AM, Peter Levart wrote: >>>> >>>> I don't quite understand the need for bypassing the inflation of native into generated method accessor >>> The VM native reflection implementation does not know about this alternate `reflected$XXX` mechanism. No VM change in this patch and so we ensure this be called via the generated bytecode for Method::invoke rather than going through the VM native reflection which reduces startup overhead. >> >> I don't think VM native reflection implementation needs to know >> anything about this alternate `reflected$XXX` mechanism. The >> NativeMethodAccessorImpl is constructed with the Method argument. In >> case of `reflected$XXX` mechanism, it is given the alternate Method >> object that points to the alternate method, so >> NativeMethodAccessorImpl.invoke0 is called with this alternate Method >> object. It is like reflecting over the alternate method itself, isn't it? >> >> Am I missing something? >> >>>> Is DelegatingMethodAccessorImpl/NativeMethodAccessorImpl combo not treated correctly (i.e. skipped) by the Reflection.getCallerClass(), while generated MethodAccessorImpl subclass is? >>> As this case is forced not to go through VM reflection support, unless I miss something, DelegatingMethodAccessorImpl/NativeMethodAccessorImpl has no need to be changed. I will double check with the VM runtime team. >> >> I was asking because I suspected that this might be the reason for >> skipping DelegatingMethodAccessorImpl/NativeMethodAccessorImpl. But >> if it is not the reason (and anyway it would be a bug because other >> @CallerSensitive methods would behave erratically if this was the >> case), then I still don't see a reason for skipping >> DelegatingMethodAccessorImpl/NativeMethodAccessorImpl and proceeding >> directly with generated method accessor. >> >> Regards, Peter >> >>> Mandy >>> >> > From daniel.fuchs at oracle.com Wed May 3 13:50:59 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 3 May 2017 14:50:59 +0100 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <73b96e4b-b59c-6934-5185-093bf4f68cc7@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> <636fd5fc-bf6b-bdd7-d2b6-195a8a74bcd3@oracle.com> <73b96e4b-b59c-6934-5185-093bf4f68cc7@oracle.com> Message-ID: <8e16abfc-6bb4-2117-aa5c-69334d071afc@oracle.com> On 03/05/2017 05:19, Amy Lu wrote: > On 5/3/17 12:53 AM, Daniel Fuchs wrote: >> Is that why you decided to drop the description? > > I tried best to keep the useful message, EmptyNavigableMap > EmptyNavigableSet are examples. For Map/Defaults.java, most cases' > message are test's description and/or "should throw NPE", such > information already in the output. > > > The only exception is for testReplaceAllNoNullReplacement, the message > " should not allow replacement with null value" > for case > map.replaceAll((k,v) -> null) > is dropped. I just think that it might not worth with extra function for > just this one usage only. > > I?ll make this message as a one-line comment when push. OK. When the messages are not informative I guess it's OK to drop them. Though as others have expressed it would be good to have an Assert.assertThrows methods that takes an additional string as argument! best regards, -- daniel > > Thanks, > Amy > >> >> best regards >> >> -- daniel >> >> On 02/05/2017 10:19, Amy Lu wrote: >>> Please review this test-only change. >>> >>> Some java/util tests use a function executeAndCatch which essentially >>> asserts that an exception is thrown, while some other tests use >>> assertThrows for doing the same work. For both cases, with jtreg >>> upgraded to testng 6.9.5 (CODETOOLS-7901639), test can then leverage >>> TestNG Assert.assertThrows >>> >>> Please review the patch to update executeAndCatch and assertThrows to >>> Assert.assertThrows for java/util testng tests. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8023897 >>> webrev: http://cr.openjdk.java.net/~amlu/8023897/webrev.00/ >>> >>> Thanks, >>> Amy >>> >> > From daniel.fuchs at oracle.com Wed May 3 14:05:59 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 3 May 2017 15:05:59 +0100 Subject: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism In-Reply-To: <0067F614-0CF4-423D-AB3B-A7EB32A7977A@oracle.com> References: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> <4e69622b-2112-4fa3-6804-16bc6f52eeef@oracle.com> <0067F614-0CF4-423D-AB3B-A7EB32A7977A@oracle.com> Message-ID: Hi Lance, Are you planning to use these modules in other tests? I'm asking because you're using the @library tag to compile them. If you want to encapsulate a module inside a test (without resorting to @library) then you can do so with the following layout and following @build line: /test/..../mytest/MyDriverTest.java /test/..../mytest/mymodule/module-info.java /test/..../mytest/mymodule/x/y/Z.java @build mymodule/x.y.Z MyDriverTest hope this helps, -- daniel On 03/05/2017 01:49, Lance Andersen wrote: > Hi Joe, > >> On May 2, 2017, at 8:34 PM, huizhe wang wrote: >> >> Hi Lance, >> >> In DriverManagerModuleTests, at line 83, did you mean to assign the result of DM::getDriver to d2 although an Exception is expected? > I must have accidentally deleted that and never noticed it due to the SQLException being thrown. > > I will add it prior to pushing. > >> >> Otherwise, the patch looks good to me. > > Thank you > > Best > Lance >> >> Best, >> Joe >> >> On 5/2/2017 11:33 AM, Lance Andersen wrote: >>> Hi all, >>> >>> The above issue adds a test to verify that a module based JDBC driver works via the service-provider loading mechanism. >>> >>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html >>> >>> Best >>> Lance >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> >> > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From Roger.Riggs at Oracle.com Wed May 3 14:58:02 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 3 May 2017 10:58:02 -0400 Subject: JDK 9 RFR of JDK-8023897: Replace/update/rename executeAndCatch in various tests to assertThrows In-Reply-To: <4f9d8e7d-97e8-3a59-5aca-4c48dd0341a9@oracle.com> References: <1420ada6-a8a2-fdd4-b22f-2f2e8a2ad583@oracle.com> <4378a604-62b5-0eb5-f137-b21fc7a5ba9f@Oracle.com> <4f9d8e7d-97e8-3a59-5aca-4c48dd0341a9@oracle.com> Message-ID: <0aee3b66-91e6-f2f5-474f-a26216f40f20@Oracle.com> Hi Amy, Ok, fine as is. My point was that there are now 2 exceptions in the log, one of which is an artifact of the test only to provide the message and useful information is spread across those two exceptions. There is no information lost but there is redundant information that has to be evaluated. Roger On 5/3/2017 12:18 AM, Amy Lu wrote: > Thank you Pavel, Paul, Roger and Daniel for your reviewing. > > On 5/3/17 5:02 AM, Roger Riggs wrote: >> But ": Must throw ClassCastException for parameter which is not >> Comparable." >> in Empty navigableMap is much more useful. >> >> And wrapping exceptions in exceptions makes debugging much harder, >> because >> it requires unwrapping the context and figuring out what the test was >> trying to >> do and which was the relevant source line. > > As the message and exception trace are all kept, it won't make > debugging harder. > > For example for EmptyNavigableMap.java: > > No exception case: > assertThrowsCCE( > () -> {}, > description + ": Must throw ClassCastException for > parameter which is not Comparable."); > > The output: > > test > EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", > {}): failure > java.lang.AssertionError: > emptyNavigableMap().descendingMap().descendingMap(): Must throw > ClassCastException for parameter which is not Comparable. > Expected ClassCastException to be thrown, but nothing was thrown > at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76) > at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82) > at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227) > ... > Caused by: java.lang.AssertionError: Expected ClassCastException to be > thrown, but nothing was thrown > at org.testng.Assert.expectThrows(Assert.java:1018) > at org.testng.Assert.assertThrows(Assert.java:989) > at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74) > ... 17 more > > Wrong exception case: > assertThrowsCCE( > () -> { > throw new NullPointerException(); > }, > description + ": Must throw ClassCastException for > parameter which is not Comparable."); > > The output: > > test > EmptyNavigableMap.testSubMap("emptyNavigableMap().descendingMap().descendingMap()", > {}): failure > java.lang.AssertionError: > emptyNavigableMap().descendingMap().descendingMap(): Must throw > ClassCastException for parameter which is not Comparable. > Expected ClassCastException to be thrown, but NullPointerException was > thrown > at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:76) > at EmptyNavigableMap.assertThrowsCCE(EmptyNavigableMap.java:82) > at EmptyNavigableMap.testSubMap(EmptyNavigableMap.java:227) > ... > Caused by: java.lang.AssertionError: Expected ClassCastException to be > thrown, but NullPointerException was thrown > at org.testng.Assert.expectThrows(Assert.java:1013) > at org.testng.Assert.assertThrows(Assert.java:989) > at EmptyNavigableMap.assertThrows(EmptyNavigableMap.java:74) > ... 17 more > > >> >> I should probably try to file a bug against TestNG.assertThrows to >> add a variant with >> a message. Many/most of the TestNG asserts have variants with messages. > > Good point! > >> - java/util/Map/Defaults.java:167 The {}'s around the lambda value >> are not necessary (like 166). > I'll remove it when push. > > Thanks, > Amy From Roger.Riggs at Oracle.com Wed May 3 16:04:25 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 3 May 2017 12:04:25 -0400 Subject: tutorial on using Cleaner-based finalization In-Reply-To: References: Message-ID: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> Hi Rick, The general nature of changes to use the Cleaner involve factoring out the cleanup code from the object being cleaned, though in many cases it does not require restructuring. For example, if an object holds a reference to a network socket that needs to be closed when the object is collected the socket.close() can called by the cleaner: Cleaner cleaner = ...; final Socket socket = ...; Object obj = ...; cleaner.register(obj, () -> { try { socket.close(); } catch (IOException ioe) { // ignore} }); Creating a cleaner starts a thread that does the work so you'll want to decide how to share it across the uses or to use than one. Using lambdas for the cleaner functions is very lightweight but be careful to avoid the using bound variables in the lambda body because they implicitly retain a reference to the enclosing instance which will prevent the instance from becoming unreferences. If there are more specific cases of interest let me know, Regards, Roger On 5/2/2017 10:08 PM, Rick Hillegas wrote: > When I compile Apache Derby using JDK 9 build 167, I see several > instances of the following warning: > > warning: [deprecation] finalize() in Object has been deprecated > > The javadoc for java.lang.Object.finalize() suggests that affected > classes should migrate their finalization to a coding pattern based on > the newly introduced java.lang.ref.Cleaner class. I am hesitant to try > my hand at this without more guidance. Can you point me at a tutorial > or list of best practices for implementing Cleaner-based finalization? > > Thanks, > -Rick From lance.andersen at oracle.com Wed May 3 16:28:11 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 3 May 2017 12:28:11 -0400 Subject: RFR: 8078267 - Add test to verify that a module based JDBC driver via the service-provider loading mechanism In-Reply-To: References: <43329D2F-4580-4445-ADD1-7040CF988CB6@oracle.com> <4e69622b-2112-4fa3-6804-16bc6f52eeef@oracle.com> <0067F614-0CF4-423D-AB3B-A7EB32A7977A@oracle.com> Message-ID: Hi Daniel, Thank you for the info. I do plan on adding some additional tests using these modules. I did run into some challenges with testng/jtreg/modules/TEST.properties that I am trying to sort out overall before I do that. Best Lance > On May 3, 2017, at 10:05 AM, Daniel Fuchs wrote: > > Hi Lance, > > Are you planning to use these modules in other tests? > I'm asking because you're using the @library tag to compile them. > If you want to encapsulate a module inside a test (without resorting > to @library) then you can do so with the following layout and > following @build line: > > /test/..../mytest/MyDriverTest.java > /test/..../mytest/mymodule/module-info.java > /test/..../mytest/mymodule/x/y/Z.java > > @build mymodule/x.y.Z MyDriverTest > > hope this helps, > > -- daniel > > On 03/05/2017 01:49, Lance Andersen wrote: >> Hi Joe, >> >>> On May 2, 2017, at 8:34 PM, huizhe wang wrote: >>> >>> Hi Lance, >>> >>> In DriverManagerModuleTests, at line 83, did you mean to assign the result of DM::getDriver to d2 although an Exception is expected? >> I must have accidentally deleted that and never noticed it due to the SQLException being thrown. >> >> I will add it prior to pushing. >> >>> >>> Otherwise, the patch looks good to me. >> >> Thank you >> >> Best >> Lance >>> >>> Best, >>> Joe >>> >>> On 5/2/2017 11:33 AM, Lance Andersen wrote: >>>> Hi all, >>>> >>>> The above issue adds a test to verify that a module based JDBC driver works via the service-provider loading mechanism. >>>> >>>> The webrev can be found at http://cr.openjdk.java.net/~lancea/8078267/webrev.00/index.html >>>> >>>> Best >>>> Lance >>>> >>>> >>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> >>> >> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From roman.grigoriadi at oracle.com Wed May 3 16:49:09 2017 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Wed, 3 May 2017 18:49:09 +0200 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> Message-ID: <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> Hi, you can find new web rev here: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ Previous review comments are addressed. > The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties There is: # for JDK integration - include version in source zip jaxb.jdk.version=2.3.0-b170412.1723 We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. Roman > On 12 Mar 2017, at 16:14, Alan Bateman wrote: > > > > On 12/03/2017 14:39, Roman Grigoriadi wrote: >> Hi, >> >> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >> > I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). > > In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. > > In MailcapCommandMap then the following doesn't seem right for the class description: > > 59 * (Where java.home is the value of the "java.home" System property > 60 * and conf is the directory named "conf" if it exists, > 61 * otherwise the directory named "lib"; the "conf" directory was > 62 * introduced in JDK 1.9.) > > It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. > > I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. > > The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. > > -Alan From bill.shannon at oracle.com Wed May 3 18:20:34 2017 From: bill.shannon at oracle.com (Bill Shannon) Date: Wed, 3 May 2017 11:20:34 -0700 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> Message-ID: Shouldn't the version information be in the manifest for the jar file containing the classes, accessed via java.lang.Package? Roman Grigoriadi wrote on 05/ 3/17 09:49 AM: > Hi, > > you can find new web rev here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > > > Previous review comments are addressed. > >> The change to version.properties reminds me to ask if there is anything in >> the jaxws repo to indicate the version of the JAX-* components? It's often >> difficult to determine what bits are in the JDK vs. the upstream project. > > Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we > are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example > in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties > There is: > # for JDK integration - include version in source zip > jaxb.jdk.version=2.3.0-b170412.1723 > > We can add another version.properties file with versions of all JAX-* > components. We may also change version from 2.3.0-SNAPSHOT to something unique > like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. > > Roman > > >> On 12 Mar 2017, at 16:14, Alan Bateman > > wrote: >> >> >> >> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>> Hi, >>> >>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>> >>> >> I skimmed the changes and have a few comments (I'm sure Lance or someone else >> will do a more detailed review). >> >> In JAXBContext then "must be open to the java.xml.bind module" should be >> "must be open to at least the java.xml.bind module" so as to cover the case >> that the package is opened unconditionally or to java.xml.bind and other >> modules. In addition, include "at least" makes it consistent with other >> wording that we have agreed for other areas. >> >> In MailcapCommandMap then the following doesn't seem right for the class >> description: >> >> 59 * (Where java.home is the value of the "java.home" System property >> 60 * and conf is the directory named "conf" if it exists, >> 61 * otherwise the directory named "lib"; the "conf" directory was >> 62 * introduced in JDK 1.9.) >> >> It might be simpler to just have javadoc specify that it attepts to locate >> the `mailcap` file in the Java run-time image and then add an @implNote with >> the details as to where it looks for specific runtime releases. >> >> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's >> use in new code has been discouraged for many years and maybe this could >> start out using String.split rather than the legacy class. >> >> The change to version.properties reminds me to ask if there is anything in >> the jaxws repo to indicate the version of the JAX-* components? It's often >> difficult to determine what bits are in the JDK vs. the upstream project. >> >> -Alan > From lance.andersen at oracle.com Wed May 3 18:58:25 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 3 May 2017 14:58:25 -0400 Subject: RFR 8179566: Add additional jaxws messages to be translated Message-ID: Hi all, Please review the following resources properties file update for jaxws. See https://bugs.openjdk.java.net/browse/JDK-8179566 for more info Best Lance $ hg diff diff -r 1c610f1b4097 src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties Wed May 03 14:53:54 2017 -0400 @@ -0,0 +1,6 @@ +wrapperTask.needEndorsed=\ +You are running on JDK6 or newer which comes with JAX-WS {0} API, but this tool requires JAX-WS {1} or newer API. Use \ +the standard override mechanism. + +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ + Use the standard override mechanism to load JAX-WS 2.2 or newer API. \ No newline at end of file ljanders-mac:resources ljanders$ Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From deepak.ramana at anthem.com Wed May 3 13:31:45 2017 From: deepak.ramana at anthem.com (Ramana, Deepak) Date: Wed, 3 May 2017 13:31:45 +0000 Subject: AppCDS in OpenJDK? In-Reply-To: <5D75F30C-F991-41B1-AC7F-84B3CCEDB42A@oracle.com> References: <118d09d837d94cd6b7ab56fbad448b2c@DM2PR2801MB0143.056d.mgd.msft.net> <5D75F30C-F991-41B1-AC7F-84B3CCEDB42A@oracle.com> Message-ID: <9a156cb1c76c412eb3b36f2a2fe25881@DM2PR2801MB0143.056d.mgd.msft.net> Thanks Jiangli Regards, Deepak From: Jiangli Zhou [mailto:jiangli.zhou at oracle.com] Sent: Tuesday, May 02, 2017 5:50 PM To: Ramana, Deepak Cc: core-libs-dev at openjdk.java.net Subject: Re: AppCDS in OpenJDK? Hi Deepak, In JDK 8u40, AppCDS is an experimental (i.e can not be used in production) feature and is not available in OpenJDK. Following is related info from release notes for 8u40: * Application Class Data Sharing (AppCDS): * Application Class Data Sharing (AppCDS) extends CDS (see Class Data Sharing) to enable you to place classes from the standard extensions directories and the application class path in the shared archive. This is an experimental feature and not licensed for commercial use. See the -XX:+UseAppCDS option in the java launcher tool page. Regards, Jiangli On May 1, 2017, at 12:16 PM, Ramana, Deepak > wrote: Hello, I am not sure if this is the right forum to ask this question. Apologies in advance, if this is not the correct place. We want to use the AppCDS feature that is available in the commercial release of Java 8 update 40. Is this feature available in OpenJDK? If so, can we use this in production for commercial use ? Regards, Deepak CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or may otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachment thereto. CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information or may otherwise be protected by law. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message and any attachment thereto. From Alan.Bateman at oracle.com Wed May 3 20:35:51 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 3 May 2017 21:35:51 +0100 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: References: Message-ID: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> On 03/05/2017 19:58, Lance Andersen wrote: > + > +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ > + Use the standard override mechanism to load JAX-WS 2.2 or newer API. > \ No newline at end of file > "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? -Alan From mandy.chung at oracle.com Wed May 3 21:14:31 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 3 May 2017 14:14:31 -0700 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> Message-ID: <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> > On May 3, 2017, at 1:35 PM, Alan Bateman wrote: > > On 03/05/2017 19:58, Lance Andersen wrote: > >> + >> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ >> + Use the standard override mechanism to load JAX-WS 2.2 or newer API. >> \ No newline at end of file >> > "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? > Since this resource bundle is for JDK 9, it should say ?upgradeable module path? instead. But is this message intended for older release and is it ever used for JDK 9? Mandy From paul.sandoz at oracle.com Wed May 3 21:44:57 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 3 May 2017 14:44:57 -0700 Subject: RFR 8150681 Update JAR specification for multi-release jar files Message-ID: Hi, Please review an update to the JAR ?specification? (in the loose sense of the term): - first, it has been moved from a closed repository into the idk repository (same shared location as the recently introduced serialisation specification) and converted to markdown: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown/webrev/ (This also includes a new attribute Launcher-Agent-Class, a Jigsaw related change to better support Java agents.) For comparison, the HTML version online is here: http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html - second i have added sections on multi-release JAR files: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/ this is based against the first patch so the changes can be easily viewed. I expect some further editing of this specification to add further links to module related stuff and tidy up existing links to tools etc. Thanks, Paul. From jonathan.gibbons at oracle.com Wed May 3 22:06:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 15:06:47 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. Message-ID: <590A5477.9050602@oracle.com> This is a review request for two co-dependent fixes. JDK-8179592: Update tables in java.base to be HTML 5-friendly. JDK-8179479: Add new styles to enable HTML 5 tables In doc comments, some of the HTML 4.01 attributes for tables are no longer available in HTML 5, and CSS should be used instead. To this end, some updates have been made to the main/default stylesheet used by javadoc, to define two new CSS classes for tables. The new classes are: Just puts plain borders around each cell, with no background coloring.
Horizontal borders are not used between cells in the table body; instead, alternating backgrounds are used to help distinguish the separate rows. In addition, there is still the default
No borders. These styles are in the langtools webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ The changes to the doc comments in java.base are in the jdk webrev, here: http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ summary vs.
The ARIA recommendations are to use the summary attribute or tag ... but the summary attribute is no longer allowed in HTML 5. In general, the text that has been provided for a summary is not suitable for direct use as a caption. The temporary workaround is to use a caption that is not displayed. In time, the appropriate API owners should update the use of these undisplayed table captions, to modify the text of the caption and make the caption displayed (by removing style="display:none"). Doc comments were changed in files in the following packages: java.io java.lang java.lang.invoke java.lang.reflect java.math java.net java.nio.channels java.nio.charset java.nio.file java.nio.file.attribute java.nio.file.spi java.security java.security.cert java.text java.time.chrono java.time.format java.time.temporal java.util java.util.concurrent java.util.regex java.util.spi javax.net.ssl The intent is that the only changes in this webrev are to the HTML 5 markup. There should be no significant changes to the text in any doc comment. The decision to add the styles to the default stylesheet at this late stage in the release is not taken lightly, and is seen as a temporary measure. JDK-8177283 is a wishlist enhancement for updates to javadoc support of stylesheets, which includes the desire to move JDK-specific styles to a JDK-specific stylesheet. This review is primarily about continuing the ongoing effort to make our docs be HTML 5 compliant. I would prefer not to get into extended discussions about which style class to use for each table, and what the exact definition of the styleclasses should be at this time. But appropriate review feedback is obviously welcome. -- Jon From joe.darcy at oracle.com Wed May 3 22:47:16 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 03 May 2017 15:47:16 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: <590A5DF4.6000307@oracle.com> Hi Jon, The changes in the java.lang and java.math packages look fine. Cheers, -Joe On 5/3/2017 3:06 PM, Jonathan Gibbons wrote: > This is a review request for two co-dependent fixes. > > JDK-8179592: Update tables in java.base to be HTML 5-friendly. > JDK-8179479: Add new styles to enable HTML 5 tables > > In doc comments, some of the HTML 4.01 attributes for tables are no > longer available in HTML 5, and CSS should be used instead. > To this end, some updates have been made to the main/default > stylesheet used by javadoc, to define two new CSS classes for tables. > > The new classes are: > > Just puts plain borders around each cell, with no background > coloring. > >
> Horizontal borders are not used between cells in the table body; > instead, alternating backgrounds are used to help distinguish the > separate rows. > > In addition, there is still the default >
> No borders. > > These styles are in the langtools webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ > > The changes to the doc comments in java.base are in the jdk webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ > > summary vs.
> > The ARIA recommendations are to use the summary attribute or > tag ... but the summary attribute is no longer allowed in > HTML 5. In general, the text that has been provided for a summary is > not suitable for direct use as a caption. The temporary workaround is > to use a caption that is not displayed. In time, the appropriate API > owners should update the use of these undisplayed table captions, to > modify the text of the caption and make the caption displayed (by > removing style="display:none"). > > Doc comments were changed in files in the following packages: > > java.io > java.lang > java.lang.invoke > java.lang.reflect > java.math > java.net > java.nio.channels > java.nio.charset > java.nio.file > java.nio.file.attribute > java.nio.file.spi > java.security > java.security.cert > java.text > java.time.chrono > java.time.format > java.time.temporal > java.util > java.util.concurrent > java.util.regex > java.util.spi > javax.net.ssl > > The intent is that the only changes in this webrev are to the HTML 5 > markup. There should be no significant changes to the text in any doc > comment. > > The decision to add the styles to the default stylesheet at this late > stage in the release is not taken lightly, and is seen as a temporary > measure. JDK-8177283 is a wishlist enhancement for updates to javadoc > support of stylesheets, which includes the desire to move JDK-specific > styles to a JDK-specific stylesheet. > > This review is primarily about continuing the ongoing effort to make > our docs be HTML 5 compliant. I would prefer not to get into extended > discussions about which style class to use for each table, and what > the exact definition of the styleclasses should be at this time. But > appropriate review feedback is obviously welcome. > > -- Jon From martinrb at google.com Wed May 3 23:39:37 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 16:39:37 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: Thanks, Jon. For the Deque/Queue tables - * + *
I expected that we would modify these to
which rendered alright and is compliant (although "border" is a weird boolean) and makes the "border intent" clear to humans and to browsers. THIS IS JAVA, so I'd prefer more verbose meaningful names for these style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is suggestive of no borders at all. Can we have some guidance comments in stylesheet.css explaining when to use the different classes? From jonathan.gibbons at oracle.com Thu May 4 00:03:13 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 17:03:13 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> Message-ID: <590A6FC1.5030803@oracle.com> On 05/03/2017 04:39 PM, Martin Buchholz wrote: > Thanks, Jon. > > For the Deque/Queue tables > - *
> + *
> I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these > style classes ... hmmm ... class="contrasting_rows" ? To me, "plain" > is suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when > to use the different classes? > Martin, If you are specifically requesting that the tables in Deque/Queue use "
" then I will do as you request, but I note that the "plain" style does more than just `border="1"`. It adjusts the caption font and the margins above and below the table. Given that the JSR166 doc comments actually use the
tag reasonably, the presentation with the non-default font seemed "better". That being said, prior to doing this work, I did some analysis on the tables coming from doc comments. There are about 484 with 70 different variants of the opening tag. Therefore, there was a secondary goal to simplify the many different visual appearances created using inline styles. How strongly do you feel about the names? As I said at the end of the email, I would like to do a more complete cleanup of javadoc support for stylesheets in a subsequent release. This would involve separating the stylesheet for the HTML generated by the doclet from a stylesheet provided to accompany the doc comments, and would clean up the name space and write a moderately formal specification of the styles in those stylesheets. I can put some comments in the default stylesheet for the time being. -- Jon From martinrb at google.com Thu May 4 00:46:23 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 17:46:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A6FC1.5030803@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: Jon, I am happy for you to own the html5 style for the entire javadoc; consistency wins; my comments are only suggestions and I'm no html or css expert. On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: > > Thanks, Jon. > > For the Deque/Queue tables > > - *
> + *
> > I expected that we would modify these to >
> which rendered alright and is compliant (although "border" is a weird > boolean) and makes the "border intent" clear to humans and to browsers. > > THIS IS JAVA, so I'd prefer more verbose meaningful names for these style > classes ... hmmm ... class="contrasting_rows" ? To me, "plain" is > suggestive of no borders at all. > > Can we have some guidance comments in stylesheet.css explaining when to > use the different classes? > > > Martin, > > If you are specifically requesting that the tables in Deque/Queue use > "
" then I will do as you request, but I note that the > "plain" style does more than just `border="1"`. It adjusts the caption > font and the margins above and below the table. Given that the JSR166 doc > comments actually use the
tag reasonably, the presentation with > the non-default font seemed "better". > > That being said, prior to doing this work, I did some analysis on the > tables coming from doc comments. There are about 484 with 70 > different variants of the opening tag. Therefore, there was a > secondary goal to simplify the many different visual appearances created > using inline styles. > > How strongly do you feel about the names? As I said at the end of the > email, I would like to do a more complete cleanup of javadoc support for > stylesheets in a subsequent release. This would involve separating the > stylesheet for the HTML generated by the doclet from a stylesheet provided > to accompany the doc comments, and would clean up the name space and write > a moderately formal specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > From david.holmes at oracle.com Thu May 4 01:13:25 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 4 May 2017 11:13:25 +1000 Subject: jdk10/jdk10 is broken on 32-bit linux Message-ID: <1810b41c-28cd-1c00-4e07-939286428348@oracle.com> With the latest changes in jdk10/jdk10 we are seeing failures of all jtreg agentvm mode tests on 32-bit linux binaries due to socket connection failures. And also some OSX failures. This seems to be have been caused by: 8165437: Evaluate the use of gettimeofday in Networking code http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/7cdde79d6a46 due to a truncation issue through using long instead of jlong. I've notified net-dev and will file a P1 bug to either have this fixed or backed out. David ----- From jonathan.gibbons at oracle.com Thu May 4 01:16:35 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 May 2017 18:16:35 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> Message-ID: <590A80F3.6050904@oracle.com> With my javadoc-tool-developer hat on, I'd like to get out of the business of jdk-style-owner, or at least identify that as a distinct hat. :-) Kumar has identified a problem with the styles as currently defined ... you cannot easily embed a table with a default style inside a table with an explicit style ... which suggests the need for a third named style for "no borders". (And yes, we have nested tables in some places.). Although we disagree with your comment "THIS IS JAVA" (no it's not, it's HTML and CSS) the point is noted. How about the following names, with appropriate comments to come in the style sheet: 1.
it does what it says, but long term, I see this being deprecated in favor of other styles ... there are places where a style with no borders is in use now, but when you add in captions, some amount of bordering would be better. 2.
simple collapsed borders around each cell 3.
previously called altrows. How about longer names, specific to tables, like "borderless-table", "plain-table", "striped-table"? That would make it easier to have named styles for other constructs, although we will need to keep a balance between a proliferation of named styles and too much inline style. All of this would be so much better with sufficient definitions for all the styles used by javadoc to allow adventurous and creative folk to use modified stylesheets for their own API. But not this week. By the way, I forgot to mention in my original email, there is a copy of the API docs showing the proposed changes, available here: http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java.base-summary.html -- Jon On 05/03/2017 05:46 PM, Martin Buchholz wrote: > Jon, I am happy for you to own the html5 style for the entire javadoc; > consistency wins; my comments are only suggestions and I'm no html or > css expert. > > On Wed, May 3, 2017 at 5:03 PM, Jonathan Gibbons > > wrote: > > > > On 05/03/2017 04:39 PM, Martin Buchholz wrote: >> Thanks, Jon. >> >> For the Deque/Queue tables >> - *
>> + *
>> I expected that we would modify these to >>
>> which rendered alright and is compliant (although "border" is a >> weird boolean) and makes the "border intent" clear to humans and >> to browsers. >> >> THIS IS JAVA, so I'd prefer more verbose meaningful names for >> these style classes ... hmmm ... class="contrasting_rows" ? To >> me, "plain" is suggestive of no borders at all. >> >> Can we have some guidance comments in stylesheet.css explaining >> when to use the different classes? >> > > Martin, > > If you are specifically requesting that the tables in Deque/Queue > use "
" then I will do as you request, but I note > that the "plain" style does more than just `border="1"`. It > adjusts the caption font and the margins above and below the > table. Given that the JSR166 doc comments actually use the >
tag reasonably, the presentation with the non-default > font seemed "better". > > That being said, prior to doing this work, I did some analysis on > the tables coming from doc comments. There are about 484 > with 70 different variants of the opening tag. Therefore, > there was a secondary goal to simplify the many different visual > appearances created using inline styles. > > How strongly do you feel about the names? As I said at the end of > the email, I would like to do a more complete cleanup of javadoc > support for stylesheets in a subsequent release. This would > involve separating the stylesheet for the HTML generated by the > doclet from a stylesheet provided to accompany the doc comments, > and would clean up the name space and write a moderately formal > specification of the styles in those stylesheets. > > I can put some comments in the default stylesheet for the time being. > > -- Jon > > From rick.hillegas at gmail.com Thu May 4 02:21:00 2017 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Wed, 3 May 2017 19:21:00 -0700 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> Message-ID: Thanks, Roger. That is a helpful example. Derby is a component which can be quiesced and unloaded on resource-constrained platforms, then re-loaded when resources free up. Unloading means garbage collecting all the classloaders created by the component so that, at the end, not a single scrap of Derby code remains loaded. Has the Cleaner pattern been tested under these kinds of conditions? Can you point me at a Cleaner-based library which successfully unloads and reloads itself without leaking classloaders? Thanks, -Rick On 5/3/17 9:04 AM, Roger Riggs wrote: > Hi Rick, > > The general nature of changes to use the Cleaner involve factoring out > the cleanup > code from the object being cleaned, though in many cases it does not > require restructuring. > For example, if an object holds a reference to a network socket that > needs to be closed > when the object is collected the socket.close() can called by the > cleaner: > > Cleaner cleaner = ...; > final Socket socket = ...; > Object obj = ...; > > cleaner.register(obj, () -> { > try { > socket.close(); > } catch (IOException ioe) { // ignore} > }); > > > Creating a cleaner starts a thread that does the work so you'll want > to decide > how to share it across the uses or to use than one. > > Using lambdas for the cleaner functions is very lightweight but be > careful to avoid > the using bound variables in the lambda body because they implicitly > retain > a reference to the enclosing instance which will prevent the instance > from becoming unreferences. > > If there are more specific cases of interest let me know, > > Regards, Roger > > > On 5/2/2017 10:08 PM, Rick Hillegas wrote: >> When I compile Apache Derby using JDK 9 build 167, I see several >> instances of the following warning: >> >> warning: [deprecation] finalize() in Object has been deprecated >> >> The javadoc for java.lang.Object.finalize() suggests that affected >> classes should migrate their finalization to a coding pattern based >> on the newly introduced java.lang.ref.Cleaner class. I am hesitant to >> try my hand at this without more guidance. Can you point me at a >> tutorial or list of best practices for implementing Cleaner-based >> finalization? >> >> Thanks, >> -Rick > > From li.jiang at oracle.com Thu May 4 02:24:46 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 4 May 2017 10:24:46 +0800 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> Message-ID: <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> === Copy from David's email That endorsed part is problem. It is valid in JDK-8 but not in 9. Following message is my proposed solution. It would fit JDK-8 and 9. JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 API. Use the standard override mechanism to load JAX-WS 2.2 API Do you think that this solution is OK? === Thanks, Leo On 05/04/2017 05:14 AM, Mandy Chung wrote: > >> On May 3, 2017, at 1:35 PM, Alan Bateman wrote: >> >> On 03/05/2017 19:58, Lance Andersen wrote: >> >>> + >>> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ >>> + Use the standard override mechanism to load JAX-WS 2.2 or newer API. >>> \ No newline at end of file >>> >> "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? >> > > Since this resource bundle is for JDK 9, it should say ?upgradeable module path? instead. But is this message intended for older release and is it ever used for JDK 9? > > Mandy > From felix.yang at oracle.com Thu May 4 02:36:42 2017 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 4 May 2017 10:36:42 +0800 Subject: RFR 8178912, Throw away sample tests Message-ID: <1b4863b5-d565-6fa1-261e-5a297c98ba8f@oracle.com> Hi there, please review following change to remove tests for several samples, which have been removed in "JEP 298: Remove Demos and Samples". Webrev: http://cr.openjdk.java.net/~xiaofeya/8178912/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8178912 Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8164813 Thanks, Felix From martinrb at google.com Thu May 4 02:49:29 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 3 May 2017 19:49:29 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A80F3.6050904@oracle.com> References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: Jonathan Gibbons for "css style czar"! --- I checked the tables at http://cr.openjdk.java.net/~jjg/8179479-8179592/api/java/util/concurrent/BlockingDeque.html They look perfectly fine, although I feel a twinge of non-collapsed-border-nostalgia. --- Yes, "striped" is a much better name than "altrows". "striped-tables" as you suggest may be better. Choose your names carefully - we can't change them in the future. --- w3.org doc seems to suggest we should only be defining table styles with borders. https://www.w3.org/TR/html5/tabular-data.html#attr-table-border """Tables should not be used as layout aids. """ """User agents, especially those that do table analysis on arbitrary content, are encouraged to find heuristics to determine which tables actually contain data and which are merely being used for layout. """ From peter.levart at gmail.com Thu May 4 06:16:26 2017 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 4 May 2017 08:16:26 +0200 Subject: tutorial on using Cleaner-based finalization In-Reply-To: References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> Message-ID: <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> Hi Rick, Allow me to join the discussion... On 05/04/2017 04:21 AM, Rick Hillegas wrote: > Thanks, Roger. That is a helpful example. > > Derby is a component which can be quiesced and unloaded on > resource-constrained platforms, then re-loaded when resources free up. > Unloading means garbage collecting all the classloaders created by the > component so that, at the end, not a single scrap of Derby code > remains loaded. Has the Cleaner pattern been tested under these kinds > of conditions? Can you point me at a Cleaner-based library which > successfully unloads and reloads itself without leaking classloaders? Can you point me to a place in Derby code where you are currently using finalize() method for your purpose and I'll try to show you how to convert this to Cleaner API... I'm surprised that you actually need finalize() in Derby. Isn't this pure Java code? Usually finalize() is needed in situations where there's some non-Java resource which has to be cleaned-up when all the references to some Java object that represents it are gone. I'm curious what you need to clean in a pure Java library. Regards, Peter > > Thanks, > -Rick > > > On 5/3/17 9:04 AM, Roger Riggs wrote: >> Hi Rick, >> >> The general nature of changes to use the Cleaner involve factoring >> out the cleanup >> code from the object being cleaned, though in many cases it does not >> require restructuring. >> For example, if an object holds a reference to a network socket that >> needs to be closed >> when the object is collected the socket.close() can called by the >> cleaner: >> >> Cleaner cleaner = ...; >> final Socket socket = ...; >> Object obj = ...; >> >> cleaner.register(obj, () -> { >> try { >> socket.close(); >> } catch (IOException ioe) { // ignore} >> }); >> >> >> Creating a cleaner starts a thread that does the work so you'll want >> to decide >> how to share it across the uses or to use than one. >> >> Using lambdas for the cleaner functions is very lightweight but be >> careful to avoid >> the using bound variables in the lambda body because they implicitly >> retain >> a reference to the enclosing instance which will prevent the instance >> from becoming unreferences. >> >> If there are more specific cases of interest let me know, >> >> Regards, Roger >> >> >> On 5/2/2017 10:08 PM, Rick Hillegas wrote: >>> When I compile Apache Derby using JDK 9 build 167, I see several >>> instances of the following warning: >>> >>> warning: [deprecation] finalize() in Object has been deprecated >>> >>> The javadoc for java.lang.Object.finalize() suggests that affected >>> classes should migrate their finalization to a coding pattern based >>> on the newly introduced java.lang.ref.Cleaner class. I am hesitant >>> to try my hand at this without more guidance. Can you point me at a >>> tutorial or list of best practices for implementing Cleaner-based >>> finalization? >>> >>> Thanks, >>> -Rick >> >> > From dalibor.topic at oracle.com Thu May 4 11:23:52 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 4 May 2017 13:23:52 +0200 Subject: AppCDS in OpenJDK? In-Reply-To: <9a156cb1c76c412eb3b36f2a2fe25881@DM2PR2801MB0143.056d.mgd.msft.net> References: <118d09d837d94cd6b7ab56fbad448b2c@DM2PR2801MB0143.056d.mgd.msft.net> <5D75F30C-F991-41B1-AC7F-84B3CCEDB42A@oracle.com> <9a156cb1c76c412eb3b36f2a2fe25881@DM2PR2801MB0143.056d.mgd.msft.net> Message-ID: <8506cc01-e617-0a02-c623-6c92f2982ac3@oracle.com> To provide a more general answer: No commercial features are available in OpenJDK. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu May 4 11:35:55 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 4 May 2017 13:35:55 +0200 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> Message-ID: <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> On 02.05.2017 18:46, Jeremy Manson wrote: > People > are using Xbootclasspath for a variety of things. It's worth keeping in mind when using such options that "Non-standard options are general purpose options that are specific to the Java HotSpot Virtual Machine, so they are not guaranteed to be supported by all JVM implementations, and are subject to change. These options start with -X." http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html#BABHDABI cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Thu May 4 14:20:13 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 4 May 2017 10:20:13 -0400 Subject: tutorial on using Cleaner-based finalization In-Reply-To: References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> Message-ID: <66d8ad46-f6b2-4d36-0833-77c2bddc8ed7@Oracle.com> Hi Rick, On 5/3/2017 10:21 PM, Rick Hillegas wrote: > Thanks, Roger. That is a helpful example. > > Derby is a component which can be quiesced and unloaded on > resource-constrained platforms, then re-loaded when resources free up. > Unloading means garbage collecting all the classloaders created by the > component so that, at the end, not a single scrap of Derby code > remains loaded. Has the Cleaner pattern been tested under these kinds > of conditions? Can you point me at a Cleaner-based library which > successfully unloads and reloads itself without leaking classloaders? The Cleaner thread will terminate when all of the cleaning actions have been cancelled or completed so it should not interfere with your goal of completely being unloaded. (Peter provided the design and implementation.) It will not retain any references to any object that is otherwise unreferenced. The Cleaner is new enough (9 is not yet GA'd) that I don't know of any library using it. My example using sockets may be a bit misleading, since sockets will be closed when otherwise unreferenced (as are files). That was an example of placeholder for some kind of connection related state that needed to be cleaned up when the referencing object is unreferenced. As Peter inquired, I would suggest investigating whether completely removing the finalization can have the desired effect. A server connection terminating unexpectedly would I think cause any server side transaction to cleanup as appropriate for the connection; and that's server side behavior. Note also a difference between the finalize case and Cleaner. In the finalize case, there may be an entire graph of unreachable instances that are finalized together. The subgraph is unreachable from live roots but still has references between the disconnected graph objects. By contrast, the Cleaner is based on an object being unreachable and the object doing the cleaning is still reachable (perhaps only via the Cleaner mechanism). So the cleanup proceeds in layers with unreachable instances being reclaimed first and the cleanup instances being reclaimed, after they are invoked, in a subsequent cycle. Regards, Roger > > Thanks, > -Rick > > > On 5/3/17 9:04 AM, Roger Riggs wrote: >> Hi Rick, >> >> The general nature of changes to use the Cleaner involve factoring >> out the cleanup >> code from the object being cleaned, though in many cases it does not >> require restructuring. >> For example, if an object holds a reference to a network socket that >> needs to be closed >> when the object is collected the socket.close() can called by the >> cleaner: >> >> Cleaner cleaner = ...; >> final Socket socket = ...; >> Object obj = ...; >> >> cleaner.register(obj, () -> { >> try { >> socket.close(); >> } catch (IOException ioe) { // ignore} >> }); >> >> >> Creating a cleaner starts a thread that does the work so you'll want >> to decide >> how to share it across the uses or to use than one. >> >> Using lambdas for the cleaner functions is very lightweight but be >> careful to avoid >> the using bound variables in the lambda body because they implicitly >> retain >> a reference to the enclosing instance which will prevent the instance >> from becoming unreferences. >> >> If there are more specific cases of interest let me know, >> >> Regards, Roger >> >> >> On 5/2/2017 10:08 PM, Rick Hillegas wrote: >>> When I compile Apache Derby using JDK 9 build 167, I see several >>> instances of the following warning: >>> >>> warning: [deprecation] finalize() in Object has been deprecated >>> >>> The javadoc for java.lang.Object.finalize() suggests that affected >>> classes should migrate their finalization to a coding pattern based >>> on the newly introduced java.lang.ref.Cleaner class. I am hesitant >>> to try my hand at this without more guidance. Can you point me at a >>> tutorial or list of best practices for implementing Cleaner-based >>> finalization? >>> >>> Thanks, >>> -Rick >> >> > From sean.mullan at oracle.com Thu May 4 14:28:09 2017 From: sean.mullan at oracle.com (Sean Mullan) Date: Thu, 4 May 2017 10:28:09 -0400 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: Message-ID: Couple of typos on a quick review: 55: s/the the/the/ 129-130: s/the exactly/exactly the/ 144: fukes -> files? --Sean On 5/3/17 5:44 PM, Paul Sandoz wrote: > Hi, > > Please review an update to the JAR ?specification? (in the loose sense of the term): > > - first, it has been moved from a closed repository into the idk repository (same shared location as the recently introduced serialisation specification) and converted to markdown: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown/webrev/ > > (This also includes a new attribute Launcher-Agent-Class, a Jigsaw related change to better support Java agents.) > > For comparison, the HTML version online is here: > > http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html > > - second i have added sections on multi-release JAR files: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/ > > this is based against the first patch so the changes can be easily viewed. > > > I expect some further editing of this specification to add further links to module related stuff and tidy up existing links to tools etc. > > Thanks, > Paul. > > From li.jiang at oracle.com Thu May 4 15:09:31 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 4 May 2017 23:09:31 +0800 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> Message-ID: Hi Mandy, Alan, Would you help to correct the messages ? We need to push this file into repo before May 5th to catch the JDK9 msg drop schedule. Otherwise I have to kick off the message drop without this jaxws update. Thanks, Leo On 05/04/2017 10:24 AM, Leo Jiang wrote: > === Copy from David's email > That endorsed part is problem. It is valid in JDK-8 but not in 9. Following message is my proposed solution. It would > fit JDK-8 and 9. > JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 API. Use the standard override mechanism to > load JAX-WS 2.2 API > > Do you think that this solution is OK? > === > > Thanks, > Leo > > > On 05/04/2017 05:14 AM, Mandy Chung wrote: >> >>> On May 3, 2017, at 1:35 PM, Alan Bateman wrote: >>> >>> On 03/05/2017 19:58, Lance Andersen wrote: >>> >>>> + >>>> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires >>>> JAX-WS 2.2 or newer API. \ >>>> + Use the standard override mechanism to load JAX-WS 2.2 or newer API. >>>> \ No newline at end of file >>>> >>> "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In >>> any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? >>> >> >> Since this resource bundle is for JDK 9, it should say ?upgradeable module path? instead. But is this message intended >> for older release and is it ever used for JDK 9? >> >> Mandy >> From jonathan.gibbons at oracle.com Thu May 4 15:16:21 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:16:21 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: On 5/3/17 7:49 PM, Martin Buchholz wrote: > > w3.org doc seems to suggest we should only be defining > table styles with borders. > > https://www.w3.org/TR/html5/tabular-data.html#attr-table-border > > """Tables should not be used as layout aids. """ > > """User agents, especially those that do table analysis on arbitrary > content, are encouraged to find heuristics to determine which tables > actually contain data and which are merely being used for layout. """ Understood. The patch as provided already changes some tables with `summary="layout"` into definition lists. There are additional candidates that would be candidates for such a change at some point. -- Jon From mandy.chung at oracle.com Thu May 4 15:21:53 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 May 2017 08:21:53 -0700 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> Message-ID: <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> The JAX-WS in JDK 9 is going to be 2.3.0 [1]. java.xml.ws is not resolved by default. JAX-WS 2.1 API can only be loaded to the runtime from class path if java.xml.ws is not resolved. The JAX-WS runtime in JDK 9 will not be loaded in this case. If this message is specific for this scenario, this message is okay to keep it and would be good to add a comment saying ?this message should not be loaded from JDK 9 runtime" Roman has to confirm whether this message will not be used when running in JDK 9. Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047426.html > On May 3, 2017, at 7:24 PM, Leo Jiang wrote: > > === Copy from David's email > That endorsed part is problem. It is valid in JDK-8 but not in 9. Following message is my proposed solution. It would fit JDK-8 and 9. > JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 API. Use the standard override mechanism to load JAX-WS 2.2 API > > Do you think that this solution is OK? > === > > Thanks, > Leo > > > On 05/04/2017 05:14 AM, Mandy Chung wrote: >> >>> On May 3, 2017, at 1:35 PM, Alan Bateman wrote: >>> >>> On 03/05/2017 19:58, Lance Andersen wrote: >>> >>>> + >>>> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ >>>> + Use the standard override mechanism to load JAX-WS 2.2 or newer API. >>>> \ No newline at end of file >>>> >>> "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? >>> >> >> Since this resource bundle is for JDK 9, it should say ?upgradeable module path? instead. But is this message intended for older release and is it ever used for JDK 9? >> >> Mandy >> From jonathan.gibbons at oracle.com Thu May 4 15:27:23 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 4 May 2017 08:27:23 -0700 Subject: RFR: Update tables in java.base to be HTML5-friendly. In-Reply-To: References: <590A5477.9050602@oracle.com> <590A6FC1.5030803@oracle.com> <590A80F3.6050904@oracle.com> Message-ID: <307d0c82-5358-5a2e-88a4-344a9f591c21@oracle.com> On 5/3/17 7:49 PM, Martin Buchholz wrote: > > --- > > Yes, "striped" is a much better name than "altrows". "striped-tables" > as you suggest may be better. Choose your names carefully - we can't > change them in the future. > > --- Well, we can, ... but ... A goal of creating specification(s) for the stylesheet(s) provided by javadoc, for the doclet-generated output, and for the doc-comment content, is that the specification(s) should be subject to specification review[1], and not just an impl detail of the javadool tool and/or build system. -- Jon [1] http://mail.openjdk.java.net/pipermail/csr-discuss/2017-April/thread.html From mandy.chung at oracle.com Thu May 4 15:32:50 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 May 2017 08:32:50 -0700 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> Message-ID: <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> > On May 3, 2017, at 11:16 PM, Peter Levart wrote: > > Hi Rick, > > Allow me to join the discussion... > > On 05/04/2017 04:21 AM, Rick Hillegas wrote: >> Thanks, Roger. That is a helpful example. >> >> Derby is a component which can be quiesced and unloaded on resource-constrained platforms, then re-loaded when resources free up. Unloading means garbage collecting all the classloaders created by the component so that, at the end, not a single scrap of Derby code remains loaded. Has the Cleaner pattern been tested under these kinds of conditions? Can you point me at a Cleaner-based library which successfully unloads and reloads itself without leaking classloaders? > > Can you point me to a place in Derby code where you are currently using finalize() method for your purpose and I'll try to show you how to convert this to Cleaner API... > > I'm surprised that you actually need finalize() in Derby. Isn't this pure Java code? Usually finalize() is needed in situations where there's some non-Java resource which has to be cleaned-up when all the references to some Java object that represents it are gone. I'm curious what you need to clean in a pure Java library. Please include me for the pointer to Derby code too. This can be used serving as examples to migrate away from use of finalizers. We also hope to do that in JDK to set up more examples. Mandy From li.jiang at oracle.com Thu May 4 15:34:13 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 4 May 2017 23:34:13 +0800 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> Message-ID: <2c4ee864-7491-617e-5d83-7a52117e3b17@oracle.com> Got it, thank you Mandy! I will wait this update into repo until May 5th 11:30pm (Beijing). Thanks, Leo On 05/04/2017 11:21 PM, Mandy Chung wrote: > The JAX-WS in JDK 9 is going to be 2.3.0 [1]. java.xml.ws is not resolved by default. JAX-WS 2.1 API can only be loaded to the runtime from class path if java.xml.ws is not resolved. The JAX-WS runtime in JDK 9 will not be loaded in this case. If this message is specific for this scenario, this message is okay to keep it and would be good to add a comment saying ?this message should not be loaded from JDK 9 runtime" > > Roman has to confirm whether this message will not be used when running in JDK 9. > > Mandy > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047426.html > > >> On May 3, 2017, at 7:24 PM, Leo Jiang wrote: >> >> === Copy from David's email >> That endorsed part is problem. It is valid in JDK-8 but not in 9. Following message is my proposed solution. It would fit JDK-8 and 9. >> JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 API. Use the standard override mechanism to load JAX-WS 2.2 API >> >> Do you think that this solution is OK? >> === >> >> Thanks, >> Leo >> >> >> On 05/04/2017 05:14 AM, Mandy Chung wrote: >>> >>>> On May 3, 2017, at 1:35 PM, Alan Bateman wrote: >>>> >>>> On 03/05/2017 19:58, Lance Andersen wrote: >>>> >>>>> + >>>>> +runtime.modeler.addressing.responses.nosuchmethod = JAX-WS 2.1 API is loaded from {0}, But JAX-WS runtime requires JAX-WS 2.2 or newer API. \ >>>>> + Use the standard override mechanism to load JAX-WS 2.2 or newer API. >>>>> \ No newline at end of file >>>>> >>>> "Use the standard override mechanism". I wonder if this meant to say the "endorsed standards override mechanism". In any case, it feels like a message for when JAX-WS is running on an older release. Do you know if that is true? >>>> >>> >>> Since this resource bundle is for JDK 9, it should say ?upgradeable module path? instead. But is this message intended for older release and is it ever used for JDK 9? >>> >>> Mandy >>> > From Alan.Bateman at oracle.com Thu May 4 15:41:28 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 May 2017 16:41:28 +0100 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: Message-ID: On 03/05/2017 22:44, Paul Sandoz wrote: > Hi, > > Please review an update to the JAR ?specification? (in the loose sense of the term): > > - first, it has been moved from a closed repository into the idk repository (same shared location as the recently introduced serialisation specification) and converted to markdown: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown/webrev/ > > (This also includes a new attribute Launcher-Agent-Class, a Jigsaw related change to better support Java agents.) > > For comparison, the HTML version online is here: > > http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html > > - second i have added sections on multi-release JAR files: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/ > > this is based against the first patch so the changes can be easily viewed. > > > I expect some further editing of this specification to add further links to module related stuff and tidy up existing links to tools etc. > I read through the changes. Modular JAR files section: "directly under the root" - somewhat subjective but I think "in the top-level directory" as we had in the original text is clearer here. "in accordance with it's module descriptor" looks unusual and I think would be better to keep the original sentence. L70 - I assume "explicitly modular or automatic" should be removed as this is JAR files on the class path. Modular multi-release JAR files section: As with the Modular JAR file section, I think "in the top-level directory" would be clearer. L155-158 - "A non-exported public or protected class ...". It might be clearer to say a public or protected class in a non-exported package. L171 - I think there is a typo here and it means non-transitive requires. Typo at L219: "This directory containers underneath" Otherwise looks good to me. -Alan From roman.grigoriadi at oracle.com Thu May 4 15:50:13 2017 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Thu, 4 May 2017 17:50:13 +0200 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> Message-ID: <91859F9C-C1DC-4C3D-8DFB-45A75FCA3159@oracle.com> > On 4 May 2017, at 17:21, Mandy Chung wrote: > > The JAX-WS in JDK 9 is going to be 2.3.0 [1]. java.xml.ws is not resolved by default. JAX-WS 2.1 API can only be loaded to the runtime from class path if java.xml.ws is not resolved. The JAX-WS runtime in JDK 9 will not be loaded in this case. If this message is specific for this scenario, this message is okay to keep it and would be good to add a comment saying ?this message should not be loaded from JDK 9 runtime" Yes I think, it is OK to keep untranslated. According to comments in code it looks like this may happen if JAXWS-RI 2.2 is loaded together with JAXWS-API 2.1. Which in turn could only happen if java.xml.ws module is not resolved in and both are loaded from classpath. Adding Lukas. Roman From roman.grigoriadi at oracle.com Thu May 4 16:16:32 2017 From: roman.grigoriadi at oracle.com (Roman Grigoriadi) Date: Thu, 4 May 2017 18:16:32 +0200 Subject: RFR 8179566: Add additional jaxws messages to be translated In-Reply-To: <91859F9C-C1DC-4C3D-8DFB-45A75FCA3159@oracle.com> References: <89179021-f56e-c0a7-d096-011cf3621f99@oracle.com> <0E9CEAB5-E0BD-4DB1-990C-E592BB44C4BE@oracle.com> <3651721a-9d17-2328-5587-d4b856ff0068@oracle.com> <84BF4CC5-4E3C-4157-ACA4-9C300939D616@oracle.com> <91859F9C-C1DC-4C3D-8DFB-45A75FCA3159@oracle.com> Message-ID: <5D1E84A7-D10F-42A4-9529-9C58794C3E13@oracle.com> > On 4 May 2017, at 17:50, Roman Grigoriadi wrote: > > >> On 4 May 2017, at 17:21, Mandy Chung > wrote: >> >> The JAX-WS in JDK 9 is going to be 2.3.0 [1]. java.xml.ws is not resolved by default. JAX-WS 2.1 API can only be loaded to the runtime from class path if java.xml.ws is not resolved. The JAX-WS runtime in JDK 9 will not be loaded in this case. If this message is specific for this scenario, this message is okay to keep it and would be good to add a comment saying ?this message should not be loaded from JDK 9 runtime" > > Yes I think, it is OK to keep untranslated. According to comments in code it looks like this may happen if JAXWS-RI 2.2 is loaded together with JAXWS-API 2.1. Which in turn could only happen if java.xml.ws module is not resolved in and both are loaded from classpath. > > Adding Lukas. Lukas, can you please confirm? The message in question is ?runtime.modeler.addressing.responses.nosuchmethod? in modeler.properties / generated ModelerMessages.java. > > Roman From lance.andersen at oracle.com Thu May 4 16:48:26 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 4 May 2017 12:48:26 -0400 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> Message-ID: <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> > On May 4, 2017, at 11:32 AM, Mandy Chung wrote: > > >> On May 3, 2017, at 11:16 PM, Peter Levart wrote: >> >> Hi Rick, >> >> Allow me to join the discussion... >> >> On 05/04/2017 04:21 AM, Rick Hillegas wrote: >>> Thanks, Roger. That is a helpful example. >>> >>> Derby is a component which can be quiesced and unloaded on resource-constrained platforms, then re-loaded when resources free up. Unloading means garbage collecting all the classloaders created by the component so that, at the end, not a single scrap of Derby code remains loaded. Has the Cleaner pattern been tested under these kinds of conditions? Can you point me at a Cleaner-based library which successfully unloads and reloads itself without leaking classloaders? >> >> Can you point me to a place in Derby code where you are currently using finalize() method for your purpose and I'll try to show you how to convert this to Cleaner API... >> >> I'm surprised that you actually need finalize() in Derby. Isn't this pure Java code? Usually finalize() is needed in situations where there's some non-Java resource which has to be cleaned-up when all the references to some Java object that represents it are gone. I'm curious what you need to clean in a pure Java library. > > Please include me for the pointer to Derby code too. This can be used serving as examples to migrate away from use of finalizers. We also hope to do that in JDK to set up more examples. Here are a few examples I believe: http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu May 4 17:40:02 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 4 May 2017 13:40:02 -0400 Subject: RFR 8179634: Add JDBC 4.2 to bullet list in package.html Message-ID: <2BB7CB73-7058-463C-862A-9EAD8E5D2E06@oracle.com> Hi, This RFR is for a trivial update to package.html to include 4.2 which was accidentally omitted ????????? hg diff package.html diff -r a50b619ac159 src/java.sql/share/classes/java/sql/package.html --- a/src/java.sql/share/classes/java/sql/package.html Wed May 03 12:58:17 2017 -0400 +++ b/src/java.sql/share/classes/java/sql/package.html Thu May 04 13:35:35 2017 -0400 @@ -59,6 +59,7 @@

Versions

The JDBC 4.3 API incorporates all of the previous JDBC API versions:
    +
  • The JDBC 4.2 API
  • The JDBC 4.1 API
  • The JDBC 4.0 API
  • The JDBC 3.0 API
    • ljanders-mac:sql ljanders$ ????????????? Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From huizhe.wang at oracle.com Thu May 4 17:53:21 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Thu, 4 May 2017 10:53:21 -0700 Subject: RFR 8179634: Add JDBC 4.2 to bullet list in package.html In-Reply-To: <2BB7CB73-7058-463C-862A-9EAD8E5D2E06@oracle.com> References: <2BB7CB73-7058-463C-862A-9EAD8E5D2E06@oracle.com> Message-ID: <34058de7-e53e-7154-dd56-a933758a3d75@oracle.com> +1 Joe On 5/4/2017 10:40 AM, Lance Andersen wrote: > Hi, > > This RFR is for a trivial update to package.html to include 4.2 which was accidentally omitted > > ????????? > hg diff package.html > diff -r a50b619ac159 src/java.sql/share/classes/java/sql/package.html > --- a/src/java.sql/share/classes/java/sql/package.html Wed May 03 12:58:17 2017 -0400 > +++ b/src/java.sql/share/classes/java/sql/package.html Thu May 04 13:35:35 2017 -0400 > @@ -59,6 +59,7 @@ >

    Versions

    > The JDBC 4.3 API incorporates all of the previous JDBC API versions: >
      > +
    • The JDBC 4.2 API
      • >
    • The JDBC 4.1 API
      • >
    • The JDBC 4.0 API
      • >
    • The JDBC 3.0 API
      • > ljanders-mac:sql ljanders$ > ????????????? > > Best > Lance > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From mandy.chung at oracle.com Thu May 4 20:35:06 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 May 2017 13:35:06 -0700 Subject: Review Request: JDK-8179645: java.util.jar.Packer.newPacker and newUnpacker fails when running with security manager Message-ID: java.util.jar.Packer.newPacker and newUnpacker fails when running with security manager. It is an existing bug but we uncovers this only now because a new RuntimePermission ?accessSystemModules? is required to access resources from the system image. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179645/webrev.00/index.html Mandy From paul.sandoz at oracle.com Thu May 4 21:12:20 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 4 May 2017 14:12:20 -0700 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: Message-ID: <7B4CA48D-9AD7-4D44-9CAF-4B0C875A91D1@oracle.com> Thanks, fixed, Paul. > On 4 May 2017, at 07:28, Sean Mullan wrote: > > Couple of typos on a quick review: > > 55: s/the the/the/ > 129-130: s/the exactly/exactly the/ > 144: fukes -> files? > > --Sean From Alan.Bateman at oracle.com Thu May 4 21:13:11 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 4 May 2017 22:13:11 +0100 Subject: Review Request: JDK-8179645: java.util.jar.Packer.newPacker and newUnpacker fails when running with security manager In-Reply-To: References: Message-ID: <642855bb-67d5-5761-51f2-24124ef044f4@oracle.com> On 04/05/2017 21:35, Mandy Chung wrote: > java.util.jar.Packer.newPacker and newUnpacker fails when running > with security manager. It is an existing bug but we uncovers this > only now because a new RuntimePermission ?accessSystemModules? is > required to access resources from the system image. > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179645/webrev.00/index.html > > Another option for the properties is GetPropertyAction.privilegedGetProperty but what you have is okay too. -Alan From paul.sandoz at oracle.com Thu May 4 21:14:24 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 4 May 2017 14:14:24 -0700 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: Message-ID: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> New update here: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/src/java.base/share/specs/jar/jar.md.sdiff.html I accepted most comments directly. I shuffled around the paragraphs in the modular jar section, partially in preparation for any changes and further explanations for automatic modules. Paul. > On 4 May 2017, at 08:41, Alan Bateman wrote: > > On 03/05/2017 22:44, Paul Sandoz wrote: > >> Hi, >> >> Please review an update to the JAR ?specification? (in the loose sense of the term): >> >> - first, it has been moved from a closed repository into the idk repository (same shared location as the recently introduced serialisation specification) and converted to markdown: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown/webrev/ >> >> (This also includes a new attribute Launcher-Agent-Class, a Jigsaw related change to better support Java agents.) >> >> For comparison, the HTML version online is here: >> >> http://download.java.net/java/jdk9/docs/technotes/guides/jar/jar.html >> >> - second i have added sections on multi-release JAR files: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/ >> >> this is based against the first patch so the changes can be easily viewed. >> >> >> I expect some further editing of this specification to add further links to module related stuff and tidy up existing links to tools etc. >> > I read through the changes. > > Modular JAR files section: > > "directly under the root" - somewhat subjective but I think "in the top-level directory" as we had in the original text is clearer here. > > "in accordance with it's module descriptor" looks unusual and I think would be better to keep the original sentence. > > L70 - I assume "explicitly modular or automatic" should be removed as this is JAR files on the class path. > > Modular multi-release JAR files section: > > As with the Modular JAR file section, I think "in the top-level directory" would be clearer. > > L155-158 - "A non-exported public or protected class ...". It might be clearer to say a public or protected class in a non-exported package. > > L171 - I think there is a typo here and it means non-transitive requires. > > Typo at L219: "This directory containers underneath" > > Otherwise looks good to me. > > -Alan From mandy.chung at oracle.com Thu May 4 21:52:29 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 4 May 2017 14:52:29 -0700 Subject: Review Request: JDK-8179645: java.util.jar.Packer.newPacker and newUnpacker fails when running with security manager In-Reply-To: <642855bb-67d5-5761-51f2-24124ef044f4@oracle.com> References: <642855bb-67d5-5761-51f2-24124ef044f4@oracle.com> Message-ID: <17695549-CC97-4366-87B1-F9C2D6B2AFFF@oracle.com> > On May 4, 2017, at 2:13 PM, Alan Bateman wrote: > > > On 04/05/2017 21:35, Mandy Chung wrote: >> java.util.jar.Packer.newPacker and newUnpacker fails when running >> with security manager. It is an existing bug but we uncovers this >> only now because a new RuntimePermission ?accessSystemModules? is >> required to access resources from the system image. >> >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179645/webrev.00/index.html >> >> > Another option for the properties is GetPropertyAction.privilegedGetProperty but what you have is okay too. I intentionally avoid using it. Mandy From kumar.x.srinivasan at oracle.com Thu May 4 22:33:11 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 04 May 2017 15:33:11 -0700 Subject: Review Request: JDK-8179645: java.util.jar.Packer.newPacker and newUnpacker fails when running with security manager In-Reply-To: <17695549-CC97-4366-87B1-F9C2D6B2AFFF@oracle.com> References: <642855bb-67d5-5761-51f2-24124ef044f4@oracle.com> <17695549-CC97-4366-87B1-F9C2D6B2AFFF@oracle.com> Message-ID: <590BAC27.4040608@oracle.com> On 5/4/2017 2:52 PM, Mandy Chung wrote: >> On May 4, 2017, at 2:13 PM, Alan Bateman wrote: >> >> >> On 04/05/2017 21:35, Mandy Chung wrote: >>> java.util.jar.Packer.newPacker and newUnpacker fails when running >>> with security manager. It is an existing bug but we uncovers this >>> only now because a new RuntimePermission ?accessSystemModules? is >>> required to access resources from the system image. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179645/webrev.00/index.html >>> >>> >> Another option for the properties is GetPropertyAction.privilegedGetProperty but what you have is okay too. > I intentionally avoid using it. Looks ok to me. Thanks Kumar > > Mandy From rick.hillegas at gmail.com Thu May 4 23:28:22 2017 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Thu, 4 May 2017 16:28:22 -0700 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> Message-ID: Thanks, Peter and Roger. In addition to the classes listed by Lance, a complete list of the affected finalizers can be found in this JIRA comment: https://issues.apache.org/jira/browse/DERBY-6856?focusedCommentId=15990011&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15990011 Thanks, -Rick On 5/4/17 9:48 AM, Lance Andersen wrote: >> On May 4, 2017, at 11:32 AM, Mandy Chung wrote: >> >> >>> On May 3, 2017, at 11:16 PM, Peter Levart wrote: >>> >>> Hi Rick, >>> >>> Allow me to join the discussion... >>> >>> On 05/04/2017 04:21 AM, Rick Hillegas wrote: >>>> Thanks, Roger. That is a helpful example. >>>> >>>> Derby is a component which can be quiesced and unloaded on resource-constrained platforms, then re-loaded when resources free up. Unloading means garbage collecting all the classloaders created by the component so that, at the end, not a single scrap of Derby code remains loaded. Has the Cleaner pattern been tested under these kinds of conditions? Can you point me at a Cleaner-based library which successfully unloads and reloads itself without leaking classloaders? >>> Can you point me to a place in Derby code where you are currently using finalize() method for your purpose and I'll try to show you how to convert this to Cleaner API... >>> >>> I'm surprised that you actually need finalize() in Derby. Isn't this pure Java code? Usually finalize() is needed in situations where there's some non-Java resource which has to be cleaned-up when all the references to some Java object that represents it are gone. I'm curious what you need to clean in a pure Java library. >> Please include me for the pointer to Derby code too. This can be used serving as examples to migrate away from use of finalizers. We also hope to do that in JDK to set up more examples. > Here are a few examples I believe: > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java >> Mandy > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > From joe.darcy at oracle.com Thu May 4 23:59:02 2017 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 4 May 2017 16:59:02 -0700 Subject: JDK 10 RFR of JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final Message-ID: <0a91c931-dd13-c806-168e-a16c2dddd7c6@oracle.com> Hello, Please review the patch below to address JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final The build works after the change; no other static fields in java.lang.Math have a missing final modifier. Thanks, -Joe diff -r 32f118110e09 src/java.base/share/classes/java/lang/Math.java --- a/src/java.base/share/classes/java/lang/Math.java Thu May 04 18:13:42 2017 +0100 +++ b/src/java.base/share/classes/java/lang/Math.java Thu May 04 16:58:10 2017 -0700 @@ -1442,8 +1442,8 @@ } // Use raw bit-wise conversions on guaranteed non-NaN arguments. - private static long negativeZeroFloatBits = Float.floatToRawIntBits(-0.0f); - private static long negativeZeroDoubleBits = Double.doubleToRawLongBits(-0.0d); + private static final long negativeZeroFloatBits = Float.floatToRawIntBits(-0.0f); + private static final long negativeZeroDoubleBits = Double.doubleToRawLongBits(-0.0d); /** * Returns the greater of two {@code float} values. That is, From paul.sandoz at oracle.com Fri May 5 00:39:40 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 4 May 2017 17:39:40 -0700 Subject: JDK 10 RFR of JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final In-Reply-To: <0a91c931-dd13-c806-168e-a16c2dddd7c6@oracle.com> References: <0a91c931-dd13-c806-168e-a16c2dddd7c6@oracle.com> Message-ID: > On 4 May 2017, at 16:59, joe darcy wrote: > > Hello, > > Please review the patch below to address > > JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final > +1 Paul. > The build works after the change; no other static fields in java.lang.Math have a missing final modifier. > > Thanks, > > -Joe > > diff -r 32f118110e09 src/java.base/share/classes/java/lang/Math.java > --- a/src/java.base/share/classes/java/lang/Math.java Thu May 04 18:13:42 2017 +0100 > +++ b/src/java.base/share/classes/java/lang/Math.java Thu May 04 16:58:10 2017 -0700 > @@ -1442,8 +1442,8 @@ > } > > // Use raw bit-wise conversions on guaranteed non-NaN arguments. > - private static long negativeZeroFloatBits = Float.floatToRawIntBits(-0.0f); > - private static long negativeZeroDoubleBits = Double.doubleToRawLongBits(-0.0d); > + private static final long negativeZeroFloatBits = Float.floatToRawIntBits(-0.0f); > + private static final long negativeZeroDoubleBits = Double.doubleToRawLongBits(-0.0d); > > /** > * Returns the greater of two {@code float} values. That is, > From brian.burkhalter at oracle.com Fri May 5 01:12:40 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 4 May 2017 18:12:40 -0700 Subject: JDK 10 RFR of JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final In-Reply-To: References: <0a91c931-dd13-c806-168e-a16c2dddd7c6@oracle.com> Message-ID: On May 4, 2017, at 5:39 PM, Paul Sandoz wrote: >> Please review the patch below to address >> >> JDK-8138672: Math. negativeZeroFloatBits and Math. negativeZeroDoubleBits should be final >> > > +1 -(-1) Brian From jeremymanson at google.com Fri May 5 06:39:08 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Thu, 4 May 2017 23:39:08 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: Thanks, Dalibor. I know it may sound surprising, but I'm not actually complaining. I do understand that most everything we're doing that requires workarounds for modules is unsupported (with the possible exception of the changes to instrumentation agents), and we were always doing them at our own risk. This is far from limited to Xbootclasspath - we have all sorts of hacks, including, to pick two things at random among many, code that introspects a Thread's Runnable to pick a good name to report for a thread, and code that introspects an AbstractInterruptibleChannel to stop the owning thread from closing the channel when it gets an interrupt. It's our problem to fix these issues, and I'm unlikely to claim otherwise. Frankly, it doesn't seem all that difficult to find other ways to introspect into the JDK - it's just busywork and more awkward than it used to be. Mostly, I'm telling you all because I think it makes an interesting case study - a large Java installation and the issues it faces trying to roll out JDK 9. If other installations do the kinds of things that we do, the path to a JDK 9 without lots of add-exports and kill switch options is likely to be slow and laborious for them. We're comparatively well situated to do it - we have our own JDK build and a staffed team to do / help with the migration, and are likely to roll it out to everyone with the kill switch turned on by default so that our awful hacks can stay put until we finish fixing them. (Also, if I were complaining, there would have been a lot of choice things I would have said that I'm not going to say. :) ) Jeremy On Thu, May 4, 2017 at 4:35 AM, dalibor topic wrote: > On 02.05.2017 18:46, Jeremy Manson wrote: > >> People >> are using Xbootclasspath for a variety of things. >> > > It's worth keeping in mind when using such options that > > "Non-standard options are general purpose options that are specific to the > Java HotSpot Virtual Machine, so they are not guaranteed to be supported by > all JVM implementations, and are subject to change. These options start > with -X." > > http://docs.oracle.com/javase/8/docs/technotes/tools/unix/ja > va.html#BABHDABI > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From kirk.pepperdine at gmail.com Fri May 5 06:44:34 2017 From: kirk.pepperdine at gmail.com (Kirk Pepperdine) Date: Fri, 5 May 2017 08:44:34 +0200 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: <25C0CD41-DD89-414C-BB53-1746E864BF61@gmail.com> Hi Jeremy, I think your email points out *why* turning this on out of the blocks is going to make things a ton more difficult. IMHO, 9 needs to be opt-in rather than opt-out. By 10 I think we?ll be ready for opt-out rather than opt-in. Kind regards, Kirk Pepperdine > On May 5, 2017, at 8:39 AM, Jeremy Manson wrote: > > Thanks, Dalibor. > > I know it may sound surprising, but I'm not actually complaining. I do > understand that most everything we're doing that requires workarounds for > modules is unsupported (with the possible exception of the changes to > instrumentation agents), and we were always doing them at our own risk. > This is far from limited to Xbootclasspath - we have all sorts of hacks, > including, to pick two things at random among many, code that introspects a > Thread's Runnable to pick a good name to report for a thread, and code that > introspects an AbstractInterruptibleChannel to stop the owning thread from > closing the channel when it gets an interrupt. > > It's our problem to fix these issues, and I'm unlikely to claim otherwise. > Frankly, it doesn't seem all that difficult to find other ways to > introspect into the JDK - it's just busywork and more awkward than it used > to be. > > Mostly, I'm telling you all because I think it makes an interesting case > study - a large Java installation and the issues it faces trying to roll > out JDK 9. > > If other installations do the kinds of things that we do, the path to a JDK > 9 without lots of add-exports and kill switch options is likely to be slow > and laborious for them. We're comparatively well situated to do it - we > have our own JDK build and a staffed team to do / help with the migration, > and are likely to roll it out to everyone with the kill switch turned on by > default so that our awful hacks can stay put until we finish fixing them. > > (Also, if I were complaining, there would have been a lot of choice things > I would have said that I'm not going to say. :) ) > > Jeremy > > On Thu, May 4, 2017 at 4:35 AM, dalibor topic > wrote: > >> On 02.05.2017 18:46, Jeremy Manson wrote: >> >>> People >>> are using Xbootclasspath for a variety of things. >>> >> >> It's worth keeping in mind when using such options that >> >> "Non-standard options are general purpose options that are specific to the >> Java HotSpot Virtual Machine, so they are not guaranteed to be supported by >> all JVM implementations, and are subject to change. These options start >> with -X." >> >> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/ja >> va.html#BABHDABI >> >> cheers, >> dalibor topic >> -- >> Dalibor Topic | Principal Product Manager >> Phone: +494089091214 | Mobile: +491737185961 >> >> >> ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg >> >> ORACLE Deutschland B.V. & Co. KG >> Hauptverwaltung: Riesstr. 25, D-80992 M?nchen >> Registergericht: Amtsgericht M?nchen, HRA 95603 >> >> Komplement?rin: ORACLE Deutschland Verwaltung B.V. >> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande >> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 >> Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher >> >> Oracle is committed to developing >> practices and products that help protect the environment >> From chris.hegarty at oracle.com Fri May 5 09:32:23 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 5 May 2017 10:32:23 +0100 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> References: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> Message-ID: > On 4 May 2017, at 22:14, Paul Sandoz wrote: > > New update here: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/src/java.base/share/specs/jar/jar.md.sdiff.html I read through the changes for modular and multi-release JAR, they seem fine. > I accepted most comments directly. I shuffled around the paragraphs in the modular jar section, partially in preparation for any changes and further explanations for automatic modules. I know you may have further changes here resulting from ongoing discussion around automatic modules, but I think the following could be resolved now. "If a multi-release JAR file is deployed on the class path of major version ?" The MR JAR can also be put on module path, it is not exclusive to the class path, or limited to only Modular multi-release JARs on the module path. -Chris. From Alan.Bateman at oracle.com Fri May 5 10:51:53 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 May 2017 11:51:53 +0100 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> References: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> Message-ID: <1595c895-49c9-5464-c3df-e923e63f92b1@oracle.com> On 04/05/2017 22:14, Paul Sandoz wrote: > New update here: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/src/java.base/share/specs/jar/jar.md.sdiff.html > > > > I accepted most comments directly. I shuffled around the paragraphs in > the modular jar section, partially in preparation for any changes and > further explanations for automatic modules. > This looks much better. L85 adds the word "security" which I don't think was in the previous iteration. Do mean the signature related files detailed in the "Signed JAR File" section? If so then they apply to modular JAR files too. The simplest might be to just drop the word "security" from the sentence. L91-95 - This could link to ModuleFinder.of(Path...) so that it can avoid the details as to how the module name and packages are derived. L177 still has "A non-exported public or protected class". Did you consider changing this to "A public or protected class in a non-exported package"? -Alan From magnus.ihse.bursie at oracle.com Fri May 5 13:30:55 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 5 May 2017 15:30:55 +0200 Subject: RFR: JDK-8179692 Move RMI spec to specs directory Message-ID: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com> The RMI spec will be moved to a new location, so all links needs to be updated. Bug: https://bugs.openjdk.java.net/browse/JDK-8179692 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179692-rmi-spec-markdown/webrev.01 /Magnus From erik.joelsson at oracle.com Fri May 5 15:53:44 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 5 May 2017 08:53:44 -0700 Subject: RFR: JDK-8179692 Move RMI spec to specs directory In-Reply-To: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com> References: <80130257-2f60-9c2a-e324-8cb1f50e1c07@oracle.com> Message-ID: <6d546a82-9ee5-f1ed-f0c6-ba3f650c9e67@oracle.com> Looks good to me. /Erik On 2017-05-05 06:30, Magnus Ihse Bursie wrote: > The RMI spec will be moved to a new location, so all links needs to be > updated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179692 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8179692-rmi-spec-markdown/webrev.01 > > /Magnus > From paul.sandoz at oracle.com Fri May 5 16:37:46 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 5 May 2017 09:37:46 -0700 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> Message-ID: <428CD780-B429-4E57-B3BB-1F5613A51447@oracle.com> > On 5 May 2017, at 02:32, Chris Hegarty wrote: > > >> On 4 May 2017, at 22:14, Paul Sandoz wrote: >> >> New update here: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/src/java.base/share/specs/jar/jar.md.sdiff.html > > I read through the changes for modular and multi-release JAR, > they seem fine. > >> I accepted most comments directly. I shuffled around the paragraphs in the modular jar section, partially in preparation for any changes and further explanations for automatic modules. > > I know you may have further changes here resulting from ongoing > discussion around automatic modules, but I think the following could > be resolved now. > > "If a multi-release JAR file is deployed on the class path of major version ?" > > The MR JAR can also be put on module path, it is not exclusive to the > class path, or limited to only Modular multi-release JARs on the module path. > Ok, i can refine to say: If a multi-release JAR file is deployed on the class path or module path (as an automatic module or an explicit [multi-release module](#Modular-multi-release)) and i can remove the paragraph in the Modular-multi-release in class loading. Paul. From paul.sandoz at oracle.com Fri May 5 16:44:39 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 5 May 2017 09:44:39 -0700 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: <1595c895-49c9-5464-c3df-e923e63f92b1@oracle.com> References: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> <1595c895-49c9-5464-c3df-e923e63f92b1@oracle.com> Message-ID: > On 5 May 2017, at 03:51, Alan Bateman wrote: > > > > On 04/05/2017 22:14, Paul Sandoz wrote: >> New update here: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8150681-jar-spec-markdown-with-mr-jar/webrev/src/java.base/share/specs/jar/jar.md.sdiff.html >> >> I accepted most comments directly. I shuffled around the paragraphs in the modular jar section, partially in preparation for any changes and further explanations for automatic modules. >> > This looks much better. > > L85 adds the word "security" which I don't think was in the previous iteration. Do mean the signature related files detailed in the "Signed JAR File" section? If so then they apply to modular JAR files too. The simplest might be to just drop the word "security" from the sentence. > Done. > L91-95 - This could link to ModuleFinder.of(Path...) so that it can avoid the details as to how the module name and packages are derived. > Thanks, yes, that simplifies and reduced possible updated. > L177 still has "A non-exported public or protected class". Did you consider changing this to "A public or protected class in a non-exported package?? Sorry, i forgot to apply with the other reshuffling going on. Done. See below for the diff on the previous changeset. Paul. diff -r 8811f1594a29 src/java.base/share/specs/jar/jar.md --- a/src/java.base/share/specs/jar/jar.md Thu May 04 14:07:32 2017 -0700 +++ b/src/java.base/share/specs/jar/jar.md Fri May 05 09:43:14 2017 -0700 @@ -81,18 +81,17 @@ modular JAR files.) A modular JAR file deployed on the module path, as opposed to the class path, is -a module. Dependences and service providers are declared in the module -descriptor. The [JAR Manifest](#JAR_Manifest) is ignored as is any security or +an *explicit* module. Dependences and service providers are declared in the +module descriptor. The [JAR Manifest](#JAR_Manifest) is ignored as is any service configuration under the [`META-INF`](#The_META-INF_directory) directory. However, if the modular JAR file is deployed on the class path then it behaves -as if a non-modular JAR file and the JAR Manifest and configurations under +as if a non-modular JAR file and the JAR Manifest and configuration under the `META-INF` directory are not ignored. -A non-modular JAR deployed on the module path is an *automatic module*, where -a module name and a module declaration is synthesized from the JAR file name and -it's contents. The module name for an automatic module is derived from the name -of the JAR file and its exported packages are determined by the `.class` files -in the JAR file. +A non-modular JAR file deployed on the module path is an *automatic module*, +where a module declaration is synthesized from the JAR file name and +its contents. For further details see the specification on the method +[java.lang.module.ModuleFinder.of](../../../api/java/lang/module/ModuleFinder.html#of-java.nio.file.Path...-). []{#Multi-release}Multi-release JAR files ----------------------------------------- @@ -141,12 +140,13 @@ this applies to a class of a class file, if present, under a versioned directory whose version is less than `N`. -If a multi-release JAR file is deployed on the class path of major version `N` -of a Java platform release runtime, then a class loader loading classes from -that JAR file will first search for class files under the `N`th versioned -directory, then prior versioned directories in descending order (if present), -down to a lower major version bound of `9`, and finally under the top-level -directory. +If a multi-release JAR file is deployed on the class path or module path +(as an automatic module or an explicit [multi-release module](#Modular-multi-release)) +of major version `N` of a Java platform release runtime, then a class loader +loading classes from that JAR file will first search for class files under the +`N`th versioned directory, then prior versioned directories in descending order +(if present), down to a lower major version bound of `9`, and finally under the +top-level directory. The public API exported by the classes in a multi-release JAR file must be *exactly* the same across versions, hence at a minimum why versioned public or @@ -174,7 +174,7 @@ module descriptor, `module-info.class`, in the top-level directory (as for a [modular](#Modular) JAR file), or directly in a versioned directory. -A non-exported public or protected class (whose package is not declared as +A public or protected class in a non-exported package (that is not declared as exported in the module descriptor) need not preside over a class of the same fully qualified name and access modifier whose class file is present under the top-level directory. @@ -195,11 +195,6 @@ 2. the presiding versioned descriptor can have different `uses` clauses, even of service types defined outside of `java.*` and `jdk.*` modules. -If a modular multi-release JAR is deployed on the module path then a class -loader loading classes from that JAR file will behave, in regards to searching -for classes, in the same manner as that specified for a multi-release JAR -deployed on the class path. - Tooling, such as the `jar` tool, should perform such verification of versioned module descriptors but a Java runtime is not required to perform any verification. From Alan.Bateman at oracle.com Fri May 5 19:11:16 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 5 May 2017 20:11:16 +0100 Subject: RFR 8150681 Update JAR specification for multi-release jar files In-Reply-To: References: <00B25F1C-1223-4342-B5D5-C4126ECEF7A9@oracle.com> <1595c895-49c9-5464-c3df-e923e63f92b1@oracle.com> Message-ID: <66739ed6-7c8b-e360-bccd-a4d86c65b3c8@oracle.com> On 05/05/2017 17:44, Paul Sandoz wrote: > : > > See below for the diff on the previous changeset. > This looks good. -Alan From ron.pressler at oracle.com Fri May 5 19:27:29 2017 From: ron.pressler at oracle.com (Ron Pressler) Date: Fri, 5 May 2017 22:27:29 +0300 Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods Message-ID: <590CD221.4080100@oracle.com> Hi, Please review the following core/hotspot change: Bug: https://bugs.openjdk.java.net/browse/JDK-8159995 core webrev: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/ hotspot webrev: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/ This change is covered by existing tests. The following renaming was applied: - compareAndExchange*Volatile -> compareAndExchange* - compareAndSwap* -> compareAndSet* - weakCompareAndSwap* -> weakCompareAndSet*Plain - weakCompareAndSwap*Volatile -> weakCompareAndSet* At this stage, only method and hotspot intrinsic names were changed; node names were left as-is, and may be handled in a separate issue. Ron From alexandre.iline at oracle.com Fri May 5 21:51:05 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 5 May 2017 14:51:05 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups Message-ID: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> Hi. Can you please take a quick look on this fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 Change: $ hg diff diff --git a/test/TEST.groups b/test/TEST.groups --- a/test/TEST.groups +++ b/test/TEST.groups @@ -465,7 +465,6 @@ needs_jdk = \ :jdk_jdi \ com/sun/tools \ - demo \ jdk/security/jarsigner \ sun/security/tools/jarsigner \ sun/security/tools/policytool \ $ Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt Thank you Shura From brian.burkhalter at oracle.com Fri May 5 21:56:48 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 May 2017 14:56:48 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> Message-ID: <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> Looks OK to me and I did verify the statement about ProblemList.txt. Brian On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline wrote: > Can you please take a quick look on this fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 > > Change: > $ hg diff > diff --git a/test/TEST.groups b/test/TEST.groups > --- a/test/TEST.groups > +++ b/test/TEST.groups > @@ -465,7 +465,6 @@ > needs_jdk = \ > :jdk_jdi \ > com/sun/tools \ > - demo \ > jdk/security/jarsigner \ > sun/security/tools/jarsigner \ > sun/security/tools/policytool \ > $ > > Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt From paul.sandoz at oracle.com Fri May 5 21:58:07 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 5 May 2017 14:58:07 -0700 Subject: RFR 8178912, Throw away sample tests In-Reply-To: <1b4863b5-d565-6fa1-261e-5a297c98ba8f@oracle.com> References: <1b4863b5-d565-6fa1-261e-5a297c98ba8f@oracle.com> Message-ID: <6A784F5C-9A2A-49BE-AAFD-075CBA229D8F@oracle.com> > On 3 May 2017, at 19:36, Felix Yang wrote: > > Hi there, > > please review following change to remove tests for several samples, which have been removed in "JEP 298: Remove Demos and Samples". > > Webrev: http://cr.openjdk.java.net/~xiaofeya/8178912/webrev.00/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8178912 > > Corresponding JEP: https://bugs.openjdk.java.net/browse/JDK-8164813 > +1 Paul. From alexandre.iline at oracle.com Fri May 5 22:00:44 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 5 May 2017 15:00:44 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> Message-ID: Thank you! Pushed. Shura > On May 5, 2017, at 2:56 PM, Brian Burkhalter wrote: > > Looks OK to me and I did verify the statement about ProblemList.txt. > > Brian > > On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline > wrote: > >> Can you please take a quick look on this fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 >> >> Change: >> $ hg diff >> diff --git a/test/TEST.groups b/test/TEST.groups >> --- a/test/TEST.groups >> +++ b/test/TEST.groups >> @@ -465,7 +465,6 @@ >> needs_jdk = \ >> :jdk_jdi \ >> com/sun/tools \ >> - demo \ >> jdk/security/jarsigner \ >> sun/security/tools/jarsigner \ >> sun/security/tools/policytool \ >> $ >> >> Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt > From brian.burkhalter at oracle.com Fri May 5 22:10:23 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 May 2017 15:10:23 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> Message-ID: <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> You?re welcome! Is there any conflict with this http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047442.html which I just noticed was approved at 2:59 PM PT? Brian On May 5, 2017, at 3:00 PM, Alexandre (Shura) Iline wrote: > Thank you! > > Pushed. > > Shura > >> On May 5, 2017, at 2:56 PM, Brian Burkhalter wrote: >> >> Looks OK to me and I did verify the statement about ProblemList.txt. >> >> Brian >> >> On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline wrote: >> >>> Can you please take a quick look on this fix. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 >>> >>> Change: >>> $ hg diff >>> diff --git a/test/TEST.groups b/test/TEST.groups >>> --- a/test/TEST.groups >>> +++ b/test/TEST.groups >>> @@ -465,7 +465,6 @@ >>> needs_jdk = \ >>> :jdk_jdi \ >>> com/sun/tools \ >>> - demo \ >>> jdk/security/jarsigner \ >>> sun/security/tools/jarsigner \ >>> sun/security/tools/policytool \ >>> $ >>> >>> Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt >> > From brian.burkhalter at oracle.com Fri May 5 22:12:50 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 May 2017 15:12:50 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> Message-ID: At the least Felix will have a merge to do with test/TEST.groups. Brian On May 5, 2017, at 3:10 PM, Brian Burkhalter wrote: > You?re welcome! > > Is there any conflict with this http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047442.html which I just noticed was approved at 2:59 PM PT? > > Brian > > On May 5, 2017, at 3:00 PM, Alexandre (Shura) Iline wrote: > >> Thank you! >> >> Pushed. >> >> Shura >> >>> On May 5, 2017, at 2:56 PM, Brian Burkhalter wrote: >>> >>> Looks OK to me and I did verify the statement about ProblemList.txt. >>> >>> Brian >>> >>> On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline wrote: >>> >>>> Can you please take a quick look on this fix. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 >>>> >>>> Change: >>>> $ hg diff >>>> diff --git a/test/TEST.groups b/test/TEST.groups >>>> --- a/test/TEST.groups >>>> +++ b/test/TEST.groups >>>> @@ -465,7 +465,6 @@ >>>> needs_jdk = \ >>>> :jdk_jdi \ >>>> com/sun/tools \ >>>> - demo \ >>>> jdk/security/jarsigner \ >>>> sun/security/tools/jarsigner \ >>>> sun/security/tools/policytool \ >>>> $ >>>> >>>> Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt >>> >> > From alexandre.iline at oracle.com Fri May 5 22:16:30 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 5 May 2017 15:16:30 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> Message-ID: <6E60B05E-71EA-471C-8030-6BF6B09F9257@oracle.com> Felix took the bug I created for the sample tests: https://bugs.openjdk.java.net/browse/JDK-8178912 He is saying that they are not useful. Looks ok. Shura > On May 5, 2017, at 3:10 PM, Brian Burkhalter wrote: > > You?re welcome! > > Is there any conflict with this http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047442.html which I just noticed was approved at 2:59 PM PT? > > Brian > > On May 5, 2017, at 3:00 PM, Alexandre (Shura) Iline > wrote: > >> Thank you! >> >> Pushed. >> >> Shura >> >>> On May 5, 2017, at 2:56 PM, Brian Burkhalter > wrote: >>> >>> Looks OK to me and I did verify the statement about ProblemList.txt. >>> >>> Brian >>> >>> On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline > wrote: >>> >>>> Can you please take a quick look on this fix. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 >>>> >>>> Change: >>>> $ hg diff >>>> diff --git a/test/TEST.groups b/test/TEST.groups >>>> --- a/test/TEST.groups >>>> +++ b/test/TEST.groups >>>> @@ -465,7 +465,6 @@ >>>> needs_jdk = \ >>>> :jdk_jdi \ >>>> com/sun/tools \ >>>> - demo \ >>>> jdk/security/jarsigner \ >>>> sun/security/tools/jarsigner \ >>>> sun/security/tools/policytool \ >>>> $ >>>> >>>> Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt >>> >> > From alexandre.iline at oracle.com Fri May 5 22:17:11 2017 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Fri, 5 May 2017 15:17:11 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> Message-ID: <4D389306-E7CD-42F2-8E66-E993362ED51A@oracle.com> > On May 5, 2017, at 3:12 PM, Brian Burkhalter wrote: > > At the least Felix will have a merge to do with test/TEST.groups. Oh, yes - that is true. Shura > > Brian > > On May 5, 2017, at 3:10 PM, Brian Burkhalter > wrote: > >> You?re welcome! >> >> Is there any conflict with this http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047442.html which I just noticed was approved at 2:59 PM PT? >> >> Brian >> >> On May 5, 2017, at 3:00 PM, Alexandre (Shura) Iline > wrote: >> >>> Thank you! >>> >>> Pushed. >>> >>> Shura >>> >>>> On May 5, 2017, at 2:56 PM, Brian Burkhalter > wrote: >>>> >>>> Looks OK to me and I did verify the statement about ProblemList.txt. >>>> >>>> Brian >>>> >>>> On May 5, 2017, at 2:51 PM, Alexandre (Shura) Iline > wrote: >>>> >>>>> Can you please take a quick look on this fix. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179852 >>>>> >>>>> Change: >>>>> $ hg diff >>>>> diff --git a/test/TEST.groups b/test/TEST.groups >>>>> --- a/test/TEST.groups >>>>> +++ b/test/TEST.groups >>>>> @@ -465,7 +465,6 @@ >>>>> needs_jdk = \ >>>>> :jdk_jdi \ >>>>> com/sun/tools \ >>>>> - demo \ >>>>> jdk/security/jarsigner \ >>>>> sun/security/tools/jarsigner \ >>>>> sun/security/tools/policytool \ >>>>> $ >>>>> >>>>> Notice that references to sample tests still exists but the tests themselves are listed in the ProblemList.txt >>>> >>> >> > From brian.burkhalter at oracle.com Fri May 5 22:17:21 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 5 May 2017 15:17:21 -0700 Subject: RFR 8179852: Remove references to demo tests from TEST.groups In-Reply-To: <6E60B05E-71EA-471C-8030-6BF6B09F9257@oracle.com> References: <2F0F591A-F034-4580-AC78-4D9BC1F7C918@oracle.com> <5242B895-E5B9-4476-B9F2-ABF3D738DF75@oracle.com> <7A9EF60E-578A-4D7C-A9A1-22AAB96D4EA7@oracle.com> <6E60B05E-71EA-471C-8030-6BF6B09F9257@oracle.com> Message-ID: OK - cool! Thanks, Brian On May 5, 2017, at 3:16 PM, Alexandre (Shura) Iline wrote: > Felix took the bug I created for the sample tests: > https://bugs.openjdk.java.net/browse/JDK-8178912 > > He is saying that they are not useful. > > Looks ok. > > Shura > From jonathan.gibbons at oracle.com Fri May 5 22:52:47 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 May 2017 15:52:47 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590A5477.9050602@oracle.com> References: <590A5477.9050602@oracle.com> Message-ID: <590D023F.1010809@oracle.com> This is an updated review for the changes to improve tables in java.base. The changes incorporate earlier review feedback, and also address a problem that was discovered with nested tables. The summary of the set of changes since the previous round is: * A new style class is added for borderless tables, to be used in preference to a table tag with no class. * The style classes are now named: borderless plain striped The longer form using a suffix `-table` was considered, but generally, there should not be so many style classes that such a level of discrimination is needed. The names `borderless` and `striped` are most likely to only apply to tables anyway, and `plain` could reasonably be used for other elements without conflict. * Comments are added to the stylesheet regarding these new classes, as a placeholder until a better specification for the styles in these stylesheets is created. * Within java.base, all uses of the `altrows` class have been updated to use `striped`, and tables with no class attribute have been changed to explicitly use `borderless`. Webrevs: langtools (the stylesheet): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ jdk (changes to java.base): http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ API showing the combined effect of these cahnges: http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html -- Jon On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: > This is a review request for two co-dependent fixes. > > JDK-8179592: Update tables in java.base to be HTML 5-friendly. > JDK-8179479: Add new styles to enable HTML 5 tables > > In doc comments, some of the HTML 4.01 attributes for tables are no > longer available in HTML 5, and CSS should be used instead. > To this end, some updates have been made to the main/default > stylesheet used by javadoc, to define two new CSS classes for tables. > > The new classes are: >
> Just puts plain borders around each cell, with no background > coloring. > >
> Horizontal borders are not used between cells in the table body; > instead, alternating backgrounds are used to help distinguish the > separate rows. > > In addition, there is still the default >
> No borders. > > These styles are in the langtools webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ > > The changes to the doc comments in java.base are in the jdk webrev, here: > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ > > summary vs.
> > The ARIA recommendations are to use the summary attribute or > tag ... but the summary attribute is no longer allowed in > HTML 5. In general, the text that has been provided for a summary is > not suitable for direct use as a caption. The temporary workaround is > to use a caption that is not displayed. In time, the appropriate API > owners should update the use of these undisplayed table captions, to > modify the text of the caption and make the caption displayed (by > removing style="display:none"). > > Doc comments were changed in files in the following packages: > > java.io > java.lang > java.lang.invoke > java.lang.reflect > java.math > java.net > java.nio.channels > java.nio.charset > java.nio.file > java.nio.file.attribute > java.nio.file.spi > java.security > java.security.cert > java.text > java.time.chrono > java.time.format > java.time.temporal > java.util > java.util.concurrent > java.util.regex > java.util.spi > javax.net.ssl > > The intent is that the only changes in this webrev are to the HTML 5 > markup. There should be no significant changes to the text in any doc > comment. > > The decision to add the styles to the default stylesheet at this late > stage in the release is not taken lightly, and is seen as a temporary > measure. JDK-8177283 is a wishlist enhancement for updates to javadoc > support of stylesheets, which includes the desire to move JDK-specific > styles to a JDK-specific stylesheet. > > This review is primarily about continuing the ongoing effort to make > our docs be HTML 5 compliant. I would prefer not to get into extended > discussions about which style class to use for each table, and what > the exact definition of the styleclasses should be at this time. But > appropriate review feedback is obviously welcome. > > -- Jon From kumar.x.srinivasan at oracle.com Sat May 6 15:21:31 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Sat, 06 May 2017 08:21:31 -0700 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option Message-ID: <590DE9FB.7040608@oracle.com> Hello, Please review the changes to remove the java launcher's data model options -d32/-d64, these options existed to support Solaris dual-mode operation, however for uniformity, these options were accepted by other platforms as well. These options are now obsolete, and deprecated in jdk9, and are now being removed. Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 Thanks Kumar PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have been purged from internal test suites. From peter.levart at gmail.com Sat May 6 20:01:05 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 6 May 2017 22:01:05 +0200 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> Message-ID: Hi Rick and others, On 05/04/2017 06:48 PM, Lance Andersen wrote: > Here are a few examples I believe: > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java > http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java I took a bite at the 1st one (ClientConnection). Here's the result: http://cr.openjdk.java.net/~plevart/misc/Cleaner/derby/ClientConnection_finalize2cleaner.patch I haven't tested this, but I believe it should work. It was quite a challenge, because of the way current ClientConnection code is structured. I tried to make the patch not incompatibly change public API of ClientConnection and related classes and I almost succeeded. The problematic part was the protected boolean ClientConnection.closed_ flag. If there is any sublclass of ClientConnection (apart from NetConnection which is derby code) that modifies this field, you are out of luck as changing (not only reading) this field directly my have an undesirable consequence (or it may not, since the only thing that changing these field to false would do is it would redundantly force performing the cleanup action. If the cleanup is idempotent, then all is OK). Further complication with ClientConnection is that it maintains a split state - some of it resides in ClientConnection and subclasses (such as NetConnection) and some of it in embedded object of Agent class and subclasses (such as NetAgent). Both - some of this state from connection object and some from the agent state are needed to perform the cleanup that is currently executed from the connection finalize() method. When using Cleaner API, we have to capture this state from both places (or more since each class has a hierarchy) and then arrange for cleanup action to use this state. Captured state can not reference the tracked object (ClientConnection in this case) either directly or indirectly since then it will never be GCed. When cleanup action is run, the tracked object is already unreachable - this is the main difference from finalize() where there is a phase in object's life-cycle where it is still reachable, albeit guaranteed only from the thread executing finalize() method. We can not capture the Agent object either, since it maintains a reference back to the ClientConnection object. All this is further complicated by the fact that captured state is mutable and we have to arrange for it to be mutated in both places. If the mutable state is captured by reference and the instance containing it never changes during the lifetime of the tracked container object, then it is easy - we just capture the object after the tracked container instance is constructed. If the captured state includes mutable fields directly in the tracked container object, then we must arrange for them to be synchronously mutated in two places. Such fields are: - ClientConnection.open_ (replicated in ClientConnection.CleanupAction.open) - Agent.logWriter_ (replicated in Agent.CleanupAction.logWriter) - NetAgent.rawSocketInputStream_ (replicated in NetAgent.NetCleanupAction.rawSocketInputStream) - NetAgent.rawSocketOutputStream_ (replicated in NetAgent.NetCleanupAction.rawSocketOutputStream) Fortunately all of this state is encapsulated with protected field ClientConnection.open_ being an exception. Note that Cleaner API also allows for cleanup action to be triggered explicitly, which then de-registers it. This is one of its advantages over finalize() where you can not deregister an object when it is already explicitly closed for example. finalize() will always be called even if closed explicitly. If you create lots of finalizable objects (such as connections, statements, etc...) and promptly close() them, they still wait for finalization and use resources (heap, CPU when GC searches for them, ReferenceHandler enqueues them, and finally finalize() method which is executed after the fact). Explicit triggering and de-registration of the cleanup action is performed in the ClientConnection.closeResourcesX() (called from public close() and closeResources()) after the connection has already being marked as closed. Cleanup action will be a no-op at this point, but it will also be de-registered. This is important to not bother GC with reference processing when it is not needed any more. In situations whre cleanup action logic is the same as explicit closing logic (in the case of ClientConnection it is not), close() method could just invoke cleanable.clean() and delegate the meat of processing to the cleanup action. Hope this non trivial example helps illustrate what is needed when converting finalize() to Cleanup API. Regards, Peter From peter.levart at gmail.com Sat May 6 21:19:56 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 6 May 2017 23:19:56 +0200 Subject: tutorial on using Cleaner-based finalization In-Reply-To: References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> Message-ID: <8ca9b992-51e8-341b-4326-53483ae8f663@gmail.com> Thinking of this for some more time... Although this is a nice exercise in converting finalize() to Cleaner API, I strongly suspect that ClientConnection.finalize() is doing unnecessary things. What it does is it: - prints some trace message to logWriter - closes logWriter (whatever it is) - closes raw socket input and output streams - closes the socket - notifies listeners I believe all this is unnecessary (apart from notifying listeners perhaps?) as those objects already have their own cleanup mechanism when they are left behind. I believe there would be no resource leaks if ClientSocket.finalize() was simply removed. Before doing the conversion from finalize() to Cleaner API one should always ask himself whether finalize() method is actually needed. All 3rd party code (with notable exceptions which use JNI) are based on Java SE APIs and these APIs already take care of resources held by objects that are left behind. There's usually no need to do the same in the higher layers of 3rd party code. What do you think? Regards, Peter On 05/06/2017 10:01 PM, Peter Levart wrote: > Hi Rick and others, > > On 05/04/2017 06:48 PM, Lance Andersen wrote: >> Here are a few examples I believe: >> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java >> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java >> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java > > I took a bite at the 1st one (ClientConnection). Here's the result: > > http://cr.openjdk.java.net/~plevart/misc/Cleaner/derby/ClientConnection_finalize2cleaner.patch > > I haven't tested this, but I believe it should work. It was quite a > challenge, because of the way current ClientConnection code is > structured. I tried to make the patch not incompatibly change public > API of ClientConnection and related classes and I almost succeeded. > The problematic part was the protected boolean > ClientConnection.closed_ flag. If there is any sublclass of > ClientConnection (apart from NetConnection which is derby code) that > modifies this field, you are out of luck as changing (not only > reading) this field directly my have an undesirable consequence (or it > may not, since the only thing that changing these field to false would > do is it would redundantly force performing the cleanup action. If the > cleanup is idempotent, then all is OK). > > Further complication with ClientConnection is that it maintains a > split state - some of it resides in ClientConnection and subclasses > (such as NetConnection) and some of it in embedded object of Agent > class and subclasses (such as NetAgent). Both - some of this state > from connection object and some from the agent state are needed to > perform the cleanup that is currently executed from the connection > finalize() method. When using Cleaner API, we have to capture this > state from both places (or more since each class has a hierarchy) and > then arrange for cleanup action to use this state. Captured state can > not reference the tracked object (ClientConnection in this case) > either directly or indirectly since then it will never be GCed. When > cleanup action is run, the tracked object is already unreachable - > this is the main difference from finalize() where there is a phase in > object's life-cycle where it is still reachable, albeit guaranteed > only from the thread executing finalize() method. We can not capture > the Agent object either, since it maintains a reference back to the > ClientConnection object. All this is further complicated by the fact > that captured state is mutable and we have to arrange for it to be > mutated in both places. If the mutable state is captured by reference > and the instance containing it never changes during the lifetime of > the tracked container object, then it is easy - we just capture the > object after the tracked container instance is constructed. If the > captured state includes mutable fields directly in the tracked > container object, then we must arrange for them to be synchronously > mutated in two places. Such fields are: > > - ClientConnection.open_ (replicated in > ClientConnection.CleanupAction.open) > - Agent.logWriter_ (replicated in Agent.CleanupAction.logWriter) > - NetAgent.rawSocketInputStream_ (replicated in > NetAgent.NetCleanupAction.rawSocketInputStream) > - NetAgent.rawSocketOutputStream_ (replicated in > NetAgent.NetCleanupAction.rawSocketOutputStream) > > Fortunately all of this state is encapsulated with protected field > ClientConnection.open_ being an exception. > > Note that Cleaner API also allows for cleanup action to be triggered > explicitly, which then de-registers it. This is one of its advantages > over finalize() where you can not deregister an object when it is > already explicitly closed for example. finalize() will always be > called even if closed explicitly. If you create lots of finalizable > objects (such as connections, statements, etc...) and promptly close() > them, they still wait for finalization and use resources (heap, CPU > when GC searches for them, ReferenceHandler enqueues them, and finally > finalize() method which is executed after the fact). Explicit > triggering and de-registration of the cleanup action is performed in > the ClientConnection.closeResourcesX() (called from public close() and > closeResources()) after the connection has already being marked as > closed. Cleanup action will be a no-op at this point, but it will also > be de-registered. This is important to not bother GC with reference > processing when it is not needed any more. In situations whre cleanup > action logic is the same as explicit closing logic (in the case of > ClientConnection it is not), close() method could just invoke > cleanable.clean() and delegate the meat of processing to the cleanup > action. > > Hope this non trivial example helps illustrate what is needed when > converting finalize() to Cleanup API. > > Regards, Peter > From rick.hillegas at gmail.com Sun May 7 18:59:12 2017 From: rick.hillegas at gmail.com (Rick Hillegas) Date: Sun, 7 May 2017 11:59:12 -0700 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <8ca9b992-51e8-341b-4326-53483ae8f663@gmail.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> <8ca9b992-51e8-341b-4326-53483ae8f663@gmail.com> Message-ID: <256358c4-cb5a-134e-c0ad-c6bc8e5acaf7@gmail.com> Thanks for investigating that sample case, Peter, and for providing a candidate solution. It is much appreciated. Your expert experience confirms my amateur hunch that this migration is a non-trivial re-factorization which merits its own mini-project. I have logged a new technical debt issue to track that effort: https://issues.apache.org/jira/browse/DERBY-6932 If I correctly understand what has been said so far, then I think that we should be able to get away with a single Cleaner instance for each component, essentially, one for each jar file which we build today. After we convert Derby into jigsaw modules, that might translate into one Cleaner instance for each module. I don't see any advantage to the extra complexity of a separate Cleaner instance for each class which currently implements finalize(). Does that sound reasonable to you? Thanks, -Rick On 5/6/17 2:19 PM, Peter Levart wrote: > Thinking of this for some more time... > > Although this is a nice exercise in converting finalize() to Cleaner > API, I strongly suspect that ClientConnection.finalize() is doing > unnecessary things. What it does is it: > > - prints some trace message to logWriter > - closes logWriter (whatever it is) > - closes raw socket input and output streams > - closes the socket > - notifies listeners > > I believe all this is unnecessary (apart from notifying listeners > perhaps?) as those objects already have their own cleanup mechanism > when they are left behind. I believe there would be no resource leaks > if ClientSocket.finalize() was simply removed. Before doing the > conversion from finalize() to Cleaner API one should always ask > himself whether finalize() method is actually needed. All 3rd party > code (with notable exceptions which use JNI) are based on Java SE APIs > and these APIs already take care of resources held by objects that are > left behind. There's usually no need to do the same in the higher > layers of 3rd party code. > > What do you think? > > Regards, Peter > > > On 05/06/2017 10:01 PM, Peter Levart wrote: >> Hi Rick and others, >> >> On 05/04/2017 06:48 PM, Lance Andersen wrote: >>> Here are a few examples I believe: >>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java >>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java >>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java >> >> I took a bite at the 1st one (ClientConnection). Here's the result: >> >> http://cr.openjdk.java.net/~plevart/misc/Cleaner/derby/ClientConnection_finalize2cleaner.patch >> >> I haven't tested this, but I believe it should work. It was quite a >> challenge, because of the way current ClientConnection code is >> structured. I tried to make the patch not incompatibly change public >> API of ClientConnection and related classes and I almost succeeded. >> The problematic part was the protected boolean >> ClientConnection.closed_ flag. If there is any sublclass of >> ClientConnection (apart from NetConnection which is derby code) that >> modifies this field, you are out of luck as changing (not only >> reading) this field directly my have an undesirable consequence (or >> it may not, since the only thing that changing these field to false >> would do is it would redundantly force performing the cleanup action. >> If the cleanup is idempotent, then all is OK). >> >> Further complication with ClientConnection is that it maintains a >> split state - some of it resides in ClientConnection and subclasses >> (such as NetConnection) and some of it in embedded object of Agent >> class and subclasses (such as NetAgent). Both - some of this state >> from connection object and some from the agent state are needed to >> perform the cleanup that is currently executed from the connection >> finalize() method. When using Cleaner API, we have to capture this >> state from both places (or more since each class has a hierarchy) and >> then arrange for cleanup action to use this state. Captured state can >> not reference the tracked object (ClientConnection in this case) >> either directly or indirectly since then it will never be GCed. When >> cleanup action is run, the tracked object is already unreachable - >> this is the main difference from finalize() where there is a phase in >> object's life-cycle where it is still reachable, albeit guaranteed >> only from the thread executing finalize() method. We can not capture >> the Agent object either, since it maintains a reference back to the >> ClientConnection object. All this is further complicated by the fact >> that captured state is mutable and we have to arrange for it to be >> mutated in both places. If the mutable state is captured by reference >> and the instance containing it never changes during the lifetime of >> the tracked container object, then it is easy - we just capture the >> object after the tracked container instance is constructed. If the >> captured state includes mutable fields directly in the tracked >> container object, then we must arrange for them to be synchronously >> mutated in two places. Such fields are: >> >> - ClientConnection.open_ (replicated in >> ClientConnection.CleanupAction.open) >> - Agent.logWriter_ (replicated in Agent.CleanupAction.logWriter) >> - NetAgent.rawSocketInputStream_ (replicated in >> NetAgent.NetCleanupAction.rawSocketInputStream) >> - NetAgent.rawSocketOutputStream_ (replicated in >> NetAgent.NetCleanupAction.rawSocketOutputStream) >> >> Fortunately all of this state is encapsulated with protected field >> ClientConnection.open_ being an exception. >> >> Note that Cleaner API also allows for cleanup action to be triggered >> explicitly, which then de-registers it. This is one of its advantages >> over finalize() where you can not deregister an object when it is >> already explicitly closed for example. finalize() will always be >> called even if closed explicitly. If you create lots of finalizable >> objects (such as connections, statements, etc...) and promptly >> close() them, they still wait for finalization and use resources >> (heap, CPU when GC searches for them, ReferenceHandler enqueues them, >> and finally finalize() method which is executed after the fact). >> Explicit triggering and de-registration of the cleanup action is >> performed in the ClientConnection.closeResourcesX() (called from >> public close() and closeResources()) after the connection has already >> being marked as closed. Cleanup action will be a no-op at this point, >> but it will also be de-registered. This is important to not bother GC >> with reference processing when it is not needed any more. In >> situations whre cleanup action logic is the same as explicit closing >> logic (in the case of ClientConnection it is not), close() method >> could just invoke cleanable.clean() and delegate the meat of >> processing to the cleanup action. >> >> Hope this non trivial example helps illustrate what is needed when >> converting finalize() to Cleanup API. >> >> Regards, Peter >> > From peter.levart at gmail.com Sun May 7 19:41:28 2017 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 7 May 2017 21:41:28 +0200 Subject: tutorial on using Cleaner-based finalization In-Reply-To: <256358c4-cb5a-134e-c0ad-c6bc8e5acaf7@gmail.com> References: <24c871ed-dd5f-80e5-6271-d70514a1d0b7@Oracle.com> <8c7cf854-61fd-521d-e743-9c3851188cb0@gmail.com> <92D5DFD6-CA04-48B5-AEE3-392B629FA0DD@oracle.com> <53097C93-0275-42D6-825E-43EAC3974A9F@oracle.com> <8ca9b992-51e8-341b-4326-53483ae8f663@gmail.com> <256358c4-cb5a-134e-c0ad-c6bc8e5acaf7@gmail.com> Message-ID: <661ea3f0-b23d-3545-5102-70c1ee726c73@gmail.com> Hi Rick, On 05/07/2017 08:59 PM, Rick Hillegas wrote: > Thanks for investigating that sample case, Peter, and for providing a > candidate solution. It is much appreciated. Your expert experience > confirms my amateur hunch that this migration is a non-trivial > re-factorization which merits its own mini-project. I have logged a > new technical debt issue to track that effort: > https://issues.apache.org/jira/browse/DERBY-6932 > > If I correctly understand what has been said so far, then I think that > we should be able to get away with a single Cleaner instance for each > component, essentially, one for each jar file which we build today. > After we convert Derby into jigsaw modules, that might translate into > one Cleaner instance for each module. I don't see any advantage to the > extra complexity of a separate Cleaner instance for each class which > currently implements finalize(). > > Does that sound reasonable to you? Each Cleaner instance means a separate thread which processes cleanup actions. If you create an instance in some common module and expose it to other modules, the same instance can be used in other modules that depend on it. Regards, Peter > > Thanks, > -Rick > > > On 5/6/17 2:19 PM, Peter Levart wrote: >> Thinking of this for some more time... >> >> Although this is a nice exercise in converting finalize() to Cleaner >> API, I strongly suspect that ClientConnection.finalize() is doing >> unnecessary things. What it does is it: >> >> - prints some trace message to logWriter >> - closes logWriter (whatever it is) >> - closes raw socket input and output streams >> - closes the socket >> - notifies listeners >> >> I believe all this is unnecessary (apart from notifying listeners >> perhaps?) as those objects already have their own cleanup mechanism >> when they are left behind. I believe there would be no resource leaks >> if ClientSocket.finalize() was simply removed. Before doing the >> conversion from finalize() to Cleaner API one should always ask >> himself whether finalize() method is actually needed. All 3rd party >> code (with notable exceptions which use JNI) are based on Java SE >> APIs and these APIs already take care of resources held by objects >> that are left behind. There's usually no need to do the same in the >> higher layers of 3rd party code. >> >> What do you think? >> >> Regards, Peter >> >> >> On 05/06/2017 10:01 PM, Peter Levart wrote: >>> Hi Rick and others, >>> >>> On 05/04/2017 06:48 PM, Lance Andersen wrote: >>>> Here are a few examples I believe: >>>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/am/ClientConnection.java >>>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/client/org/apache/derby/client/ClientPooledConnection.java >>>> http://svn.apache.org/repos/asf/db/derby/code/trunk/java/engine/org/apache/derby/impl/jdbc/EmbedPreparedStatement.java >>> >>> I took a bite at the 1st one (ClientConnection). Here's the result: >>> >>> http://cr.openjdk.java.net/~plevart/misc/Cleaner/derby/ClientConnection_finalize2cleaner.patch >>> >>> I haven't tested this, but I believe it should work. It was quite a >>> challenge, because of the way current ClientConnection code is >>> structured. I tried to make the patch not incompatibly change public >>> API of ClientConnection and related classes and I almost succeeded. >>> The problematic part was the protected boolean >>> ClientConnection.closed_ flag. If there is any sublclass of >>> ClientConnection (apart from NetConnection which is derby code) that >>> modifies this field, you are out of luck as changing (not only >>> reading) this field directly my have an undesirable consequence (or >>> it may not, since the only thing that changing these field to false >>> would do is it would redundantly force performing the cleanup >>> action. If the cleanup is idempotent, then all is OK). >>> >>> Further complication with ClientConnection is that it maintains a >>> split state - some of it resides in ClientConnection and subclasses >>> (such as NetConnection) and some of it in embedded object of Agent >>> class and subclasses (such as NetAgent). Both - some of this state >>> from connection object and some from the agent state are needed to >>> perform the cleanup that is currently executed from the connection >>> finalize() method. When using Cleaner API, we have to capture this >>> state from both places (or more since each class has a hierarchy) >>> and then arrange for cleanup action to use this state. Captured >>> state can not reference the tracked object (ClientConnection in this >>> case) either directly or indirectly since then it will never be >>> GCed. When cleanup action is run, the tracked object is already >>> unreachable - this is the main difference from finalize() where >>> there is a phase in object's life-cycle where it is still reachable, >>> albeit guaranteed only from the thread executing finalize() method. >>> We can not capture the Agent object either, since it maintains a >>> reference back to the ClientConnection object. All this is further >>> complicated by the fact that captured state is mutable and we have >>> to arrange for it to be mutated in both places. If the mutable state >>> is captured by reference and the instance containing it never >>> changes during the lifetime of the tracked container object, then it >>> is easy - we just capture the object after the tracked container >>> instance is constructed. If the captured state includes mutable >>> fields directly in the tracked container object, then we must >>> arrange for them to be synchronously mutated in two places. Such >>> fields are: >>> >>> - ClientConnection.open_ (replicated in >>> ClientConnection.CleanupAction.open) >>> - Agent.logWriter_ (replicated in Agent.CleanupAction.logWriter) >>> - NetAgent.rawSocketInputStream_ (replicated in >>> NetAgent.NetCleanupAction.rawSocketInputStream) >>> - NetAgent.rawSocketOutputStream_ (replicated in >>> NetAgent.NetCleanupAction.rawSocketOutputStream) >>> >>> Fortunately all of this state is encapsulated with protected field >>> ClientConnection.open_ being an exception. >>> >>> Note that Cleaner API also allows for cleanup action to be triggered >>> explicitly, which then de-registers it. This is one of its >>> advantages over finalize() where you can not deregister an object >>> when it is already explicitly closed for example. finalize() will >>> always be called even if closed explicitly. If you create lots of >>> finalizable objects (such as connections, statements, etc...) and >>> promptly close() them, they still wait for finalization and use >>> resources (heap, CPU when GC searches for them, ReferenceHandler >>> enqueues them, and finally finalize() method which is executed after >>> the fact). Explicit triggering and de-registration of the cleanup >>> action is performed in the ClientConnection.closeResourcesX() >>> (called from public close() and closeResources()) after the >>> connection has already being marked as closed. Cleanup action will >>> be a no-op at this point, but it will also be de-registered. This is >>> important to not bother GC with reference processing when it is not >>> needed any more. In situations whre cleanup action logic is the same >>> as explicit closing logic (in the case of ClientConnection it is >>> not), close() method could just invoke cleanable.clean() and >>> delegate the meat of processing to the cleanup action. >>> >>> Hope this non trivial example helps illustrate what is needed when >>> converting finalize() to Cleanup API. >>> >>> Regards, Peter >>> >> > From david.holmes at oracle.com Mon May 8 00:47:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 May 2017 10:47:08 +1000 Subject: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms In-Reply-To: References: Message-ID: Added back jdk10-dev as a bcc. Added hotspot-dev and core-libs-dev (for launcher) for follow up discussions. Hi John, On 8/05/2017 10:33 AM, John Platts wrote: > I actually did a search through the code that implements > JNI_CreateJavaVM, and I found that the conversion of the strings is done > using java_lang_String::create_from_platform_dependent_str, which > converts from the platform-default encoding to Unicode. In the case of > Windows-based platforms, the conversion is done based on the ANSI > character encoding instead of UTF-8 or Modified UTF-8. > > > The platform encoding detection logic on Windows is implemented > java_props_md.c, which can be found at > jdk/src/windows/native/java/lang/java_props_md.c in releases prior to > JDK 9 and at src/java.base/windows/native/libjava/java_props_md.c in JDK > 9 and later. The encoding used for command-line arguments passed into > the JNI invocation API is Cp1252 for English locales on Windows > platforms, and not Modified UTF-8 or UTF-8. > > > The documentation found > at http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html also > states that the strings passed into JNI_CreateJavaVM are in the > platform-default encoding. Thanks for the additional details. I assume you are referring to: typedef struct JavaVMOption { char *optionString; /* the option as a string in the default platform encoding */ that comment should not form part of the specification as it is non-normative text. If the intent is truly to use the platform default encoding and not UTF-8 then that should be very clearly spelt out in the spec! That said, the implementation is following this so it is a limitation. I suspect this is historical. > A version of JNI_CreateJavaVM that takes UTF-16-encoded strings should > be added to the JNI Invocation API. The java.exe launchers and javaw.exe > launchers should also be updated to use the UTF-16 version of the > JNI_CreateJavaVM function on Windows platforms and to use wmain and > wWinMain instead of main and WinMain. Why versions for UTF-16 instead of the missing UTF-8 variants? As I said the whole spec is intended to be based around UTF-8 so we would not want to throw in just a couple of UTF-16 based usages. Thanks, David > > A few files in HotSpot would need to be changed in order to implement > the UTF-16 version of JNI_CreateJavaVM, but the change would improve > consistency across different locales on Windows platforms and allow > arguments that contain Unicode characters that are not available in the > platform-default encoding to be passed into the JVM on the command line. > > > The UTF-16-based version of JNI_CreateJavaVM also makes it easier to > allocate string objects that contain non-ASCII characters as the strings > are already in UTF-16 format, at least in cases where the strings > contain Unicode characters that are not in Latin-1 or on VMs that do not > support compact Latin-1 strings. > > > The UTF-16-based version of JNI_CreateJavaVM should probably be > implemented as a separate function so that the solution could be > backported to JDK 8 and JDK 9 updates and so that backwards > compatibility with the current JNI_CreateJavaVM implementation is > maintained. > > > Here is what the new UTF-16-based API might look like: > > typedef struct JavaVMInitArgs_UTF16 { > jint version; > jint nOptions; > JavaVMOptionUTF16 *options; > jboolean ignoreUnrecognized; > } JavaVMInitArgs; > > > typedef struct JavaVMOption_UTF16 { > char *optionString; /* the option as a string in the default > platform encoding */ > void *extraInfo; > } JavaVMOptionUTF16; > > /* vm_args is an pointer to a JavaVMInitArgs_UTF16 structure */ > > jint JNI_CreateJavaVM_UTF16(JavaVM **p_vm, void **p_env, void *vm_args); > > > /* vm_args is a pointer to a JavaVMInitArgs_UTF16 structure */ > > jint JNI_GetDefaultJavaVMInitArgs_UTF16(void *vm_args); > > ------------------------------------------------------------------------ > *From:* David Holmes > *Sent:* Thursday, May 4, 2017 11:07 PM > *To:* John Platts; jdk10-dev at openjdk.java.net > *Subject:* Re: Add support for Unicode versions of JNI_CreateJavaVM and > JNI_GetDefaultJavaVMInitArgs on Windows platforms > > Hi John, > > The JNI is defined to use Modified UTF-8 format for strings, so any > Unicode character should be handled if passed in in the right format. > Updating the JNI specification and implementation to accept UTF-16 > directly would be a major undertaking. > > Is the issue here that you want a tool, like the java launcher, to > accept arbitrary Unicode strings in a end-user friendly manner and then > have it perform the modified UTF-8 conversion when invoking the VM? > > Can you give a concrete example of what you would like to be able to > pass as arguments to the JVM? > > Thanks, > David > > On 5/05/2017 1:04 PM, John Platts wrote: >> The JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods in the JNI invocation API expect ANSI strings on Windows platforms instead of Unicode-encoded strings. This is an issue on Windows-based platforms since some of the option strings that are passed into JNI_CreateJavaVM might contain Unicode characters that are not in > the ANSI encoding on Windows platforms. >> >> >> There is support for UTF-16 literals on Windows platforms with wchar_t and wide character literals prefixed with the L prefix, and on platforms that support C11 and C++11 with char16_t and UTF-16 character literals that are prefixed with the u prefix. >> >> >> jchar is currently defined to be a typedef for unsigned short on all platforms, but char16_t is a separate type and not a typedef for unsigned short or jchar in C++11 and later. jchar should be changed to be a typedef for wchar_t on Windows platforms and to be a typedef for char16_t on non-Windows platforms that support the > char16_t type. This change will make it possible to define jchar > character and string literals on Windows platforms and on non-Windows > platforms that support the C11 or C++11 standard. >> >> >> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on Windows: >> >> #define JCHAR_LITERAL(x) L ## x >> >> >> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on non-Windows platforms: >> >> #define JCHAR_LITERAL(x) u ## x >> >> >> Here is how the Unicode version of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs could be defined: >> >> typedef struct JavaVMUnicodeOption { >> const jchar *optionString; /* the option as a string in UTF-16 encoding */ >> void *extraInfo; >> } JavaVMUnicodeOption; >> >> typedef struct JavaVMUnicodeInitArgs { >> jint version; >> jint nOptions; >> JavaVMUnicodeOption *options; >> jboolean ignoreUnrecognized; >> } JavaVMUnicodeInitArgs; >> >> jint JNI_CreateJavaVMUnicode(JavaVM **pvm, void **penv, void *args); >> jint JNI_GetDefaultJavaVMInitArgs(void *args); >> >> The java.exe wrapper should use wmain instead of main on Windows platforms, and the javaw.exe wrapper should use wWinMain instead of WinMain on Windows platforms. This change, along with the support for Unicode-enabled version of the JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods, would allow the JVM to be > launched with arguments that contain Unicode characters that are not in > the platform-default encoding. >> >> All of the Windows platforms that Java SE 10 and later VMs would be supported on do support Unicode. Adding support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs will allow Unicode characters that are not in the platform-default encoding on Windows platforms to be supported in command-line arguments > that are passed to the JVM. >> From david.holmes at oracle.com Mon May 8 04:21:13 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 May 2017 14:21:13 +1000 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option In-Reply-To: <590DE9FB.7040608@oracle.com> References: <590DE9FB.7040608@oracle.com> Message-ID: Hi Kumar, On 7/05/2017 1:21 AM, Kumar Srinivasan wrote: > Hello, > > Please review the changes to remove the java launcher's data model > options -d32/-d64, these options existed to support Solaris dual-mode > operation, however for uniformity, these options were accepted by other > platforms as well. These options are now obsolete, and deprecated in > jdk9,and are now being removed. > > Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 > Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 This seems okay in itself, though I'm curious why you made the launcher/jli responsible for treating -d32/-d64 as invalid options instead of just passing them through to the VM to let it reject them as it does any other non-existent option eg: > java -foo -version Unrecognized option: -foo Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. I also see some pre-existing messiness you might want to tidy up while you're in the area :) src/java.base/macosx/native/libjli/java_md_macosx.c 378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg", 379 jrepath, FILESEP, FILESEP, "", ""); The last two %s should just be removed instead of passing empty strings. 422 } else { 423 /* 424 * macosx client library is built thin, i386 only. 425 * 64 bit client requests must load server library 426 */ 427 const char *jvmtypeUsed = "server"; 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, jrepath, jvmtypeUsed); 429 } I don't think we have ever had 32-bit client on OSX! So this whole clause seems strange. That aside you can just hardwire %s/lib/server instead of using the jvmTypeUsed variable. --- src/java.base/unix/native/libjli/java_md_solinux.c 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg", 324 jrepath, FILESEP, FILESEP, FILESEP); Another strange version of this code - only 4 %s this time, but adjacent FILESEP. :) I'm assuming this is from when was removed. Thanks, David > Thanks > Kumar > > PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have been > purged from internal test suites. > From david.holmes at oracle.com Mon May 8 05:30:42 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 8 May 2017 15:30:42 +1000 Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods In-Reply-To: <590CD221.4080100@oracle.com> References: <590CD221.4080100@oracle.com> Message-ID: <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com> Hi Ron, On 6/05/2017 5:27 AM, Ron Pressler wrote: > Hi, > Please review the following core/hotspot change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159995 > core webrev: > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/ > > hotspot webrev: > http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/ > > > This change is covered by existing tests. > > The following renaming was applied: > > - compareAndExchange*Volatile -> compareAndExchange* > - compareAndSwap* -> compareAndSet* So to clarify this for others, there was confusion surrounding the use of "swap" versus "exchange" when both words mean the same thing effectively, but the "swap" functions return a boolean, while the "exchange" functions return the old value. So we changed "swap" to "set" across the APIs - _except_ for the old /jdk.unsupported/share/classes/sun/misc/Unsafe.java because we can't change its exported API for compatibility reasons. Given any "swap(exp, new)" function can be implemented as "exchange(exp, new) == exp" I'm not sure why we have two complete sets of functions all the way through. But I guess that is a different issue. :) > - weakCompareAndSwap* -> weakCompareAndSet*Plain > - weakCompareAndSwap*Volatile -> weakCompareAndSet* > > At this stage, only method and hotspot intrinsic names were changed; > node names were left as-is, and may be handled in a separate issue. Overall looks good for libs and hotspot changes. One nit I spotted: src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java + * compareAndSwap for longs. While the intrinsic compareAndSetLong compareAndSwap should be compareAndSet --- All hotspot files need their copyright years updated to 2017 (if not already). As there are hotspot changes this must be pushed using JPRT and "-testset hotspot" (but your sponsor should know that :) ). Thanks, David > Ron From amy.lu at oracle.com Mon May 8 09:00:59 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 8 May 2017 17:00:59 +0800 Subject: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area Message-ID: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> Please review this test-only change to move the test library jdk/test/java/util/stream/bootlib to jdk/test/lib/testlibrary/bootlib to make it formally easier for tests to depend on. There is no change to the functionality of the tests. This patch also removed NullArgsTestCase.java which is an abstract class designed to be extended reused with a data provider. It provides no test itself but be wrongly put in the directory of TestNG.dirs thus be run as a test. In fact it is not even used and can be removed. bug: https://bugs.openjdk.java.net/browse/JDK-8085814 https://bugs.openjdk.java.net/browse/JDK-8173414 webrev: http://cr.openjdk.java.net/~amlu/8085814/webrev.00/ (I did not update the year in the Copyright header for bootlib files, to make the review easier. I can do bulk update for those files on the header before push, if that is necessary.) Thanks, Amy From m4rtntns at gmail.com Mon May 8 11:00:22 2017 From: m4rtntns at gmail.com (Martin T) Date: Mon, 8 May 2017 14:00:22 +0300 Subject: IBM RSA-II "virtual drive" feature does not work with OpenJDK Message-ID: Hi, first of all, I hope that this is a correct mailing list. I have an IBM server with Remote Supervisor Adapter II out-of-band card which provides a remote console function using an Java applet. It works fine with Java version 1.7.0_121 provided by openjdk-7-jre-headless package under Debian and IcedTea-Web plugin version 1.5.3 except one can not use "virtual drive" function: http://i.imgur.com/qDqlFPR.png However, this "virtual drive" feature works fine under Windows(IE 7.0.5730.13, Java SE 1.6.0.05): http://i.imgur.com/a8H7lXn.jpg If I start my browser(Firefox 45.9.0) from the terminal and launch the applet, then it logs following error: java.lang.UnsatisfiedLinkError: VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices; at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method) at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source) at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source) at sun.applet.AppletPanel.run(AppletPanel.java:476) at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90) at java.lang.Thread.run(Thread.java:745) I also tried with OpenJDK version 1.8.0_121, but the error message was almost exactly the same: java.lang.UnsatisfiedLinkError: VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices; at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method) at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source) at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source) at sun.applet.AppletPanel.run(AppletPanel.java:476) at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:84) at java.lang.Thread.run(Thread.java:745) Is this feature not supported by OpenJDK? Please let me know if I can provide any additional information for troubleshooting. thanks, Martin From dalibor.topic at oracle.com Mon May 8 11:45:34 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 8 May 2017 13:45:34 +0200 Subject: IBM RSA-II "virtual drive" feature does not work with OpenJDK In-Reply-To: References: Message-ID: Hi Martin, we don't provide OpenJDK binaries in Linux distributions. I'd suggest reporting it to the provider of your binaries directly (Debian in this case), as we don't provide a browser plugin implementation, either. Alternatively, you may want to give the distro-pkg-dev mailing list a try, where the developers of the IcedTea-Web plugin and/or Debian packages may be found. cheers, dalibor topic On 08.05.2017 13:00, Martin T wrote: > Hi, > > first of all, I hope that this is a correct mailing list. > > I have an IBM server with Remote Supervisor Adapter II out-of-band > card which provides a remote console function using an Java applet. It > works fine with Java version 1.7.0_121 provided by > openjdk-7-jre-headless package under Debian and IcedTea-Web plugin > version 1.5.3 except one can not use "virtual drive" function: > http://i.imgur.com/qDqlFPR.png However, this "virtual drive" feature > works fine under Windows(IE 7.0.5730.13, Java SE 1.6.0.05): > http://i.imgur.com/a8H7lXn.jpg > > > If I start my browser(Firefox 45.9.0) from the terminal and launch the > applet, then it logs following error: > > java.lang.UnsatisfiedLinkError: > VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices; > at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method) > at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source) > at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source) > at sun.applet.AppletPanel.run(AppletPanel.java:476) > at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:90) > at java.lang.Thread.run(Thread.java:745) > > I also tried with OpenJDK version 1.8.0_121, but the error message was > almost exactly the same: > > java.lang.UnsatisfiedLinkError: > VirtualDrive.PassThroughCommand.GetSupportedDevices()LVirtualDrive/SupportedDevices; > at VirtualDrive.PassThroughCommand.GetSupportedDevices(Native Method) > at com.ibm.asm.remotedisk.RemoteDisk.buildDriveList(Unknown Source) > at com.ibm.asm.remotedisk.RemoteDisk.start(Unknown Source) > at sun.applet.AppletPanel.run(AppletPanel.java:476) > at sun.applet.AppletViewerPanelAccess.run(AppletViewerPanelAccess.java:84) > at java.lang.Thread.run(Thread.java:745) > > > Is this feature not supported by OpenJDK? Please let me know if I can > provide any additional information for troubleshooting. > > > thanks, > Martin > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From neugens.limasoftware at gmail.com Mon May 8 12:07:37 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 8 May 2017 14:07:37 +0200 Subject: IBM RSA-II "virtual drive" feature does not work with OpenJDK In-Reply-To: References: Message-ID: 2017-05-08 13:45 GMT+02:00 dalibor topic : > Hi Martin, > > we don't provide OpenJDK binaries in Linux distributions. > > I'd suggest reporting it to the provider of your binaries directly (Debian > in this case), as we don't provide a browser plugin implementation, either. > Alternatively, you may want to give the distro-pkg-dev mailing list a try, > where the developers of the IcedTea-Web plugin and/or Debian packages may be > found. > > cheers, > dalibor topic This is probably something to report to IBM first, I suspect some use of some weird hidden internal code. Jigsaw is long overdue... Cheers, Mario -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From m4rtntns at gmail.com Mon May 8 12:37:44 2017 From: m4rtntns at gmail.com (Martin T) Date: Mon, 8 May 2017 15:37:44 +0300 Subject: IBM RSA-II "virtual drive" feature does not work with OpenJDK In-Reply-To: References: Message-ID: On Mon, May 8, 2017 at 3:07 PM, Mario Torre wrote: > 2017-05-08 13:45 GMT+02:00 dalibor topic : >> Hi Martin, >> >> we don't provide OpenJDK binaries in Linux distributions. >> >> I'd suggest reporting it to the provider of your binaries directly (Debian >> in this case), as we don't provide a browser plugin implementation, either. >> Alternatively, you may want to give the distro-pkg-dev mailing list a try, >> where the developers of the IcedTea-Web plugin and/or Debian packages may be >> found. >> >> cheers, >> dalibor topic > > This is probably something to report to IBM first, I suspect some use > of some weird hidden internal code. Jigsaw is long overdue... > > Cheers, > Mario > -- > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > Proud GNU Classpath developer: http://www.classpath.org/ > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > Please, support open standards: > http://endsoftpatents.org/ Mario, when I start the applet, then it downloads libibmxrdisk.so.1.0.3 binary which I guess is a native library(Java Native Interface) for Linux operating system: # file /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped # # strings /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 | grep GetSupportedDevices Java_VirtualDrive_PassThroughCommand_GetSupportedDevices GetSupportedDevices Java_VirtualDrive_PassThroughCommand_GetSupportedDevices # I also guess that this is provided by IBM and it's probably broken? Under Windows operating system it seems to download a dll file according to Java Console: ClientInterface::downloadLib: downloaded C:\Documents and Settings\user\IBM\10.10.10.65\remotedrive3d.dll in 1 attempts. So I guess either the libibmxrdisk.so.1.0.3 is broken or my Linux version is not compatible with this native library..? thanks, Martin From neugens.limasoftware at gmail.com Mon May 8 12:42:01 2017 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 08 May 2017 12:42:01 +0000 Subject: IBM RSA-II "virtual drive" feature does not work with OpenJDK In-Reply-To: References: Message-ID: Hi Martin, As I said, you need to report that to IBM, they will guide you. Cheers, Mario On Mon 8. May 2017 at 14:37, Martin T wrote: > On Mon, May 8, 2017 at 3:07 PM, Mario Torre > wrote: > > 2017-05-08 13:45 GMT+02:00 dalibor topic : > >> Hi Martin, > >> > >> we don't provide OpenJDK binaries in Linux distributions. > >> > >> I'd suggest reporting it to the provider of your binaries directly > (Debian > >> in this case), as we don't provide a browser plugin implementation, > either. > >> Alternatively, you may want to give the distro-pkg-dev mailing list a > try, > >> where the developers of the IcedTea-Web plugin and/or Debian packages > may be > >> found. > >> > >> cheers, > >> dalibor topic > > > > This is probably something to report to IBM first, I suspect some use > > of some weird hidden internal code. Jigsaw is long overdue... > > > > Cheers, > > Mario > > -- > > pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF > > Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF > > > > Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens > > Proud GNU Classpath developer: http://www.classpath.org/ > > OpenJDK: http://openjdk.java.net/projects/caciocavallo/ > > > > Please, support open standards: > > http://endsoftpatents.org/ > > Mario, > > when I start the applet, then it downloads libibmxrdisk.so.1.0.3 > binary which I guess is a native library(Java Native Interface) for > Linux operating system: > > # file /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 > /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3: ELF 32-bit LSB shared > object, Intel 80386, version 1 (SYSV), dynamically linked, not > stripped > # > # strings /root/IBM/10.10.10.65/libibmxrdisk.so.1.0.3 | grep > GetSupportedDevices > Java_VirtualDrive_PassThroughCommand_GetSupportedDevices > GetSupportedDevices > Java_VirtualDrive_PassThroughCommand_GetSupportedDevices > # > > I also guess that this is provided by IBM and it's probably broken? > Under Windows operating system it seems to download a dll file > according to Java Console: > > ClientInterface::downloadLib: downloaded C:\Documents and > Settings\user\IBM\10.10.10.65\remotedrive3d.dll in 1 attempts. > > > So I guess either the libibmxrdisk.so.1.0.3 is broken or my Linux > version is not compatible with this native library..? > > > thanks, > Martin > From dalibor.topic at oracle.com Mon May 8 12:54:14 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 8 May 2017 14:54:14 +0200 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: On 05.05.2017 08:39, Jeremy Manson wrote: > Mostly, I'm telling you all because I think it makes an interesting case > study - a large Java installation and the issues it faces trying to roll > out JDK 9. Indeed - thank you for providing valuable insight into your concerns and experiences. > If other installations do the kinds of things that we do, the path to a > JDK 9 without lots of add-exports and kill switch options is likely to > be slow and laborious for them. We're comparatively well situated to do > it - we have our own JDK build and a staffed team to do / help with the > migration, and are likely to roll it out to everyone with the kill > switch turned on by default so that our awful hacks can stay put until > we finish fixing them. I think part of responsibly relying on awful hacks leveraging unsupported behavior is to budget for their removal/rewrite as the assumptions behind them get invalidated over time. Sometimes, it might be well known where the awful hacks are buried, in particular with one's own code. Other times, in particular with third party code, it might not be quite as obvious. That's where the jdeps & jdeprscan tools come in to help get a sense of the scope & intensity of such problems at compile time. The kill switch complements that at runtime. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From eolivelli at gmail.com Mon May 8 13:16:24 2017 From: eolivelli at gmail.com (Enrico Olivelli) Date: Mon, 8 May 2017 15:16:24 +0200 Subject: Accessing UNIX FileDescriptor id without reflection Message-ID: Hi, I am trying to port a project (Apache BookKeeper) to Java9, actually this code uses reflection in order to access the 'fd' field of the FileDescriptor class. We have to access that ID in order to call low level native functions See https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java # getSysFileDescriptor Is there any way to access the FD handle without using reflecttion ? If not, is it possibile to enhance the FileDescriptor API in order to given access to the internal "fd" field ? Thank you Enrico Olivelli From forax at univ-mlv.fr Mon May 8 14:14:36 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 8 May 2017 16:14:36 +0200 (CEST) Subject: Accessing UNIX FileDescriptor id without reflection In-Reply-To: References: Message-ID: <389905192.345751.1494252876022.JavaMail.zimbra@u-pem.fr> I agree that a method getFd should be great, we will need this kind of value if we want to use Panama. Did you try to serializing the FileDescriptor in memory and extract the int corresponding to the file descriptor ? cheers, R?mi ----- Mail original ----- > De: "Enrico Olivelli" > ?: core-libs-dev at openjdk.java.net > Envoy?: Lundi 8 Mai 2017 15:16:24 > Objet: Accessing UNIX FileDescriptor id without reflection > Hi, > I am trying to port a project (Apache BookKeeper) to Java9, actually > this code uses reflection in order to access the 'fd' field of the > FileDescriptor class. > > We have to access that ID in order to call low level native functions > > See > https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java > # getSysFileDescriptor > > Is there any way to access the FD handle without using reflecttion ? > If not, is it possibile to enhance the FileDescriptor API in order to > given access to the internal "fd" field ? > > Thank you > > Enrico Olivelli From kumar.x.srinivasan at oracle.com Mon May 8 14:27:19 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 08 May 2017 07:27:19 -0700 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option In-Reply-To: References: <590DE9FB.7040608@oracle.com> Message-ID: <59108047.9090003@oracle.com> Hi David, > Hi Kumar, > > On 7/05/2017 1:21 AM, Kumar Srinivasan wrote: >> Hello, >> >> Please review the changes to remove the java launcher's data model >> options -d32/-d64, these options existed to support Solaris dual-mode >> operation, however for uniformity, these options were accepted by other >> platforms as well. These options are now obsolete, and deprecated in >> jdk9,and are now being removed. >> >> Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 > > This seems okay in itself, though I'm curious why you made the > launcher/jli responsible for treating -d32/-d64 as invalid options > instead of just passing them through to the VM to let it reject them > as it does any other non-existent option eg: I mulled over this for sometime, and felt that since the launcher supported these options before, it should give a better/reasonable error message than the VM does. I am undecided. What do you think ? > > > java -foo -version > Unrecognized option: -foo > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. > > I also see some pre-existing messiness you might want to tidy up while > you're in the area :) OMG Pre-existing conditions. ;) > > src/java.base/macosx/native/libjli/java_md_macosx.c > > 378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg", > 379 jrepath, FILESEP, FILESEP, "", ""); > > The last two %s should just be removed instead of passing empty strings. > > 422 } else { > 423 /* > 424 * macosx client library is built thin, i386 only. > 425 * 64 bit client requests must load server library > 426 */ > 427 const char *jvmtypeUsed = "server"; > 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, > jrepath, jvmtypeUsed); > 429 } > > I don't think we have ever had 32-bit client on OSX! So this whole > clause seems strange. That aside you can just hardwire %s/lib/server > instead of using the jvmTypeUsed variable. +1, I think we did support 32-bit for sometime, in the early days of MacOSX. > > --- > > src/java.base/unix/native/libjli/java_md_solinux.c > > 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg", > 324 jrepath, FILESEP, FILESEP, FILESEP); > > Another strange version of this code - only 4 %s this time, but > adjacent FILESEP. :) I'm assuming this is from when was removed. Urk. Ok I will revisit the above, good catches!, and prepare another changeset. Kumar > > Thanks, > David > >> Thanks >> Kumar >> >> PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have >> been >> purged from internal test suites. >> From peter.levart at gmail.com Mon May 8 15:01:48 2017 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 8 May 2017 17:01:48 +0200 Subject: Accessing UNIX FileDescriptor id without reflection In-Reply-To: References: Message-ID: Hi Enrico, java.io.FileDescriptor is a public class, part of public API. There's one version for JVMs running on UNIX-based OSes and another for JVMs running on Windows. Both contain int field 'fd'. But you already know that if you access this field using reflection. Now instead of doing this in Java and then passing the numberic 'fd' down to native code, you could pass the whole FileDescriptor object to native code and access the field using JNI. There's no restriction imposed by Jigsaw in JNI. Regards, Peter On 05/08/2017 03:16 PM, Enrico Olivelli wrote: > Hi, > I am trying to port a project (Apache BookKeeper) to Java9, actually > this code uses reflection in order to access the 'fd' field of the > FileDescriptor class. > > We have to access that ID in order to call low level native functions > > See > https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java > # getSysFileDescriptor > > Is there any way to access the FD handle without using reflecttion ? > If not, is it possibile to enhance the FileDescriptor API in order to > given access to the internal "fd" field ? > > Thank you > > Enrico Olivelli From Roger.Riggs at Oracle.com Mon May 8 15:45:25 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 8 May 2017 11:45:25 -0400 Subject: Accessing UNIX FileDescriptor id without reflection In-Reply-To: <389905192.345751.1494252876022.JavaMail.zimbra@u-pem.fr> References: <389905192.345751.1494252876022.JavaMail.zimbra@u-pem.fr> Message-ID: Hi, I would be very cautious about giving out fds for arbitrary FileDescriptors. With concurrency and threading, how do you make sure that it does not not get closed and someone's code still has the fd and uses it later? Or worse yet, the fd gets re-used and then it is possible to operate on the wrong file. Quite a bit of implementation code assumes it has complete control over the lifecycle of the FileDescriptor. Exposing the raw FD breaks the encapsulation. As R?mi suggests, passing the FileDescriptor to native will at least maintain the current encapsulation. Roger On 5/8/2017 10:14 AM, Remi Forax wrote: > I agree that a method getFd should be great, we will need this kind of value if we want to use Panama. > > Did you try to serializing the FileDescriptor in memory and extract the int corresponding to the file descriptor ? > > cheers, > R?mi > > ----- Mail original ----- >> De: "Enrico Olivelli" >> ?: core-libs-dev at openjdk.java.net >> Envoy?: Lundi 8 Mai 2017 15:16:24 >> Objet: Accessing UNIX FileDescriptor id without reflection >> Hi, >> I am trying to port a project (Apache BookKeeper) to Java9, actually >> this code uses reflection in order to access the 'fd' field of the >> FileDescriptor class. >> >> We have to access that ID in order to call low level native functions >> >> See >> https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java >> # getSysFileDescriptor >> >> Is there any way to access the FD handle without using reflection ? >> If not, is it possibile to enhance the FileDescriptor API in order to >> given access to the internal "fd" field ? >> >> Thank you >> >> Enrico Olivelli From forax at univ-mlv.fr Mon May 8 16:37:52 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 8 May 2017 18:37:52 +0200 (CEST) Subject: Accessing UNIX FileDescriptor id without reflection In-Reply-To: References: <389905192.345751.1494252876022.JavaMail.zimbra@u-pem.fr> Message-ID: <1740416405.359685.1494261472637.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Roger Riggs" > ?: core-libs-dev at openjdk.java.net > Envoy?: Lundi 8 Mai 2017 17:45:25 > Objet: Re: Accessing UNIX FileDescriptor id without reflection > Hi, > > I would be very cautious about giving out fds for arbitrary FileDescriptors. > With concurrency and threading, how do you make sure that it does not > not get closed > and someone's code still has the fd and uses it later? Or worse yet, > the fd gets re-used > and then it is possible to operate on the wrong file. > Quite a bit of implementation code assumes it has complete control over > the lifecycle of > the FileDescriptor. Exposing the raw FD breaks the encapsulation. > > As R?mi suggests, passing the FileDescriptor to native will at least > maintain the current > encapsulation. s/R?mi/Peter Peter is right, i'm wrong :) > > Roger R?mi > > > On 5/8/2017 10:14 AM, Remi Forax wrote: >> I agree that a method getFd should be great, we will need this kind of value if >> we want to use Panama. >> >> Did you try to serializing the FileDescriptor in memory and extract the int >> corresponding to the file descriptor ? >> >> cheers, >> R?mi >> >> ----- Mail original ----- >>> De: "Enrico Olivelli" >>> ?: core-libs-dev at openjdk.java.net >>> Envoy?: Lundi 8 Mai 2017 15:16:24 >>> Objet: Accessing UNIX FileDescriptor id without reflection >>> Hi, >>> I am trying to port a project (Apache BookKeeper) to Java9, actually >>> this code uses reflection in order to access the 'fd' field of the >>> FileDescriptor class. >>> >>> We have to access that ID in order to call low level native functions >>> >>> See >>> https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java >>> # getSysFileDescriptor >>> >>> Is there any way to access the FD handle without using reflection ? >>> If not, is it possibile to enhance the FileDescriptor API in order to >>> given access to the internal "fd" field ? >>> >>> Thank you >>> > >> Enrico Olivelli From paul.sandoz at oracle.com Mon May 8 17:33:30 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 May 2017 10:33:30 -0700 Subject: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area In-Reply-To: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> References: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> Message-ID: <662CEC09-CC50-41A5-93B9-2135811AC400@oracle.com> Hi Amy, The changes look good. Would you mind re-basing this fix for JDK 10 instead? At this point we should be more conservative with such changes (even for tests). Thanks, Paul. > On 8 May 2017, at 02:00, Amy Lu wrote: > > Please review this test-only change to move the test library > jdk/test/java/util/stream/bootlib > to > jdk/test/lib/testlibrary/bootlib > to make it formally easier for tests to depend on. > > There is no change to the functionality of the tests. > > This patch also removed NullArgsTestCase.java which is an abstract class designed to be extended reused with a data provider. It provides no test itself but be wrongly put in the directory of TestNG.dirs thus be run as a test. In fact it is not even used and can be removed. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8085814 > https://bugs.openjdk.java.net/browse/JDK-8173414 > > webrev: > http://cr.openjdk.java.net/~amlu/8085814/webrev.00/ > (I did not update the year in the Copyright header for bootlib files, to make the review easier. I can do bulk update for those files on the header before push, if that is necessary.) > > Thanks, > Amy > > From brian.burkhalter at oracle.com Mon May 8 17:37:47 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 10:37:47 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: Message-ID: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Thanks for the patch. The correct forum is core-libs-dev at openjdk.java.net, which I have CCed. Brian On May 7, 2017, at 5:16 PM, Isaac Levy wrote: > Apologies if this is the wrong forum, I'm new to the OpenJDK project. From isaac.r.levy at gmail.com Mon May 8 18:14:28 2017 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Mon, 8 May 2017 14:14:28 -0400 Subject: Long.bitCount micro-optimization In-Reply-To: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Message-ID: Original message below: The JDK impl of bitCount can be improved -- though most users will get the hotspot intrinsic. The best source I could find for the suggestion below is page 195: http://support.amd.com/techdocs/25112.pdf Cheers, Isaac Levy Proposed Long.bitCount and Integer.bitCount: public static int bitCount(long i) { i -= (i >>> 1) & 0x5555555555555555L; i = (i & 0x3333333333333333L) + ((i >>> 2) & 0x3333333333333333L); i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL; return (i * 0x0101010101010101L) >>> 56; } public static int bitCount(int i) { i -= (i >>> 1) & 0x55555555; i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); i = (i + (i >>> 4)) & 0x0f0f0f0f; return (i * 0x01010101) >>> 24; } From huizhe.wang at oracle.com Mon May 8 18:17:50 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Mon, 8 May 2017 11:17:50 -0700 Subject: RFR (JAXP) 8150256: removing xerces-related dead code Message-ID: Hi, Please review removing three unused classes from the jaxp repo. JBS: https://bugs.openjdk.java.net/browse/JDK-8150256 Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/ Tests: passed Refer to the jaxp change history [1], the following changes in particular: - - protected XPointerFramework fXPointerFramework = null; - protected XPointerSchema [] fXPointerSchema; - The references to these classes were removed during the early JDK 6 development. [1] https://java.net/projects/jaxp-sources/sources/svn/diff/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java?rev1=509&rev2=510 Thanks, Joe From lance.andersen at oracle.com Mon May 8 18:33:34 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 8 May 2017 14:33:34 -0400 Subject: RFR (JAXP) 8150256: removing xerces-related dead code In-Reply-To: References: Message-ID: +1 > On May 8, 2017, at 2:17 PM, huizhe wang wrote: > > Hi, > > Please review removing three unused classes from the jaxp repo. > JBS: https://bugs.openjdk.java.net/browse/JDK-8150256 > Webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8150256/webrev/ > Tests: passed > > Refer to the jaxp change history [1], the following changes in particular: > > - - protected XPointerFramework fXPointerFramework = null; - protected XPointerSchema [] fXPointerSchema; - > > The references to these classes were removed during the early JDK 6 development. > > > [1] https://java.net/projects/jaxp-sources/sources/svn/diff/trunk/xml-xerces/java/src/com/sun/org/apache/xerces/internal/xinclude/XIncludeHandler.java?rev1=509&rev2=510 > > Thanks, > Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From jeremymanson at google.com Mon May 8 18:49:16 2017 From: jeremymanson at google.com (Jeremy Manson) Date: Mon, 8 May 2017 11:49:16 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: On Mon, May 8, 2017 at 5:54 AM, dalibor topic wrote: > On 05.05.2017 08:39, Jeremy Manson wrote: > >> Mostly, I'm telling you all because I think it makes an interesting case >> study - a large Java installation and the issues it faces trying to roll >> out JDK 9. >> > > Indeed - thank you for providing valuable insight into your concerns and > experiences. > > If other installations do the kinds of things that we do, the path to a >> JDK 9 without lots of add-exports and kill switch options is likely to >> be slow and laborious for them. We're comparatively well situated to do >> it - we have our own JDK build and a staffed team to do / help with the >> migration, and are likely to roll it out to everyone with the kill >> switch turned on by default so that our awful hacks can stay put until >> we finish fixing them. >> > > I think part of responsibly relying on awful hacks leveraging unsupported > behavior is to budget for their removal/rewrite as the assumptions behind > them get invalidated over time. > And we generally do go through this at every JDK release cycle. This is hardly the only time we've had to do a lot of unpleasant work. A fun one was in the Java 6->7 timeframe, when it turned out the fact that the JDK iterated over methods in approximately-declaration order spilled over into many, many tests, even though that was implementation-dependent behavior. There was a very painful cleanup for everyone working on Java here. We didn't mind doing that, because we knew it was an important part of the metaspace work. However, we did put in a JDK flag to mimic the old behavior, for transitional purposes. Sometimes, it might be well known where the awful hacks are buried, in > particular with one's own code. Other times, in particular with third party > code, it might not be quite as obvious. That's where the jdeps & jdeprscan > tools come in to help get a sense of the scope & intensity of such problems > at compile time. > > The kill switch complements that at runtime. I'm sure we can mostly work around the compile-time stuff. Similar situations arise whenever an unsupported method is removed or changed. I recall we had to orchestrate a migration to javax.imageio from (something else? can't remember) when we moved to OpenJDK. We now have the moral equivalent of a lot of unsupported methods being removed - even though they aren't being removed, they are being hidden. In general, I don't think it is worth complaining about that, especially since we have the kill switch. We shouldn't have much problem analyzing our dependencies - we build everything feasible from source at head, and have a very comprehensive suite of tests, so if there is a broken dependency in third party code, we should know immediately. In general, our upgrade strategy involves getting the world into a state that works with both JDKs, and then switching the JDKs out from underneath. We are most likely to have to put our own hacks in the JDK for the things for which "what you do in Java 8" and "what you do in Java 9" can't be the same (or getting them to be the same is very difficult, or a bad idea). >From that perspective, the bootclasspath situation is interesting. There is no Xbootclasspath/p flag in Java 9, and no --add-exports or --patch-module in Java 8, so there is no state that will work with both. We could comb through every use in our repo, and add extra code to detect which JDK we are using / switch between them. Then, after the transition, we could delete all of that extra code. However, that would be meaningfully harder than just putting Xbootclasspath/p back for the transition, and it would leave our command lines less readable. The better thing for us to do is almost certainly to allow users to use Xbootclasspath/p until we kill Java 8 internally. Turning the big kill switch on by default, by comparison, is more similar to the method iteration situation in Java 7; if we work hard, we can probably get the world into a single state that will work without making everyone's code worse. However, doing that migration up front would be a headache that will take time, and, typically, the more time we take, the more incompatibilities crop up. So, starting with the kill switch on by default should be a time saver. Jeremy > > cheers, > dalibor topic > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > From eolivelli at gmail.com Mon May 8 20:11:58 2017 From: eolivelli at gmail.com (Enrico Olivelli) Date: Mon, 08 May 2017 20:11:58 +0000 Subject: Accessing UNIX FileDescriptor id without reflection In-Reply-To: <1740416405.359685.1494261472637.JavaMail.zimbra@u-pem.fr> References: <389905192.345751.1494252876022.JavaMail.zimbra@u-pem.fr> <1740416405.359685.1494261472637.JavaMail.zimbra@u-pem.fr> Message-ID: Il lun 8 mag 2017, 18:38 Remi Forax ha scritto: > > > ----- Mail original ----- > > De: "Roger Riggs" > > ?: core-libs-dev at openjdk.java.net > > Envoy?: Lundi 8 Mai 2017 17:45:25 > > Objet: Re: Accessing UNIX FileDescriptor id without reflection > > > Hi, > > > > I would be very cautious about giving out fds for arbitrary > FileDescriptors. > > With concurrency and threading, how do you make sure that it does not > > not get closed > > and someone's code still has the fd and uses it later? Or worse yet, > > the fd gets re-used > > and then it is possible to operate on the wrong file. > > Quite a bit of implementation code assumes it has complete control over > > the lifecycle of > > the FileDescriptor. Exposing the raw FD breaks the encapsulation. > > > > As R?mi suggests, passing the FileDescriptor to native will at least > > maintain the current > > encapsulation. > I like this option. I will give it a try. Thank you all very much Enrico > s/R?mi/Peter > Peter is right, i'm wrong :) > > > > > Roger > > R?mi > > > > > > > On 5/8/2017 10:14 AM, Remi Forax wrote: > >> I agree that a method getFd should be great, we will need this kind of > value if > >> we want to use Panama. > >> > >> Did you try to serializing the FileDescriptor in memory and extract the > int > >> corresponding to the file descriptor ? > >> > >> cheers, > >> R?mi > >> > >> ----- Mail original ----- > >>> De: "Enrico Olivelli" > >>> ?: core-libs-dev at openjdk.java.net > >>> Envoy?: Lundi 8 Mai 2017 15:16:24 > >>> Objet: Accessing UNIX FileDescriptor id without reflection > >>> Hi, > >>> I am trying to port a project (Apache BookKeeper) to Java9, actually > >>> this code uses reflection in order to access the 'fd' field of the > >>> FileDescriptor class. > >>> > >>> We have to access that ID in order to call low level native functions > >>> > >>> See > >>> > https://github.com/apache/bookkeeper/blob/master/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/NativeIO.java > >>> # getSysFileDescriptor > >>> > >>> Is there any way to access the FD handle without using reflection ? > >>> If not, is it possibile to enhance the FileDescriptor API in order to > >>> given access to the internal "fd" field ? > >>> > >>> Thank you > >>> > > >> Enrico Olivelli > -- -- Enrico Olivelli From dl at cs.oswego.edu Mon May 8 20:29:04 2017 From: dl at cs.oswego.edu (Doug Lea) Date: Mon, 8 May 2017 16:29:04 -0400 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Message-ID: On 05/08/2017 02:14 PM, Isaac Levy wrote: > Original message below: > > The JDK impl of bitCount can be improved -- though most users will get > the hotspot intrinsic. The best source I could find for the suggestion > below is page 195: http://support.amd.com/techdocs/25112.pdf > The int version differs from current implementation in that it uses one multiply instead of two shift+adds. (Similarly for long.) I wonder if there is any processor that does not already have a bit-count instruction for which this is actually faster? Some evidence either way would be helpful. -Doug > Cheers, > Isaac Levy > > > Proposed Long.bitCount and Integer.bitCount: > > > public static int bitCount(long i) > { > i -= (i >>> 1) & 0x5555555555555555L; > i = (i & 0x3333333333333333L) + ((i >>> 2) & 0x3333333333333333L); > i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL; > return (i * 0x0101010101010101L) >>> 56; > } > > > public static int bitCount(int i) { > i -= (i >>> 1) & 0x55555555; > i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); > i = (i + (i >>> 4)) & 0x0f0f0f0f; > return (i * 0x01010101) >>> 24; > } > From lance.andersen at oracle.com Mon May 8 20:38:12 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Mon, 8 May 2017 16:38:12 -0400 Subject: RFR: 8176508 Update JAX-WS RI integration to latest version In-Reply-To: <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com> <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com> Message-ID: Hi Roman, I made a pass through the webrev and have the following feedback: src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted. Also what happens to the svn info in this file with the move to github? src/java.xml.ws/share/classes/javax/xml/soap/package-info.java - I would use ™ for TM src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java - I would make the comments starting at 139 be consistent with the other comments src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted src/jdk.xml.bind/share/classes/module-info.java should already be updated in the workspace src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017 src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java - the copyright was reverted src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017 src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017 src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017 src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already > On May 3, 2017, at 12:49 PM, Roman Grigoriadi wrote: > > Hi, > > you can find new web rev here: > http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/ > > Previous review comments are addressed. > >> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. > > > Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example > in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties > There is: > # for JDK integration - include version in source zip > jaxb.jdk.version=2.3.0-b170412.1723 > > We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo. > > Roman > > >> On 12 Mar 2017, at 16:14, Alan Bateman wrote: >> >> >> >> On 12/03/2017 14:39, Roman Grigoriadi wrote: >>> Hi, >>> >>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 >>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ >>> >> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review). >> >> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas. >> >> In MailcapCommandMap then the following doesn't seem right for the class description: >> >> 59 * (Where java.home is the value of the "java.home" System property >> 60 * and conf is the directory named "conf" if it exists, >> 61 * otherwise the directory named "lib"; the "conf" directory was >> 62 * introduced in JDK 1.9.) >> >> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases. >> >> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class. >> >> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project. >> >> -Alan > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From david.holmes at oracle.com Mon May 8 20:56:35 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 06:56:35 +1000 Subject: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area In-Reply-To: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> References: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> Message-ID: <5558c5b1-5270-36aa-1063-af8aad318f45@oracle.com> Hi Amy, Not a review ... On 8/05/2017 7:00 PM, Amy Lu wrote: > Please review this test-only change to move the test library > jdk/test/java/util/stream/bootlib > to > jdk/test/lib/testlibrary/bootlib > to make it formally easier for tests to depend on. > > There is no change to the functionality of the tests. > > This patch also removed NullArgsTestCase.java which is an abstract class > designed to be extended reused with a data provider. It provides no test > itself but be wrongly put in the directory of TestNG.dirs thus be run as > a test. In fact it is not even used and can be removed. > > bug: > https://bugs.openjdk.java.net/browse/JDK-8085814 > https://bugs.openjdk.java.net/browse/JDK-8173414 > > webrev: > http://cr.openjdk.java.net/~amlu/8085814/webrev.00/ > (I did not update the year in the Copyright header for bootlib files, to If the bootlib files were simply moved then no update to their copyright year is needed. Cheers, David > make the review easier. I can do bulk update for those files on the > header before push, if that is necessary.) > > Thanks, > Amy > > From david.holmes at oracle.com Mon May 8 21:30:41 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 07:30:41 +1000 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option In-Reply-To: <59108047.9090003@oracle.com> References: <590DE9FB.7040608@oracle.com> <59108047.9090003@oracle.com> Message-ID: Hi Kumar, On 9/05/2017 12:27 AM, Kumar Srinivasan wrote: > > Hi David, > >> Hi Kumar, >> >> On 7/05/2017 1:21 AM, Kumar Srinivasan wrote: >>> Hello, >>> >>> Please review the changes to remove the java launcher's data model >>> options -d32/-d64, these options existed to support Solaris dual-mode >>> operation, however for uniformity, these options were accepted by other >>> platforms as well. These options are now obsolete, and deprecated in >>> jdk9,and are now being removed. >>> >>> Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 >> >> This seems okay in itself, though I'm curious why you made the >> launcher/jli responsible for treating -d32/-d64 as invalid options >> instead of just passing them through to the VM to let it reject them >> as it does any other non-existent option eg: > > I mulled over this for sometime, and felt that since the launcher > supported these options before, it should give a better/reasonable > error message than the VM does. I am undecided. What do you think ? I think all invalid options should be treated the same. We had the deprecation phase for providing custom feedback - now we're just rejecting them outright. Cheers, David >> >> > java -foo -version >> Unrecognized option: -foo >> Error: Could not create the Java Virtual Machine. >> Error: A fatal exception has occurred. Program will exit. >> >> I also see some pre-existing messiness you might want to tidy up while >> you're in the area :) > > OMG Pre-existing conditions. ;) > >> >> src/java.base/macosx/native/libjli/java_md_macosx.c >> >> 378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg", >> 379 jrepath, FILESEP, FILESEP, "", ""); >> >> The last two %s should just be removed instead of passing empty strings. >> >> 422 } else { >> 423 /* >> 424 * macosx client library is built thin, i386 only. >> 425 * 64 bit client requests must load server library >> 426 */ >> 427 const char *jvmtypeUsed = "server"; >> 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, >> jrepath, jvmtypeUsed); >> 429 } >> >> I don't think we have ever had 32-bit client on OSX! So this whole >> clause seems strange. That aside you can just hardwire %s/lib/server >> instead of using the jvmTypeUsed variable. > > +1, I think we did support 32-bit for sometime, in the early days of > MacOSX. > > >> >> --- >> >> src/java.base/unix/native/libjli/java_md_solinux.c >> >> 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg", >> 324 jrepath, FILESEP, FILESEP, FILESEP); >> >> Another strange version of this code - only 4 %s this time, but >> adjacent FILESEP. :) I'm assuming this is from when was removed. > Urk. > > Ok I will revisit the above, good catches!, and prepare > another changeset. > > Kumar > > >> >> Thanks, >> David >> >>> Thanks >>> Kumar >>> >>> PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have >>> been >>> purged from internal test suites. >>> > From paul.sandoz at oracle.com Mon May 8 21:43:56 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 8 May 2017 14:43:56 -0700 Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods In-Reply-To: <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com> References: <590CD221.4080100@oracle.com> <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com> Message-ID: <06957B86-7C6A-4F9B-AF23-327DAC46F0CE@oracle.com> > On 7 May 2017, at 22:30, David Holmes wrote: > > Hi Ron, > > On 6/05/2017 5:27 AM, Ron Pressler wrote: >> Hi, >> Please review the following core/hotspot change: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8159995 >> core webrev: >> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/ >> >> hotspot webrev: >> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/ >> >> >> This change is covered by existing tests. >> >> The following renaming was applied: >> >> - compareAndExchange*Volatile -> compareAndExchange* >> - compareAndSwap* -> compareAndSet* > > So to clarify this for others, there was confusion surrounding the use of "swap" versus "exchange" when both words mean the same thing effectively, but the "swap" functions return a boolean, while the "exchange" functions return the old value. So we changed "swap" to "set" across the APIs - _except_ for the old /jdk.unsupported/share/classes/sun/misc/Unsafe.java because we can't change its exported API for compatibility reasons. > > Given any "swap(exp, new)" function can be implemented as "exchange(exp, new) == exp" I'm not sure why we have two complete sets of functions all the way through. But I guess that is a different issue. :) > Yes, it might be possible after some careful performance analysis (we might run into some subtle issues). >> - weakCompareAndSwap* -> weakCompareAndSet*Plain >> - weakCompareAndSwap*Volatile -> weakCompareAndSet* >> >> At this stage, only method and hotspot intrinsic names were changed; >> node names were left as-is, and may be handled in a separate issue. > > Overall looks good for libs and hotspot changes. > > One nit I spotted: > > src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java > > + * compareAndSwap for longs. While the intrinsic compareAndSetLong > > compareAndSwap should be compareAndSet > > --- > > All hotspot files need their copyright years updated to 2017 (if not already). > > As there are hotspot changes this must be pushed using JPRT and "-testset hotspot" (but your sponsor should know that :) ). > I do :-) Paul. From kumar.x.srinivasan at oracle.com Mon May 8 22:12:11 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 08 May 2017 15:12:11 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <590D023F.1010809@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> Message-ID: <5910ED3B.9090808@oracle.com> Hi Jon, I looked at the stylesheet can the descriptive comments for each of the classes be moved closer to the class itself, ie. just before the definition ? Kumar > This is an updated review for the changes to improve tables in java.base. > > The changes incorporate earlier review feedback, and also address a > problem that was discovered with nested tables. > > The summary of the set of changes since the previous round is: > > * A new style class is added for borderless tables, to be used in > preference to a table tag with no class. > > * The style classes are now named: > borderless > plain > striped > The longer form using a suffix `-table` was considered, but > generally, there should not be so many style classes that such a level > of discrimination is needed. The names `borderless` and `striped` are > most likely to only apply to tables anyway, and `plain` could > reasonably be used for other elements without conflict. > > * Comments are added to the stylesheet regarding these new classes, as > a placeholder until a better specification for the styles in these > stylesheets is created. > > * Within java.base, all uses of the `altrows` class have been updated > to use `striped`, and tables with no class attribute have been changed > to explicitly use `borderless`. > > > Webrevs: > > langtools (the stylesheet): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ > > jdk (changes to java.base): > http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ > > API showing the combined effect of these cahnges: > http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html > > > > -- Jon > > > > > On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >> This is a review request for two co-dependent fixes. >> >> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >> JDK-8179479: Add new styles to enable HTML 5 tables >> >> In doc comments, some of the HTML 4.01 attributes for tables are no >> longer available in HTML 5, and CSS should be used instead. >> To this end, some updates have been made to the main/default >> stylesheet used by javadoc, to define two new CSS classes for tables. >> >> The new classes are: >> >> Just puts plain borders around each cell, with no background >> coloring. >> >>
>> Horizontal borders are not used between cells in the table body; >> instead, alternating backgrounds are used to help distinguish the >> separate rows. >> >> In addition, there is still the default >>
>> No borders. >> >> These styles are in the langtools webrev, here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >> >> The changes to the doc comments in java.base are in the jdk webrev, >> here: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >> >> summary vs.
>> >> The ARIA recommendations are to use the summary attribute or >> tag ... but the summary attribute is no longer allowed in >> HTML 5. In general, the text that has been provided for a summary is >> not suitable for direct use as a caption. The temporary workaround is >> to use a caption that is not displayed. In time, the appropriate API >> owners should update the use of these undisplayed table captions, to >> modify the text of the caption and make the caption displayed (by >> removing style="display:none"). >> >> Doc comments were changed in files in the following packages: >> >> java.io >> java.lang >> java.lang.invoke >> java.lang.reflect >> java.math >> java.net >> java.nio.channels >> java.nio.charset >> java.nio.file >> java.nio.file.attribute >> java.nio.file.spi >> java.security >> java.security.cert >> java.text >> java.time.chrono >> java.time.format >> java.time.temporal >> java.util >> java.util.concurrent >> java.util.regex >> java.util.spi >> javax.net.ssl >> >> The intent is that the only changes in this webrev are to the HTML 5 >> markup. There should be no significant changes to the text in any doc >> comment. >> >> The decision to add the styles to the default stylesheet at this late >> stage in the release is not taken lightly, and is seen as a temporary >> measure. JDK-8177283 is a wishlist enhancement for updates to javadoc >> support of stylesheets, which includes the desire to move >> JDK-specific styles to a JDK-specific stylesheet. >> >> This review is primarily about continuing the ongoing effort to make >> our docs be HTML 5 compliant. I would prefer not to get into extended >> discussions about which style class to use for each table, and what >> the exact definition of the styleclasses should be at this time. But >> appropriate review feedback is obviously welcome. >> >> -- Jon > From jonathan.gibbons at oracle.com Mon May 8 22:22:39 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 08 May 2017 15:22:39 -0700 Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly. In-Reply-To: <5910ED3B.9090808@oracle.com> References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com> <5910ED3B.9090808@oracle.com> Message-ID: <5910EFAF.2080609@oracle.com> Kumar, The nature of CSS is such that there is generally no one single definition. The descriptive comments are just before the shared/common parts of the definitions. If I grouped the comment and class definition, someone else would point out that I could be sharing common properties. The better long term solution is a separate document, with examples. -- Jon On 05/08/2017 03:12 PM, Kumar Srinivasan wrote: > > Hi Jon, > > I looked at the stylesheet can the descriptive comments for each of the > classes be moved closer to the class itself, ie. just before the > definition ? > > Kumar > >> This is an updated review for the changes to improve tables in >> java.base. >> >> The changes incorporate earlier review feedback, and also address a >> problem that was discovered with nested tables. >> >> The summary of the set of changes since the previous round is: >> >> * A new style class is added for borderless tables, to be used in >> preference to a table tag with no class. >> >> * The style classes are now named: >> borderless >> plain >> striped >> The longer form using a suffix `-table` was considered, but >> generally, there should not be so many style classes that such a >> level of discrimination is needed. The names `borderless` and >> `striped` are most likely to only apply to tables anyway, and `plain` >> could reasonably be used for other elements without conflict. >> >> * Comments are added to the stylesheet regarding these new classes, >> as a placeholder until a better specification for the styles in these >> stylesheets is created. >> >> * Within java.base, all uses of the `altrows` class have been updated >> to use `striped`, and tables with no class attribute have been >> changed to explicitly use `borderless`. >> >> >> Webrevs: >> >> langtools (the stylesheet): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/ >> >> jdk (changes to java.base): >> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/ >> >> API showing the combined effect of these cahnges: >> http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html >> >> >> >> -- Jon >> >> >> >> >> On 05/03/2017 03:06 PM, Jonathan Gibbons wrote: >>> This is a review request for two co-dependent fixes. >>> >>> JDK-8179592: Update tables in java.base to be HTML 5-friendly. >>> JDK-8179479: Add new styles to enable HTML 5 tables >>> >>> In doc comments, some of the HTML 4.01 attributes for tables are no >>> longer available in HTML 5, and CSS should be used instead. >>> To this end, some updates have been made to the main/default >>> stylesheet used by javadoc, to define two new CSS classes for tables. >>> >>> The new classes are: >>> >>> Just puts plain borders around each cell, with no background >>> coloring. >>> >>>
>>> Horizontal borders are not used between cells in the table body; >>> instead, alternating backgrounds are used to help distinguish the >>> separate rows. >>> >>> In addition, there is still the default >>>
>>> No borders. >>> >>> These styles are in the langtools webrev, here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev/ >>> >>> The changes to the doc comments in java.base are in the jdk webrev, >>> here: >>> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev/ >>> >>> summary vs.
>>> >>> The ARIA recommendations are to use the summary attribute or >>> tag ... but the summary attribute is no longer allowed in >>> HTML 5. In general, the text that has been provided for a summary >>> is not suitable for direct use as a caption. The temporary >>> workaround is to use a caption that is not displayed. In time, the >>> appropriate API owners should update the use of these undisplayed >>> table captions, to modify the text of the caption and make the >>> caption displayed (by removing style="display:none"). >>> >>> Doc comments were changed in files in the following packages: >>> >>> java.io >>> java.lang >>> java.lang.invoke >>> java.lang.reflect >>> java.math >>> java.net >>> java.nio.channels >>> java.nio.charset >>> java.nio.file >>> java.nio.file.attribute >>> java.nio.file.spi >>> java.security >>> java.security.cert >>> java.text >>> java.time.chrono >>> java.time.format >>> java.time.temporal >>> java.util >>> java.util.concurrent >>> java.util.regex >>> java.util.spi >>> javax.net.ssl >>> >>> The intent is that the only changes in this webrev are to the HTML 5 >>> markup. There should be no significant changes to the text in any >>> doc comment. >>> >>> The decision to add the styles to the default stylesheet at this >>> late stage in the release is not taken lightly, and is seen as a >>> temporary measure. JDK-8177283 is a wishlist enhancement for updates >>> to javadoc support of stylesheets, which includes the desire to move >>> JDK-specific styles to a JDK-specific stylesheet. >>> >>> This review is primarily about continuing the ongoing effort to make >>> our docs be HTML 5 compliant. I would prefer not to get into >>> extended discussions about which style class to use for each table, >>> and what the exact definition of the styleclasses should be at this >>> time. But appropriate review feedback is obviously welcome. >>> >>> -- Jon >> > From brian.burkhalter at oracle.com Mon May 8 22:24:08 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 15:24:08 -0700 Subject: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that Message-ID: <7A5CD678-6E20-459B-994E-9FE8E3D33CCB@oracle.com> This issue [1] does in fact appear to be a bug. It could be fixed in one of three ways: A) Remove the fallacious sentence "The size of this buffer may be specified, but by default it is large enough for most purposes.? from the second paragraph of the class documentation. This would at least make the specification consistent with the behavior without removing any functionality and could be done for JDK 9. B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) which would permit specifying the buffer size. This would make the behavior consistent with the specification but would have to be targeted to JDK 10. C) Do option A for JDK 9 and (possibly) file an enhancement issue for option B for JDK 10. Any opinions as to which option would be preferable? Another possibility would be to have some kind of ?setBufferSize()? capability which I think would add less API but ultimately more code. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8179662 From aguibert at us.ibm.com Mon May 8 22:27:23 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Mon, 8 May 2017 17:27:23 -0500 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() Message-ID: Hi all, I've been cleaning up code that I work on to be Java 9 compatible, but have ran into a blocker due to limitations of the Naming API. I could work around the blocker with an --add-opens, but I'd rather find a proper solution. *** Background Currently the javax.naming.spi.NamingManager allows for setting a JVM-wide InitialContextFactoryBuilder (ICFB) once and only once by using the static NamingManager.setInitialContextFactoryBuilder() method [1]. The javadoc clearly states: > Once installed, the builder cannot be replaced. If the set ICFB method is called after a ICFB is set, it will throw an IllegalStateException. This seems to be an overly-aggressive restriction of the API. Currently my product has code that reflects into the NamingManager class in order to clear out the ICFB field using reflection. To be Java 9 compliant, we would like to remove this usage of deep reflection, but there are no clear alternatives for doing so. *** Use case We have a JNDI server that may be started/stopped by other java code in the same JVM. If users stop the JNDI server we clear out the ICFB (using reflection) when the JNDI server OSGi bundle deactivates, so that if a user decides to start the JNDI server again in the same JVM, they may do so and we simply set the ICFB when the JNDI server bundle activates. *** Proposed Solution: I could add a layer of indirection by creating an ICFB wrapper that supports re-setting what ICFB it wraps. However, this would cause the ICFB wrapper and all other classes loaded using that bundle's classloader to be leaked (since it can't be fully deactivated and garbage collected). To sort of work around this classloader leak, we would need to load the ICFB wrapper using its own classloader. Although the wrapper classloader would still be leaked, it would have minimal impact because only the one wrapper class would be leaked. I am not sure why the "no resetting" restriction is on the NamingManager API in the first place. Is anyone aware why the API has this restriction? In any case, the solution outlined above seems rather messy (as it only solves the problem by mitigating a classloader leak), so I would like to propose the following addition to the NamingManager API: /** * Clears the InitialContextFactoryBuilder that was previously installed, if any, so that a different one may be set at a later time. * @throws SecurityException - the builder cannot be cleared for security reasons. * @see SecurityManager.checkSetFactory() */ public static void clearInitialContextFactoryBuilder() Additionally, I think it would make sense to permit clearing the NamingManager's ObjectFactoryBuilder using a similar mechanism. Although I don't have any immediate need or use case for this API, I can imagine others may need the same. [1] http://download.java.net/java/jdk9/docs/api/javax/naming/spi/NamingManager.html#setInitialContextFactoryBuilder-javax.naming.spi.InitialContextFactoryBuilder- - Andy From david.holmes at oracle.com Mon May 8 23:50:57 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 9 May 2017 09:50:57 +1000 Subject: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms In-Reply-To: References: Message-ID: Hi John, Responding back on the mailing lists. There are people on the mailing lists who are in a better position to evaluate the merits of the proposal. I searched the bug database and could not see this issue being raised in the past. On 9/05/2017 8:46 AM, John Platts wrote: > The real reasons to add UTF-16 versions of these APIs is the following: > > * The arguments passed into the wmain and wWinMain functions use > UTF-16-encoded strings instead of UTF-8 strings > * The arguments passed into the main and WinMain functions on > Windows-platforms are in the ANSI character encoding instead of the > UTF-8 character encoding > * The NewString and GetStringChars APIs in the JNI already use > UTF-16-encoded strings Yes you are right the String functions already support UTF-16 as that is the format for char[] and so java.lang.String. > * Unicode APIs on Windows normally use UTF-16-encoded strings > * The C11 and C++11 standards support UTF-16 strings through the > char16_t type and support for UTF-16 character literals with a u prefix Thanks for the additional input. David > > ------------------------------------------------------------------------ > *From:* David Holmes > *Sent:* Sunday, May 7, 2017 7:47 PM > *To:* John Platts > *Cc:* hotspot-dev developers; core-libs-dev Libs > *Subject:* Re: Add support for Unicode versions of JNI_CreateJavaVM and > JNI_GetDefaultJavaVMInitArgs on Windows platforms > > Added back jdk10-dev as a bcc. > > Added hotspot-dev and core-libs-dev (for launcher) for follow up > discussions. > > Hi John, > > On 8/05/2017 10:33 AM, John Platts wrote: >> I actually did a search through the code that implements >> JNI_CreateJavaVM, and I found that the conversion of the strings is done >> using java_lang_String::create_from_platform_dependent_str, which >> converts from the platform-default encoding to Unicode. In the case of >> Windows-based platforms, the conversion is done based on the ANSI >> character encoding instead of UTF-8 or Modified UTF-8. >> >> >> The platform encoding detection logic on Windows is implemented >> java_props_md.c, which can be found at >> jdk/src/windows/native/java/lang/java_props_md.c in releases prior to >> JDK 9 and at src/java.base/windows/native/libjava/java_props_md.c in JDK >> 9 and later. The encoding used for command-line arguments passed into >> the JNI invocation API is Cp1252 for English locales on Windows >> platforms, and not Modified UTF-8 or UTF-8. >> >> >> The documentation found >> at http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html > also > The Invocation API - Oracle > > docs.oracle.com > The Invocation API allows software vendors to load the Java VM into an > arbitrary native application. Vendors can deliver Java-enabled > applications without having to ... > > > >> states that the strings passed into JNI_CreateJavaVM are in the >> platform-default encoding. > > Thanks for the additional details. I assume you are referring to: > > typedef struct JavaVMOption { > char *optionString; /* the option as a string in the default > platform encoding */ > > that comment should not form part of the specification as it is > non-normative text. If the intent is truly to use the platform default > encoding and not UTF-8 then that should be very clearly spelt out in the > spec! > > That said, the implementation is following this so it is a limitation. I > suspect this is historical. > >> A version of JNI_CreateJavaVM that takes UTF-16-encoded strings should >> be added to the JNI Invocation API. The java.exe launchers and javaw.exe >> launchers should also be updated to use the UTF-16 version of the >> JNI_CreateJavaVM function on Windows platforms and to use wmain and >> wWinMain instead of main and WinMain. > > Why versions for UTF-16 instead of the missing UTF-8 variants? As I said > the whole spec is intended to be based around UTF-8 so we would not want > to throw in just a couple of UTF-16 based usages. > > Thanks, > David > >> >> A few files in HotSpot would need to be changed in order to implement >> the UTF-16 version of JNI_CreateJavaVM, but the change would improve >> consistency across different locales on Windows platforms and allow >> arguments that contain Unicode characters that are not available in the >> platform-default encoding to be passed into the JVM on the command line. >> >> >> The UTF-16-based version of JNI_CreateJavaVM also makes it easier to >> allocate string objects that contain non-ASCII characters as the strings >> are already in UTF-16 format, at least in cases where the strings >> contain Unicode characters that are not in Latin-1 or on VMs that do not >> support compact Latin-1 strings. >> >> >> The UTF-16-based version of JNI_CreateJavaVM should probably be >> implemented as a separate function so that the solution could be >> backported to JDK 8 and JDK 9 updates and so that backwards >> compatibility with the current JNI_CreateJavaVM implementation is >> maintained. >> >> >> Here is what the new UTF-16-based API might look like: >> >> typedef struct JavaVMInitArgs_UTF16 { >> jint version; >> jint nOptions; >> JavaVMOptionUTF16 *options; >> jboolean ignoreUnrecognized; >> } JavaVMInitArgs; >> >> >> typedef struct JavaVMOption_UTF16 { >> char *optionString; /* the option as a string in the default >> platform encoding */ >> void *extraInfo; >> } JavaVMOptionUTF16; >> >> /* vm_args is an pointer to a JavaVMInitArgs_UTF16 structure */ >> >> jint JNI_CreateJavaVM_UTF16(JavaVM **p_vm, void **p_env, void *vm_args); >> >> >> /* vm_args is a pointer to a JavaVMInitArgs_UTF16 structure */ >> >> jint JNI_GetDefaultJavaVMInitArgs_UTF16(void *vm_args); >> >> ------------------------------------------------------------------------ >> *From:* David Holmes >> *Sent:* Thursday, May 4, 2017 11:07 PM >> *To:* John Platts; jdk10-dev at openjdk.java.net >> *Subject:* Re: Add support for Unicode versions of JNI_CreateJavaVM and >> JNI_GetDefaultJavaVMInitArgs on Windows platforms >> >> Hi John, >> >> The JNI is defined to use Modified UTF-8 format for strings, so any >> Unicode character should be handled if passed in in the right format. >> Updating the JNI specification and implementation to accept UTF-16 >> directly would be a major undertaking. >> >> Is the issue here that you want a tool, like the java launcher, to >> accept arbitrary Unicode strings in a end-user friendly manner and then >> have it perform the modified UTF-8 conversion when invoking the VM? >> >> Can you give a concrete example of what you would like to be able to >> pass as arguments to the JVM? >> >> Thanks, >> David >> >> On 5/05/2017 1:04 PM, John Platts wrote: >>> The JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods in the JNI invocation API expect ANSI strings on Windows platforms instead of Unicode-encoded strings. This is an issue on Windows-based platforms since some of the option strings that are passed into JNI_CreateJavaVM might contain Unicode characters that are not in >> the ANSI encoding on Windows platforms. >>> >>> >>> There is support for UTF-16 literals on Windows platforms with wchar_t and wide character literals prefixed with the L prefix, and on platforms that support C11 and C++11 with char16_t and UTF-16 character literals that are prefixed with the u prefix. >>> >>> >>> jchar is currently defined to be a typedef for unsigned short on all platforms, but char16_t is a separate type and not a typedef for unsigned short or jchar in C++11 and later. jchar should be changed to be a typedef for wchar_t on Windows platforms and to be a typedef for char16_t on non-Windows platforms that support the >> char16_t type. This change will make it possible to define jchar >> character and string literals on Windows platforms and on non-Windows >> platforms that support the C11 or C++11 standard. >>> >>> >>> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on Windows: >>> >>> #define JCHAR_LITERAL(x) L ## x >>> >>> >>> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on non-Windows platforms: >>> >>> #define JCHAR_LITERAL(x) u ## x >>> >>> >>> Here is how the Unicode version of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs could be defined: >>> >>> typedef struct JavaVMUnicodeOption { >>> const jchar *optionString; /* the option as a string in UTF-16 encoding */ >>> void *extraInfo; >>> } JavaVMUnicodeOption; >>> >>> typedef struct JavaVMUnicodeInitArgs { >>> jint version; >>> jint nOptions; >>> JavaVMUnicodeOption *options; >>> jboolean ignoreUnrecognized; >>> } JavaVMUnicodeInitArgs; >>> >>> jint JNI_CreateJavaVMUnicode(JavaVM **pvm, void **penv, void *args); >>> jint JNI_GetDefaultJavaVMInitArgs(void *args); >>> >>> The java.exe wrapper should use wmain instead of main on Windows platforms, and the javaw.exe wrapper should use wWinMain instead of WinMain on Windows platforms. This change, along with the support for Unicode-enabled version of the JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods, would allow the JVM to be >> launched with arguments that contain Unicode characters that are not in >> the platform-default encoding. >>> >>> All of the Windows platforms that Java SE 10 and later VMs would be supported on do support Unicode. Adding support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs will allow Unicode characters that are not in the platform-default encoding on Windows platforms to be supported in command-line arguments >> that are passed to the JVM. >>> From isaac.r.levy at gmail.com Tue May 9 00:06:33 2017 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Mon, 8 May 2017 20:06:33 -0400 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Message-ID: AMD started shipping popcnt instruction in 2007, and intel in 2008. Does the OpenJDK runtime include a bitCount intrinsic? I can't speak much to relevance in this regard. But in terms of performance, http://dalkescientific.com/writings/diary/archive/2011/11/02/faster_popcount_update.html gives a 45% speedup from current jdk algorithm (called "Wikipedia #2") to the propsed one ("Wikipedia #3"). Benchmark source: http://dalkescientific.com/writings/diary/popcnt.cpp The multiply is also the suggested algorithm in the linked PDF (page 195 of http://support.amd.com/techdocs/25112.pdf), an official AMD optimization guide. Isaac On Mon, May 8, 2017 at 4:29 PM, Doug Lea
wrote: > On 05/08/2017 02:14 PM, Isaac Levy wrote: >> >> Original message below: >> >> The JDK impl of bitCount can be improved -- though most users will get >> the hotspot intrinsic. The best source I could find for the suggestion >> below is page 195: http://support.amd.com/techdocs/25112.pdf >> > > The int version differs from current implementation in that it uses > one multiply instead of two shift+adds. (Similarly for long.) > > I wonder if there is any processor that does not already have a > bit-count instruction for which this is actually faster? > Some evidence either way would be helpful. > > -Doug > > > > >> Cheers, >> Isaac Levy >> >> >> Proposed Long.bitCount and Integer.bitCount: >> >> >> public static int bitCount(long i) >> { >> i -= (i >>> 1) & 0x5555555555555555L; >> i = (i & 0x3333333333333333L) + ((i >>> 2) & 0x3333333333333333L); >> i = (i + (i >>> 4)) & 0x0f0f0f0f0f0f0f0fL; >> return (i * 0x0101010101010101L) >>> 56; >> } >> >> >> public static int bitCount(int i) { >> i -= (i >>> 1) & 0x55555555; >> i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); >> i = (i + (i >>> 4)) & 0x0f0f0f0f; >> return (i * 0x01010101) >>> 24; >> } >> > From joe.darcy at oracle.com Tue May 9 00:07:24 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 08 May 2017 17:07:24 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> Message-ID: <5911083C.4020906@oracle.com> On 5/8/2017 1:29 PM, Doug Lea wrote: > On 05/08/2017 02:14 PM, Isaac Levy wrote: >> Original message below: >> >> The JDK impl of bitCount can be improved -- though most users will get >> the hotspot intrinsic. The best source I could find for the suggestion >> below is page 195: http://support.amd.com/techdocs/25112.pdf >> > > The int version differs from current implementation in that it uses > one multiply instead of two shift+adds. (Similarly for long.) > > I wonder if there is any processor that does not already have a > bit-count instruction for which this is actually faster? > Some evidence either way would be helpful. > This is a case of "jmh results or it isn't faster." [1] It is challenging to evaluate such changes as being universally faster without benchmark results, especially for small methods like this. Without compelling performance support, my preference would be to leave the current Java implementation as-is, especially when there are VM intrinsics on many platforms. Thanks, -Joe [1] http://openjdk.java.net/projects/code-tools/jmh/ From brian.burkhalter at oracle.com Tue May 9 00:11:19 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 17:11:19 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: <5911083C.4020906@oracle.com> References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> Message-ID: <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> On May 8, 2017, at 5:07 PM, Joseph D. Darcy wrote: > This is a case of "jmh results or it isn't faster." [1] > > It is challenging to evaluate such changes as being universally faster without benchmark results, especially for small methods like this. Without compelling performance support, my preference would be to leave the current Java implementation as-is, especially when there are VM intrinsics on many platforms. I concur. Brian From john_platts at hotmail.com Tue May 9 00:28:09 2017 From: john_platts at hotmail.com (John Platts) Date: Tue, 9 May 2017 00:28:09 +0000 Subject: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms In-Reply-To: References: , Message-ID: Reasons to add UTF-16 versions of the JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs APIs include the following: * The arguments passed into the wmain and wWinMain functions use UTF-16-encoded strings instead of UTF-8 strings. * The arguments passed into the main and WinMain functions on Windows-platforms are in the ANSI character encoding instead of the UTF-8 character encoding. * The arguments passed into the wmain and wWinMain functions would need to be converted to UTF-8 or modified UTF-8 encoding unless a UTF-16 version of JNI_CreateJavaVM is added. * The NewString and GetStringChars APIs in the JNI already use UTF-16-encoded strings. * Unicode APIs on Windows normally use UTF-16-encoded strings. * The C11 and C++11 standards support UTF-16 strings through the char16_t type and support for UTF-16 literals with a u prefix. * Windows platforms have long supported UTF-16 strings in C and C++ through the wchar_t type and support for UTF-16 literals with a L prefix. * A UTF-16 version of JNI_CreateJavaVM would allow command line arguments to be passed into the JVM without having to perform the platform-dependent encoding to UTF-16 conversion that currently has to be done in the JVM. * A UTF-16 version of JNI_CreateJavaVM would improve consistency across different locales on Windows-based platforms since the command-line arguments can be passed into the JVM in a locale-independent manner on Windows-based platforms. ________________________________ From: David Holmes Sent: Sunday, May 7, 2017 7:47 PM To: John Platts Cc: hotspot-dev developers; core-libs-dev Libs Subject: Re: Add support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs on Windows platforms Added back jdk10-dev as a bcc. Added hotspot-dev and core-libs-dev (for launcher) for follow up discussions. Hi John, On 8/05/2017 10:33 AM, John Platts wrote: > I actually did a search through the code that implements > JNI_CreateJavaVM, and I found that the conversion of the strings is done > using java_lang_String::create_from_platform_dependent_str, which > converts from the platform-default encoding to Unicode. In the case of > Windows-based platforms, the conversion is done based on the ANSI > character encoding instead of UTF-8 or Modified UTF-8. > > > The platform encoding detection logic on Windows is implemented > java_props_md.c, which can be found at > jdk/src/windows/native/java/lang/java_props_md.c in releases prior to > JDK 9 and at src/java.base/windows/native/libjava/java_props_md.c in JDK > 9 and later. The encoding used for command-line arguments passed into > the JNI invocation API is Cp1252 for English locales on Windows > platforms, and not Modified UTF-8 or UTF-8. > > > The documentation found > at http://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/invocation.html also The Invocation API - Oracle docs.oracle.com The Invocation API allows software vendors to load the Java VM into an arbitrary native application. Vendors can deliver Java-enabled applications without having to ... > states that the strings passed into JNI_CreateJavaVM are in the > platform-default encoding. Thanks for the additional details. I assume you are referring to: typedef struct JavaVMOption { char *optionString; /* the option as a string in the default platform encoding */ that comment should not form part of the specification as it is non-normative text. If the intent is truly to use the platform default encoding and not UTF-8 then that should be very clearly spelt out in the spec! That said, the implementation is following this so it is a limitation. I suspect this is historical. > A version of JNI_CreateJavaVM that takes UTF-16-encoded strings should > be added to the JNI Invocation API. The java.exe launchers and javaw.exe > launchers should also be updated to use the UTF-16 version of the > JNI_CreateJavaVM function on Windows platforms and to use wmain and > wWinMain instead of main and WinMain. Why versions for UTF-16 instead of the missing UTF-8 variants? As I said the whole spec is intended to be based around UTF-8 so we would not want to throw in just a couple of UTF-16 based usages. Thanks, David > > A few files in HotSpot would need to be changed in order to implement > the UTF-16 version of JNI_CreateJavaVM, but the change would improve > consistency across different locales on Windows platforms and allow > arguments that contain Unicode characters that are not available in the > platform-default encoding to be passed into the JVM on the command line. > > > The UTF-16-based version of JNI_CreateJavaVM also makes it easier to > allocate string objects that contain non-ASCII characters as the strings > are already in UTF-16 format, at least in cases where the strings > contain Unicode characters that are not in Latin-1 or on VMs that do not > support compact Latin-1 strings. > > > The UTF-16-based version of JNI_CreateJavaVM should probably be > implemented as a separate function so that the solution could be > backported to JDK 8 and JDK 9 updates and so that backwards > compatibility with the current JNI_CreateJavaVM implementation is > maintained. > > > Here is what the new UTF-16-based API might look like: > > typedef struct JavaVMInitArgs_UTF16 { > jint version; > jint nOptions; > JavaVMOptionUTF16 *options; > jboolean ignoreUnrecognized; > } JavaVMInitArgs; > > > typedef struct JavaVMOption_UTF16 { > char *optionString; /* the option as a string in the default > platform encoding */ > void *extraInfo; > } JavaVMOptionUTF16; > > /* vm_args is an pointer to a JavaVMInitArgs_UTF16 structure */ > > jint JNI_CreateJavaVM_UTF16(JavaVM **p_vm, void **p_env, void *vm_args); > > > /* vm_args is a pointer to a JavaVMInitArgs_UTF16 structure */ > > jint JNI_GetDefaultJavaVMInitArgs_UTF16(void *vm_args); > > ------------------------------------------------------------------------ > *From:* David Holmes > *Sent:* Thursday, May 4, 2017 11:07 PM > *To:* John Platts; jdk10-dev at openjdk.java.net > *Subject:* Re: Add support for Unicode versions of JNI_CreateJavaVM and > JNI_GetDefaultJavaVMInitArgs on Windows platforms > > Hi John, > > The JNI is defined to use Modified UTF-8 format for strings, so any > Unicode character should be handled if passed in in the right format. > Updating the JNI specification and implementation to accept UTF-16 > directly would be a major undertaking. > > Is the issue here that you want a tool, like the java launcher, to > accept arbitrary Unicode strings in a end-user friendly manner and then > have it perform the modified UTF-8 conversion when invoking the VM? > > Can you give a concrete example of what you would like to be able to > pass as arguments to the JVM? > > Thanks, > David > > On 5/05/2017 1:04 PM, John Platts wrote: >> The JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods in the JNI invocation API expect ANSI strings on Windows platforms instead of Unicode-encoded strings. This is an issue on Windows-based platforms since some of the option strings that are passed into JNI_CreateJavaVM might contain Unicode characters that are not in > the ANSI encoding on Windows platforms. >> >> >> There is support for UTF-16 literals on Windows platforms with wchar_t and wide character literals prefixed with the L prefix, and on platforms that support C11 and C++11 with char16_t and UTF-16 character literals that are prefixed with the u prefix. >> >> >> jchar is currently defined to be a typedef for unsigned short on all platforms, but char16_t is a separate type and not a typedef for unsigned short or jchar in C++11 and later. jchar should be changed to be a typedef for wchar_t on Windows platforms and to be a typedef for char16_t on non-Windows platforms that support the > char16_t type. This change will make it possible to define jchar > character and string literals on Windows platforms and on non-Windows > platforms that support the C11 or C++11 standard. >> >> >> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on Windows: >> >> #define JCHAR_LITERAL(x) L ## x >> >> >> The JCHAR_LITERAL macro should be added to the JNI header and defined as follows on non-Windows platforms: >> >> #define JCHAR_LITERAL(x) u ## x >> >> >> Here is how the Unicode version of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs could be defined: >> >> typedef struct JavaVMUnicodeOption { >> const jchar *optionString; /* the option as a string in UTF-16 encoding */ >> void *extraInfo; >> } JavaVMUnicodeOption; >> >> typedef struct JavaVMUnicodeInitArgs { >> jint version; >> jint nOptions; >> JavaVMUnicodeOption *options; >> jboolean ignoreUnrecognized; >> } JavaVMUnicodeInitArgs; >> >> jint JNI_CreateJavaVMUnicode(JavaVM **pvm, void **penv, void *args); >> jint JNI_GetDefaultJavaVMInitArgs(void *args); >> >> The java.exe wrapper should use wmain instead of main on Windows platforms, and the javaw.exe wrapper should use wWinMain instead of WinMain on Windows platforms. This change, along with the support for Unicode-enabled version of the JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs methods, would allow the JVM to be > launched with arguments that contain Unicode characters that are not in > the platform-default encoding. >> >> All of the Windows platforms that Java SE 10 and later VMs would be supported on do support Unicode. Adding support for Unicode versions of JNI_CreateJavaVM and JNI_GetDefaultJavaVMInitArgs will allow Unicode characters that are not in the platform-default encoding on Windows platforms to be supported in command-line arguments > that are passed to the JVM. >> From isaac.r.levy at gmail.com Tue May 9 00:42:24 2017 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Mon, 8 May 2017 20:42:24 -0400 Subject: Long.bitCount micro-optimization In-Reply-To: <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest bitCountInt avgt 10 44550.630 ? 2670.294 ns/op bitCountIntNew avgt 10 33904.058 ? 1108.438 ns/op bitCountLong avgt 10 58638.138 ? 3736.014 ns/op bitCountLongNew avgt 10 38700.601 ? 526.648 ns/op JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14 https://gist.github.com/isaacl/338a3f88e7d18a0c64bf9aed6e4a816b Isaac On Mon, May 8, 2017 at 8:11 PM, Brian Burkhalter wrote: > > On May 8, 2017, at 5:07 PM, Joseph D. Darcy wrote: > >> This is a case of "jmh results or it isn't faster." [1] >> >> It is challenging to evaluate such changes as being universally faster without benchmark results, especially for small methods like this. Without compelling performance support, my preference would be to leave the current Java implementation as-is, especially when there are VM intrinsics on many platforms. > > I concur. > > Brian From martinrb at google.com Tue May 9 00:45:50 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 May 2017 17:45:50 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: <06d99b2d-2140-7c22-a8a0-612de7d83b5d@redhat.com> References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <06d99b2d-2140-7c22-a8a0-612de7d83b5d@redhat.com> Message-ID: On Tue, May 2, 2017 at 2:40 AM, Andrew Dinn wrote: > > Just wanted to post a heads-up that this fall-back behaviour has now > been implemented in Byteman release 4.0.0-BETA5. Thanks - I can confirm 4.0.0-BETA5 works for me. From martinrb at google.com Tue May 9 00:58:54 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 May 2017 17:58:54 -0700 Subject: Accessing module internals from bytecode rewriting agent In-Reply-To: References: <2099da91-fe6e-a5ed-3396-1e57284a75f1@oracle.com> <64a587a9-ec06-f0cd-f136-149b85e083d7@oracle.com> <3aef86fc-3fc2-9ff9-7be4-06d92800f0a7@oracle.com> <0e51419c-b100-8dc8-fb81-dd0b50b5177b@oracle.com> Message-ID: Another way to think about transition to a new JDK is to treat the new release JDK N as a "better JDK N-1". You still target JDK N-1 at build time but get performance and quality improvements from the JDK N runtime, running along with JDK N-1 for years. Then every small incompatibility is a big nuisance. It's an interesting thought experiment whether using two releases to get to strong encapsulation might have been an easier transition for users (but of course too late now and would have made jigsaw implementers' lives tougher). From brian.burkhalter at oracle.com Tue May 9 01:01:19 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 18:01:19 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: Thanks for running the numbers. On May 8, 2017, at 5:42 PM, Isaac Levy wrote: > bitCountInt avgt 10 44550.630 ? 2670.294 ns/op [41880, 47221] > bitCountIntNew avgt 10 33904.058 ? 1108.438 ns/op [32796, 35012] > bitCountLong avgt 10 58638.138 ? 3736.014 ns/op [54902, 62374] > bitCountLongNew avgt 10 38700.601 ? 526.648 ns/op [38174, 39227] So the ranges don?t overlap which is important. > JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14 Thing is one needs to run the benchmark on a variety of hardware. I went through a lot of this sort of thing myself when evaluating among other things for example the crossover thresholds for the Karatsuba and Toom-Cook multiplication algorithms in BigInteger multiplication. There was a lot of variation. Thanks, Brian From joe.darcy at oracle.com Tue May 9 01:09:06 2017 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 08 May 2017 18:09:06 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: <591116B2.9010103@oracle.com> Hello, To strengthen Brian' point, running faster on at least one platform is a necessary but not sufficient condition for a change like this since it is possible the change could run slower on a different platform. To guard against that being the case, with data points across more platforms a better informed decision can be made. Unfortunately, to my knowledge there isn't a convenient way to run a test like this across a large set of platforms of interest. Cheers, -Joe On 5/8/2017 6:01 PM, Brian Burkhalter wrote: > Thanks for running the numbers. > > On May 8, 2017, at 5:42 PM, Isaac Levy > wrote: > >> bitCountInt avgt 10 44550.630 ? 2670.294 ns/op > > [41880, 47221] > >> bitCountIntNew avgt 10 33904.058 ? 1108.438 ns/op > > [32796, 35012] > >> bitCountLong avgt 10 58638.138 ? 3736.014 ns/op > > [54902, 62374] > >> bitCountLongNew avgt 10 38700.601 ? 526.648 ns/op > > [38174, 39227] > > So the ranges don?t overlap which is important. > >> JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14 > > Thing is one needs to run the benchmark on a variety of hardware. I > went through a lot of this sort of thing myself when evaluating among > other things for example the crossover thresholds for the Karatsuba > and Toom-Cook multiplication algorithms in BigInteger multiplication. > There was a lot of variation. > > Thanks, > > Brian From brian.goetz at oracle.com Tue May 9 01:38:22 2017 From: brian.goetz at oracle.com (Brian Goetz) Date: Mon, 8 May 2017 20:38:22 -0500 Subject: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that In-Reply-To: <7A5CD678-6E20-459B-994E-9FE8E3D33CCB@oracle.com> References: <7A5CD678-6E20-459B-994E-9FE8E3D33CCB@oracle.com> Message-ID: Given that this went unnoticed for 18 years, the urgency seems low. Either (a) or (b) sound fine to me. (c) sounds like a recipe for spending more time talking about the bug than actually fixing it. > On May 8, 2017, at 5:24 PM, Brian Burkhalter wrote: > > This issue [1] does in fact appear to be a bug. It could be fixed in one of three ways: > > A) Remove the fallacious sentence "The size of this buffer may be specified, but by default it is large enough for most purposes.? from the second paragraph of the class documentation. This would at least make the specification consistent with the behavior without removing any functionality and could be done for JDK 9. > > B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) which would permit specifying the buffer size. This would make the behavior consistent with the specification but would have to be targeted to JDK 10. > > C) Do option A for JDK 9 and (possibly) file an enhancement issue for option B for JDK 10. > > Any opinions as to which option would be preferable? > > Another possibility would be to have some kind of ?setBufferSize()? capability which I think would add less API but ultimately more code. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8179662 From brian.burkhalter at oracle.com Tue May 9 01:54:18 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 18:54:18 -0700 Subject: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that In-Reply-To: References: <7A5CD678-6E20-459B-994E-9FE8E3D33CCB@oracle.com> Message-ID: <2A8105B6-1DFD-4281-A5DE-B9DBFB27C5D5@oracle.com> I agree. I would opt for (A) and be done with it. On May 8, 2017, at 6:38 PM, Brian Goetz wrote: > Given that this went unnoticed for 18 years, the urgency seems low. Either (a) or (b) sound fine to me. (c) sounds like a recipe for spending more time talking about the bug than actually fixing it. > > > >> On May 8, 2017, at 5:24 PM, Brian Burkhalter wrote: >> >> This issue [1] does in fact appear to be a bug. It could be fixed in one of three ways: >> >> A) Remove the fallacious sentence "The size of this buffer may be specified, but by default it is large enough for most purposes.? from the second paragraph of the class documentation. This would at least make the specification consistent with the behavior without removing any functionality and could be done for JDK 9. >> >> B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) which would permit specifying the buffer size. This would make the behavior consistent with the specification but would have to be targeted to JDK 10. >> >> C) Do option A for JDK 9 and (possibly) file an enhancement issue for option B for JDK 10. >> >> Any opinions as to which option would be preferable? >> >> Another possibility would be to have some kind of ?setBufferSize()? capability which I think would add less API but ultimately more code. >> >> Thanks, >> >> Brian >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8179662 > From amy.lu at oracle.com Tue May 9 02:23:17 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 9 May 2017 10:23:17 +0800 Subject: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area In-Reply-To: <662CEC09-CC50-41A5-93B9-2135811AC400@oracle.com> References: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> <662CEC09-CC50-41A5-93B9-2135811AC400@oracle.com> Message-ID: On 5/9/17 1:33 AM, Paul Sandoz wrote: > The changes look good. > > Would you mind re-basing this fix for JDK 10 instead? At this point we should be more conservative with such changes (even for tests). Sure, I'll re-base and push this to JDK 10. Thank you for reviewing. Thanks, Amy From amy.lu at oracle.com Tue May 9 02:24:30 2017 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 9 May 2017 10:24:30 +0800 Subject: JDK 9 RFR of JDK-8085814: Move stream test library to the jdk test library area In-Reply-To: <5558c5b1-5270-36aa-1063-af8aad318f45@oracle.com> References: <88db653f-151d-7a7c-37e3-4b7e83105d63@oracle.com> <5558c5b1-5270-36aa-1063-af8aad318f45@oracle.com> Message-ID: <120f91ce-a1c5-7e04-643e-e825ae93c831@oracle.com> On 5/9/17 4:56 AM, David Holmes wrote: > If the bootlib files were simply moved then no update to their > copyright year is needed. > > Cheers, > David Got it. Thank you David! Thanks, Amy From brian.burkhalter at oracle.com Tue May 9 02:28:46 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 8 May 2017 19:28:46 -0700 Subject: JDK 9 RFR of 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that Message-ID: <555108A4-7F55-463F-8561-99BBE7723C6A@oracle.com> Please review this doc-only change [2] for [1] at your convenience with reference to [3]. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8179662 [2] diff --- a/src/java.base/share/classes/java/io/OutputStreamWriter.java +++ b/src/java.base/share/classes/java/io/OutputStreamWriter.java @@ -40,10 +40,8 @@ * *

Each invocation of a write() method causes the encoding converter to be * invoked on the given character(s). The resulting bytes are accumulated in a - * buffer before being written to the underlying output stream. The size of - * this buffer may be specified, but by default it is large enough for most - * purposes. Note that the characters passed to the write() methods are not - * buffered. + * buffer before being written to the underlying output stream. Note that the + * characters passed to the write() methods are not buffered. * *

For top efficiency, consider wrapping an OutputStreamWriter within a * BufferedWriter so as to avoid frequent converter invocations. For example: [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047526.html From martinrb at google.com Tue May 9 02:54:00 2017 From: martinrb at google.com (Martin Buchholz) Date: Mon, 8 May 2017 19:54:00 -0700 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: Being able to do better here is very impressive. I took a quick look and found two things that a paranoid benchmarker like myself would not have done: - write the benchmark in scala instead of boring java - use jdk8 instead of "head" (i.e. jdk10) I would also have benchmarked against the intrinsified version to see how it did. On Mon, May 8, 2017 at 5:42 PM, Isaac Levy wrote: > jmh:run -t1 -f 1 -wi 5 -i 10 BitCountTest > > bitCountInt avgt 10 44550.630 ? 2670.294 ns/op > bitCountIntNew avgt 10 33904.058 ? 1108.438 ns/op > > bitCountLong avgt 10 58638.138 ? 3736.014 ns/op > bitCountLongNew avgt 10 38700.601 ? 526.648 ns/op > > JDK 1.8.0_131, 2.3ghz Core i7, each run counting numbers 0 to 2^14 > > https://gist.github.com/isaacl/338a3f88e7d18a0c64bf9aed6e4a816b > > Isaac > > > On Mon, May 8, 2017 at 8:11 PM, Brian Burkhalter > wrote: > > > > On May 8, 2017, at 5:07 PM, Joseph D. Darcy > wrote: > > > >> This is a case of "jmh results or it isn't faster." [1] > >> > >> It is challenging to evaluate such changes as being universally faster > without benchmark results, especially for small methods like this. Without > compelling performance support, my preference would be to leave the current > Java implementation as-is, especially when there are VM intrinsics on many > platforms. > > > > I concur. > > > > Brian > From chris.hegarty at oracle.com Tue May 9 08:08:31 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 9 May 2017 09:08:31 +0100 Subject: JDK 9 RFR of 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that In-Reply-To: <555108A4-7F55-463F-8561-99BBE7723C6A@oracle.com> References: <555108A4-7F55-463F-8561-99BBE7723C6A@oracle.com> Message-ID: <0D85AD9D-FACA-4F05-ADED-B10B76FFA658@oracle.com> > On 9 May 2017, at 03:28, Brian Burkhalter wrote: > > Please review this doc-only change [2] for [1] at your convenience with reference to [3]. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8179662 > [2] diff > > --- a/src/java.base/share/classes/java/io/OutputStreamWriter.java > +++ b/src/java.base/share/classes/java/io/OutputStreamWriter.java > @@ -40,10 +40,8 @@ > * > *

Each invocation of a write() method causes the encoding converter to be > * invoked on the given character(s). The resulting bytes are accumulated in a > - * buffer before being written to the underlying output stream. The size of > - * this buffer may be specified, but by default it is large enough for most > - * purposes. Note that the characters passed to the write() methods are not > - * buffered. > + * buffer before being written to the underlying output stream. Note that the > + * characters passed to the write() methods are not buffered. > * > *

For top efficiency, consider wrapping an OutputStreamWriter within a > * BufferedWriter so as to avoid frequent converter invocations. For example: Looks ok to me Brian. -Chris. From aph at redhat.com Tue May 9 08:17:18 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 9 May 2017 09:17:18 +0100 Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods In-Reply-To: <06957B86-7C6A-4F9B-AF23-327DAC46F0CE@oracle.com> References: <590CD221.4080100@oracle.com> <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com> <06957B86-7C6A-4F9B-AF23-327DAC46F0CE@oracle.com> Message-ID: On 08/05/17 22:43, Paul Sandoz wrote: >> Given any "swap(exp, new)" function can be implemented as >> "exchange(exp, new) == exp" I'm not sure why we have two complete >> sets of functions all the way through. But I guess that is a >> different issue. :) > > Yes, it might be possible after some careful performance analysis > (we might run into some subtle issues). They don't quite generate the same code, and there is no way to write an "Exchange" version of a weak "Swap". Andrew. From lance.andersen at oracle.com Tue May 9 10:57:56 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 May 2017 06:57:56 -0400 Subject: JDK 9 RFR of 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that In-Reply-To: <555108A4-7F55-463F-8561-99BBE7723C6A@oracle.com> References: <555108A4-7F55-463F-8561-99BBE7723C6A@oracle.com> Message-ID: +1 > On May 8, 2017, at 10:28 PM, Brian Burkhalter wrote: > > Please review this doc-only change [2] for [1] at your convenience with reference to [3]. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8179662 > [2] diff > > --- a/src/java.base/share/classes/java/io/OutputStreamWriter.java > +++ b/src/java.base/share/classes/java/io/OutputStreamWriter.java > @@ -40,10 +40,8 @@ > * > *

Each invocation of a write() method causes the encoding converter to be > * invoked on the given character(s). The resulting bytes are accumulated in a > - * buffer before being written to the underlying output stream. The size of > - * this buffer may be specified, but by default it is large enough for most > - * purposes. Note that the characters passed to the write() methods are not > - * buffered. > + * buffer before being written to the underlying output stream. Note that the > + * characters passed to the write() methods are not buffered. > * > *

For top efficiency, consider wrapping an OutputStreamWriter within a > * BufferedWriter so as to avoid frequent converter invocations. For example: > > [3] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047526.html Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From pavel.rappo at oracle.com Tue May 9 13:55:00 2017 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Tue, 9 May 2017 14:55:00 +0100 Subject: RFR [9] 8179021: Latest bugfixes to WebSocket/HPACK from the sandbox repo In-Reply-To: References: Message-ID: This thread has just moved to net-dev mailing list: http://mail.openjdk.java.net/pipermail/net-dev/2017-May/010785.html Sorry for the noise, thanks. > On 20 Apr 2017, at 17:08, Pavel Rappo wrote: > > Hello, > > Please review the following change: > > http://cr.openjdk.java.net/~prappo/8179021/webrev.00/ > > Along with refactoring this change contains a number of critical fixes for > WebSocket. Critical fixes are applied to Receiver and OpeningHandshake. > > Also this change removes 2 convenience methods and 1 constant from WebSocket > interface. Since this interface is a part of incubation feature there shouldn't > be any problem. Those members were initially controversial. > > Thanks, > -Pavel From isaac.r.levy at gmail.com Tue May 9 13:59:15 2017 From: isaac.r.levy at gmail.com (Isaac Levy) Date: Tue, 9 May 2017 09:59:15 -0400 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: On Mon, May 8, 2017 at 10:54 PM Martin Buchholz wrote: > > Being able to do better here is very impressive. > > I took a quick look and found two things that a paranoid benchmarker like myself would not have done: > - write the benchmark in scala instead of boring java > - use jdk8 instead of "head" (i.e. jdk10) > > I would also have benchmarked against the intrinsified version to see how it did. I had trouble building jmh, so used a setup I already had working. I added a java runner in https://github.com/isaacl/BitCountJDK, would you be willing to run a test against head to get a second data point? From maurizio.cimadamore at oracle.com Tue May 9 14:28:20 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 May 2017 15:28:20 +0100 Subject: Long.bitCount micro-optimization In-Reply-To: References: <8FC4835A-6585-4EE9-B31D-14E6AA1C3C4A@oracle.com> <5911083C.4020906@oracle.com> <6C7E41BE-7CFF-41E9-9E44-333D2E17395D@oracle.com> Message-ID: To expand a bit on Martin's point - I think your benchmark should include a 'baseline' version of bitCountInt/bitCountLong whose implementation simply delegates to the JDK methods (Integer.bitCount/Long.bitCount) - I see that bitCount is on the list of supported intrinsics [1], so, by adding those 'baselines' intrinsification should definitively kick in, and give you different (possibly even better) numbers. [1] - http://hg.openjdk.java.net/jdk9/dev/hotspot/file/tip/src/share/vm/classfile/vmSymbols.hpp#l830 Maurizio On 09/05/17 03:54, Martin Buchholz wrote: > I would also have benchmarked against the intrinsified version to see how > it did. From Roger.Riggs at Oracle.com Tue May 9 14:32:29 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 9 May 2017 10:32:29 -0400 Subject: RFC on 8179662: OutputStreamWriter javadocs states that you can set the buffer size but there is no way to do that In-Reply-To: <2A8105B6-1DFD-4281-A5DE-B9DBFB27C5D5@oracle.com> References: <7A5CD678-6E20-459B-994E-9FE8E3D33CCB@oracle.com> <2A8105B6-1DFD-4281-A5DE-B9DBFB27C5D5@oracle.com> Message-ID: <21d62646-f34c-909b-9149-8efd9ef75dfe@Oracle.com> +1 On 5/8/2017 9:54 PM, Brian Burkhalter wrote: > I agree. I would opt for (A) and be done with it. > > On May 8, 2017, at 6:38 PM, Brian Goetz wrote: > >> Given that this went unnoticed for 18 years, the urgency seems low. Either (a) or (b) sound fine to me. (c) sounds like a recipe for spending more time talking about the bug than actually fixing it. >> >> >> >>> On May 8, 2017, at 5:24 PM, Brian Burkhalter wrote: >>> >>> This issue [1] does in fact appear to be a bug. It could be fixed in one of three ways: >>> >>> A) Remove the fallacious sentence "The size of this buffer may be specified, but by default it is large enough for most purposes.? from the second paragraph of the class documentation. This would at least make the specification consistent with the behavior without removing any functionality and could be done for JDK 9. >>> >>> B) Add constructors (and the supporting methods in sun.nio.cs.CtreamEncoder) which would permit specifying the buffer size. This would make the behavior consistent with the specification but would have to be targeted to JDK 10. >>> >>> C) Do option A for JDK 9 and (possibly) file an enhancement issue for option B for JDK 10. >>> >>> Any opinions as to which option would be preferable? >>> >>> Another possibility would be to have some kind of ?setBufferSize()? capability which I think would add less API but ultimately more code. >>> >>> Thanks, >>> >>> Brian >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8179662 From mandy.chung at oracle.com Tue May 9 16:58:07 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 09:58:07 -0700 Subject: Review Request: JDK-8179950: Custom system class loader using Enum.valueOf in its initialization triggers java.lang.InternalError Message-ID: Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html This is a regression caused by JDK-8020801 that the initialization of a custom system class loader hits a code path that checks if a class is loaded by the platform class loader. Such code path should not call ClassLoader::getSystemClassLoader since the system class loader is being initialized. The fix is simple and uses jdk.internal.loader.ClassLoaders.platformClassLoader() instead. Mandy From daniel.fuchs at oracle.com Tue May 9 17:03:25 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 9 May 2017 18:03:25 +0100 Subject: Review Request: JDK-8179950: Custom system class loader using Enum.valueOf in its initialization triggers java.lang.InternalError In-Reply-To: References: Message-ID: <1fd7b845-ffb8-f15d-7f76-c09465bef3d7@oracle.com> Looks good to me Mandy! Nice test :-) best regards, -- daniel On 09/05/2017 17:58, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html > > This is a regression caused by JDK-8020801 that the initialization of a custom system class loader hits a code path that checks if a class is loaded by the platform class loader. Such code path should not call ClassLoader::getSystemClassLoader since the system class loader is being initialized. > > The fix is simple and uses jdk.internal.loader.ClassLoaders.platformClassLoader() instead. > > Mandy > From lance.andersen at oracle.com Tue May 9 17:05:23 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 May 2017 13:05:23 -0400 Subject: Review Request: JDK-8179950: Custom system class loader using Enum.valueOf in its initialization triggers java.lang.InternalError In-Reply-To: References: Message-ID: looks fine Mandy... > On May 9, 2017, at 12:58 PM, Mandy Chung wrote: > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html > > This is a regression caused by JDK-8020801 that the initialization of a custom system class loader hits a code path that checks if a class is loaded by the platform class loader. Such code path should not call ClassLoader::getSystemClassLoader since the system class loader is being initialized. > > The fix is simple and uses jdk.internal.loader.ClassLoaders.platformClassLoader() instead. > > Mandy Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Tue May 9 17:08:19 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 9 May 2017 18:08:19 +0100 Subject: Review Request: JDK-8179950: Custom system class loader using Enum.valueOf in its initialization triggers java.lang.InternalError In-Reply-To: References: Message-ID: <69c7f441-0677-afc8-be6b-b2e72eb98a54@oracle.com> On 09/05/2017 17:58, Mandy Chung wrote: > Webrev: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html > > This is a regression caused by JDK-8020801 that the initialization of a custom system class loader hits a code path that checks if a class is loaded by the platform class loader. Such code path should not call ClassLoader::getSystemClassLoader since the system class loader is being initialized. > > The fix is simple and uses jdk.internal.loader.ClassLoaders.platformClassLoader() instead. > The fix looks fine. For the test then I would rename initCustomSystemLoader to something like testEnumValueOf as it's a very specific sub-test. Also I could imagine adding more sub-tests to this too. -Alan From mandy.chung at oracle.com Tue May 9 17:25:36 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 10:25:36 -0700 Subject: Review Request: JDK-8179950: Custom system class loader using Enum.valueOf in its initialization triggers java.lang.InternalError In-Reply-To: <69c7f441-0677-afc8-be6b-b2e72eb98a54@oracle.com> References: <69c7f441-0677-afc8-be6b-b2e72eb98a54@oracle.com> Message-ID: > On May 9, 2017, at 10:08 AM, Alan Bateman wrote: > > > > On 09/05/2017 17:58, Mandy Chung wrote: >> Webrev: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8179950/webrev.00/index.html >> >> This is a regression caused by JDK-8020801 that the initialization of a custom system class loader hits a code path that checks if a class is loaded by the platform class loader. Such code path should not call ClassLoader::getSystemClassLoader since the system class loader is being initialized. >> >> The fix is simple and uses jdk.internal.loader.ClassLoaders.platformClassLoader() instead. >> > The fix looks fine. For the test then I would rename initCustomSystemLoader to something like testEnumValueOf as it's a very specific sub-test. Also I could imagine adding more sub-tests to this too. Good idea. I updated webrev.00 in place. That?s exactly what I have in mind in writing this test to add more subtests to cover code paths - we need to have better test coverage for custom system class loader. Mandy From kumar.x.srinivasan at oracle.com Tue May 9 19:45:48 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 09 May 2017 12:45:48 -0700 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option In-Reply-To: References: <590DE9FB.7040608@oracle.com> <59108047.9090003@oracle.com> Message-ID: <59121C6C.20709@oracle.com> Hi David, I have made the following changes: 1. Removed the launcher's check for model flags, allowing the VM to process and fail, aligned the test ChangeDataModel to the VM's message. 2. Fixed up all the pre-existing conditions, pointed out earlier. Full webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.1/ Incremental webrev (since last reviewed changeset): http://cr.openjdk.java.net/~ksrini/8169646/webrev.1/webrev.delta/ Thanks Kumar > Hi Kumar, > > On 9/05/2017 12:27 AM, Kumar Srinivasan wrote: >> >> Hi David, >> >>> Hi Kumar, >>> >>> On 7/05/2017 1:21 AM, Kumar Srinivasan wrote: >>>> Hello, >>>> >>>> Please review the changes to remove the java launcher's data model >>>> options -d32/-d64, these options existed to support Solaris dual-mode >>>> operation, however for uniformity, these options were accepted by >>>> other >>>> platforms as well. These options are now obsolete, and deprecated in >>>> jdk9,and are now being removed. >>>> >>>> Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 >>> >>> This seems okay in itself, though I'm curious why you made the >>> launcher/jli responsible for treating -d32/-d64 as invalid options >>> instead of just passing them through to the VM to let it reject them >>> as it does any other non-existent option eg: >> >> I mulled over this for sometime, and felt that since the launcher >> supported these options before, it should give a better/reasonable >> error message than the VM does. I am undecided. What do you think ? > > I think all invalid options should be treated the same. We had the > deprecation phase for providing custom feedback - now we're just > rejecting them outright. > > Cheers, > David > >>> >>> > java -foo -version >>> Unrecognized option: -foo >>> Error: Could not create the Java Virtual Machine. >>> Error: A fatal exception has occurred. Program will exit. >>> >>> I also see some pre-existing messiness you might want to tidy up while >>> you're in the area :) >> >> OMG Pre-existing conditions. ;) >> >>> >>> src/java.base/macosx/native/libjli/java_md_macosx.c >>> >>> 378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg", >>> 379 jrepath, FILESEP, FILESEP, "", ""); >>> >>> The last two %s should just be removed instead of passing empty >>> strings. >>> >>> 422 } else { >>> 423 /* >>> 424 * macosx client library is built thin, i386 only. >>> 425 * 64 bit client requests must load server library >>> 426 */ >>> 427 const char *jvmtypeUsed = "server"; >>> 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, >>> jrepath, jvmtypeUsed); >>> 429 } >>> >>> I don't think we have ever had 32-bit client on OSX! So this whole >>> clause seems strange. That aside you can just hardwire %s/lib/server >>> instead of using the jvmTypeUsed variable. >> >> +1, I think we did support 32-bit for sometime, in the early days of >> MacOSX. >> >> >>> >>> --- >>> >>> src/java.base/unix/native/libjli/java_md_solinux.c >>> >>> 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg", >>> 324 jrepath, FILESEP, FILESEP, FILESEP); >>> >>> Another strange version of this code - only 4 %s this time, but >>> adjacent FILESEP. :) I'm assuming this is from when was removed. >> Urk. >> >> Ok I will revisit the above, good catches!, and prepare >> another changeset. >> >> Kumar >> >> >>> >>> Thanks, >>> David >>> >>>> Thanks >>>> Kumar >>>> >>>> PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have >>>> been >>>> purged from internal test suites. >>>> >> From huizhe.wang at oracle.com Tue May 9 22:15:01 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 9 May 2017 15:15:01 -0700 Subject: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs Message-ID: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> Hi, Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/webrev/ Thanks, Joe From brian.burkhalter at oracle.com Tue May 9 22:51:18 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 9 May 2017 15:51:18 -0700 Subject: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs In-Reply-To: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> References: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> Message-ID: <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> Hi Joe, The verbiage looks good (certainly much better than TODO), but the new copyright year is now 20017. ;-) Thanks, Brian On May 9, 2017, at 3:15 PM, huizhe wang wrote: > Hi, > > Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/webrev/ > > Thanks, > Joe From lance.andersen at oracle.com Tue May 9 22:54:09 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 9 May 2017 18:54:09 -0400 Subject: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs In-Reply-To: <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> References: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> Message-ID: Hi Joe, Definitely reads much better > On May 9, 2017, at 6:51 PM, Brian Burkhalter wrote: > > Hi Joe, > > The verbiage looks good (certainly much better than TODO), but the new copyright year is now 20017. ;-) > > Thanks, > > Brian > > On May 9, 2017, at 3:15 PM, huizhe wang wrote: > >> Hi, >> >> Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/webrev/ >> >> Thanks, >> Joe > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brent.christian at oracle.com Tue May 9 23:23:49 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 9 May 2017 16:23:49 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> Message-ID: <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> Brent Christian wrote: > Mandy Chung wrote: >> >> I think we could take out the automatic module case as named module >> would verify it. One refactor you can consider by separating them >> in several @run actions. >> ... >> I think it would make the test easier to read and understand the cases >> it cover. > > True. I'll see what I can do, then. I've removed the test case for automatic modules, and added a @run action for each policy file + system classloader configuration. I also removed the code to compile test sources, using @build instead. I also made some (hopefully) clarifying changes to the code. The String[] argument to execute() is now separated into args/status/message, instead of being lumped into one String[], and then having to be split() out of a single String. Where execute() is called, it's easier to read the args in order (versus assembled using String.format()). I also simplified the code for expected status/output, and made some path variable names more descriptive. Webrev: http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Thanks, -Brent From mandy.chung at oracle.com Tue May 9 23:27:58 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 9 May 2017 16:27:58 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> Message-ID: <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> > On May 9, 2017, at 4:23 PM, Brent Christian > > I've removed the test case for automatic modules, and added a @run action for each policy file + system classloader configuration. I also removed the code to compile test sources, using @build instead. > > I also made some (hopefully) clarifying changes to the code. > > The String[] argument to execute() is now separated into args/status/message, instead of being lumped into one String[], and then having to be split() out of a single String. Where execute() is called, it's easier to read the args in order (versus assembled using String.format()). > > I also simplified the code for expected status/output, and made some path variable names more descriptive. > > Webrev: > http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ Thanks for the clean up. Does each @run action need 4 mins timeout? Can it restore to the default timeout? Mandy From brent.christian at oracle.com Tue May 9 23:39:47 2017 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 9 May 2017 16:39:47 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> Message-ID: On 5/9/17 4:27 PM, Mandy Chung wrote: >> >> Webrev: >> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ > > Thanks for the clean up. Does each @run action need 4 mins timeout? Can it restore to the default timeout? Yes. Between the additional @runs and no longer testing automated modules, I believe that should be fine. -Brent From huizhe.wang at oracle.com Tue May 9 23:54:41 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 9 May 2017 16:54:41 -0700 Subject: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs In-Reply-To: <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> References: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> Message-ID: <03f65704-3f89-e8ec-7168-a086644f6175@oracle.com> On 5/9/2017 3:51 PM, Brian Burkhalter wrote: > Hi Joe, > > The verbiage looks good (certainly much better than TODO), but the new copyright year is now 20017. ;-) wow, predicting copyright 18,000 years ahead of time, am I :-) Fixed. Thanks, Joe > > Thanks, > > Brian > > On May 9, 2017, at 3:15 PM, huizhe wang wrote: > >> Hi, >> >> Please review a fix for stax's package description. This is in a format similar to its SAX/DOM/Stream counterparts. For JDK 10, we could consider converting to package-info.java. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/webrev/ >> >> Thanks, >> Joe From huizhe.wang at oracle.com Tue May 9 23:55:08 2017 From: huizhe.wang at oracle.com (huizhe wang) Date: Tue, 9 May 2017 16:55:08 -0700 Subject: RFR (JAXP) 8179868: Java API Docs of javax.xml.transform.stax contains TODOs In-Reply-To: References: <2c0de625-6fe8-2a6d-291a-e09ea7e2ad29@oracle.com> <807E8599-ED49-4A6D-BFD6-B1423F2FC76F@oracle.com> Message-ID: Thanks Lance! Joe On 5/9/2017 3:54 PM, Lance Andersen wrote: > Hi Joe, > > Definitely reads much better > >> On May 9, 2017, at 6:51 PM, Brian Burkhalter >> > wrote: >> >> Hi Joe, >> >> The verbiage looks good (certainly much better than TODO), but the >> new copyright year is now 20017. ;-) >> >> Thanks, >> >> Brian >> >> On May 9, 2017, at 3:15 PM, huizhe wang > > wrote: >> >>> Hi, >>> >>> Please review a fix for stax's package description. This is in a >>> format similar to its SAX/DOM/Stream counterparts. For JDK 10, we >>> could consider converting to package-info.java. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179868 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8179868/webrev/ >>> >>> >>> Thanks, >>> Joe >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From jonathan.gibbons at oracle.com Wed May 10 00:58:50 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 09 May 2017 17:58:50 -0700 Subject: RFR: 8180041 Fix HTML 5 issues in java.corba Message-ID: <591265CA.40403@oracle.com> Another review for HTML 5 fixes, this time in the java.corba module. As usual, changes are just to the markup, and not to any specification text. JBS: https://bugs.openjdk.java.net/browse/JDK-8180041 Webrev: http://cr.openjdk.java.net/~jjg/8180041/webrev.00/ -- Jon From david.holmes at oracle.com Wed May 10 04:17:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 May 2017 14:17:17 +1000 Subject: RFR: jdk10: 8169646: Remove launcher's -d32/-d64 option In-Reply-To: <59121C6C.20709@oracle.com> References: <590DE9FB.7040608@oracle.com> <59108047.9090003@oracle.com> <59121C6C.20709@oracle.com> Message-ID: <1ad3c789-96e5-cd3a-9f15-4d6931e80a15@oracle.com> Hi Kumar, Changes look good to me! Thanks, David On 10/05/2017 5:45 AM, Kumar Srinivasan wrote: > > Hi David, > > I have made the following changes: > 1. Removed the launcher's check for model flags, allowing the VM to > process > and fail, aligned the test ChangeDataModel to the VM's message. > 2. Fixed up all the pre-existing conditions, pointed out earlier. > > > Full webrev: > http://cr.openjdk.java.net/~ksrini/8169646/webrev.1/ > > Incremental webrev (since last reviewed changeset): > http://cr.openjdk.java.net/~ksrini/8169646/webrev.1/webrev.delta/ > > Thanks > Kumar > >> Hi Kumar, >> >> On 9/05/2017 12:27 AM, Kumar Srinivasan wrote: >>> >>> Hi David, >>> >>>> Hi Kumar, >>>> >>>> On 7/05/2017 1:21 AM, Kumar Srinivasan wrote: >>>>> Hello, >>>>> >>>>> Please review the changes to remove the java launcher's data model >>>>> options -d32/-d64, these options existed to support Solaris dual-mode >>>>> operation, however for uniformity, these options were accepted by >>>>> other >>>>> platforms as well. These options are now obsolete, and deprecated in >>>>> jdk9,and are now being removed. >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ksrini/8169646/webrev.0 >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8169646 >>>> >>>> This seems okay in itself, though I'm curious why you made the >>>> launcher/jli responsible for treating -d32/-d64 as invalid options >>>> instead of just passing them through to the VM to let it reject them >>>> as it does any other non-existent option eg: >>> >>> I mulled over this for sometime, and felt that since the launcher >>> supported these options before, it should give a better/reasonable >>> error message than the VM does. I am undecided. What do you think ? >> >> I think all invalid options should be treated the same. We had the >> deprecation phase for providing custom feedback - now we're just >> rejecting them outright. >> >> Cheers, >> David >> >>>> >>>> > java -foo -version >>>> Unrecognized option: -foo >>>> Error: Could not create the Java Virtual Machine. >>>> Error: A fatal exception has occurred. Program will exit. >>>> >>>> I also see some pre-existing messiness you might want to tidy up while >>>> you're in the area :) >>> >>> OMG Pre-existing conditions. ;) >>> >>>> >>>> src/java.base/macosx/native/libjli/java_md_macosx.c >>>> >>>> 378 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%s%sjvm.cfg", >>>> 379 jrepath, FILESEP, FILESEP, "", ""); >>>> >>>> The last two %s should just be removed instead of passing empty >>>> strings. >>>> >>>> 422 } else { >>>> 423 /* >>>> 424 * macosx client library is built thin, i386 only. >>>> 425 * 64 bit client requests must load server library >>>> 426 */ >>>> 427 const char *jvmtypeUsed = "server"; >>>> 428 JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, >>>> jrepath, jvmtypeUsed); >>>> 429 } >>>> >>>> I don't think we have ever had 32-bit client on OSX! So this whole >>>> clause seems strange. That aside you can just hardwire %s/lib/server >>>> instead of using the jvmTypeUsed variable. >>> >>> +1, I think we did support 32-bit for sometime, in the early days of >>> MacOSX. >>> >>> >>>> >>>> --- >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>> >>>> 323 JLI_Snprintf(jvmcfg, so_jvmcfg, "%s%slib%s%sjvm.cfg", >>>> 324 jrepath, FILESEP, FILESEP, FILESEP); >>>> >>>> Another strange version of this code - only 4 %s this time, but >>>> adjacent FILESEP. :) I'm assuming this is from when was removed. >>> Urk. >>> >>> Ok I will revisit the above, good catches!, and prepare >>> another changeset. >>> >>> Kumar >>> >>> >>>> >>>> Thanks, >>>> David >>>> >>>>> Thanks >>>>> Kumar >>>>> >>>>> PS: Thanks to David Holmes and Igor Ignatyev the -d32/-d64 flags have >>>>> been >>>>> purged from internal test suites. >>>>> >>> > From lance.andersen at oracle.com Wed May 10 10:53:54 2017 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 10 May 2017 06:53:54 -0400 Subject: RFR: 8180041 Fix HTML 5 issues in java.corba In-Reply-To: <591265CA.40403@oracle.com> References: <591265CA.40403@oracle.com> Message-ID: looks fine jon > On May 9, 2017, at 8:58 PM, Jonathan Gibbons wrote: > > Another review for HTML 5 fixes, this time in the java.corba module. > > As usual, changes are just to the markup, and not to any specification text. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180041 > Webrev: http://cr.openjdk.java.net/~jjg/8180041/webrev.00/ > > -- Jon Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Alan.Bateman at oracle.com Wed May 10 12:32:47 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 May 2017 13:32:47 +0100 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() In-Reply-To: References: Message-ID: On 08/05/2017 23:27, Andrew Guibert wrote: > : > > I am not sure why the "no resetting" restriction is on the NamingManager > API in the first place. Is anyone aware why the API has this restriction? > In any case, the solution outlined above seems rather messy (as it only > solves the problem by mitigating a classloader leak), so I would like to > propose the following addition to the NamingManager API: > > I checked with one of the engineers that worked on the JNDI API a long time ago and there doesn't seem to be any significant reason to disallow it be changed. Looking at it now then it might be simpler to change setInitialContextFactoryBuilder to allow a new builder to be set rather than introducing a clearXXX method. I can't imagine anything but tests relying on IllegalStateException to be thrown if already set. A variant to explore is setting the builder to a placeholder InitialContextFactory rather than null. So is your plan to proposal a patch and tests for this? -Alan From pierre at 2bst.fr Wed May 10 13:30:03 2017 From: pierre at 2bst.fr (=?utf-8?q?pierre=402bst=2Efr?=) Date: Wed, 10 May 2017 15:30:03 +0200 Subject: Environment variables truth source of the JVM =?utf-8?q?=28and?= how to mutate =?utf-8?q?it=29?= Message-ID: <5f2a-59131600-b-3f8a2840@228257416> Hi, I've been trying to understand how the JVM accesses environment variables and how they can be mutated. I sent an email about this list few hours ago on the general-purpose discuss mailing-list but it appears it would be better posted herein. For this I've made some assumptions and I would like to know if they'recorrect, could you help me on this? 1) It appears that the JVM gets a copy of its process environment variables and store them in static final fields theUnmodifiableEnvironment and theEnvironment of class java.lang.ProcessEnvironment. - My assumption is: these fields are the "truth source" about ? environment variables inside the JVM and any attempt to access some of ? them will end up in a lookup of this fields. - I have a question about this: why two final fields instead of only ? one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst ? theEnvironment is for env of current process (which could be changed ? with Process.exec(String[] cmdarray, String[] envp, File dir))? 2) There is a subtle way to mutate them in Sun JDK (see http://www.javaspecialists.eu/archive/Issue161.html). - My assumption is: These fields are passed to all new JVM threads, so ? mutating them (as ugly as it can sound) will be JVM-wide and will ? result in all thread getting mutated env as their environment ? variables. ? - Sensitive question: is this enforced? System.getenv() appears to ? correctly returns mutated env, can I deduce all new threads in the JVM ? will get mutated values? ? - Another sensitive question: as these fields are static final, can I ? deduce all threads in the JVM will get mutated values, not only new ? ones? It would be my pleasure to provide further details ifneedsbe. Just let me know if some of the above assumptions are incorrect! Yours faithfully, p2b From aguibert at us.ibm.com Wed May 10 13:33:02 2017 From: aguibert at us.ibm.com (Andrew Guibert) Date: Wed, 10 May 2017 08:33:02 -0500 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() In-Reply-To: References: Message-ID: > From: Alan Bateman > To: Andrew Guibert , core-libs-dev at openjdk.java.net > Date: 05/10/2017 07:32 AM > Subject: Re: Proposal: > javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() > > On 08/05/2017 23:27, Andrew Guibert wrote: > > > : > > > > I am not sure why the "no resetting" restriction is on the NamingManager > > API in the first place. Is anyone aware why the API has this restriction? > > In any case, the solution outlined above seems rather messy (as it only > > solves the problem by mitigating a classloader leak), so I would like to > > propose the following addition to the NamingManager API: > > > > > I checked with one of the engineers that worked on the JNDI API a long > time ago and there doesn't seem to be any significant reason to disallow > it be changed. > > Looking at it now then it might be simpler to change > setInitialContextFactoryBuilder to allow a new builder to be set rather > than introducing a clearXXX method. I can't imagine anything but tests > relying on IllegalStateException to be thrown if already set. A variant > to explore is setting the builder to a placeholder InitialContextFactory > rather than null. Thank you for checking on this Alan! I agree relaxing the setXXX method would be cleaner than introducing a new clearXXX method, but I wasn't sure what the policy was on behavior changes to existing APIs. But I think you are right, there probably isn't any "real" code that depends on this behavior (aside from code like mine that forcibly clears if an ISE is thrown). > So is your plan to proposal a patch and tests for this? I need to check with my management to get all the legal approvals before proposing a patch, so it might take a while. Since it's likely a very small code change I won't be offended if someone else proposes the patch for me =) From Roger.Riggs at Oracle.com Wed May 10 13:47:58 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 May 2017 09:47:58 -0400 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <5f2a-59131600-b-3f8a2840@228257416> References: <5f2a-59131600-b-3f8a2840@228257416> Message-ID: <40ad8f85-6b0b-a996-b89a-0cb6f562b084@Oracle.com> Hi, I'm not sure I have all the history. The current implementation seems more complicated than necessary by trying to avoid copying when not necessary and providing an unused facility to provide access to binary values in the environment. On 5/10/2017 9:30 AM, pierre at 2bst.fr wrote: > Hi, I've been trying to understand how the JVM accesses environment > variables and how they can be mutated. > > I sent an email about this list few hours ago on the general-purpose > discuss mailing-list but it appears it would be better posted herein. > > For this I've made some assumptions and I would like to know if > they'recorrect, could you help me on this? > > 1) It appears that the JVM gets a copy of its process environment > variables and store them in static final fields > theUnmodifiableEnvironment and theEnvironment of class > java.lang.ProcessEnvironment. > > - My assumption is: these fields are the "truth source" about > environment variables inside the JVM and any attempt to access some of > them will end up in a lookup of this fields. The supported access to the environment is System.getenv(String) and System.getenv() to get a Map of all of the values. The environment is shared by all threads within a process and modification is not supported. > > - I have a question about this: why two final fields instead of only > one? Perhaps theUnmodifiableEnvironment stands for base JVM env whilst > theEnvironment is for env of current process (which could be changed > with Process.exec(String[] cmdarray, String[] envp, File dir))? During construction of the environment a modifiable map is needed. When it is fully constructed it is wrapped in an UnmodifiableMap so it cannot be modified when the map is returned from System.getenv(). Process.exec allows the environment to be supplied for *new* process, not to change the environment for the current process. > > 2) There is a subtle way to mutate them in Sun JDK (see > http://www.javaspecialists.eu/archive/Issue161.html). > > - My assumption is: These fields are passed to all new JVM threads, so > mutating them (as ugly as it can sound) will be JVM-wide and will > result in all thread getting mutated env as their environment > variables. > > - Sensitive question: is this enforced? System.getenv() appears to > correctly returns mutated env, can I deduce all new threads in the JVM > will get mutated values? > > - Another sensitive question: as these fields are static final, can I > deduce all threads in the JVM will get mutated values, not only new > ones? Don't do it. It breaks the encapsulation and can cause unexpected behavior in code that uses environment variables. Can you share your use case and rationale for breaking into the API? Roger > > It would be my pleasure to provide further details ifneedsbe. Just let > me know if some of the above assumptions are incorrect! > > Yours faithfully, > > p2b From martinrb at google.com Wed May 10 14:02:20 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 10 May 2017 07:02:20 -0700 Subject: Environment variables truth source of the JVM (and how to mutate it) In-Reply-To: <40ad8f85-6b0b-a996-b89a-0cb6f562b084@Oracle.com> References: <5f2a-59131600-b-3f8a2840@228257416> <40ad8f85-6b0b-a996-b89a-0cb6f562b084@Oracle.com> Message-ID: More info at https://bugs.openjdk.java.net/browse/JDK-8173654 On Wed, May 10, 2017 at 6:47 AM, Roger Riggs wrote: > providing an unused > facility to provide access to binary values in the environment. > > The design was to not modify environment variables passed to children even if they contained binary gibberish and two trip conversion to java String and back to byte array was lossy. From Alan.Bateman at oracle.com Wed May 10 14:25:37 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 May 2017 15:25:37 +0100 Subject: Proposal: javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder() In-Reply-To: References: Message-ID: <9b2a8bfd-b30d-a05c-8aff-6f406b9a64ef@oracle.com> On 10/05/2017 14:33, Andrew Guibert wrote: > : > > I need to check with my management to get all the legal approvals > before proposing a patch, so it might take a while. Since it's likely > a very small code change I won't be offended if someone else proposes > the patch for me =) > I don't see too many people interested in JNDI these days so I think it's all yours. -Alan From brent.christian at oracle.com Wed May 10 16:42:36 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 10 May 2017 09:42:36 -0700 Subject: RFR 9 test-only RFR 8177328 : java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with -Xcomp In-Reply-To: References: <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com> <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com> <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com> <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com> <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com> <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com> <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com> Message-ID: <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com> On 5/9/17 4:39 PM, Brent Christian wrote: > On 5/9/17 4:27 PM, Mandy Chung wrote: >>> >>> Webrev: >>> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/ >> >> Can it restore to the default timeout? > > Yes. Between the additional @runs and no longer testing automated > modules, I believe that should be fine. Webrev updated in place, with the timeout value removed. -Brent From paul.sandoz at oracle.com Wed May 10 17:25:14 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 May 2017 10:25:14 -0700 Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods In-Reply-To: <590CD221.4080100@oracle.com> References: <590CD221.4080100@oracle.com> Message-ID: <43110285-7C52-4DC5-B213-61DC1468119F@oracle.com> Hi, Looks good. Some minor comments. Paul. src/share/vm/classfile/vmSymbols.cpp ? A prior bug: in the original code the case statements for the _weakCompareAndSwapLongVolatile were missing, so we need to add: case vmIntrinsics::_weakCompareAndSeLong etc. I think this is mostly benign as it?s related to disabling intrinsics. src/share/vm/opto/library_call.cpp ? 2594 // LS_cmp_swap_weak: 2595 // 2596 // boolean weakCompareAndSetObjectPlain( Object o, long offset, Object expected, Object x); 2597 // boolean weakCompareAndSetObjectAcquire(Object o, long offset, Object expected, Object x); 2598 // boolean weakCompareAndSetObjectRelease(Object o, long offset, Object expected, Object x); 2599 // 2600 // boolean weakCompareAndSetIntPlain( Object o, long offset, int expected, int x); 2601 // boolean weakCompareAndSetIntAcquire( Object o, long offset, int expected, int x); 2602 // boolean weakCompareAndSetIntRelease( Object o, long offset, int expected, int x); 2603 // 2604 // boolean weakCompareAndSetLongPlain( Object o, long offset, long expected, long x); 2605 // boolean weakCompareAndSetLongAcquire( Object o, long offset, long expected, long x); 2606 // boolean weakCompareAndSetLongRelease( Object o, long offset, long expected, long x); 2607 // Missing volatile variantes in the comment. @@ -4962,7 +4962,7 @@ // See arraycopy_restore_alloc_state() comment // if alloc == NULL we don't have to worry about a tightly coupled allocation so we can emit all needed guards // if saved_jvms != NULL (then alloc != NULL) then we can handle guards and a tightly coupled allocation - // if saved_jvms == NULL and alloc != NULL, we can?t emit any guards + // if saved_jvms == NULL and alloc != NULL, we can???t emit any guards Rouge characters that substituted ?," test/compiler/unsafe/ ? In this directory there are templates you can update from which the test source is generated by running a script. See: hotspot/test/compiler/unsafe/generate-unsafe-access-tests.sh hotspot/test/compiler/unsafe/X-UnsafeAccessTest.java.template > On 5 May 2017, at 12:27, Ron Pressler wrote: > > Hi, > Please review the following core/hotspot change: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8159995 > core webrev: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/ > hotspot webrev: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/ > > This change is covered by existing tests. > > The following renaming was applied: > > - compareAndExchange*Volatile -> compareAndExchange* > - compareAndSwap* -> compareAndSet* > - weakCompareAndSwap* -> weakCompareAndSet*Plain > - weakCompareAndSwap*Volatile -> weakCompareAndSet* > > At this stage, only method and hotspot intrinsic names were changed; node names were left as-is, and may be handled in a separate issue. > > Ron From paul.sandoz at oracle.com Wed May 10 18:16:30 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 May 2017 11:16:30 -0700 Subject: 8169425: Values computed by a ClassValue should not strongly reference the ClassValue In-Reply-To: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com> Message-ID: Hi, I would like to still propose this note for 9, we ain?t gonna resolve the underlying issue in 9. It?s currently an api note but it?s more appropriate as an implementation note (e.g. Ephemerons might help). We could amend the note with Peter?s suggestion as follows: @implNote Care should be taken to ensure that this ClassValue is not strongly reachable from the computed value, more specifically for the case when the class loader of the computed value?s class is not the same as or a descendent of the class loader of this ClassValue?s class. Doing so will prevent classes and their loader from being garbage collected which in turn may induce out of memory errors. Paul. > On 8 Nov 2016, at 15:27, Paul Sandoz wrote: > > Hi, > > Please review the addition of an api note to ClassValue.computeValue. > > There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC?ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down. > > But, there is an edge case where it?s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics. > > So i have opted for an api note. I don?t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.) > > Thanks, > Paul. > > [1] https://bugs.openjdk.java.net/browse/JDK-8136353 > > --- a/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 12:36:21 2016 -0800 > +++ b/src/java.base/share/classes/java/lang/ClassValue.java Tue Nov 08 15:25:04 2016 -0800 > @@ -62,6 +62,13 @@ > * If this method throws an exception, the corresponding call to {@code get} > * will terminate abnormally with that exception, and no class value will be recorded. > * > + * @apiNote > + * Care should be taken to ensure that this {@code ClassValue} is not > + * strongly reachable > + * from the computed value. Doing so may prevent classes and their loaders > + * from being garbage collected which in turn may induce out of memory > + * errors. > + * > * @param type the type whose class value must be computed > * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface > * @see #get From Roger.Riggs at Oracle.com Wed May 10 18:22:40 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 May 2017 14:22:40 -0400 Subject: RFR 9: 8180082 : Broken javadoc links Message-ID: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com> Please review corrections to broken javadoc links: - links to the serialization spec now in ./specs/serialization - links in java.lang to java/util/Spliterator - link in ModuleLayer to Classloader - Links using ../../../.. do not work well when they show up in some indexes; they should use @docRoot webrev: http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/ Issue: https://bugs.openjdk.java.net/browse/JDK-8180082 Thanks, Roger From mandy.chung at oracle.com Wed May 10 18:26:36 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 May 2017 11:26:36 -0700 Subject: RFR 9: 8180082 : Broken javadoc links In-Reply-To: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com> References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com> Message-ID: > On May 10, 2017, at 11:22 AM, Roger Riggs wrote: > > Please review corrections to broken javadoc links: > - links to the serialization spec now in ./specs/serialization > - links in java.lang to java/util/Spliterator > - link in ModuleLayer to Classloader > - Links using ../../../.. do not work well when they show up in some indexes; they should use @docRoot > > webrev: > http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/ Looks good. Mandy From kumar.x.srinivasan at oracle.com Wed May 10 18:35:41 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 10 May 2017 11:35:41 -0700 Subject: RFR: JDK-8179631: Fix Html5 errors in java.management, jdk.management, jdk.jdi and jdk.attach Message-ID: <59135D7D.3010704@oracle.com> Hi All, Please review fixes to make the API doc comments HTML5 clean, there are no changes to the verbiage, and mostly fixes for the table styles defined here: http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ee84b7d44339 For tables with many entries I have used "striped", there are few tables used for formatting purposes, for which "borderless" is used, and "plain" for everything else. Thanks Kumar Webrev: http://cr.openjdk.java.net/~ksrini/8179631/webrev.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8179631 From Alan.Bateman at oracle.com Wed May 10 18:39:07 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 May 2017 19:39:07 +0100 Subject: RFR: 8180041 Fix HTML 5 issues in java.corba In-Reply-To: <591265CA.40403@oracle.com> References: <591265CA.40403@oracle.com> Message-ID: <97e40c85-3bb7-9742-ccd4-d9dac7cd09f0@oracle.com> On 10/05/2017 01:58, Jonathan Gibbons wrote: > Another review for HTML 5 fixes, this time in the java.corba module. > > As usual, changes are just to the markup, and not to any specification > text. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8180041 > Webrev: http://cr.openjdk.java.net/~jjg/8180041/webrev.00/ Looks okay to me. -Alan From kumar.x.srinivasan at oracle.com Wed May 10 18:57:57 2017 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Wed, 10 May 2017 11:57:57 -0700 Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, jdk.httpserver, jdk.net, jdk.sctp Message-ID: <591362B5.9070806@oracle.com> Hello, Please review HTML5 related changes to the above modules, please note there are no changes to the verbiage. Thanks Kumar Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/ JBS: https://bugs.openjdk.java.net/browse/JDK-8179697 From rob.mckenna at oracle.com Wed May 10 19:25:01 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 May 2017 20:25:01 +0100 Subject: RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout Message-ID: <20170510192501.GE3159@vimes> Hi folks, Looking for a review of the following simple change: https://bugs.openjdk.java.net/browse/JDK-8175131 http://cr.openjdk.java.net/~robm/8175131/webrev.01/ Note: I've deliberately limited the connection closure to the described case. If however you feel that it should be applied generally when an exception is thrown (in the if and / or else block) let me know! -Rob From Roger.Riggs at Oracle.com Wed May 10 19:38:57 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 May 2017 15:38:57 -0400 Subject: RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout In-Reply-To: <20170510192501.GE3159@vimes> References: <20170510192501.GE3159@vimes> Message-ID: <61eb44e1-65dc-0306-d82f-229a928fa56b@Oracle.com> Hi Rob, If an exception is thrown in createConnection, it can't return the connection that was created and so it should close it. I would close the connection at line 298, before throwing the exception. Roger On 5/10/2017 3:25 PM, Rob McKenna wrote: > Hi folks, > > Looking for a review of the following simple change: > > https://bugs.openjdk.java.net/browse/JDK-8175131 > http://cr.openjdk.java.net/~robm/8175131/webrev.01/ > > Note: I've deliberately limited the connection closure to the described > case. If however you feel that it should be applied generally when an > exception is thrown (in the if and / or else block) let me know! > > -Rob > From rob.mckenna at oracle.com Wed May 10 20:22:55 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 10 May 2017 21:22:55 +0100 Subject: RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection close connection on timeout In-Reply-To: <61eb44e1-65dc-0306-d82f-229a928fa56b@Oracle.com> References: <20170510192501.GE3159@vimes> <61eb44e1-65dc-0306-d82f-229a928fa56b@Oracle.com> Message-ID: <20170510202255.GG3159@vimes> Good point, I was nervous that there may have been a reason for not closing the connection and completely overlooked the obvious. http://cr.openjdk.java.net/~robm/8175131/webrev.02/ Thanks, -Rob On 10/05/17 03:38, Roger Riggs wrote: > Hi Rob, > > If an exception is thrown in createConnection, it can't return the > connection that was created > and so it should close it. > > I would close the connection at line 298, before throwing the exception. > > Roger > > On 5/10/2017 3:25 PM, Rob McKenna wrote: > >Hi folks, > > > >Looking for a review of the following simple change: > > > >https://bugs.openjdk.java.net/browse/JDK-8175131 > >http://cr.openjdk.java.net/~robm/8175131/webrev.01/ > > > >Note: I've deliberately limited the connection closure to the described > >case. If however you feel that it should be applied generally when an > >exception is thrown (in the if and / or else block) let me know! > > > > -Rob > > > From ron.pressler at oracle.com Wed May 10 20:46:14 2017 From: ron.pressler at oracle.com (Ron Pressler) Date: Wed, 10 May 2017 23:46:14 +0300 Subject: RFR 9 JDK-8180075: Javadoc of MethodHandles.Lookup::bind should note the difference from MethodHandle::bindTo introduced by JDK-8177146 Message-ID: <59137C16.2050509@oracle.com> Hi. Please review the following doc-only patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8180075 There is no change in specification, only an elaboration on a note. Ron ---- diff -r fc53a0468c1f src/java.base/share/classes/java/lang/invoke/MethodHandles.java --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Apr 14 00:05:54 2017 -0700 +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed May 10 20:38:05 2017 +0000 @@ -1660,7 +1660,7 @@ * (If the trailing array argument is the only argument, * the given receiver value will be bound to it.) *

- * This is equivalent to the following code: + * This is almost equivalent to the following code, with some differences noted below: * 

{@code
  import static java.lang.invoke.MethodHandles.*;
  import static java.lang.invoke.MethodType.*;
@@ -1673,7 +1673,10 @@
           * where {@code defc} is either {@code receiver.getClass()} or 
a super
           * type of that class, in which the requested method is accessible
           * to the lookup class.
-         * (Note that {@code bindTo} does not preserve variable arity.)
+         * (Unlike {@code bind}, {@code bindTo} does not preserve 
variable arity.
+         * Also, {@code bindTo} may throw a {@code ClassCastException} 
in instances where {@code bind} would
+         * throw a {@code IllegalAccessException}, as in the case where 
the member is {@code protected} and
+         * the receiver is restricted by {@code findVirtual} to the 
lookup class.)
           * @param receiver the object from which the method is accessed
           * @param name the name of the method
           * @param type the type of the method, with the receiver 
argument omitted



From ron.pressler at oracle.com  Wed May 10 20:57:07 2017
From: ron.pressler at oracle.com (Ron Pressler)
Date: Wed, 10 May 2017 23:57:07 +0300
Subject: RFR 10 JDK-8159995: Rename internal Unsafe.compare methods
In-Reply-To: <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com>
References: <590CD221.4080100@oracle.com>
 <6cfadc10-f64b-c536-0d29-c74c3e81f2b7@oracle.com>
Message-ID: <59137EA3.5020403@oracle.com>

Thank you.

Your comments, and Paul's, have all been addressed in a revised patch 
(same webrev).

Ron

On 08/05/2017 08:30, David Holmes wrote:
> Hi Ron,
>
> On 6/05/2017 5:27 AM, Ron Pressler wrote:
>> Hi,
>> Please review the following core/hotspot change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8159995
>> core webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-jdk/webrev/ 
>>
>>
>> hotspot webrev:
>> http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8159995-unsafe-compare-and-swap-to-set-hotspot/webrev/ 
>>
>>
>>
>> This change is covered by existing tests.
>>
>> The following renaming was applied:
>>
>> - compareAndExchange*Volatile -> compareAndExchange*
>> - compareAndSwap* -> compareAndSet*
>
> So to clarify this for others, there was confusion surrounding the use 
> of "swap" versus "exchange" when both words mean the same thing 
> effectively, but the "swap" functions return a boolean, while the 
> "exchange" functions return the old value. So we changed "swap" to 
> "set" across the APIs - _except_ for the old 
> /jdk.unsupported/share/classes/sun/misc/Unsafe.java because we can't 
> change its exported API for compatibility reasons.
>
> Given any "swap(exp, new)" function can be implemented as 
> "exchange(exp, new) == exp" I'm not sure why we have two complete sets 
> of functions all the way through. But I guess that is a different 
> issue. :)
>
>> - weakCompareAndSwap* -> weakCompareAndSet*Plain
>> - weakCompareAndSwap*Volatile -> weakCompareAndSet*
>>
>> At this stage, only method and hotspot intrinsic names were changed;
>> node names were left as-is, and may be handled in a separate issue.
>
> Overall looks good for libs and hotspot changes.
>
> One nit I spotted:
>
> src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java
>
> +     * compareAndSwap for longs. While the intrinsic compareAndSetLong
>
> compareAndSwap should be compareAndSet
>
> ---
>
> All hotspot files need their copyright years updated to 2017 (if not 
> already).
>
> As there are hotspot changes this must be pushed using JPRT and 
> "-testset hotspot" (but your sponsor should know that :) ).
>
> Thanks,
> David
>
>> Ron


From brian.burkhalter at oracle.com  Wed May 10 21:05:10 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 10 May 2017 14:05:10 -0700
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
Message-ID: 

Hi Roger,

Looks all right to me. I assume you will have already built the actual docs and clicked through the updated links. Always a bit painful ?

Thanks,

Brian

On May 10, 2017, at 11:22 AM, Roger Riggs  wrote:

> Please review corrections to broken javadoc links:
> - links to the serialization spec now in ./specs/serialization
> - links in java.lang to java/util/Spliterator
> - link in ModuleLayer to Classloader
> - Links using ../../../.. do not work well when they show up in some indexes; they should use @docRoot
> 
> webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
> 
> Issue:
>  https://bugs.openjdk.java.net/browse/JDK-8180082


From cedric.champeau at gmail.com  Wed May 10 21:37:25 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Wed, 10 May 2017 23:37:25 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
Message-ID: 

Hi all,

I'm writing this on behalf of the Gradle team. This email is closely
related to the other thread just posted today, but just a timeline
coincidence (just like the email exchange I had today about this with Alan
Bateman ;)) and not exactly the same issue.

We are in the process of making sure Gradle runs properly on JDK 9, but
there's an issue which is unresolved so far, and probably requires a new
API. It's described at [1], and I have discussed this at Devoxx France with
R?mi Forax who suggested to post something here.

In short, Gradle is a build tool which supports building a variety of
different things, from Java to C++. The JVM happens to be its runtime
environment, and Gradle has what we call the Gradle Daemon [2] which is a
long running process, benefiting from the JIT, aimed at effectively running
builds. When the build starts, a client connects to the daemon and sends a
"build request". A daemon will run a single build at a time, and there are
several cases which would trigger a new daemon to spawn (the daemon JVM
arguments are one) but the environment variables are *not*. Since the
daemon is a long running process, it is possible that the environment
variables are mutated between the moment the daemon was spawned (in a
previous build) and the moment the build is executed.

What we do, now, is to send the environment variables of the client to the
daemon, which *mutates* the existing environment variables map provided by
System.getenv. This is exactly what is described in [1] as being sneaky (it
is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
However, there are valid use cases for this:

   - in practice, environment variables are not immutable. It is especially
   true for long running process.
   - native programs can mutate the environment variables. Even if it's not
   recommended, it is possible and legal.
   - Gradle runs in a "blackbox": we don't know what plugins are doing.
   Even if we provide an API which gives access to "environment variables",
   and that those environment variables are not the ones returned by
   System.getenv, plugin authors would have to use this new API to get
   correct information. However, they may use libraries which access
   System.getenv directly, or use native APIs which would get out-of-sync
   information.
   - we need to propagate the environment to forked process (typically,
   forked compilers and worker daemons)

This means that today, we use JNI to effectively mutate the environment
variables of running process (that?s one of the purposes of the
native-platform project). Then, we mutate the backing map of the JDK to
reflect those changes, otherwise the mutation is not visible from Java code.

What can we do now?

   - Have the JDK honor the fact that environment variables *can* be
   mutated, because it just happens. In short, don't create an immutable copy
   of environment variables at startup, but provide a live view of the
   environment variables (using the existing APIs, System.getenv, would be the
   best thing because it would be immediately visible to all consumers,
   including 3rd party code run in plugins). In addition (but not mandatory),
   you could provide us with an API to set environment variables directly from
   Java. This would avoid JNI calls to do this. However, it?s not mandatory,
   because the live view of environment variables would just work in this case.
   - Last, but we would really, really avoid to do this, spawn a new daemon
   if we detect that the environment variables have changed (diff between what
   the client has and the daemon sees). The major drawback of this approach is
   that it kills performance, since a new daemon would have to be spawned. And
   it is likely to do so each time something (through native code, for
   example), mutates environment variables. A very simple example is
the PWD environment
   variables on Linux which contains the working directory. Basically changing
   the directory would be enough to spawn a new daemon. Another example is the
   TERM_SESSION_ID one, which means that 2 different terminals would force
   us to spawn 2 different Gradle daemons. We could, of course, have a list of
   ?blessed? environments variables that we don?t trust, but it?s very easily
   broken, and no good design. That?s why, even if it?s possible, we don?t
   consider this a solution.

Thanks for considering our request, which is currently a blocker for us
(understand, have Gradle running properly under JDK 9).

[1] https://github.com/adammurdoch/native-platform/issues/16
[2] https://docs.gradle.org/current/userguide/gradle_daemon.html

From martinrb at google.com  Wed May 10 21:53:10 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 May 2017 14:53:10 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
Message-ID: 

It seems to be the day for environment variable mutation.

System.getenv was always designed as an immutable snapshot, and more
recently there's emerging consensus that one must never ever mutate
environment variables in a multi-threaded Unix program.  One tends to
acquire a biased view on this after chasing down production programs
mysteriously crashing in getenv.

https://bugs.openjdk.java.net/browse/JDK-8173654
https://bugs.openjdk.java.net/browse/JDK-4953367

On Wed, May 10, 2017 at 2:37 PM, C?dric Champeau 
wrote:

> Hi all,
>
> I'm writing this on behalf of the Gradle team. This email is closely
> related to the other thread just posted today, but just a timeline
> coincidence (just like the email exchange I had today about this with Alan
> Bateman ;)) and not exactly the same issue.
>
> We are in the process of making sure Gradle runs properly on JDK 9, but
> there's an issue which is unresolved so far, and probably requires a new
> API. It's described at [1], and I have discussed this at Devoxx France with
> R?mi Forax who suggested to post something here.
>
> In short, Gradle is a build tool which supports building a variety of
> different things, from Java to C++. The JVM happens to be its runtime
> environment, and Gradle has what we call the Gradle Daemon [2] which is a
> long running process, benefiting from the JIT, aimed at effectively running
> builds. When the build starts, a client connects to the daemon and sends a
> "build request". A daemon will run a single build at a time, and there are
> several cases which would trigger a new daemon to spawn (the daemon JVM
> arguments are one) but the environment variables are *not*. Since the
> daemon is a long running process, it is possible that the environment
> variables are mutated between the moment the daemon was spawned (in a
> previous build) and the moment the build is executed.
>
> What we do, now, is to send the environment variables of the client to the
> daemon, which *mutates* the existing environment variables map provided by
> System.getenv. This is exactly what is described in [1] as being sneaky (it
> is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
> However, there are valid use cases for this:
>
>    - in practice, environment variables are not immutable. It is especially
>    true for long running process.
>    - native programs can mutate the environment variables. Even if it's not
>    recommended, it is possible and legal.
>    - Gradle runs in a "blackbox": we don't know what plugins are doing.
>    Even if we provide an API which gives access to "environment variables",
>    and that those environment variables are not the ones returned by
>    System.getenv, plugin authors would have to use this new API to get
>    correct information. However, they may use libraries which access
>    System.getenv directly, or use native APIs which would get out-of-sync
>    information.
>    - we need to propagate the environment to forked process (typically,
>    forked compilers and worker daemons)
>
> This means that today, we use JNI to effectively mutate the environment
> variables of running process (that?s one of the purposes of the
> native-platform project). Then, we mutate the backing map of the JDK to
> reflect those changes, otherwise the mutation is not visible from Java
> code.
>
> What can we do now?
>
>    - Have the JDK honor the fact that environment variables *can* be
>    mutated, because it just happens. In short, don't create an immutable
> copy
>    of environment variables at startup, but provide a live view of the
>    environment variables (using the existing APIs, System.getenv, would be
> the
>    best thing because it would be immediately visible to all consumers,
>    including 3rd party code run in plugins). In addition (but not
> mandatory),
>    you could provide us with an API to set environment variables directly
> from
>    Java. This would avoid JNI calls to do this. However, it?s not
> mandatory,
>    because the live view of environment variables would just work in this
> case.
>    - Last, but we would really, really avoid to do this, spawn a new daemon
>    if we detect that the environment variables have changed (diff between
> what
>    the client has and the daemon sees). The major drawback of this
> approach is
>    that it kills performance, since a new daemon would have to be spawned.
> And
>    it is likely to do so each time something (through native code, for
>    example), mutates environment variables. A very simple example is
> the PWD environment
>    variables on Linux which contains the working directory. Basically
> changing
>    the directory would be enough to spawn a new daemon. Another example is
> the
>    TERM_SESSION_ID one, which means that 2 different terminals would force
>    us to spawn 2 different Gradle daemons. We could, of course, have a
> list of
>    ?blessed? environments variables that we don?t trust, but it?s very
> easily
>    broken, and no good design. That?s why, even if it?s possible, we don?t
>    consider this a solution.
>
> Thanks for considering our request, which is currently a blocker for us
> (understand, have Gradle running properly under JDK 9).
>
> [1] https://github.com/adammurdoch/native-platform/issues/16
> [2] https://docs.gradle.org/current/userguide/gradle_daemon.html
>

From stuart.marks at oracle.com  Wed May 10 22:02:49 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 10 May 2017 15:02:49 -0700
Subject: JDK 9 RFR(xs): 8180128: small errors in String javadoc
Message-ID: <92d4d920-52d0-44a8-24f3-2a9a9ead4a2e@oracle.com>

Hi all,

Please review a couple really small fixes to the String javadoc.

1) The String(byte[], int, int, int) constructor refers to converting bytes to 
chars as specified "in the method above" except that the method "above" has 
never converted bytes to chars as far as I can see. It really should refer to 
the String(byte[], int) constructor.

2) Missing space in the spec for the String(byte[], int) constructor.

Bug link:  https://bugs.openjdk.java.net/browse/JDK-8180128

Diff below.

Thanks,

s'marks


# HG changeset patch
# User smarks
# Date 1494453313 25200
#      Wed May 10 14:55:13 2017 -0700
# Node ID 89a0a00be57bf543c4304e0a536bbb3fc5fda95a
# Parent  ca5d05dc27dd5912abc14655e637ed62ce3fe505
8180128: small errors in String javadoc
Reviewed-by: XXX

diff -r ca5d05dc27dd -r 89a0a00be57b 
src/java.base/share/classes/java/lang/String.java
--- a/src/java.base/share/classes/java/lang/String.java	Sun May 07 19:01:13 2017 
-0700
+++ b/src/java.base/share/classes/java/lang/String.java	Wed May 10 14:55:13 2017 
-0700
@@ -335,7 +335,7 @@
       * subarray.
       *
       * 
 Each {@code byte} in the subarray is converted to a {@code char} as
-     * specified in the method above.
+     * specified in the {@link #String(byte[],int) String(byte[],int)} constructor.
       *
       * @deprecated This method does not properly convert bytes into characters.
       * As of JDK 1.1, the preferred way to do this is via the
@@ -390,7 +390,7 @@

      /**
       * Allocates a new {@code String} containing characters constructed from
-     * an array of 8-bit integer values. Each character cin the
+     * an array of 8-bit integer values. Each character c in the
       * resulting string is constructed from the corresponding component
       * b in the byte array such that:
       *


From lance.andersen at oracle.com  Wed May 10 22:04:35 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 10 May 2017 18:04:35 -0400
Subject: JDK 9 RFR(xs): 8180128: small errors in String javadoc
In-Reply-To: <92d4d920-52d0-44a8-24f3-2a9a9ead4a2e@oracle.com>
References: <92d4d920-52d0-44a8-24f3-2a9a9ead4a2e@oracle.com>
Message-ID: <43159D26-593A-44E8-BD14-E8840AB18A56@oracle.com>

Looks fine Stuart
> On May 10, 2017, at 6:02 PM, Stuart Marks  wrote:
> 
> Hi all,
> 
> Please review a couple really small fixes to the String javadoc.
> 
> 1) The String(byte[], int, int, int) constructor refers to converting bytes to chars as specified "in the method above" except that the method "above" has never converted bytes to chars as far as I can see. It really should refer to the String(byte[], int) constructor.
> 
> 2) Missing space in the spec for the String(byte[], int) constructor.
> 
> Bug link:  https://bugs.openjdk.java.net/browse/JDK-8180128
> 
> Diff below.
> 
> Thanks,
> 
> s'marks
> 
> 
> # HG changeset patch
> # User smarks
> # Date 1494453313 25200
> #      Wed May 10 14:55:13 2017 -0700
> # Node ID 89a0a00be57bf543c4304e0a536bbb3fc5fda95a
> # Parent  ca5d05dc27dd5912abc14655e637ed62ce3fe505
> 8180128: small errors in String javadoc
> Reviewed-by: XXX
> 
> diff -r ca5d05dc27dd -r 89a0a00be57b src/java.base/share/classes/java/lang/String.java
> --- a/src/java.base/share/classes/java/lang/String.java	Sun May 07 19:01:13 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/String.java	Wed May 10 14:55:13 2017 -0700
> @@ -335,7 +335,7 @@
>      * subarray.
>      *
>      * 
 Each {@code byte} in the subarray is converted to a {@code char} as
> -     * specified in the method above.
> +     * specified in the {@link #String(byte[],int) String(byte[],int)} constructor.
>      *
>      * @deprecated This method does not properly convert bytes into characters.
>      * As of JDK 1.1, the preferred way to do this is via the
> @@ -390,7 +390,7 @@
> 
>     /**
>      * Allocates a new {@code String} containing characters constructed from
> -     * an array of 8-bit integer values. Each character cin the
> +     * an array of 8-bit integer values. Each character c in the
>      * resulting string is constructed from the corresponding component
>      * b in the byte array such that:
>      *
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From brian.burkhalter at oracle.com  Wed May 10 22:07:14 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 10 May 2017 15:07:14 -0700
Subject: JDK 9 RFR(xs): 8180128: small errors in String javadoc
In-Reply-To: <43159D26-593A-44E8-BD14-E8840AB18A56@oracle.com>
References: <92d4d920-52d0-44a8-24f3-2a9a9ead4a2e@oracle.com>
 <43159D26-593A-44E8-BD14-E8840AB18A56@oracle.com>
Message-ID: <7847E67F-769D-4491-A893-1CAA0067FC6F@oracle.com>

+1

The missing space after the ?c? was hard to ?see.?

Brian

On May 10, 2017, at 3:04 PM, Lance Andersen  wrote:

> Looks fine Stuart
>> On May 10, 2017, at 6:02 PM, Stuart Marks  wrote:
>> 
>> Hi all,
>> 
>> Please review a couple really small fixes to the String javadoc.
>> 
>> 1) The String(byte[], int, int, int) constructor refers to converting bytes to chars as specified "in the method above" except that the method "above" has never converted bytes to chars as far as I can see. It really should refer to the String(byte[], int) constructor.
>> 
>> 2) Missing space in the spec for the String(byte[], int) constructor.
>> 
>> Bug link:  https://bugs.openjdk.java.net/browse/JDK-8180128
>> 
>> Diff below.
>> 
>> Thanks,
>> 
>> s'marks
>> 
>> 
>> # HG changeset patch
>> # User smarks
>> # Date 1494453313 25200
>> #      Wed May 10 14:55:13 2017 -0700
>> # Node ID 89a0a00be57bf543c4304e0a536bbb3fc5fda95a
>> # Parent  ca5d05dc27dd5912abc14655e637ed62ce3fe505
>> 8180128: small errors in String javadoc
>> Reviewed-by: XXX
>> 
>> diff -r ca5d05dc27dd -r 89a0a00be57b src/java.base/share/classes/java/lang/String.java
>> --- a/src/java.base/share/classes/java/lang/String.java	Sun May 07 19:01:13 2017 -0700
>> +++ b/src/java.base/share/classes/java/lang/String.java	Wed May 10 14:55:13 2017 -0700
>> @@ -335,7 +335,7 @@
>>     * subarray.
>>     *
>>     * 
 Each {@code byte} in the subarray is converted to a {@code char} as
>> -     * specified in the method above.
>> +     * specified in the {@link #String(byte[],int) String(byte[],int)} constructor.
>>     *
>>     * @deprecated This method does not properly convert bytes into characters.
>>     * As of JDK 1.1, the preferred way to do this is via the
>> @@ -390,7 +390,7 @@
>> 
>>    /**
>>     * Allocates a new {@code String} containing characters constructed from
>> -     * an array of 8-bit integer values. Each character cin the
>> +     * an array of 8-bit integer values. Each character c in the
>>     * resulting string is constructed from the corresponding component
>>     * b in the byte array such that:
>>     *
>> 
> 
> 
>  
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
> 
> 
> 


From martinrb at google.com  Wed May 10 22:10:05 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 May 2017 15:10:05 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
Message-ID: 

You're already acquiring superpowers and voiding any warranty by calling
putenv from JNI.  Why not go further and do your reflective shenanigans via
JNI as well?  In practice, if hotspot has started up and only one java
thread is doing anything, putenv is unlikely to cause a crash (and probably
none of your users have reported any such crash).

From paul.sandoz at oracle.com  Wed May 10 22:40:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 10 May 2017 15:40:31 -0700
Subject: RFR 9 JDK-8180075: Javadoc of MethodHandles.Lookup::bind should
 note the difference from MethodHandle::bindTo introduced by JDK-8177146
In-Reply-To: <59137C16.2050509@oracle.com>
References: <59137C16.2050509@oracle.com>
Message-ID: 


> On 10 May 2017, at 13:46, Ron Pressler  wrote:
> 
> Hi.
> Please review the following doc-only patch.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8180075
> 
> There is no change in specification, only an elaboration on a note.
> 

+1

Paul.

> Ron
> 
> ----
> 
> diff -r fc53a0468c1f src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Fri Apr 14 00:05:54 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java Wed May 10 20:38:05 2017 +0000
> @@ -1660,7 +1660,7 @@
>          * (If the trailing array argument is the only argument,
>          * the given receiver value will be bound to it.)
>          * 

> -         * This is equivalent to the following code:
> +         * This is almost equivalent to the following code, with some differences noted below:
>          * 
{@code
> import static java.lang.invoke.MethodHandles.*;
> import static java.lang.invoke.MethodType.*;
> @@ -1673,7 +1673,10 @@
>          * where {@code defc} is either {@code receiver.getClass()} or a super
>          * type of that class, in which the requested method is accessible
>          * to the lookup class.
> -         * (Note that {@code bindTo} does not preserve variable arity.)
> +         * (Unlike {@code bind}, {@code bindTo} does not preserve variable arity.
> +         * Also, {@code bindTo} may throw a {@code ClassCastException} in instances where {@code bind} would
> +         * throw a {@code IllegalAccessException}, as in the case where the member is {@code protected} and
> +         * the receiver is restricted by {@code findVirtual} to the lookup class.)
>          * @param receiver the object from which the method is accessed
>          * @param name the name of the method
>          * @param type the type of the method, with the receiver argument omitted
> 
> 


From mandy.chung at oracle.com  Wed May 10 22:50:45 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 10 May 2017 15:50:45 -0700
Subject: RFR: [Updated]  Update tables in java.base to be HTML5-friendly.
In-Reply-To: <590D023F.1010809@oracle.com>
References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com>
Message-ID: <63E72F41-CF80-4692-9600-3A3857A5F94E@oracle.com>


> On May 5, 2017, at 3:52 PM, Jonathan Gibbons  wrote:
> 
> This is an updated review for the changes to improve tables in java.base.
> :
> Webrevs:
> 
> langtools (the stylesheet):
> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179479/webrev.01/
> 
> jdk (changes to java.base):
> http://cr.openjdk.java.net/~jjg/8179479-8179592/8179592/webrev.01/
> 
> API showing the combined effect of these cahnges:
> http://cr.openjdk.java.net/~jjg/8179479-8179592/api.01/java.base-summary.html
> 

The new style class names are better. I reviewed the javadoc changes in java.base.

Mostly looks good.  A few table without an explicit class and FileSystemProvider should use striped class table.

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java
-     * 
+     * 


src/java.base/share/classes/java/nio/charset/Charset.java
+ * 

+ * 

+ * 

+ * 

+     * 

> +     * 

>
> src/java.base/share/classes/java/nio/charset/Charset.java
> + * 

> + * 

> + * 

> + * 
 -     *  border="0" cellpadding="2" cellspacing="2" summary="locale-format combinations for newBundle">
> +     * 
 several cases which would trigger a new daemon to spawn (the daemon JVM
> arguments are one) but the environment variables are *not*. Since the
> daemon is a long running process, it is possible that the environment
> variables are mutated between the moment the daemon was spawned (in a
> previous build) and the moment the build is executed.
>
> What we do, now, is to send the environment variables of the client to the
> daemon, which *mutates* the existing environment variables map provided by
> System.getenv. This is exactly what is described in [1] as being sneaky (it
> is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
> However, there are valid use cases for this:
>
>    - in practice, environment variables are not immutable. It is especially
>    true for long running process.
>    - native programs can mutate the environment variables. Even if it's not
>    recommended, it is possible and legal.
>    - Gradle runs in a "blackbox": we don't know what plugins are doing.
>    Even if we provide an API which gives access to "environment variables",
>    and that those environment variables are not the ones returned by
>    System.getenv, plugin authors would have to use this new API to get
>    correct information. However, they may use libraries which access
>    System.getenv directly, or use native APIs which would get out-of-sync
>    information.
>    - we need to propagate the environment to forked process (typically,
>    forked compilers and worker daemons)
>
> This means that today, we use JNI to effectively mutate the environment
> variables of running process (that?s one of the purposes of the
> native-platform project). Then, we mutate the backing map of the JDK to
> reflect those changes, otherwise the mutation is not visible from Java code.
>
> What can we do now?
>
>    - Have the JDK honor the fact that environment variables *can* be
>    mutated, because it just happens. In short, don't create an immutable copy
>    of environment variables at startup, but provide a live view of the
>    environment variables (using the existing APIs, System.getenv, would be the
>    best thing because it would be immediately visible to all consumers,
>    including 3rd party code run in plugins). In addition (but not mandatory),
>    you could provide us with an API to set environment variables directly from
>    Java. This would avoid JNI calls to do this. However, it?s not mandatory,
>    because the live view of environment variables would just work in this case.
>    - Last, but we would really, really avoid to do this, spawn a new daemon
>    if we detect that the environment variables have changed (diff between what
>    the client has and the daemon sees). The major drawback of this approach is
>    that it kills performance, since a new daemon would have to be spawned. And
>    it is likely to do so each time something (through native code, for
>    example), mutates environment variables. A very simple example is
> the PWD environment
>    variables on Linux which contains the working directory. Basically changing
>    the directory would be enough to spawn a new daemon. Another example is the
>    TERM_SESSION_ID one, which means that 2 different terminals would force
>    us to spawn 2 different Gradle daemons. We could, of course, have a list of
>    ?blessed? environments variables that we don?t trust, but it?s very easily
>    broken, and no good design. That?s why, even if it?s possible, we don?t
>    consider this a solution.
>
> Thanks for considering our request, which is currently a blocker for us
> (understand, have Gradle running properly under JDK 9).
>
> [1] https://github.com/adammurdoch/native-platform/issues/16
> [2] https://docs.gradle.org/current/userguide/gradle_daemon.html
>

From martinrb at google.com  Thu May 11 02:10:27 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 May 2017 19:10:27 -0700
Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly.
In-Reply-To: <590D023F.1010809@oracle.com>
References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com>
Message-ID: 

Looks good.

---

I suspect there's some way to specify the styles more compactly, but I
don't know enough css to say.

---

+table.borderless thead tr th, table.borderless tbody tr th,
table.borderless tr th,

+table.plain > thead > tr > th, table.plain > tbody > tr > th, table.plain
> tr > th,

I was surprised at the difference in syntax; why the ">" in one but not the
other?

From martinrb at google.com  Thu May 11 02:50:00 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 10 May 2017 19:50:00 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
Message-ID: 

Since you're OK with doing brain surgery on the JDK and you control the
entire process, consider controlling your daemon with a bytecode rewriting
agent (e.g. byteman) that changes the definition of System.getenv etc.

(Whose side are you on Martin?! ...  I confess I also wish for a faster
gradle ...)

From cedric.champeau at gmail.com  Thu May 11 07:02:09 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 11 May 2017 09:02:09 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
Message-ID: 

Thanks for the answers, folks, but I think they are kind of missing the
point. The fact is that environment variables *are* mutable. Java happens
to return an immutable view of the environment variables when the VM was
started, which is not the reality. We cannot trust what `System.geteenv`
returns. The Javadocs say "current system environment" but it's just not
true. The method should be called `getEnvWhenTheVMWasStarted`.

We also have the problem that the environment of the client and the daemon
differ over time, as I explained in the previous email. And it is pretty
easy to understand that _when the build runs_, we need to get the
environment variables of the _client_, not the daemon. Imagine something as
simple as this:

String toolPath = System.getenv('SOMETOOL_HOME')

and imagine that this code runs in the daemon. When the daemon is started,
there's absolutely no guarantee that this variable is going to exist.
However, we know that when we're going to execute the build, this variable
*has* to be defined. Obviously, it's going to be done from the CLI:

$ export SOMETOOL_HOME = ...
$ ./gradlew run ---> connects to the daemon, passes environment variables,
mutates those of the daemon, which then executes the build

Similarly, from a *single* CLI/terminal, it's very common to change the
values of environment variables (because, hey, they are mutable!):

$ export SOMETOOL_HOME = another path I want to try out
$ ./gradlew run --> ... must update env vars again

So, to work around the problem that Java doesn't provide a way to mutate
the current environment variables, we perform a JNI call to do it. *Then*
we need to mutate the "immutable view" that Java provides, or all Java code
is going to get wrong information, and we would never succeed. Note that
having to resort on JNI to mutate the environment is not the problem. We
can live with that. Once can think it's a bad idea to allow mutation, in
practice, it is necessary, but I reckon it could be a bad idea to have an
API for this. The *real* issue is that `System.getenv` does *not* return
the real values, because it's an immutable view of what existed at the VM
startup.

Note that it's not recommended to mutate environment variables in a
multi-threaded environment. But in practice, you can assimilate what we do
to the VM startup: we get environment variables, mutate them, _then_ the
build runs (and only at that moment we would effectively be
multi-threaded). We can live with potential issues of mutating the
environment: the benefits outperforms the drawbacks by orders of magnitude.
When the daemon is activated, we're not talking about 10% faster builds.
They can effectively be 3, 5 or 10x faster!

Now, back to the problem with JDK 9:

- first, the implementation has changed. But we could adapt our code.
- second, calling `setAccessible` is not allowed anymore. And this is a
MAJOR pita. The problem is that we're trying to access the java base
module, and reflection on that module is not allowed anymore. There are no
good solutions for this: we could write a JVM agent, like you suggested,
that rewrites bytecode. But since we're trying to rewrite a core class, it
would have to be found on the invocation of `java` command itself, and
cannot be dynamically loaded. In addition, we would have to add a flag to
open core classes to rewrite. There are multiple problems with this
approach: first, we don't know on which environment we run before we're
started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
script which tries to infer the version from whatever it finds, this is not
realistic and would add unacceptable latency on the client side (plus, a
lot of headaches to support the various environments we support: Linux,
Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
example, if the build runs in Travis CI, Amazon, or whatever cloudish thing
that spawns its own containers, we cannot tweak the VM arguments. We just
have to use whatever is there. Last, rewriting bytecode has a cost, that
you pay at startup.

Again, what we need is that Java just returns the live view of the
environment variables. Allowing *mutation* is not necessary, technically
speaking, because we can rely on JNI. However, I reckon that returning an
immutable view is done for performance reasons. That's why adding a way to
mutate "the view" would be an acceptable thing I think. No reflection, no
bytecode rewriting, just give a way to mutate the map that
`ProcessEnvironment` retains. The advantage of this is that you would not
effectively mutate the environment variables, so you, on the JVM side,
would be safe. What you would mutate is the view you are retaining.
Alternatively, provide us with an API to "refresh" the view. Like,
`System.getenv(true)`. The benefit would be that you would only have to get
the new view of environment variables if the user asks for it. And,
subsequent callers would get the refreshed view, so people using `gettenv`
in their code would be up-to-date.

I'm really concerned that this problem is not taken seriously. It's a major
performance problem for the most widely used build tool out there
(considering all users, from native to Java and Android). Just saying
"you're doing something nasty" is not a valid answer: we have to do it, and
do it for good reasons.


2017-05-11 4:50 GMT+02:00 Martin Buchholz :

> Since you're OK with doing brain surgery on the JDK and you control the
> entire process, consider controlling your daemon with a bytecode rewriting
> agent (e.g. byteman) that changes the definition of System.getenv etc.
>
> (Whose side are you on Martin?! ...  I confess I also wish for a faster
> gradle ...)
>

From chris.hegarty at oracle.com  Thu May 11 08:07:41 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 11 May 2017 09:07:41 +0100
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
Message-ID: 


On May 10, 2017, at 11:22 AM, Roger Riggs  wrote:

> Please review corrections to broken javadoc links:
> - links to the serialization spec now in ./specs/serialization
> - links in java.lang to java/util/Spliterator
> - link in ModuleLayer to Classloader
> - Links using ../../../.. do not work well when they show up in some indexes; they should use @docRoot
> 
> webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Looks good Roger.

-Chris.

From daniel.fuchs at oracle.com  Thu May 11 09:24:02 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 May 2017 10:24:02 +0100
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
Message-ID: 

Hi Roger,

I'm surprised to see we have  style links in .java
files to link to package summary and java APIs for classes and
methods, when {@link } should work...

For instance in this file:
http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/src/jdk.management/share/classes/com/sun/management/package-info.java.frames.html

Does:

   29  * 

actualy works?? Looks like it has too many ../.. to me...

I suspect (hope?) it could be advantageously replaced by {@link 
java.lang.management}.


Similarly:

   36  * 
   37  * java.lang.management.ManagementFactory.getPlatformMBeanServer

could probably be {@link 
java.lang.management.ManagementFactory#getPlatformMBeanServer()}


This also reminds me that as part of the technical debt we might also
think about replacing package.html files by their more modern
package-info.java counterpart - but that's probably for another day...


cheers,

-- daniel



On 10/05/2017 19:22, Roger Riggs wrote:
> Please review corrections to broken javadoc links:
>  - links to the serialization spec now in ./specs/serialization
>  - links in java.lang to java/util/Spliterator
>  - link in ModuleLayer to Classloader
>  - Links using ../../../.. do not work well when they show up in some
> indexes; they should use @docRoot
>
> webrev:
>   http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>
> Issue:
>   https://bugs.openjdk.java.net/browse/JDK-8180082
>
> Thanks, Roger
>


From Alan.Bateman at oracle.com  Thu May 11 10:39:19 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 May 2017 11:39:19 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
Message-ID: <3941bfab-0464-2721-9ce1-944f1308ffbf@oracle.com>

On 11/05/2017 08:02, C?dric Champeau wrote:

> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable. Java happens
> to return an immutable view of the environment variables when the VM was
> started, which is not the reality. We cannot trust what `System.geteenv`
> returns. The Javadocs say "current system environment" but it's just not
> true. The method should be called `getEnvWhenTheVMWasStarted`.
>
> We also have the problem that the environment of the client and the daemon
> differ over time, as I explained in the previous email. And it is pretty
> easy to understand that _when the build runs_, we need to get the
> environment variables of the _client_, not the daemon. Imagine something as
> simple as this:
>
> String toolPath = System.getenv('SOMETOOL_HOME')
>
> and imagine that this code runs in the daemon. When the daemon is started,
> there's absolutely no guarantee that this variable is going to exist.
> However, we know that when we're going to execute the build, this variable
> *has* to be defined. Obviously, it's going to be done from the CLI:
>
> $ export SOMETOOL_HOME = ...
> $ ./gradlew run ---> connects to the daemon, passes environment variables,
> mutates those of the daemon, which then executes the build
>
> Similarly, from a *single* CLI/terminal, it's very common to change the
> values of environment variables (because, hey, they are mutable!):
>
> $ export SOMETOOL_HOME = another path I want to try out
> $ ./gradlew run --> ... must update env vars again
>
One thing that isn't clear to me is what is reading the env variables in 
the build.

If native tools are reading the env variables then the daemon must be 
executing them in a child process, in which case there is no need for 
the env variables to be in the daemon's environment.

On the other hand, maybe you mean tools written in Java that are invoked 
in the same VM as the daemon (you mentioned warm up in your first mail). 
Do these tools have any other way to specify the configuration? Can you 
give specific examples? I'm just wondering if these in-process tools can 
pick up configuration via system properties or their main method.

BTW: The discussion reminds me a bit of jtreg test harness that we use 
for testing the JDK. It maintains a pool of agents VM and will reuse if 
possible. If tests need special options then it may have to startup a 
new agent VM to do the test that needs the special options.

-Alan

From david.holmes at oracle.com  Thu May 11 10:50:44 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 11 May 2017 20:50:44 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
Message-ID: <742f67ea-9d12-8ade-ba4f-507a64816227@oracle.com>

Hi Cedric,

On 11/05/2017 5:02 PM, C?dric Champeau wrote:
> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable. Java

Yes they are, provided you do it carefully and don't have to deal with 
the fact that its basically just a malloc'd char* array with no 
requirements for any kind of thread-safety. And given the JVM is 
multi-threaded almost as soon as it is launched we're not off to a great 
start in terms of safe and reliable access to a potentially concurrently 
mutable environment.

> happens to return an immutable view of the environment variables when
> the VM was started, which is not the reality. We cannot trust what
> `System.geteenv` returns. The Javadocs say "current system environment"
> but it's just not true. The method should be called
> `getEnvWhenTheVMWasStarted`.

It takes the snapshot on first call, but yes the docs are wrong.

> We also have the problem that the environment of the client and the
> daemon differ over time, as I explained in the previous email. And it is
> pretty easy to understand that _when the build runs_, we need to get the
> environment variables of the _client_, not the daemon. Imagine something
> as simple as this:
>
> String toolPath = System.getenv('SOMETOOL_HOME')
>
> and imagine that this code runs in the daemon. When the daemon is
> started, there's absolutely no guarantee that this variable is going to
> exist. However, we know that when we're going to execute the build, this
> variable *has* to be defined. Obviously, it's going to be done from the CLI:
>
> $ export SOMETOOL_HOME = ...
> $ ./gradlew run ---> connects to the daemon, passes environment
> variables, mutates those of the daemon, which then executes the build

Thanks for clarifying the scenario. So IIUC there is a set of env vars 
defined that provide the communication between the client and the 
daemon. The value of those vars in the client are passed to the daemon 
(via some normal IPC mechanism) and then JNI code on the daemon is used 
to update the daemon's process env so that if the Java getenv looked it 
would see the updated value.

> Similarly, from a *single* CLI/terminal, it's very common to change the
> values of environment variables (because, hey, they are mutable!):
> $ export SOMETOOL_HOME = another path I want to try out
> $ ./gradlew run --> ... must update env vars again
>
> So, to work around the problem that Java doesn't provide a way to mutate
> the current environment variables, we perform a JNI call to do it.
> *Then* we need to mutate the "immutable view" that Java provides, or all
> Java code is going to get wrong information, and we would never succeed.
> Note that having to resort on JNI to mutate the environment is not the
> problem. We can live with that. Once can think it's a bad idea to allow
> mutation, in practice, it is necessary, but I reckon it could be a bad
> idea to have an API for this. The *real* issue is that `System.getenv`
> does *not* return the real values, because it's an immutable view of
> what existed at the VM startup.

Understood.

> Note that it's not recommended to mutate environment variables in a
> multi-threaded environment. But in practice, you can assimilate what we
> do to the VM startup: we get environment variables, mutate them, _then_
> the build runs (and only at that moment we would effectively be
> multi-threaded). We can live with potential issues of mutating the
> environment: the benefits outperforms the drawbacks by orders of
> magnitude. When the daemon is activated, we're not talking about 10%
> faster builds. They can effectively be 3, 5 or 10x faster!
>
> Now, back to the problem with JDK 9:
>
> - first, the implementation has changed. But we could adapt our code.
> - second, calling `setAccessible` is not allowed anymore. And this is a
> MAJOR pita. The problem is that we're trying to access the java base
> module, and reflection on that module is not allowed anymore. There are

I was going to suggest --permit-illegal-access but from what you write 
below it isn't feasible to manage this through VM startup options. I 
don't know whether there is a programmatic equivalent to the "big kill 
switch" - probably not given it will only be there for 9.

> no good solutions for this: we could write a JVM agent, like you
> suggested, that rewrites bytecode. But since we're trying to rewrite a
> core class, it would have to be found on the invocation of `java`
> command itself, and cannot be dynamically loaded. In addition, we would
> have to add a flag to open core classes to rewrite. There are multiple
> problems with this approach: first, we don't know on which environment
> we run before we're started. Gradle can run on JDK 7, 8, 9, ... and we
> cannot have a startup script which tries to infer the version from
> whatever it finds, this is not realistic and would add unacceptable
> latency on the client side (plus, a lot of headaches to support the
> various environments we support: Linux, Mac, Windows, ...). Second, we
> may not have a hand on the CLI at all. For example, if the build runs in
> Travis CI, Amazon, or whatever cloudish thing that spawns its own
> containers, we cannot tweak the VM arguments. We just have to use
> whatever is there. Last, rewriting bytecode has a cost, that you pay at
> startup.
>
> Again, what we need is that Java just returns the live view of the
> environment variables. Allowing *mutation* is not necessary, technically
> speaking, because we can rely on JNI. However, I reckon that returning
> an immutable view is done for performance reasons. That's why adding a
> way to mutate "the view" would be an acceptable thing I think. No
> reflection, no bytecode rewriting, just give a way to mutate the map
> that `ProcessEnvironment` retains. The advantage of this is that you
> would not effectively mutate the environment variables, so you, on the
> JVM side, would be safe. What you would mutate is the view you are
> retaining. Alternatively, provide us with an API to "refresh" the view.
> Like, `System.getenv(true)`. The benefit would be that you would only
> have to get the new view of environment variables if the user asks for
> it. And, subsequent callers would get the refreshed view, so people
> using `gettenv` in their code would be up-to-date.

That may be feasible. I like the idea of getenv(true) to request a 
refresh of the underlying data structure.

> I'm really concerned that this problem is not taken seriously. It's a
> major performance problem for the most widely used build tool out there
> (considering all users, from native to Java and Android). Just saying
> "you're doing something nasty" is not a valid answer: we have to do it,
> and do it for good reasons.

It isn't a matter of not taking the problem seriously. You've raised an 
issue for discussion and it is being discussed, but it is very late in 
the JDK 9 end game to try and add new APIs. This issue has been known 
for a long time and a Gradle issue was filed last September [1]. There 
was some discussion on jigsaw-dev [2] last October, and Alan even 
suggested back then to raise the "setenv" issue on core-libs-dev.

Cheers,
David

[1] https://issues.gradle.org/browse/GRADLE-3565
[2] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-October/009551.html
>
>
> 2017-05-11 4:50 GMT+02:00 Martin Buchholz  >:
>
>     Since you're OK with doing brain surgery on the JDK and you control
>     the entire process, consider controlling your daemon with a bytecode
>     rewriting agent (e.g. byteman) that changes the definition of
>     System.getenv etc.
>
>     (Whose side are you on Martin?! ...  I confess I also wish for a
>     faster gradle ...)
>
>

From daniel.fuchs at oracle.com  Thu May 11 11:54:13 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 May 2017 12:54:13 +0100
Subject: (9) (docs only) RFR: 8180176: Broken javadoc links in java.logging
 and java.naming
Message-ID: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>

Hi,

Please find below a patch for:

8180176: Broken javadoc links in java.logging and java.naming
https://bugs.openjdk.java.net/browse/JDK-8180176

The fix is to use {@docRoot} as has been done elsewhere...
http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

From dalibor.topic at oracle.com  Thu May 11 13:19:10 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Thu, 11 May 2017 15:19:10 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
Message-ID: <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>



On 11.05.2017 09:02, C?dric Champeau wrote:
> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable.

Unfortunately, they are not safely mutable in multi-threaded programs on 
many operating system/libc combinations.

Consider a situation in which one thread calls a not multi-thread safe 
setenv() with a long enough piece of data to stuff into an environment 
variable that it takes more then an instant, while another thread 
simultaneously calls a not multi-thread safe getenv() and reads the 
unfinished, corrupted data, potentially reading beyond boundaries and 
crashing the application.

In such an environment, the safest thing to do is to not update 
environment variables at all. Such environments are very common, 
unfortunately (Linux/glibc is a rather popular one).

Unfortunately, you might not really be able to stop JNI code from 
calling setenv() or an equivalent (or just messing with char ** environ 
directly for fun and profit) at any given point in time so you might not 
be sure that the environment is safe to read at any given point in time, 
either, except at startup time before anyone has had a chance to mess 
with the environment in the first place.

So the one safe thing one can do is what Java already does.

Going beyond in a safe and portable fashion in the JDK itself might be 
quite tricky and require a bit of thought, because environment variables 
are quite a bit of mess to deal with  - see 
http://www.club.cc.cmu.edu/~cmccabe/blog_the_setenv_fiasco.html for a 
nice read.

And that's without even starting to think about the security surface of 
such functionality. For a start, consider the various ways environment 
variables can go wrong elaborated in 
https://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#ENVIRONMENT-VARIABLES 
.

So while it may seem that we're missing the point, and you may very well 
be right, I would naively suspect that providing functionality to 
read/modify/update environment variables in a way that doesn't cause 
problems down the road might not be quite as trivial as it might seem.

cheers,
dalibor topic
-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

From jonathan.gibbons at oracle.com  Thu May 11 15:17:56 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 08:17:56 -0700
Subject: RFR: [Updated] Update tables in java.base to be HTML5-friendly.
In-Reply-To: 
References: <590A5477.9050602@oracle.com> <590D023F.1010809@oracle.com>
 
Message-ID: <37cbe0ce-060c-6c4c-044b-7903b291fac2@oracle.com>

Martin,

I've worked with Bhavesh to sort out these issues. The inconsistency in 
the syntax has been fixed.

The CSS could be more compact ... if we did not have to deal with nested 
tables.  It was also a goal to simplify the use for the doc comment 
author, such that it was possible to put just one class definition on 
the 
 tag, and not have to make additional declarations on the 
tags within the table.

Our experiments showed that when we did not fully specify the structure, 
it was possible for the details of one style to "leak" into another when 
a table of one style was nested in another table of a different style.

At this point, the goal is to introduce the class names, and to have CSS 
that works well enough across the major browsers. If someone wants to 
suggest more concise CSS that works well in all our uses cases, that 
would be a fine RFE for a future release.

-- Jon



On 5/10/17 7:10 PM, Martin Buchholz wrote:
> Looks good.
>
> ---
>
> I suspect there's some way to specify the styles more compactly, but I 
> don't know enough css to say.
>
> ---
>
> +table.borderless thead tr th, table.borderless tbody tr th, 
> table.borderless tr th,
>
> +table.plain > thead > tr > th, table.plain > tbody > tr > th, 
> table.plain > tr > th,
>
> I was surprised at the difference in syntax; why the ">" in one but 
> not the other?


From cedric.champeau at gmail.com  Thu May 11 16:27:59 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 11 May 2017 18:27:59 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <742f67ea-9d12-8ade-ba4f-507a64816227@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <742f67ea-9d12-8ade-ba4f-507a64816227@oracle.com>
Message-ID: 

2017-05-11 12:50 GMT+02:00 David Holmes :

> Hi Cedric,
>
> On 11/05/2017 5:02 PM, C?dric Champeau wrote:
>
>> Thanks for the answers, folks, but I think they are kind of missing the
>> point. The fact is that environment variables *are* mutable. Java
>>
>
> Yes they are, provided you do it carefully and don't have to deal with the
> fact that its basically just a malloc'd char* array with no requirements
> for any kind of thread-safety. And given the JVM is multi-threaded almost
> as soon as it is launched we're not off to a great start in terms of safe
> and reliable access to a potentially concurrently mutable environment.


Yes, we are aware of that, and it has never been a problem so far. As I
said the gain overwhelms the risks.

>
>
>>
> Thanks for clarifying the scenario. So IIUC there is a set of env vars
> defined that provide the communication between the client and the daemon.
> The value of those vars in the client are passed to the daemon (via some
> normal IPC mechanism) and then JNI code on the daemon is used to update the
> daemon's process env so that if the Java getenv looked it would see the
> updated value.


Yes, and to be very clear, the problem is code running in the daemon
itself, which can be build scripts, plugins, or code in 3rd party jars used
by the scripts or plugins. When we fork a process we have no such issue.

>
>>
> That may be feasible. I like the idea of getenv(true) to request a refresh
> of the underlying data structure.
>
> Do you think it's something that could be added in JDK 9? It seems to be a
rather limited change, but I understand what "feature freeze" means :) One
could argue that the current behavior of `getenv` is a bug :)


> It isn't a matter of not taking the problem seriously. You've raised an
> issue for discussion and it is being discussed, but it is very late in the
> JDK 9 end game to try and add new APIs. This issue has been known for a
> long time and a Gradle issue was filed last September [1]. There was some
> discussion on jigsaw-dev [2] last October, and Alan even suggested back
> then to raise the "setenv" issue on core-libs-dev.
>
>
Yes and I apologize for that: I've been talking to several people offline
about this problem, but without a proper email to this list, it was just
side discussions I'm afraid. I had other priorities... Anyway, if it is
impossible to get a fix for JDK 9, I'm afraid the only solution for us is
an agent that would rewrite the `System` class...


> Cheers,
> David
>
> [1] https://issues.gradle.org/browse/GRADLE-3565
> [2] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-Octob
> er/009551.html
>
>>
>>
>> 2017-05-11 4:50 GMT+02:00 Martin Buchholz > >:
>>
>>     Since you're OK with doing brain surgery on the JDK and you control
>>     the entire process, consider controlling your daemon with a bytecode
>>     rewriting agent (e.g. byteman) that changes the definition of
>>     System.getenv etc.
>>
>>     (Whose side are you on Martin?! ...  I confess I also wish for a
>>     faster gradle ...)
>>
>>
>>

From cedric.champeau at gmail.com  Thu May 11 16:29:10 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 11 May 2017 18:29:10 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
Message-ID: 

>
>
>>
> Unfortunately, they are not safely mutable in multi-threaded programs on
> many operating system/libc combinations.
>
> But the problem is less about mutating, that it is about reading: the VM
returns wrong values at some point, because it _assumes_ that the
environment variables are not mutated.

From peter.levart at gmail.com  Thu May 11 17:10:19 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 11 May 2017 19:10:19 +0200
Subject: 8169425: Values computed by a ClassValue should not strongly
 reference the ClassValue
In-Reply-To: 
References: <314D8B90-3D99-4666-A1B4-3152C0D103D3@oracle.com>
 
Message-ID: <06bb8052-ba2e-4805-e66e-80bd11eeae80@gmail.com>

Hm,

Such advise might not be fruitful for average user. Why?

1. ClassValue instances are typically assigned to static final fields of 
application classes. Which means that they will be strongly reachable as 
long as the ClassLoader of such static field's declaring class is 
strongly reachable. In case the app is deployed in some app server, this 
will be a non-permanent class loader (supporting undeployment of the app).

2. ClassValue associated values (i.e. computed values) are typically 
composed of objects that are instances of application classes too. We 
can't expect users to only use objects that are instances of system 
classes (HashMap, String, Integer, etc... loaded by some "permanent" 
class loader such as bootstrap or platform CL).

How can now user adhere to the @implNote?

Even if the user pays attention and does not directly reference the 
ClassValue instance from the associated value(s) through some explicit 
chain of fields, the ClassValue instance will be strongly reachable from 
the associated value:

associated class (the argument to ClassValue.get()) -> associated value 
(i.e. computed value) -> associated value class (presumably some app 
class) -> app class loader -> all app classes (including static field's 
declaring class) -> ClassValue instance

if the associated class is some system class (String, Integer, etc...), 
all above instances are permanently strongly reachable!

Should @implNote advise against either assigning ClassValue instance to 
static fields of application classes or maybe against using application 
classes to construct computed values?

Just using ClassValue> is not a complete solution 
since AppData instances must also be strongly reachable from app class 
loader or they will be GCed prematurely.

We could advise that instead of:

public class AppDataHolder {

     public static final ClassValue APP_DATA_CV = new 
ClassValue<>() {
         @Override
         protected AppData computeValue(Class type) {
             return new AppData();
         }
     };


Users do something like the following:

public class AppDataHolder {

     // make AppData instances strongly reachable from app class loader
     private static final Queue _APP_DATAS = new 
ConcurrentLinkedQueue<>();

     private static final ClassValue> 
_WEAK_APP_DATA_CV = new ClassValue<>() {
         @Override
         protected WeakReference computeValue(Class type) {
             AppData appData = new AppData();
             // make appData strongly reachable from the app class loader
             _APP_DATAS.add(appData);
             return new WeakReference<>(appData);
         }
     };

     // use this function...
     public static final Function, AppData> APP_DATA_FN =
         clazz -> 
Objects.requireNonNull(_WEAK_APP_DATA_CV.get(clazz).get());


Regards, Peter


On 05/10/2017 08:16 PM, Paul Sandoz wrote:
> Hi,
>
> I would like to still propose this note for 9, we ain?t gonna resolve the underlying issue in 9.
>
> It?s currently an api note but it?s more appropriate as an implementation note (e.g. Ephemerons might help).
>
> We could amend the note with Peter?s suggestion as follows:
>
>   @implNote
>   Care should be taken to ensure that this ClassValue is not strongly reachable
>   from the computed value, more specifically for the case when the class loader
>   of the computed value?s class is not the same as or a descendent of the class
>   loader of this ClassValue?s class.
>   Doing so will prevent classes and their loader from being garbage collected
>   which in turn may induce out of memory errors.
>
> Paul.
>
>> On 8 Nov 2016, at 15:27, Paul Sandoz  wrote:
>>
>> Hi,
>>
>> Please review the addition of an api note to ClassValue.computeValue.
>>
>> There is some history behind this issue. Another issue was logged [1] related to Groovy using ClassValue and there being a memory leak with classes/loaders not being GC?ed, but it turned out the problem was with Groovy's explicit retention of computed values in a global set. So i closed that issue down.
>>
>> But, there is an edge case where it?s possible to induce out of memory errors with ClassValue, specifically if the computed value holds onto the corresponding ClassValue instance. I think this is an edge case and does not warrant a change to the ClassValue implementation to support weak refs to computed values which is likely to complicate an already intricate implementation and perturb its performance characteristics.
>>
>> So i have opted for an api note. I don?t want to normatively specify this, nor do i want to allude to various implementation details. (One can argue a similar note could be written for ThreadLocal.)
>>
>> Thanks,
>> Paul.
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8136353
>>
>> --- a/src/java.base/share/classes/java/lang/ClassValue.java	Tue Nov 08 12:36:21 2016 -0800
>> +++ b/src/java.base/share/classes/java/lang/ClassValue.java	Tue Nov 08 15:25:04 2016 -0800
>> @@ -62,6 +62,13 @@
>>       * If this method throws an exception, the corresponding call to {@code get}
>>       * will terminate abnormally with that exception, and no class value will be recorded.
>>       *
>> +     * @apiNote
>> +     * Care should be taken to ensure that this {@code ClassValue} is not
>> +     * strongly reachable
>> +     * from the computed value.  Doing so may prevent classes and their loaders
>> +     * from being garbage collected which in turn may induce out of memory
>> +     * errors.
>> +     *
>>       * @param type the type whose class value must be computed
>>       * @return the newly computed value associated with this {@code ClassValue}, for the given class or interface
>>       * @see #get


From daniel.fuchs at oracle.com  Thu May 11 18:19:31 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 11 May 2017 19:19:31 +0100
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <591362B5.9070806@oracle.com>
References: <591362B5.9070806@oracle.com>
Message-ID: <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>

Hi Kumar,

Looks mostly good.
I'm not too sure about the changes from 
 to 
 and 
 to

 though.

Now some of the package.html files in java.naming retain their

Package Specification
 section, and others have it
changed to 
Package Specification
.

best regards,

-- daniel

On 10/05/2017 19:57, Kumar Srinivasan wrote:
> Hello,
>
> Please review HTML5 related changes to the above modules, please
> note there are no changes to the verbiage.
>
> Thanks
> Kumar
>
> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697


From Roger.Riggs at Oracle.com  Thu May 11 19:41:43 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 11 May 2017 15:41:43 -0400
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
Message-ID: <01443bce-f221-3e10-1c16-e954aba61ae4@Oracle.com>

Hi,

Thanks for the review and suggestions.
{@link ...} will work those links;  some hrefs will remain in cases 
where the link is to an "id" of some
element that is not a method or field name.

Webrev updated in place:
     http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Thanks, Roger

On 5/11/2017 5:24 AM, Daniel Fuchs wrote:
> Hi Roger,
>
> I'm surprised to see we have  style links in .java
> files to link to package summary and java APIs for classes and
> methods, when {@link } should work...
>
> For instance in this file:
> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/src/jdk.management/share/classes/com/sun/management/package-info.java.frames.html 
>
>
> Does:
>
>   29  *  href="{@docRoot}/../../../../api/java/lang/management/package-summary.html">
>
> actualy works?? Looks like it has too many ../.. to me...
>
> I suspect (hope?) it could be advantageously replaced by {@link 
> java.lang.management}.
>
>
> Similarly:
>
>   36  *  href="{@docRoot}/java/lang/management/ManagementFactory.html#getPlatformMBeanServer()">
>   37  * java.lang.management.ManagementFactory.getPlatformMBeanServer
>
> could probably be {@link 
> java.lang.management.ManagementFactory#getPlatformMBeanServer()}
>
>
> This also reminds me that as part of the technical debt we might also
> think about replacing package.html files by their more modern
> package-info.java counterpart - but that's probably for another day...
>
>
> cheers,
>
> -- daniel
>
>
>
> On 10/05/2017 19:22, Roger Riggs wrote:
>> Please review corrections to broken javadoc links:
>>  - links to the serialization spec now in ./specs/serialization
>>  - links in java.lang to java/util/Spliterator
>>  - link in ModuleLayer to Classloader
>>  - Links using ../../../.. do not work well when they show up in some
>> indexes; they should use @docRoot
>>
>> webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8180082
>>
>> Thanks, Roger
>>
>


From jonathan.gibbons at oracle.com  Thu May 11 19:46:04 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 12:46:04 -0700
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
Message-ID: <5914BF7C.4030506@oracle.com>

Daniel,

As a general comment, it is an accessibility error to have "gaps" in the 
header numbering, such as an 
 following an 
 without an 
intervening 
.

If you can point to specific files where you think the numbering has 
been semantically changed, that would be good to know.

-- Jon


On 05/11/2017 11:19 AM, Daniel Fuchs wrote:
> Hi Kumar,
>
> Looks mostly good.
> I'm not too sure about the changes from 
 to 
 and 
 to
> 
 though.
>
> Now some of the package.html files in java.naming retain their
> 
Package Specification
 section, and others have it
> changed to 
Package Specification
.
>
> best regards,
>
> -- daniel
>
> On 10/05/2017 19:57, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review HTML5 related changes to the above modules, please
>> note there are no changes to the verbiage.
>>
>> Thanks
>> Kumar
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
>


From david.holmes at oracle.com  Thu May 11 20:46:08 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 06:46:08 +1000
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom fails
 to Initialize when using SecurityManager
Message-ID: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>

Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/

This is a fix contributed by Doug Lea, from a suggestion made by Alan 
Bateman. While I'm handling the fix process for Doug, it isn't my fix so 
I am also a Reviewer of this fix. I expect Martin to also review.

The fix is quite simple - break the dependency between ThreadLocalRandom 
and the security framework by replacing a doPrivileged block that reads 
a system property with a call to the JDK internal VM.getSavedProperty(). 
This allows TLR to be used transitively from the security framework 
without creating a cyclic initialization dependency which leads to 
failure to initialize.

This fixed is approved for 9.

Thanks,
David

From claes.redestad at oracle.com  Thu May 11 21:01:28 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Thu, 11 May 2017 23:01:28 +0200
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
Message-ID: 

The null check is redundant, so the code could be simplified a bit.

Reviewed regardless!

/Claes

On 2017-05-11 22:46, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>
> This is a fix contributed by Doug Lea, from a suggestion made by Alan 
> Bateman. While I'm handling the fix process for Doug, it isn't my fix 
> so I am also a Reviewer of this fix. I expect Martin to also review.
>
> The fix is quite simple - break the dependency between 
> ThreadLocalRandom and the security framework by replacing a 
> doPrivileged block that reads a system property with a call to the JDK 
> internal VM.getSavedProperty(). This allows TLR to be used 
> transitively from the security framework without creating a cyclic 
> initialization dependency which leads to failure to initialize.
>
> This fixed is approved for 9.
>
> Thanks,
> David


From david.holmes at oracle.com  Thu May 11 21:06:32 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 07:06:32 +1000
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: 
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
 
Message-ID: 

On 12/05/2017 7:01 AM, Claes Redestad wrote:
> The null check is redundant, so the code could be simplified a bit.
>
> Reviewed regardless!

Thanks Claes!

David

> /Claes
>
> On 2017-05-11 22:46, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>>
>> This is a fix contributed by Doug Lea, from a suggestion made by Alan
>> Bateman. While I'm handling the fix process for Doug, it isn't my fix
>> so I am also a Reviewer of this fix. I expect Martin to also review.
>>
>> The fix is quite simple - break the dependency between
>> ThreadLocalRandom and the security framework by replacing a
>> doPrivileged block that reads a system property with a call to the JDK
>> internal VM.getSavedProperty(). This allows TLR to be used
>> transitively from the security framework without creating a cyclic
>> initialization dependency which leads to failure to initialize.
>>
>> This fixed is approved for 9.
>>
>> Thanks,
>> David
>

From paul.sandoz at oracle.com  Thu May 11 21:14:36 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 11 May 2017 14:14:36 -0700
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
Message-ID: <9FE1C8AA-B5E6-4178-AFD8-2F6BD078C9BE@oracle.com>

+1

Paul.

> On 11 May 2017, at 13:46, David Holmes  wrote:
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
> 
> This is a fix contributed by Doug Lea, from a suggestion made by Alan Bateman. While I'm handling the fix process for Doug, it isn't my fix so I am also a Reviewer of this fix. I expect Martin to also review.
> 
> The fix is quite simple - break the dependency between ThreadLocalRandom and the security framework by replacing a doPrivileged block that reads a system property with a call to the JDK internal VM.getSavedProperty(). This allows TLR to be used transitively from the security framework without creating a cyclic initialization dependency which leads to failure to initialize.
> 
> This fixed is approved for 9.
> 
> Thanks,
> David


From aguibert at us.ibm.com  Thu May 11 21:25:13 2017
From: aguibert at us.ibm.com (Andrew Guibert)
Date: Thu, 11 May 2017 16:25:13 -0500
Subject: Proposal:
 javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
In-Reply-To: 
References: 
 
Message-ID: 

Alan, could you please commit this patch for me?  We've tested it locally
and all of the jdk_other tests pass with this change on jdk9.

93d92
<      * Once installed, the builder cannot be replaced.
101d99
<      * @exception IllegalStateException If a factory has already been
installed.
109,111d106
<         if (object_factory_builder != null)
<             throw new IllegalStateException("ObjectFactoryBuilder already
set");
<
739,740c734
<      * the security manager to do so. Once installed, the builder cannot
<      * be replaced.
---
>      * the security manager to do so.
747d740
<      * @exception IllegalStateException If a builder was previous
installed.
754,757d746
<             if (initctx_factory_builder != null)
<                 throw new IllegalStateException(
<                     "InitialContextFactoryBuilder already set");
<

Alan Bateman  wrote on 05/10/2017 07:32:47 AM:

> From: Alan Bateman 
> To: Andrew Guibert , core-libs-dev at openjdk.java.net
> Date: 05/10/2017 07:32 AM
> Subject: Re: Proposal:
> javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
>
> On 08/05/2017 23:27, Andrew Guibert wrote:
>
> > :
> >
> > I am not sure why the "no resetting" restriction is on the
NamingManager
> > API in the first place.  Is anyone aware why the API has this
restriction?
> > In any case, the solution outlined above seems rather messy (as it only
> > solves the problem by mitigating a classloader leak), so I would like
to
> > propose the following addition to the NamingManager API:
> >
> >
> I checked with one of the engineers that worked on the JNDI API a long
> time ago and there doesn't seem to be any significant reason to disallow
> it be changed.
>
> Looking at it now then it might be simpler to change
> setInitialContextFactoryBuilder to allow a new builder to be set rather
> than introducing a clearXXX method. I can't imagine anything but tests
> relying on IllegalStateException to be thrown if already set. A variant
> to explore is setting the builder to a placeholder InitialContextFactory
> rather than null.
>
> So is your plan to proposal a patch and tests for this?
>
> -Alan
>

From david.holmes at oracle.com  Thu May 11 21:29:28 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 07:29:28 +1000
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: <9FE1C8AA-B5E6-4178-AFD8-2F6BD078C9BE@oracle.com>
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
 <9FE1C8AA-B5E6-4178-AFD8-2F6BD078C9BE@oracle.com>
Message-ID: <8b157ce0-ca13-c484-cf97-39aaeabfe323@oracle.com>

Thanks Paul!

David

On 12/05/2017 7:14 AM, Paul Sandoz wrote:
> +1
>
> Paul.
>
>> On 11 May 2017, at 13:46, David Holmes  wrote:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>>
>> This is a fix contributed by Doug Lea, from a suggestion made by Alan Bateman. While I'm handling the fix process for Doug, it isn't my fix so I am also a Reviewer of this fix. I expect Martin to also review.
>>
>> The fix is quite simple - break the dependency between ThreadLocalRandom and the security framework by replacing a doPrivileged block that reads a system property with a call to the JDK internal VM.getSavedProperty(). This allows TLR to be used transitively from the security framework without creating a cyclic initialization dependency which leads to failure to initialize.
>>
>> This fixed is approved for 9.
>>
>> Thanks,
>> David
>

From mandy.chung at oracle.com  Thu May 11 21:55:50 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 14:55:50 -0700
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: 
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
 
Message-ID: <5503721D-044D-47E8-848F-D7FE5DD1AA81@oracle.com>

+1 (dropping the null check as Claes suggests).

Mandy

> On May 11, 2017, at 2:01 PM, Claes Redestad  wrote:
> 
> The null check is redundant, so the code could be simplified a bit.
> 
> Reviewed regardless!
> 
> /Claes
> 
> On 2017-05-11 22:46, David Holmes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>> 
>> This is a fix contributed by Doug Lea, from a suggestion made by Alan Bateman. While I'm handling the fix process for Doug, it isn't my fix so I am also a Reviewer of this fix. I expect Martin to also review.
>> 
>> The fix is quite simple - break the dependency between ThreadLocalRandom and the security framework by replacing a doPrivileged block that reads a system property with a call to the JDK internal VM.getSavedProperty(). This allows TLR to be used transitively from the security framework without creating a cyclic initialization dependency which leads to failure to initialize.
>> 
>> This fixed is approved for 9.
>> 
>> Thanks,
>> David
> 


From brent.christian at oracle.com  Thu May 11 22:25:02 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 11 May 2017 15:25:02 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
In-Reply-To: <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com>
References: 
 <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com>
 <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com>
 <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com>
 
 <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com>
 <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com>
 <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com>
 <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com>
 
 <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com>
Message-ID: <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com>

Hi,

I have one more update, with a couple of suggested changes to simplify 
the execute() calls:

* execute() takes a vararg, so explicit String[] creation can be omitted 
(mostly).

* args common to every execute() call are consolidated into a List. 
(The resulting arg reordering should not affect test execution.)

http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/

Thanks,
-Brent

On 5/10/17 9:42 AM, Brent Christian wrote:
> On 5/9/17 4:39 PM, Brent Christian wrote:
>> On 5/9/17 4:27 PM, Mandy Chung wrote:
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~bchristi/8177328/webrev.01/
>>>
>>> Can it restore to the default timeout?
>>
>> Yes.  Between the additional @runs and no longer testing automated
>> modules, I believe that should be fine.
>
> Webrev updated in place, with the timeout value removed.
>
> -Brent
>

From david.holmes at oracle.com  Thu May 11 22:25:06 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 May 2017 08:25:06 +1000
Subject: (9) RFR: 8179515: Class java.util.concurrent.ThreadLocalRandom
 fails to Initialize when using SecurityManager
In-Reply-To: <5503721D-044D-47E8-848F-D7FE5DD1AA81@oracle.com>
References: <14ae9056-8777-e351-efa2-290b9aa4407e@oracle.com>
 
 <5503721D-044D-47E8-848F-D7FE5DD1AA81@oracle.com>
Message-ID: 

On 12/05/2017 7:55 AM, Mandy Chung wrote:
> +1 (dropping the null check as Claes suggests).

Ok - dropping null check. :)

Thanks,
David

> Mandy
>
>> On May 11, 2017, at 2:01 PM, Claes Redestad  wrote:
>>
>> The null check is redundant, so the code could be simplified a bit.
>>
>> Reviewed regardless!
>>
>> /Claes
>>
>> On 2017-05-11 22:46, David Holmes wrote:
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev/
>>>
>>> This is a fix contributed by Doug Lea, from a suggestion made by Alan Bateman. While I'm handling the fix process for Doug, it isn't my fix so I am also a Reviewer of this fix. I expect Martin to also review.
>>>
>>> The fix is quite simple - break the dependency between ThreadLocalRandom and the security framework by replacing a doPrivileged block that reads a system property with a call to the JDK internal VM.getSavedProperty(). This allows TLR to be used transitively from the security framework without creating a cyclic initialization dependency which leads to failure to initialize.
>>>
>>> This fixed is approved for 9.
>>>
>>> Thanks,
>>> David
>>
>

From kumar.x.srinivasan at oracle.com  Thu May 11 23:16:56 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 11 May 2017 16:16:56 -0700
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
Message-ID: <5914F0E8.2090707@oracle.com>


Hi Daniel,

As Jon surmised, this is an ARIA/accessibility requirement, in that one 
can't
have holes in the usage of h* tags,  as javadoc tool itself uses h1 and h2,
the API docs have to start with h3.

With respect to your comment, the h2->h3 is erroneous and have reverted
them back, so the only changes wrt. h* are h4 -> h3.

New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/

Thanks
Kumar



> Hi Kumar,
>
> Looks mostly good.
> I'm not too sure about the changes from 
 to 
 and 
 to
> 
 though.
>
> Now some of the package.html files in java.naming retain their
> 
Package Specification
 section, and others have it
> changed to 
Package Specification
.
>
> best regards,
>
> -- daniel
>
> On 10/05/2017 19:57, Kumar Srinivasan wrote:
>> Hello,
>>
>> Please review HTML5 related changes to the above modules, please
>> note there are no changes to the verbiage.
>>
>> Thanks
>> Kumar
>>
>> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
>


From jonathan.gibbons at oracle.com  Thu May 11 23:38:35 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 16:38:35 -0700
Subject: RFR: 8180256: HTML5 issues in java.sql
Message-ID: <5914F5FB.1080100@oracle.com>

More HTML 5 fixes to review in a few files in the java.sql and 
java.sql.rowset modules:

JBS: https://bugs.openjdk.java.net/browse/JDK-8180256
Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.00/
API: http://cr.openjdk.java.net/~jjg/8180256/api.00/overview-summary.html

-- Jon

From igor.ignatyev at oracle.com  Fri May 12 00:07:13 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 11 May 2017 17:07:13 -0700
Subject: RFR(S): 8180195: remove jaxp testlibrary
Message-ID: <6E0DF973-A303-44A6-A1D6-8113D2ADDE61@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
> 3049 lines changed: 114 ins; 2927 del; 8 mod;

Hi all,

could you please review this small patch which removes a fork of testlibrary from jaxp repo? there were a few differences b/w the testlibraries: top level testlibrary did not have CompilerUtils class, its ProcessTools did not have executeTestJava (which is basically an alias for executeTestJvm) and its OutputAnalyzer did not have methods to dump stdout, stderr into specific streams.

this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

bug: https://bugs.openjdk.java.net/browse/JDK-8180195
webrev: http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
testing: :jaxp_all

[1] https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor


From kumar.x.srinivasan at oracle.com  Fri May 12 00:17:03 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 11 May 2017 17:17:03 -0700
Subject: RFR: JDK-8179631: Fix Html5 errors in java.management,
 jdk.management, jdk.jdi and jdk.attach
In-Reply-To: <59135D7D.3010704@oracle.com>
References: <59135D7D.3010704@oracle.com>
Message-ID: <5914FEFF.1010404@oracle.com>

Hello,

Ping!.  Lets wrap this up soon, as we have to move to
the next steps in the docs related work.

Thanks
Kumar

> Hi All,
>
> Please review fixes to make the API doc comments HTML5 clean,
> there are no changes to the verbiage, and mostly  fixes for the table
> styles defined here:
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ee84b7d44339
>
> For tables with many entries I have used "striped", there are few
> tables used for formatting purposes, for which "borderless" is used,
> and "plain" for everything else.
>
> Thanks
> Kumar
>
> Webrev: http://cr.openjdk.java.net/~ksrini/8179631/webrev.0/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179631


From lance.andersen at oracle.com  Fri May 12 00:37:06 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 11 May 2017 20:37:06 -0400
Subject: RFR: 8180256: HTML5 issues in java.sql
In-Reply-To: <5914F5FB.1080100@oracle.com>
References: <5914F5FB.1080100@oracle.com>
Message-ID: <0244954F-CD68-4A46-9EF0-018728B6D188@oracle.com>

Looks fine Jon

Best
Lance
> On May 11, 2017, at 7:38 PM, Jonathan Gibbons  wrote:
> 
> More HTML 5 fixes to review in a few files in the java.sql and java.sql.rowset modules:
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180256
> Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.00/
> API: http://cr.openjdk.java.net/~jjg/8180256/api.00/overview-summary.html
> 
> -- Jon

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From jonathan.gibbons at oracle.com  Fri May 12 00:40:39 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 11 May 2017 17:40:39 -0700
Subject: RFR: 8180256: HTML5 issues in java.sql
In-Reply-To: <0244954F-CD68-4A46-9EF0-018728B6D188@oracle.com>
References: <5914F5FB.1080100@oracle.com>
 <0244954F-CD68-4A46-9EF0-018728B6D188@oracle.com>
Message-ID: <59150487.1010704@oracle.com>

Thanks

-- Jon

On 05/11/2017 05:37 PM, Lance Andersen wrote:
> Looks fine Jon
>
> Best
> Lance
>> On May 11, 2017, at 7:38 PM, Jonathan Gibbons 
>> > wrote:
>>
>> More HTML 5 fixes to review in a few files in the java.sql and 
>> java.sql.rowset modules:
>>
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180256
>> Webrev: http://cr.openjdk.java.net/~jjg/8180256/webrev.00/ 
>> 
>> API: 
>> http://cr.openjdk.java.net/~jjg/8180256/api.00/overview-summary.html 
>> 
>>
>> -- Jon
>
> 
> 
> Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
>
>
>


From mandy.chung at oracle.com  Fri May 12 02:48:46 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 11 May 2017 19:48:46 -0700
Subject: RFR: JDK-8179631: Fix Html5 errors in java.management,
 jdk.management, jdk.jdi and jdk.attach
In-Reply-To: <59135D7D.3010704@oracle.com>
References: <59135D7D.3010704@oracle.com>
Message-ID: 


> On May 10, 2017, at 11:35 AM, Kumar Srinivasan  wrote:
> 
> Hi All,
> 
> Please review fixes to make the API doc comments HTML5 clean,
> there are no changes to the verbiage, and mostly  fixes for the table
> styles defined here:
> http://hg.openjdk.java.net/jdk9/dev/langtools/rev/ee84b7d44339
> 
> For tables with many entries I have used "striped", there are few
> tables used for formatting purposes, for which "borderless" is used,
> and "plain" for everything else.
> 
> Thanks
> Kumar
> 
> Webrev: http://cr.openjdk.java.net/~ksrini/8179631/webrev.0/
> JBS: https://bugs.openjdk.java.net/browse/JDK-8179631

Looks good to me.

Mandy

From magnus.ihse.bursie at oracle.com  Fri May 12 08:26:59 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 10:26:59 +0200
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
Message-ID: 

On 2017-05-10 23:05, Brian Burkhalter wrote:
> Hi Roger,
>
> Looks all right to me. I assume you will have already built the actual docs and clicked through the updated links. Always a bit painful ?

Roger,

Did you test the actual links?

I found one needing updating:

In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
class.html#4100 should be updated to class.html#stream-unique-identifiers.

Also, the link in src/java.base/share/classes/java/lang/String.java 
looks suspect. The text refers to Section 6.2 Stream Elements, but to 
get there the link should go to protocol.html#stream-elements. Instead 
it points to output.html, which is Section 2, Object Output Classes. I 
can't really tell which is correct, but my guess is that the text is 
correct and the link is not.

/Magnus

>
> Thanks,
>
> Brian
>
> On May 10, 2017, at 11:22 AM, Roger Riggs  wrote:
>
>> Please review corrections to broken javadoc links:
>> - links to the serialization spec now in ./specs/serialization
>> - links in java.lang to java/util/Spliterator
>> - link in ModuleLayer to Classloader
>> - Links using ../../../.. do not work well when they show up in some indexes; they should use @docRoot
>>
>> webrev:
>>   http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>>
>> Issue:
>>   https://bugs.openjdk.java.net/browse/JDK-8180082


From daniel.fuchs at oracle.com  Fri May 12 09:01:14 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 May 2017 10:01:14 +0100
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: <01443bce-f221-3e10-1c16-e954aba61ae4@Oracle.com>
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
 <01443bce-f221-3e10-1c16-e954aba61ae4@Oracle.com>
Message-ID: <27a6dd98-fc63-8622-9fe7-f04c40e6ebbf@oracle.com>

Hi Roger,

Looks good!

Nit:
java/lang/management/package.html:
   38 conforms to the {@link javax.management JMX}
should probably use {@linkplain } instead.

(no need for a new webrev)

best regards,

-- daniel

On 11/05/2017 20:41, Roger Riggs wrote:
> Hi,
>
> Thanks for the review and suggestions.
> {@link ...} will work those links;  some hrefs will remain in cases
> where the link is to an "id" of some
> element that is not a method or field name.
>
> Webrev updated in place:
>     http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>
> Thanks, Roger
>
> On 5/11/2017 5:24 AM, Daniel Fuchs wrote:
>> Hi Roger,
>>
>> I'm surprised to see we have  style links in .java
>> files to link to package summary and java APIs for classes and
>> methods, when {@link } should work...
>>
>> For instance in this file:
>> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/src/jdk.management/share/classes/com/sun/management/package-info.java.frames.html
>>
>>
>> Does:
>>
>>   29  * > href="{@docRoot}/../../../../api/java/lang/management/package-summary.html">
>>
>>
>> actualy works?? Looks like it has too many ../.. to me...
>>
>> I suspect (hope?) it could be advantageously replaced by {@link
>> java.lang.management}.
>>
>>
>> Similarly:
>>
>>   36  * > href="{@docRoot}/java/lang/management/ManagementFactory.html#getPlatformMBeanServer()">
>>
>>   37  * java.lang.management.ManagementFactory.getPlatformMBeanServer
>>
>> could probably be {@link
>> java.lang.management.ManagementFactory#getPlatformMBeanServer()}
>>
>>
>> This also reminds me that as part of the technical debt we might also
>> think about replacing package.html files by their more modern
>> package-info.java counterpart - but that's probably for another day...
>>
>>
>> cheers,
>>
>> -- daniel
>>
>>
>>
>> On 10/05/2017 19:22, Roger Riggs wrote:
>>> Please review corrections to broken javadoc links:
>>>  - links to the serialization spec now in ./specs/serialization
>>>  - links in java.lang to java/util/Spliterator
>>>  - link in ModuleLayer to Classloader
>>>  - Links using ../../../.. do not work well when they show up in some
>>> indexes; they should use @docRoot
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>>>
>>> Issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8180082
>>>
>>> Thanks, Roger
>>>
>>
>


From Alan.Bateman at oracle.com  Fri May 12 09:02:12 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 May 2017 10:02:12 +0100
Subject: Proposal:
 javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
In-Reply-To: 
References: 
 
 
Message-ID: <7ecfcdef-af59-7760-d3b8-99de47b1e2bf@oracle.com>

On 11/05/2017 22:25, Andrew Guibert wrote:

> Alan, could you please commit this patch for me? We've tested it 
> locally and all of the jdk_other tests pass with this change on jdk9.
>
> 93d92
> < * Once installed, the builder cannot be replaced.
> 101d99
> < * @exception IllegalStateException If a factory has already been 
> installed.
> 109,111d106
> < if (object_factory_builder != null)
> < throw new IllegalStateException("ObjectFactoryBuilder already set");
> <
> 739,740c734
> < * the security manager to do so. Once installed, the builder cannot
> < * be replaced.
> ---
> > * the security manager to do so.
> 747d740
> < * @exception IllegalStateException If a builder was previous installed.
> 754,757d746
> < if (initctx_factory_builder != null)
> < throw new IllegalStateException(
> < "InitialContextFactoryBuilder already set");
> <
>
I assume you will be able to get an IBM contributor to sponsor this. It 
will need an issue in JIRA and tests. All API changes for Java SE 10 and 
beyond will be reviewed by the CSR group [1], that process will be 
opening soon.

-Alan

[1] https://wiki.openjdk.java.net/display/csr/Main

From daniel.fuchs at oracle.com  Fri May 12 09:05:12 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 May 2017 10:05:12 +0100
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <5914BF7C.4030506@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
 <5914BF7C.4030506@oracle.com>
Message-ID: <6aeb2a3b-5aa6-c190-ff26-b5fe6fdb58a9@oracle.com>

On 11/05/2017 20:46, Jonathan Gibbons wrote:
> Daniel,
>
> As a general comment, it is an accessibility error to have "gaps" in the
> header numbering, such as an 
 following an 
 without an
> intervening 
.

Oh! Thank you for the precision. I will take a second look with
that in mind.

>
> If you can point to specific files where you think the numbering has
> been semantically changed, that would be good to know.

In java.naming package.html files, some 
 have been changed to 
.
I was just surprised that it only happened in some of java.naming
package.html files and not all, but I see that Kumar has fixed the issue
in his later webrev.

best regards,

-- daniel

>
> -- Jon
>


From tanderson at openvpms.org  Fri May 12 09:09:06 2017
From: tanderson at openvpms.org (Tim Anderson)
Date: Fri, 12 May 2017 19:09:06 +1000
Subject: How to create dynamically generated JNLP files post JDK-8157337?
Message-ID: <3abe398d-946f-ee64-1cd0-3aba83c07c06@openvpms.org>

Apologies if this is the wrong place for this post, but there doesn't 
appear to be a webstart specific list.

Is it possible to generate a JNLP file with arguments that change each 
invocation, and avoid the webstart security popup being displayed each time?

Background

I have a signed webstart application that is launched via a generated JNLP.

The JNLP is generated to:
* specify the codebase. The application is deployed from a .war
* supply arguments to the application, which change with each invocation

This was working fine up to Java 8 update 111. With subsequent releases, 
webstart now displays a popup every time the app is run:

    Do you want to run this application ?
    ...

    This application will run with unrestricted access which may put 
your computer and personal information at risk.
    Run this application only if you trust the location and publisher above.

It appears to have broken since 8 update 112, when 
https://bugs.openjdk.java.net/browse/JDK-8157337 was introduced.

The issue seems to be that the jnlp href is not supplied, so it 
considers the app to be from multiple hosts.
I can't implement the workaround suggested at 
http://stackoverflow.com/a/43716680 as the codebase is not known until 
runtime.

The JNLP used for template replacement:


     
         
         
             
         
         
             
             

            
         

         
             $$arguments
         
     

The APPLICATION_TEMPLATE.JNLP

     
         
         
             
         
         
             
             

             
         

         
             *
         
     

Thanks,

-Tim

Also see:
* https://bugs.openjdk.java.net/browse/JDK-8175981
* https://bugs.openjdk.java.net/browse/JDK-8157337
* 
http://stackoverflow.com/questions/42866652/the-do-you-want-to-run-this-application-prompt-is-always-displayed-for-a-dyna


From daniel.fuchs at oracle.com  Fri May 12 09:18:42 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 May 2017 10:18:42 +0100
Subject: RFR: JDK-8179697: Fix Html5 errors in java.naming, java.logging, 
 jdk.httpserver, jdk.net, jdk.sctp
In-Reply-To: <5914F0E8.2090707@oracle.com>
References: <591362B5.9070806@oracle.com>
 <6b3349ec-8093-c308-1e31-87ec894370b8@oracle.com>
 <5914F0E8.2090707@oracle.com>
Message-ID: <3227dd91-0ab8-b411-322e-312026503b9e@oracle.com>

Hi Kumar,

On 12/05/2017 00:16, Kumar Srinivasan wrote:
>
> Hi Daniel,
>
> As Jon surmised, this is an ARIA/accessibility requirement, in that one
> can't
> have holes in the usage of h* tags,  as javadoc tool itself uses h1 and h2,
> the API docs have to start with h3.
>
> With respect to your comment, the h2->h3 is erroneous and have reverted
> them back, so the only changes wrt. h* are h4 -> h3.
>
> New webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.1/

This looks good now. Thanks for explaining the issue with holes in
the usage of h* tags - it makes it much easier to understand the
rationale behind the changes.

A few nits:
com/sun/net/httpserver/HttpServer.java:
   62  * 

   71  * 
description


there are 2 spaces after 'caption'


javax/naming/event/package.html:
   82 
Threading Issues

  101 
Exception Handling


I wonder if these two tags should be changed to 
 as well,
so as not to introduce a hierarchy that was not there before.
(these do not seem to be sub-concepts of 
Naming Events

  as far as I can see - but then I'm not a JNDI expert)

Otherwise looks good, no need for a new webrev.

best regards,

-- daniel


>
> Thanks
> Kumar
>
>
>
>> Hi Kumar,
>>
>> Looks mostly good.
>> I'm not too sure about the changes from 
 to 
 and 
 to
>> 
 though.
>>
>> Now some of the package.html files in java.naming retain their
>> 
Package Specification
 section, and others have it
>> changed to 
Package Specification
.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 10/05/2017 19:57, Kumar Srinivasan wrote:
>>> Hello,
>>>
>>> Please review HTML5 related changes to the above modules, please
>>> note there are no changes to the verbiage.
>>>
>>> Thanks
>>> Kumar
>>>
>>> Webrev: http://cr.openjdk.java.net/~ksrini/8179697/webrev.0/
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8179697
>>
>


From daniel.fuchs at oracle.com  Fri May 12 11:39:39 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Fri, 12 May 2017 12:39:39 +0100
Subject: (9) (docs only) RFR: 8180176: Broken javadoc links in
 java.logging and java.naming
In-Reply-To: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>
References: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>
Message-ID: 

Hi,

I have refreshed my webrev to use {@extLink } instead as this
is what is needed now for links to technical guides:

http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

best regards,

-- daniel

On 11/05/2017 12:54, Daniel Fuchs wrote:
> Hi,
>
> Please find below a patch for:
>
> 8180176: Broken javadoc links in java.logging and java.naming
> https://bugs.openjdk.java.net/browse/JDK-8180176
>
> The fix is to use {@docRoot} as has been done elsewhere...
> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html
>
> best regards,
>
> -- daniel


From vyom.tewari at oracle.com  Fri May 12 12:11:17 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Fri, 12 May 2017 17:41:17 +0530
Subject: (9) (docs only) RFR: 8180176: Broken javadoc links in
 java.logging and java.naming
In-Reply-To: 
References: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>
 
Message-ID: <141aa493-8b5f-4ee6-efd9-ab34cbd0d666@oracle.com>

Hi Daniel,

Changes looks good, i was under impression that if {@extLink } 
description is multi word then you have to put it under double quotes 
like {xtLink jndi_overview "JNDI documentation"} but looks like that is 
not the case ExtLink.java will take care of this.

Thanks,

Vyom


On Friday 12 May 2017 05:09 PM, Daniel Fuchs wrote:
> Hi,
>
> I have refreshed my webrev to use {@extLink } instead as this
> is what is needed now for links to technical guides:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html
>
> best regards,
>
> -- daniel
>
> On 11/05/2017 12:54, Daniel Fuchs wrote:
>> Hi,
>>
>> Please find below a patch for:
>>
>> 8180176: Broken javadoc links in java.logging and java.naming
>> https://bugs.openjdk.java.net/browse/JDK-8180176
>>
>> The fix is to use {@docRoot} as has been done elsewhere...
>> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html
>>
>> best regards,
>>
>> -- daniel
>


From dalibor.topic at oracle.com  Fri May 12 13:28:28 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Fri, 12 May 2017 15:28:28 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
 
Message-ID: <09a6a643-1b30-b6ed-9345-4de1cd5e616f@oracle.com>

On 11.05.2017 18:29, C?dric Champeau wrote:
>
>
>     Unfortunately, they are not safely mutable in multi-threaded
>     programs on many operating system/libc combinations.
>
> But the problem is less about mutating, that it is about reading: the VM
> returns wrong values at some point, because it _assumes_ that the
> environment variables are not mutated.

Right. Assuming that another thread could be simultaneously writing to 
the same data structure holding environment variables (char **), reading 
itself becomes problematic at such points in time, as you might read a 
temporarily corrupted data structure.

I guess the question underneath is if there is a safe point in time when 
reading the data could be preformed and no concurrent write from JNI 
code corrupting the data when it's partially read is possible.

cheers,
dalibor topic
-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

From stuart.marks at oracle.com  Fri May 12 15:19:33 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 12 May 2017 08:19:33 -0700
Subject: JDK 9 RFR(xs): 8180137: fix broken link in java.lang.Iterable
Message-ID: 

Hi all,

Another quick doc change. This one removes a link from Iterable to 
technotes/guides and adjusts adjacent wording to match. Patch below.

Bug link: https://bugs.openjdk.java.net/browse/JDK-8180137

Thanks,

s'marks

# HG changeset patch
# User smarks
# Date 1494544788 25200
#      Thu May 11 16:19:48 2017 -0700
# Node ID cfff17f92ff2422ea4c576835b90cc16f0e3d805
# Parent  a3af889e7f6591e4c00d79ce454f6725cba19eb6
8180137: fix broken link in java.lang.Iterable
Reviewed-by: XXX

diff -r a3af889e7f65 -r cfff17f92ff2 
src/java.base/share/classes/java/lang/Iterable.java
--- a/src/java.base/share/classes/java/lang/Iterable.java	Wed May 10 15:59:15 
2017 -0700
+++ b/src/java.base/share/classes/java/lang/Iterable.java	Thu May 11 16:19:48 
2017 -0700
@@ -31,16 +31,13 @@
  import java.util.function.Consumer;

  /**
- * Implementing this interface allows an object to be the target of
- * the "for-each loop" statement. See
- * 
- * For-each Loop
- * 
+ * Implementing this interface allows an object to be the target of the enhanced
+ * {@code for} statement (sometimes called the "for-each loop" statement).
   *
   * @param  the type of elements returned by the iterator
   *
   * @since 1.5
- * @jls 14.14.2 The enhanced for statement
+ * @jls 14.14.2 The enhanced {@code for} statement
   */
  public interface Iterable {
      /**

From Roger.Riggs at Oracle.com  Fri May 12 15:23:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 12 May 2017 11:23:07 -0400
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
 
Message-ID: 

Hi Magnus,

Webrev updated:
    http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/


On 5/12/2017 4:26 AM, Magnus Ihse Bursie wrote:
> On 2017-05-10 23:05, Brian Burkhalter wrote:
>> Hi Roger,
>>
>> Looks all right to me. I assume you will have already built the 
>> actual docs and clicked through the updated links. Always a bit 
>> painful ?
>
> Roger,
>
> Did you test the actual links?
Well, linklint tries; though the output is a bit clouded by the 7105 
missing named anchors
and it did not complain about the missing #4100.

>
> I found one needing updating:
>
> In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
> class.html#4100 should be updated to 
> class.html#stream-unique-identifiers.
yes, fixed
>
> Also, the link in src/java.base/share/classes/java/lang/String.java 
> looks suspect. The text refers to Section 6.2 Stream Elements, but to 
> get there the link should go to protocol.html#stream-elements. Instead 
> it points to output.html, which is Section 2, Object Output Classes. I 
> can't really tell which is correct, but my guess is that the text is 
> correct and the link is not.
The current reference is to bullet 9 that describes procedurally how 
serializationof String occurs.

The target you suggest in protocol.html describes the encoding and would 
be ok too,
but for stability I'd leave it as is.

Is it ok to put in a  anchor in 
the output.md markdown
or what is the preferred markup?

Thanks, Roger


>
> /Magnus
>
>>
>> Thanks,
>>
>> Brian
>>
>> On May 10, 2017, at 11:22 AM, Roger Riggs  
>> wrote:
>>
>>> Please review corrections to broken javadoc links:
>>> - links to the serialization spec now in ./specs/serialization
>>> - links in java.lang to java/util/Spliterator
>>> - link in ModuleLayer to Classloader
>>> - Links using ../../../.. do not work well when they show up in some 
>>> indexes; they should use @docRoot
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>>>
>>> Issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8180082
>


From Roger.Riggs at Oracle.com  Fri May 12 15:26:48 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 12 May 2017 11:26:48 -0400
Subject: JDK 9 RFR(xs): 8180137: fix broken link in java.lang.Iterable
In-Reply-To: 
References: 
Message-ID: <92c18756-eb24-735b-e6a1-bbe9631ae281@Oracle.com>

Looks fine.

On 5/12/2017 11:19 AM, Stuart Marks wrote:
> Hi all,
>
> Another quick doc change. This one removes a link from Iterable to 
> technotes/guides and adjusts adjacent wording to match. Patch below.
>
> Bug link: https://bugs.openjdk.java.net/browse/JDK-8180137
>
> Thanks,
>
> s'marks
>
> # HG changeset patch
> # User smarks
> # Date 1494544788 25200
> #      Thu May 11 16:19:48 2017 -0700
> # Node ID cfff17f92ff2422ea4c576835b90cc16f0e3d805
> # Parent  a3af889e7f6591e4c00d79ce454f6725cba19eb6
> 8180137: fix broken link in java.lang.Iterable
> Reviewed-by: XXX
>
> diff -r a3af889e7f65 -r cfff17f92ff2 
> src/java.base/share/classes/java/lang/Iterable.java
> --- a/src/java.base/share/classes/java/lang/Iterable.java    Wed May 
> 10 15:59:15 2017 -0700
> +++ b/src/java.base/share/classes/java/lang/Iterable.java    Thu May 
> 11 16:19:48 2017 -0700
> @@ -31,16 +31,13 @@
>  import java.util.function.Consumer;
>
>  /**
> - * Implementing this interface allows an object to be the target of
> - * the "for-each loop" statement. See
> - * 
> - *  href="{@docRoot}/../technotes/guides/language/foreach.html">For-each 
> Loop
> - * 
> + * Implementing this interface allows an object to be the target of 
> the enhanced
> + * {@code for} statement (sometimes called the "for-each loop" 
> statement).
>   *
>   * @param  the type of elements returned by the iterator
>   *
>   * @since 1.5
> - * @jls 14.14.2 The enhanced for statement
> + * @jls 14.14.2 The enhanced {@code for} statement
>   */
>  public interface Iterable {
>      /**


From mandy.chung at oracle.com  Fri May 12 16:11:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 09:11:52 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
In-Reply-To: <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com>
References: 
 <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com>
 <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com>
 <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com>
 
 <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com>
 <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com>
 <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com>
 <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com>
 
 <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com>
 <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com>
Message-ID: <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com>


> On May 11, 2017, at 3:25 PM, Brent Christian  wrote:
> 
> Hi,
> 
> I have one more update, with a couple of suggested changes to simplify the execute() calls:
> 
> * execute() takes a vararg, so explicit String[] creation can be omitted (mostly).
> 
> * args common to every execute() call are consolidated into a List. (The resulting arg reordering should not affect test execution.)
> 
> http://cr.openjdk.java.net/~bchristi/8177328/webrev.02/

This looks much cleaner.  Thanks for the change.

Minor comment:
  95     private final List COMMON_ARGS;

This is an instance field and you can use lower case as the convention.

 238                     return !s.equals("");                

You can consider using String::isEmpty.

No need for an updated webrev.

Thanks
Mandy

From chris.hegarty at oracle.com  Fri May 12 16:40:58 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 12 May 2017 17:40:58 +0100
Subject: (9) (docs only) RFR: 8180176: Broken javadoc links in
 java.logging and java.naming
In-Reply-To: 
References: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>
 
Message-ID: <15e79df8-1c78-4e7f-baa0-f73726d34fca@oracle.com>

On 12/05/17 12:39, Daniel Fuchs wrote:
> Hi,
>
> I have refreshed my webrev to use {@extLink } instead as this
> is what is needed now for links to technical guides:
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

Looks good.

-Chris.

From mandy.chung at oracle.com  Fri May 12 16:56:14 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 09:56:14 -0700
Subject: (9) (docs only) RFR: 8180176: Broken javadoc links in
 java.logging and java.naming
In-Reply-To: 
References: <5d82baff-1a4f-2c9f-f385-89f53073989a@oracle.com>
 
Message-ID: <0288A539-B2A9-4B83-BBD9-0252F16E8F4A@oracle.com>


> On May 12, 2017, at 4:39 AM, Daniel Fuchs  wrote:
> 
> Hi,
> 
> I have refreshed my webrev to use {@extLink } instead as this
> is what is needed now for links to technical guides:
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8180176/webrev.00/index.html

Looks good.

Mandy


From brent.christian at oracle.com  Fri May 12 17:10:11 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 12 May 2017 10:10:11 -0700
Subject: RFR 9 test-only RFR 8177328 :
 java/lang/ClassLoader/securityManager/ClassLoaderTest.java times out with
 -Xcomp
In-Reply-To: <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com>
References: 
 <118606be-39f7-182f-c58e-bdf8fdaaa9f6@oracle.com>
 <077c33d5-3114-b496-7f12-b4b5db6cb5bb@oracle.com>
 <559682CF-A3BA-427E-AAE3-0FE16F87B08A@oracle.com>
 
 <93AA5D4A-5775-43F3-8F5E-4E47C3877DFE@oracle.com>
 <2719a055-31e1-ff1f-3c17-662e82cfb04b@oracle.com>
 <00ce4b5a-62b4-c569-3aa9-c508a14a2a55@oracle.com>
 <3614F0D9-7CD6-4A91-9B19-C53BD1830AD3@oracle.com>
 
 <5cd74a85-eee3-d892-5bd0-cd0e1c2fa0f8@oracle.com>
 <8bf39416-d566-a192-86c3-ee04f55c2b5f@oracle.com>
 <8EA37F21-9000-4BF1-AA95-82D8FF2C558A@oracle.com>
Message-ID: <2ec6153e-5cbf-1458-449b-7ac6755f0aa8@oracle.com>

On 5/12/17 9:11 AM, Mandy Chung wrote:
>
> Minor comment:
>   95     private final List COMMON_ARGS;
>
> This is an instance field and you can use lower case as the convention.
>
>  238                     return !s.equals("");
>
> You can consider using String::isEmpty.

Thanks, Mandy.  I will make these changes before pushing.

-Brent


From lance.andersen at oracle.com  Fri May 12 18:07:48 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 12 May 2017 14:07:48 -0400
Subject: RFR 8180309: Minor update to  javax.sql.rowset package.html
Message-ID: 

Hi all, 

This change updates the JDBC spec that is being pointed to

?????
hg diff
diff -r e2b414957632 src/java.sql.rowset/share/classes/javax/sql/rowset/package.html
--- a/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html	Fri May 12 10:43:28 2017 -0700
+++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html	Fri May 12 14:03:34 2017 -0400
@@ -284,7 +284,7 @@
 
 
4.0 Related Specifications

 

???????

Best
Lance
 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From mandy.chung at oracle.com  Fri May 12 18:29:07 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 12 May 2017 11:29:07 -0700
Subject: RFR 8180309: Minor update to  javax.sql.rowset package.html
In-Reply-To: 
References: 
Message-ID: 

+1

Mandy

> On May 12, 2017, at 11:07 AM, Lance Andersen  wrote:
> 
> Hi all, 
> 
> This change updates the JDBC spec that is being pointed to
> 
> ?????
> hg diff
> diff -r e2b414957632 src/java.sql.rowset/share/classes/javax/sql/rowset/package.html
> --- a/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html	Fri May 12 10:43:28 2017 -0700
> +++ b/src/java.sql.rowset/share/classes/javax/sql/rowset/package.html	Fri May 12 14:03:34 2017 -0400
> @@ -284,7 +284,7 @@
> 
> 
4.0 Related Specifications

> 
> 
> ???????
> 
> Best
> Lance
> 
>  
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
> 
> 
> 


From magnus.ihse.bursie at oracle.com  Fri May 12 18:42:50 2017
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 12 May 2017 20:42:50 +0200
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
 
 
Message-ID: 



On 2017-05-12 17:23, Roger Riggs wrote:
> Hi Magnus,
>
> Webrev updated:
> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/

Looks good to me.

>
>
>
> On 5/12/2017 4:26 AM, Magnus Ihse Bursie wrote:
>> On 2017-05-10 23:05, Brian Burkhalter wrote:
>>> Hi Roger,
>>>
>>> Looks all right to me. I assume you will have already built the 
>>> actual docs and clicked through the updated links. Always a bit 
>>> painful ?
>>
>> Roger,
>>
>> Did you test the actual links?
> Well, linklint tries; though the output is a bit clouded by the 7105 
> missing named anchors
> and it did not complain about the missing #4100.
>
>>
>> I found one needing updating:
>>
>> In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
>> class.html#4100 should be updated to 
>> class.html#stream-unique-identifiers.
> yes, fixed
>>
>> Also, the link in src/java.base/share/classes/java/lang/String.java 
>> looks suspect. The text refers to Section 6.2 Stream Elements, but to 
>> get there the link should go to protocol.html#stream-elements. 
>> Instead it points to output.html, which is Section 2, Object Output 
>> Classes. I can't really tell which is correct, but my guess is that 
>> the text is correct and the link is not.
> The current reference is to bullet 9 that describes procedurally how 
> serializationof String occurs.
>
> The target you suggest in protocol.html describes the encoding and 
> would be ok too,
> but for stability I'd leave it as is.
>
> Is it ok to put in a  anchor in 
> the output.md markdown
> or what is the preferred markup?

Yes, if you need to link to something other than a heading, that's what 
you need to to. More modern pandocs support a more "markdownish" syntax 
but that's not available for us right now.

/Magnus


From jonathan.gibbons at oracle.com  Fri May 12 18:55:46 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 12 May 2017 11:55:46 -0700
Subject: RFR 9: 8180082 : Broken javadoc links
In-Reply-To: 
References: <0f6908b1-65bf-ab05-6432-ecb0af5e49da@Oracle.com>
 
 
Message-ID: <59160532.1030703@oracle.com>

I can strongly recommend using link checker tools.

For a long time, linklint has been the recommendation. However, linklint 
cannot cope with "id" attribute on tags that are not  tags. That's 
legal in HTML 5, but linklint is an old tool.  There are newer tools out 
there, for both online and offline use, but I haven't used them enough 
to make a specific recommendation.

-- Jon


On 05/12/2017 01:26 AM, Magnus Ihse Bursie wrote:
> On 2017-05-10 23:05, Brian Burkhalter wrote:
>> Hi Roger,
>>
>> Looks all right to me. I assume you will have already built the 
>> actual docs and clicked through the updated links. Always a bit 
>> painful ?
>
> Roger,
>
> Did you test the actual links?
>
> I found one needing updating:
>
> In src/java.base/share/classes/java/io/ObjectStreamClass.java, 
> class.html#4100 should be updated to 
> class.html#stream-unique-identifiers.
>
> Also, the link in src/java.base/share/classes/java/lang/String.java 
> looks suspect. The text refers to Section 6.2 Stream Elements, but to 
> get there the link should go to protocol.html#stream-elements. Instead 
> it points to output.html, which is Section 2, Object Output Classes. I 
> can't really tell which is correct, but my guess is that the text is 
> correct and the link is not.
>
> /Magnus
>
>>
>> Thanks,
>>
>> Brian
>>
>> On May 10, 2017, at 11:22 AM, Roger Riggs  
>> wrote:
>>
>>> Please review corrections to broken javadoc links:
>>> - links to the serialization spec now in ./specs/serialization
>>> - links in java.lang to java/util/Spliterator
>>> - link in ModuleLayer to Classloader
>>> - Links using ../../../.. do not work well when they show up in some 
>>> indexes; they should use @docRoot
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-broken-links-8180082/
>>>
>>> Issue:
>>>   https://bugs.openjdk.java.net/browse/JDK-8180082
>


From david.holmes at oracle.com  Mon May 15 05:14:39 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 May 2017 15:14:39 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <6fa4254e-fbfb-a612-e336-b01d45a1f51a@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
 
 <09a6a643-1b30-b6ed-9345-4de1cd5e616f@oracle.com>
 <6fa4254e-fbfb-a612-e336-b01d45a1f51a@oracle.com>
Message-ID: <540ee326-3b57-2e9f-2f8d-507b84ecd44e@oracle.com>

Re-sending to core-libs-dev

On 13/05/2017 5:56 PM, David Holmes wrote:
> Hi Dalibor,
>
> On 12/05/2017 11:28 PM, dalibor topic wrote:
>> On 11.05.2017 18:29, C?dric Champeau wrote:
>>>
>>>
>>>     Unfortunately, they are not safely mutable in multi-threaded
>>>     programs on many operating system/libc combinations.
>>>
>>> But the problem is less about mutating, that it is about reading: the VM
>>> returns wrong values at some point, because it _assumes_ that the
>>> environment variables are not mutated.
>>
>> Right. Assuming that another thread could be simultaneously writing to
>> the same data structure holding environment variables (char **), reading
>> itself becomes problematic at such points in time, as you might read a
>> temporarily corrupted data structure.
>>
>> I guess the question underneath is if there is a safe point in time when
>> reading the data could be preformed and no concurrent write from JNI
>> code corrupting the data when it's partially read is possible.
>
> I'm afraid no such safe point guarantee exists at all - even for the
> initial reading of the process environment on the first call to System
> getenv(). There could always potentially be some JNI, or other native
> in-process code, mutating the environ char** at the same time as we
> first read it in the JVM.
>
> But we're not trying to protect against random concurrent updates in the
> current scenario, things are more structured:
> - request comes in with data that says to update certain env vars
> - JNI code updates the env vars
> - the daemon's java code (currently) causes the System.getenv map to be
> updated
> - the "client" code is executed and reads the env var and sees the right
> value
>
> There would have to be a caveat on System.getenv(true) if we went that
> path, that it is up to the user to ensure it is called in as safe a
> manner as possible having regard to any concurrent updates in their
> application code and how the environment is managed on a given platform.
>
> Cheers,
> David
> -----
>
>> cheers,
>> dalibor topic

From david.holmes at oracle.com  Tue May 16 00:02:38 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 May 2017 10:02:38 +1000
Subject: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX
In-Reply-To: <5919B970.2070004@oracle.com>
References: <5918EE3B.4010405@oracle.com>
 
 <5919B970.2070004@oracle.com>
Message-ID: 

Hi Kumar,

On 16/05/2017 12:21 AM, Kumar Srinivasan wrote:
> Hi David,
>
>>>
>>> Please review simple fix for JDK-8180202, recall we hard coded "server",
>>> this is incorrect because the function CheckJvmType will determin
>>> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
>>> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.
>>
>> So this original change was wrong:
>>
>> !         const char *jvmtypeUsed = ((bitsWanted == 64) &&
>> (strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
>> !         const char *jvmtypeUsed = "server";
>>
>> because jvmType might still be something other than "server"? Not sure
>> how but okay.
>>
>> However I don't see the connection to -XXaltjvm as that should be
>> setting a full path itself and not relying on jvmType within the
>> well-known path ??
>
> Ah, please see
> http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/51214dadd48f/src/java.base/macosx/native/libjli/java_md_macosx.c#l420
>
>
> What is happening is if XXaltjvm contains a slash then it treats it as a
> path,
> ex: -XXaltjvm /tmp/myvm
>
> if not then jvmtype, and uses it choose the VM variant, the latter seems to
> be an override for jvm.cfg, ex: -XXaltjvm minimal

Ah! I did not realize that - how quirky - I guess it avoids the need to 
modify jvm.cfg to add a known VM.

> Not sure of the historical background,  all this needs some cleanup, and
> removing jvm.cfg will help clean some of this mess up.
>
> Hope that clarifies.

Thanks!

David

>
> Kumar
>
>
>
>>
>>> Thanks
>>> Kumar
>>>
>>> PS: please also approve the removal of the test from the internal
>>> ProblemList.txt
>>
>> Ok.
>>
>> Thanks,
>> David
>>
>>> diff in the JBS issue.
>>>
>>> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> b/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
>>> @@ -424,7 +424,7 @@
>>>           * macosx client library is built thin, i386 only.
>>>           * 64 bit client requests must load server library
>>>           */
>>> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
>>> jrepath);
>>> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
>>> jrepath, jvmtype);
>>>      }
>>>
>>>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>>>
>>>
>>>
>>>
>>>
>>>
>

From kumar.x.srinivasan at oracle.com  Mon May 15 14:21:36 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 15 May 2017 07:21:36 -0700
Subject: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX
In-Reply-To: 
References: <5918EE3B.4010405@oracle.com>
 
Message-ID: <5919B970.2070004@oracle.com>

Hi David,

>>
>> Please review simple fix for JDK-8180202, recall we hard coded "server",
>> this is incorrect because the function CheckJvmType will determin
>> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
>> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.
>
> So this original change was wrong:
>
> !         const char *jvmtypeUsed = ((bitsWanted == 64) && 
> (strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
> !         const char *jvmtypeUsed = "server";
>
> because jvmType might still be something other than "server"? Not sure 
> how but okay.
>
> However I don't see the connection to -XXaltjvm as that should be 
> setting a full path itself and not relying on jvmType within the 
> well-known path ??

Ah, please see
http://hg.openjdk.java.net/jdk10/jdk10/jdk/file/51214dadd48f/src/java.base/macosx/native/libjli/java_md_macosx.c#l420

What is happening is if XXaltjvm contains a slash then it treats it as a 
path,
ex: -XXaltjvm /tmp/myvm

if not then jvmtype, and uses it choose the VM variant, the latter seems to
be an override for jvm.cfg, ex: -XXaltjvm minimal

Not sure of the historical background,  all this needs some cleanup, and
removing jvm.cfg will help clean some of this mess up.

Hope that clarifies.

Kumar



>
>> Thanks
>> Kumar
>>
>> PS: please also approve the removal of the test from the internal
>> ProblemList.txt
>
> Ok.
>
> Thanks,
> David
>
>> diff in the JBS issue.
>>
>> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
>> b/src/java.base/macosx/native/libjli/java_md_macosx.c
>> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
>> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
>> @@ -424,7 +424,7 @@
>>           * macosx client library is built thin, i386 only.
>>           * 64 bit client requests must load server library
>>           */
>> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
>> jrepath);
>> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
>> jrepath, jvmtype);
>>      }
>>
>>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>>
>>
>>
>>
>>
>>


From david.holmes at oracle.com  Mon May 15 00:28:54 2017
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 May 2017 10:28:54 +1000
Subject: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX
In-Reply-To: <5918EE3B.4010405@oracle.com>
References: <5918EE3B.4010405@oracle.com>
Message-ID: 

Hi Kumar,

On 15/05/2017 9:54 AM, Kumar Srinivasan wrote:
> Hi David,
>
> Please review simple fix for JDK-8180202, recall we hard coded "server",
> this is incorrect because the function CheckJvmType will determin
> the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
> -XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.

So this original change was wrong:

!         const char *jvmtypeUsed = ((bitsWanted == 64) && 
(strcmp(jvmtype, "client") == 0)) ? "server" : jvmtype;
!         const char *jvmtypeUsed = "server";

because jvmType might still be something other than "server"? Not sure 
how but okay.

However I don't see the connection to -XXaltjvm as that should be 
setting a full path itself and not relying on jvmType within the 
well-known path ??

> Thanks
> Kumar
>
> PS: please also approve the removal of the test from the internal
> ProblemList.txt

Ok.

Thanks,
David

> diff in the JBS issue.
>
> diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c
> b/src/java.base/macosx/native/libjli/java_md_macosx.c
> --- a/src/java.base/macosx/native/libjli/java_md_macosx.c
> +++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
> @@ -424,7 +424,7 @@
>           * macosx client library is built thin, i386 only.
>           * 64 bit client requests must load server library
>           */
> -        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL,
> jrepath);
> +        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL,
> jrepath, jvmtype);
>      }
>
>      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);
>
>
>
>
>
>

From huizhe.wang at oracle.com  Tue May 16 03:21:09 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Mon, 15 May 2017 20:21:09 -0700
Subject: RFR(S): 8180195: remove jaxp testlibrary
In-Reply-To: <029a01d2cdef$33ad29f0$9b077dd0$@oracle.com>
References: <6E0DF973-A303-44A6-A1D6-8113D2ADDE61@oracle.com>
 <029a01d2cdef$33ad29f0$9b077dd0$@oracle.com>
Message-ID: <72ceab50-4e34-59d7-fcc8-8b870b2f6b4b@oracle.com>

+1. Thanks Frank for checking.

-Joe

On 5/15/2017 7:50 PM, Frank Yuan wrote:
> Looks fine, although I am not a reviewer.
>
> Thanks
> Frank
>
>> -----Original Message-----
>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
>> Subject: RFR(S): 8180195: remove jaxp testlibrary
>>
>> http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
>>> 3049 lines changed: 114 ins; 2927 del; 8 mod;
>> Hi all,
>>
>> could you please review this small patch which removes a fork of testlibrary from jaxp repo? there were a few differences b/w the
> testlibraries:
>> top level testlibrary did not have CompilerUtils class, its ProcessTools did not have executeTestJava (which is basically an alias
> for
>> executeTestJvm) and its OutputAnalyzer did not have methods to dump stdout, stderr into specific streams.
>>
>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8180195
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
>> testing: :jaxp_all
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8075327
>>
>> Thanks,
>> -- Igor
>


From igor.ignatyev at oracle.com  Mon May 15 21:00:03 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 15 May 2017 14:00:03 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
Message-ID: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
>  lines changed: 2 ins; 88 del; 6 mod; 

Hi all,

could you please review this small fix which removes TimeLimitedRunner class from jdk testlibrary? we have two TimeLimitedRunner classes one in jdk test library and another in the the toplevel test library, there is no difference b/w these two library classes (besides location and package name), so the tests were simply updated to use TimeLimitedRunner from the toplevel test library.

this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

webrev: http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180386
testing: affected tests (java/lang/invoke)

[1] https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor

From brian.burkhalter at oracle.com  Tue May 16 01:27:59 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 15 May 2017 18:27:59 -0700
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation does
 not indicate properly whether files get truncated or not
Message-ID: 

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-8180353
Patch:	[1]

Thanks,

Brian

[1] Hg diff

--- a/src/java.base/share/classes/java/io/FileOutputStream.java
+++ b/src/java.base/share/classes/java/io/FileOutputStream.java
@@ -91,6 +91,12 @@
      * If the file exists but is a directory rather than a regular file, does
      * not exist but cannot be created, or cannot be opened for any other
      * reason then a FileNotFoundException is thrown.
+     * 

+     * Invoking this constructor with the parameter {@code name} is equivalent
+     * to invoking the constructor {@link #FileOutputStream(String,boolean)
+     * FileOutputStream(name,append)} with the same {@code String} parameter
+     * {@code name} and the {@code boolean} parameter {@code append} equal to
+     * {@code false}.
      *
      * @param      name   the system-dependent filename
      * @exception  FileNotFoundException  if the file exists but is a directory

From frank.yuan at oracle.com  Tue May 16 02:50:36 2017
From: frank.yuan at oracle.com (Frank Yuan)
Date: Tue, 16 May 2017 10:50:36 +0800
Subject: RFR(S): 8180195: remove jaxp testlibrary
In-Reply-To: <6E0DF973-A303-44A6-A1D6-8113D2ADDE61@oracle.com>
References: <6E0DF973-A303-44A6-A1D6-8113D2ADDE61@oracle.com>
Message-ID: <029a01d2cdef$33ad29f0$9b077dd0$@oracle.com>

Looks fine, although I am not a reviewer.

Thanks
Frank

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
> Subject: RFR(S): 8180195: remove jaxp testlibrary
> 
> http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
> > 3049 lines changed: 114 ins; 2927 del; 8 mod;
> 
> Hi all,
> 
> could you please review this small patch which removes a fork of testlibrary from jaxp repo? there were a few differences b/w the
testlibraries:
> top level testlibrary did not have CompilerUtils class, its ProcessTools did not have executeTestJava (which is basically an alias
for
> executeTestJvm) and its OutputAnalyzer did not have methods to dump stdout, stderr into specific streams.
> 
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8180195
> webrev: http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
> testing: :jaxp_all
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> Thanks,
> -- Igor



From kumar.x.srinivasan at oracle.com  Sun May 14 23:54:35 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Sun, 14 May 2017 16:54:35 -0700
Subject: RFR: JDK-8180202: -XXaltjvm is not working anymore on MacOSX
Message-ID: <5918EE3B.4010405@oracle.com>

Hi David,

Please review simple fix for JDK-8180202, recall we hard coded "server",
this is incorrect because the function CheckJvmType will determin
the correct jvmtype based on jvm.cfg *or* path/jvmtype specified by
-XXaltjvm.  IMO all this needs to be cleaned up when jvm.cfg is removed.

Thanks
Kumar

PS: please also approve the removal of the test from the internal 
ProblemList.txt
diff in the JBS issue.

diff --git a/src/java.base/macosx/native/libjli/java_md_macosx.c 
b/src/java.base/macosx/native/libjli/java_md_macosx.c
--- a/src/java.base/macosx/native/libjli/java_md_macosx.c
+++ b/src/java.base/macosx/native/libjli/java_md_macosx.c
@@ -424,7 +424,7 @@
           * macosx client library is built thin, i386 only.
           * 64 bit client requests must load server library
           */
-        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/server/" JVM_DLL, 
jrepath);
+        JLI_Snprintf(jvmpath, jvmpathsize, "%s/lib/%s/" JVM_DLL, 
jrepath, jvmtype);
      }

      JLI_TraceLauncher("Does `%s' exist ... ", jvmpath);







From Roger.Riggs at Oracle.com  Mon May 15 15:58:00 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Mon, 15 May 2017 11:58:00 -0400
Subject: RFR 9 (doc) 8180319 : Update Serialization spec to omit obsolete
 serialver -show and change history
Message-ID: 

Please review editorial updates to the serialization spec to remove
obsolete serialver -show option and the obsolete change history.

Webrev:
   http://cr.openjdk.java.net/~rriggs/webrev-serialver-noui-8180319/

Thanks, Roger



From david.holmes at oracle.com  Tue May 16 07:02:58 2017
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 May 2017 17:02:58 +1000
Subject: RFR 8u Backport: 8179515: Class
 java.util.concurrent.ThreadLocalRandom fails to Initialize when using
 SecurityManager
Message-ID: 

The existing code in 8u was a little different to 9, but the new code is 
identical (other than package names):

webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
9 review thread: 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html

Thanks,
David

From chris.hegarty at oracle.com  Tue May 16 08:02:05 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 May 2017 09:02:05 +0100
Subject: RFR 9 (doc) 8180319 : Update Serialization spec to omit obsolete
 serialver -show and change history
In-Reply-To: 
References: 
Message-ID: <0ED995A1-CC19-4992-A076-BF1A52EF12E5@oracle.com>

On 15 May 2017, at 16:58, Roger Riggs  wrote:
> 
> Please review editorial updates to the serialization spec to remove
> obsolete serialver -show option and the obsolete change history.
> 
> Webrev:
>  http://cr.openjdk.java.net/~rriggs/webrev-serialver-noui-8180319/

Looks good to me Roger.

-Chris.

From chris.hegarty at oracle.com  Tue May 16 08:05:18 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 May 2017 09:05:18 +0100
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation
 does not indicate properly whether files get truncated or not
In-Reply-To: 
References: 
Message-ID: <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>

Looks good Brian.

-Chris.

> On 16 May 2017, at 02:27, Brian Burkhalter  wrote:
> 
> Please review at your convenience.
> 
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8180353
> Patch:	[1]
> 
> Thanks,
> 
> Brian
> 
> [1] Hg diff
> 
> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
> @@ -91,6 +91,12 @@
>      * If the file exists but is a directory rather than a regular file, does
>      * not exist but cannot be created, or cannot be opened for any other
>      * reason then a FileNotFoundException is thrown.
> +     * 

> +     * Invoking this constructor with the parameter {@code name} is equivalent
> +     * to invoking the constructor {@link #FileOutputStream(String,boolean)
> +     * FileOutputStream(name,append)} with the same {@code String} parameter
> +     * {@code name} and the {@code boolean} parameter {@code append} equal to
> +     * {@code false}.
>      *
>      * @param      name   the system-dependent filename
>      * @exception  FileNotFoundException  if the file exists but is a directory


From felix.yang at oracle.com  Tue May 16 08:59:12 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 16 May 2017 16:59:12 +0800
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
Message-ID: 

Hi there,

     please review the new tests added for ServiceLoader updates for 
module system.

Test bug:

     https://bugs.openjdk.java.net/browse/JDK-8087307

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/

Related product Changes:

     https://bugs.openjdk.java.net/browse/JDK-8132026

     https://bugs.openjdk.java.net/browse/JDK-8047814

Thanks,

Felix



From matthias.baesken at sap.com  Tue May 16 09:04:31 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 16 May 2017 09:04:31 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
Message-ID: 

Hello, could you please review this small change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/

it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .

Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent


https://bugs.openjdk.java.net/browse/JDK-8180413


Best regards, Matthias


From christoph.langer at sap.com  Tue May 16 09:23:44 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 16 May 2017 09:23:44 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: 
References: 
Message-ID: 

Hi Matthias,

this definitely makes sense. If 'data' is NULL, one should not access its fields, except a hard crash is desired... Reviewed. Don't forget to update the copyright year.

Best regards
Christoph

From: Baesken, Matthias
Sent: Dienstag, 16. Mai 2017 11:05
To: core-libs-dev at openjdk.java.net
Cc: Simonis, Volker ; Langer, Christoph 
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Hello, could you please review this small change :

http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/

it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .

Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent


https://bugs.openjdk.java.net/browse/JDK-8180413


Best regards, Matthias


From Alan.Bateman at oracle.com  Tue May 16 09:50:52 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 May 2017 10:50:52 +0100
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: 
References: 
Message-ID: <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>



On 16/05/2017 10:04, Baesken, Matthias wrote:
> Hello, could you please review this small change :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>
> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>
> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>
>
> https://bugs.openjdk.java.net/browse/JDK-8180413
>
>
Can you bring this to serviceability-dev as that is the mailing list 
where the JDWP agent is maintained?

-Alan

From dalibor.topic at oracle.com  Tue May 16 10:00:31 2017
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Tue, 16 May 2017 12:00:31 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <540ee326-3b57-2e9f-2f8d-507b84ecd44e@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
 
 <09a6a643-1b30-b6ed-9345-4de1cd5e616f@oracle.com>
 <6fa4254e-fbfb-a612-e336-b01d45a1f51a@oracle.com>
 <540ee326-3b57-2e9f-2f8d-507b84ecd44e@oracle.com>
Message-ID: <7EB0A598-D18E-461B-A2A0-E7B14529DCAE@oracle.com>

Thanks for the explanation, David. That doesn't sound much more risky than what we already do today in getenv. 

Cheers,
Dalibor

--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214 | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

> On 15. May 2017, at 07:14, David Holmes  wrote:
> 
> Re-sending to core-libs-dev
> 
>> On 13/05/2017 5:56 PM, David Holmes wrote:
>> Hi Dalibor,
>> 
>>> On 12/05/2017 11:28 PM, dalibor topic wrote:
>>>> On 11.05.2017 18:29, C?dric Champeau wrote:
>>>> 
>>>> 
>>>>    Unfortunately, they are not safely mutable in multi-threaded
>>>>    programs on many operating system/libc combinations.
>>>> 
>>>> But the problem is less about mutating, that it is about reading: the VM
>>>> returns wrong values at some point, because it _assumes_ that the
>>>> environment variables are not mutated.
>>> 
>>> Right. Assuming that another thread could be simultaneously writing to
>>> the same data structure holding environment variables (char **), reading
>>> itself becomes problematic at such points in time, as you might read a
>>> temporarily corrupted data structure.
>>> 
>>> I guess the question underneath is if there is a safe point in time when
>>> reading the data could be preformed and no concurrent write from JNI
>>> code corrupting the data when it's partially read is possible.
>> 
>> I'm afraid no such safe point guarantee exists at all - even for the
>> initial reading of the process environment on the first call to System
>> getenv(). There could always potentially be some JNI, or other native
>> in-process code, mutating the environ char** at the same time as we
>> first read it in the JVM.
>> 
>> But we're not trying to protect against random concurrent updates in the
>> current scenario, things are more structured:
>> - request comes in with data that says to update certain env vars
>> - JNI code updates the env vars
>> - the daemon's java code (currently) causes the System.getenv map to be
>> updated
>> - the "client" code is executed and reads the env var and sees the right
>> value
>> 
>> There would have to be a caveat on System.getenv(true) if we went that
>> path, that it is up to the user to ensure it is called in as safe a
>> manner as possible having regard to any concurrent updates in their
>> application code and how the environment is managed on a given platform.
>> 
>> Cheers,
>> David
>> -----
>> 
>>> cheers,
>>> dalibor topic

From cedric.champeau at gmail.com  Tue May 16 10:05:13 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 12:05:13 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <3afcb469-72bf-a056-cf04-b47909a6da2a@gmail.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <3afcb469-72bf-a056-cf04-b47909a6da2a@gmail.com>
Message-ID: 

Thanks Peter for your thoughts, but I don't think it's as simple as that.
As I explained in my original email, there are multiple ways the
environment variables can be mutated, and it can be done _externally_.
Typically, during a task execution, a JNI call performed by a random native
tool could mutate the environment. That's something we, as a build tool,
have to consider as a use case. It's very unlikely but it can happen. This
means that for the same classloader, the environment can change. And for
performance reasons, we cache classloaders between builds, and reuse them
as much as possible (because classloading is far from being cheap).

2017-05-14 19:51 GMT+02:00 Peter Levart :

> Hi Cedric,
>
> Chiming in with my thoughts...
>
> It's unfortunate that Gradle plugins or libraries used by plugins use
> environment variables at all. I wonder who was the first? Did Gradle
> introduce the feature of passing client environment to the daemon and
> establishing the view of System.getenv for plugins 1st or did libraries
> used by plugins happen to use environment variables using System.getenv and
> Gradle was just kind enough to provide them a dynamic view controlled by
> client?
>
> In the end it doesn't matter. The fact is that System.getenv is part of
> standard Java API and anyone using it should be aware that by doing so,
> they are limiting their software to be (re)configured only by spawning new
> process(es). UNIX environment was not designed to be mutated during the
> course of a long-running process. Maybe just at process startup/setup when
> conditions are under control (i.e. a single running thread) but later, the
> environment is meant to be read only.
>
> Maybe there is a solution for Gradle and othert though. But that solution,
> I think, is not in exposing a "live" view of process environment through
> System.getenv or new methods to "refresh" the view as you are proposing,
> since that would only encourage people to mutate the process environment
> which, as was established on this thread, is not safe in a long-running
> multi-threaded process, which Java processes usually are. Perhaps the
> solution is in extending the System.getenv API with ways to provide
> "custom" views of variables for code that runs in a "container".
>
> Gradle is, among other things, a container for plugins. Is Gradle running
> plugins in a separate ClassLoader? Does it use a separate ClassLoader for
> each "build" which might bring with it a new set of environment variables
> from the client? In such a setup, one could provide a separate set of
> environment variables for each ClassLoader, simply by passing them to the
> ClassLoader constructor. System.getenv would need to be a @CallerSensitive
> method which would return caller's ClassLoader view of variables, if any
> such view was established, or simply the view inherited from the parent
> ClassLoader.
>
> Such would be a "functional" approach, which would keep environment
> variables immutable, but allow child "contexts" to have different views of
> them. Such approach would also play well with idioms like:
>
> class AbcPlugin {
>     static final String SOME_SETTING = System.getenv("SOME_SETTING");
>
> ...and would also help other containers (such as app servers) support
> existing libraries that use environment variables to be configured
> differently in different apps deployed in the same VM process.
>
> Just a thought.
>
> Regards, Peter
>
>
>
> On 05/11/2017 09:02 AM, C?dric Champeau wrote:
>
> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable. Java happens
> to return an immutable view of the environment variables when the VM was
> started, which is not the reality. We cannot trust what `System.geteenv`
> returns. The Javadocs say "current system environment" but it's just not
> true. The method should be called `getEnvWhenTheVMWasStarted`.
>
> We also have the problem that the environment of the client and the daemon
> differ over time, as I explained in the previous email. And it is pretty
> easy to understand that _when the build runs_, we need to get the
> environment variables of the _client_, not the daemon. Imagine something as
> simple as this:
>
> String toolPath = System.getenv('SOMETOOL_HOME')
>
> and imagine that this code runs in the daemon. When the daemon is started,
> there's absolutely no guarantee that this variable is going to exist.
> However, we know that when we're going to execute the build, this variable
> *has* to be defined. Obviously, it's going to be done from the CLI:
>
> $ export SOMETOOL_HOME = ...
> $ ./gradlew run ---> connects to the daemon, passes environment variables,
> mutates those of the daemon, which then executes the build
>
> Similarly, from a *single* CLI/terminal, it's very common to change the
> values of environment variables (because, hey, they are mutable!):
>
> $ export SOMETOOL_HOME = another path I want to try out
> $ ./gradlew run --> ... must update env vars again
>
> So, to work around the problem that Java doesn't provide a way to mutate
> the current environment variables, we perform a JNI call to do it. *Then*
> we need to mutate the "immutable view" that Java provides, or all Java code
> is going to get wrong information, and we would never succeed. Note that
> having to resort on JNI to mutate the environment is not the problem. We
> can live with that. Once can think it's a bad idea to allow mutation, in
> practice, it is necessary, but I reckon it could be a bad idea to have an
> API for this. The *real* issue is that `System.getenv` does *not* return
> the real values, because it's an immutable view of what existed at the VM
> startup.
>
> Note that it's not recommended to mutate environment variables in a
> multi-threaded environment. But in practice, you can assimilate what we do
> to the VM startup: we get environment variables, mutate them, _then_ the
> build runs (and only at that moment we would effectively be
> multi-threaded). We can live with potential issues of mutating the
> environment: the benefits outperforms the drawbacks by orders of magnitude.
> When the daemon is activated, we're not talking about 10% faster builds.
> They can effectively be 3, 5 or 10x faster!
>
> Now, back to the problem with JDK 9:
>
> - first, the implementation has changed. But we could adapt our code.
> - second, calling `setAccessible` is not allowed anymore. And this is a
> MAJOR pita. The problem is that we're trying to access the java base
> module, and reflection on that module is not allowed anymore. There are no
> good solutions for this: we could write a JVM agent, like you suggested,
> that rewrites bytecode. But since we're trying to rewrite a core class, it
> would have to be found on the invocation of `java` command itself, and
> cannot be dynamically loaded. In addition, we would have to add a flag to
> open core classes to rewrite. There are multiple problems with this
> approach: first, we don't know on which environment we run before we're
> started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
> script which tries to infer the version from whatever it finds, this is not
> realistic and would add unacceptable latency on the client side (plus, a
> lot of headaches to support the various environments we support: Linux,
> Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
> example, if the build runs in Travis CI, Amazon, or whatever cloudish thing
> that spawns its own containers, we cannot tweak the VM arguments. We just
> have to use whatever is there. Last, rewriting bytecode has a cost, that
> you pay at startup.
>
> Again, what we need is that Java just returns the live view of the
> environment variables. Allowing *mutation* is not necessary, technically
> speaking, because we can rely on JNI. However, I reckon that returning an
> immutable view is done for performance reasons. That's why adding a way to
> mutate "the view" would be an acceptable thing I think. No reflection, no
> bytecode rewriting, just give a way to mutate the map that
> `ProcessEnvironment` retains. The advantage of this is that you would not
> effectively mutate the environment variables, so you, on the JVM side,
> would be safe. What you would mutate is the view you are retaining.
> Alternatively, provide us with an API to "refresh" the view. Like,
> `System.getenv(true)`. The benefit would be that you would only have to get
> the new view of environment variables if the user asks for it. And,
> subsequent callers would get the refreshed view, so people using `gettenv`
> in their code would be up-to-date.
>
> I'm really concerned that this problem is not taken seriously. It's a major
> performance problem for the most widely used build tool out there
> (considering all users, from native to Java and Android). Just saying
> "you're doing something nasty" is not a valid answer: we have to do it, and
> do it for good reasons.
>
>
> 2017-05-11 4:50 GMT+02:00 Martin Buchholz  :
>
>
> Since you're OK with doing brain surgery on the JDK and you control the
> entire process, consider controlling your daemon with a bytecode rewriting
> agent (e.g. byteman) that changes the definition of System.getenv etc.
>
> (Whose side are you on Martin?! ...  I confess I also wish for a faster
> gradle ...)
>
>
>
>

From matthias.baesken at sap.com  Tue May 16 10:21:57 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Tue, 16 May 2017 10:21:57 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
Message-ID: <444e21a8d38c42338fa5c38093a32e9c@sap.com>

 Sure, I forward it to  serviceability-dev .

-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Dienstag, 16. Mai 2017 11:51
To: Baesken, Matthias ; core-libs-dev at openjdk.java.net
Cc: Simonis, Volker 
Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent



On 16/05/2017 10:04, Baesken, Matthias wrote:
> Hello, could you please review this small change :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>
> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>
> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>
>
> https://bugs.openjdk.java.net/browse/JDK-8180413
>
>
Can you bring this to serviceability-dev as that is the mailing list 
where the JDWP agent is maintained?

-Alan

From scolebourne at joda.org  Tue May 16 10:27:54 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 16 May 2017 11:27:54 +0100
Subject: Java-Time Clock Implementation Note
Message-ID: 

In JDK 9, the implementation of Clock has been improved to be better
than millisecond in most cases [1]. However, I've just noticed that
the Javadoc of the "Implementation Note" is now wrong. It says:

"The clock implementation provided here is based on
System.currentTimeMillis(). That method provides little to no
guarantee about the accuracy of the clock. Applications requiring a
more accurate clock must implement this abstract class themselves
using a different external clock, such as an NTP server."

This needs to be updated to indicate that the implementation is no
longer based on System.currentTimeMillis(). Since this is an
"implementation note" I hope that this doesn't affect the
specification, or need too much process.

Is anyone willing to take this up as a JDK 9 bug?

thanks
Stephen

[1] https://bugs.openjdk.java.net/browse/JDK-8068730

From daniel.fuchs at oracle.com  Tue May 16 10:59:13 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 May 2017 11:59:13 +0100
Subject: Java-Time Clock Implementation Note
In-Reply-To: 
References: 
Message-ID: <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>

Hi Stephen,

Thanks for pointing that out.

On 16/05/2017 11:27, Stephen Colebourne wrote:
> In JDK 9, the implementation of Clock has been improved to be better
> than millisecond in most cases [1]. However, I've just noticed that
> the Javadoc of the "Implementation Note" is now wrong. It says:
>
> "The clock implementation provided here is based on
> System.currentTimeMillis(). That method provides little to no
> guarantee about the accuracy of the clock. Applications requiring a
> more accurate clock must implement this abstract class themselves
> using a different external clock, such as an NTP server."
>
> This needs to be updated to indicate that the implementation is no
> longer based on System.currentTimeMillis(). Since this is an
> "implementation note" I hope that this doesn't affect the
> specification, or need too much process.

Strictly speaking the implementation is based on the *same* clock
than System.currentTimeMillis() is based on. This is very important
as it means that times obtained by System.currentTimeMillis() and
times obtained by the system clock are consistent with each other.

So I am not sure the note [2] is actually wrong?

Would the following be a better wording (syntax/grammar may need
correction)?

<<
The clock implementation provided here is based on the same clock than 
System.currentTimeMillis() is based on, but may have a precision finer
than milliseconds if provided by the underlying clock.
However, little to no guarantee is provided about the accuracy of the 
underlying clock. Applications requiring a more accurate clock must 
implement this abstract class themselves using a different external 
clock, such as an NTP server.
 >>

best regards,

-- daniel

[2] http://download.java.net/java/jdk9/docs/api/java/time/Clock.html



>
> Is anyone willing to take this up as a JDK 9 bug?
>
> thanks
> Stephen
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8068730
>


From dmitry.samersoff at oracle.com  Tue May 16 11:17:32 2017
From: dmitry.samersoff at oracle.com (Dmitry Samersoff)
Date: Tue, 16 May 2017 14:17:32 +0300
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: <444e21a8d38c42338fa5c38093a32e9c@sap.com>
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
Message-ID: <8c96fd99-cdb2-dc78-7c35-f46d5d181d91@oracle.com>

Matthias,

Looks good to me.

-Dmitry

On 2017-05-16 13:21, Baesken, Matthias wrote:
>  Sure, I forward it to  serviceability-dev .
> 
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
> Sent: Dienstag, 16. Mai 2017 11:51
> To: Baesken, Matthias ; core-libs-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> 
> 
> 
> On 16/05/2017 10:04, Baesken, Matthias wrote:
>> Hello, could you please review this small change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>>
>> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>>
>> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180413
>>
>>
> Can you bring this to serviceability-dev as that is the mailing list 
> where the JDWP agent is maintained?
> 
> -Alan
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

From neugens.limasoftware at gmail.com  Tue May 16 12:00:34 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Tue, 16 May 2017 14:00:34 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <540ee326-3b57-2e9f-2f8d-507b84ecd44e@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <1e3293f8-8edc-aba0-f076-4eaea647af9c@oracle.com>
 
 <09a6a643-1b30-b6ed-9345-4de1cd5e616f@oracle.com>
 <6fa4254e-fbfb-a612-e336-b01d45a1f51a@oracle.com>
 <540ee326-3b57-2e9f-2f8d-507b84ecd44e@oracle.com>
Message-ID: 

2017-05-15 7:14 GMT+02:00 David Holmes :
>> There would have to be a caveat on System.getenv(true) if we went that
>> path, that it is up to the user to ensure it is called in as safe a
>> manner as possible having regard to any concurrent updates in their
>> application code and how the environment is managed on a given platform.

If we get a System.setEnv in Java we can synchronise that method
access, either internally or by asking the user to explicitly
synchronise.

That would not protect from direct system calls, but it with a proper
Java API that would be the recommended way to set environment
variables, thus lowering the risk.

The question is if this use case is really that compelling that
justify an official wrapper against set/putEnv.

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From scolebourne at joda.org  Tue May 16 14:32:21 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 16 May 2017 15:32:21 +0100
Subject: Java-Time Clock Implementation Note
In-Reply-To: <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>
References: 
 <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>
Message-ID: 

Its not terrible, but I think confusing enough it should be fixed.

Maybe:
"The clock implementation provided here is based on the same
underlying clock as System.currentTimeMillis(), but may have a
precision finer
than milliseconds if available. However, little to no guarantee is
provided about the accuracy of the underlying clock. Applications
requiring a more accurate clock must implement this abstract class
themselves using a different external clock, such as an NTP server."

Stephen



On 16 May 2017 at 11:59, Daniel Fuchs  wrote:
> Hi Stephen,
>
> Thanks for pointing that out.
>
> On 16/05/2017 11:27, Stephen Colebourne wrote:
>>
>> In JDK 9, the implementation of Clock has been improved to be better
>> than millisecond in most cases [1]. However, I've just noticed that
>> the Javadoc of the "Implementation Note" is now wrong. It says:
>>
>> "The clock implementation provided here is based on
>> System.currentTimeMillis(). That method provides little to no
>> guarantee about the accuracy of the clock. Applications requiring a
>> more accurate clock must implement this abstract class themselves
>> using a different external clock, such as an NTP server."
>>
>> This needs to be updated to indicate that the implementation is no
>> longer based on System.currentTimeMillis(). Since this is an
>> "implementation note" I hope that this doesn't affect the
>> specification, or need too much process.
>
>
> Strictly speaking the implementation is based on the *same* clock
> than System.currentTimeMillis() is based on. This is very important
> as it means that times obtained by System.currentTimeMillis() and
> times obtained by the system clock are consistent with each other.
>
> So I am not sure the note [2] is actually wrong?
>
> Would the following be a better wording (syntax/grammar may need
> correction)?
>
> <<
> The clock implementation provided here is based on the same clock than
> System.currentTimeMillis() is based on, but may have a precision finer
> than milliseconds if provided by the underlying clock.
> However, little to no guarantee is provided about the accuracy of the
> underlying clock. Applications requiring a more accurate clock must
> implement this abstract class themselves using a different external clock,
> such as an NTP server.
>>>
>
> best regards,
>
> -- daniel
>
> [2] http://download.java.net/java/jdk9/docs/api/java/time/Clock.html
>
>
>
>
>>
>> Is anyone willing to take this up as a JDK 9 bug?
>>
>> thanks
>> Stephen
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730
>>
>

From daniel.fuchs at oracle.com  Tue May 16 14:39:17 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 16 May 2017 15:39:17 +0100
Subject: Java-Time Clock Implementation Note
In-Reply-To: 
References: 
 <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>
 
Message-ID: 

Thanks Stephen,

On 16/05/2017 15:32, Stephen Colebourne wrote:
> Its not terrible, but I think confusing enough it should be fixed.
>
> Maybe:
> "The clock implementation provided here is based on the same
> underlying clock as System.currentTimeMillis(), but may have a
> precision finer
> than milliseconds if available. However, little to no guarantee is
> provided about the accuracy of the underlying clock. Applications
> requiring a more accurate clock must implement this abstract class
> themselves using a different external clock, such as an NTP server."

I like this. Let's turn it into a docs-only bug for JDK 9: we can
still fix those... I will log the issue - unless you prefer to do it?

best regards,

-- daniel

>
> Stephen
>
>
>
> On 16 May 2017 at 11:59, Daniel Fuchs  wrote:
>> Hi Stephen,
>>
>> Thanks for pointing that out.
>>
>> On 16/05/2017 11:27, Stephen Colebourne wrote:
>>>
>>> In JDK 9, the implementation of Clock has been improved to be better
>>> than millisecond in most cases [1]. However, I've just noticed that
>>> the Javadoc of the "Implementation Note" is now wrong. It says:
>>>
>>> "The clock implementation provided here is based on
>>> System.currentTimeMillis(). That method provides little to no
>>> guarantee about the accuracy of the clock. Applications requiring a
>>> more accurate clock must implement this abstract class themselves
>>> using a different external clock, such as an NTP server."
>>>
>>> This needs to be updated to indicate that the implementation is no
>>> longer based on System.currentTimeMillis(). Since this is an
>>> "implementation note" I hope that this doesn't affect the
>>> specification, or need too much process.
>>
>>
>> Strictly speaking the implementation is based on the *same* clock
>> than System.currentTimeMillis() is based on. This is very important
>> as it means that times obtained by System.currentTimeMillis() and
>> times obtained by the system clock are consistent with each other.
>>
>> So I am not sure the note [2] is actually wrong?
>>
>> Would the following be a better wording (syntax/grammar may need
>> correction)?
>>
>> <<
>> The clock implementation provided here is based on the same clock than
>> System.currentTimeMillis() is based on, but may have a precision finer
>> than milliseconds if provided by the underlying clock.
>> However, little to no guarantee is provided about the accuracy of the
>> underlying clock. Applications requiring a more accurate clock must
>> implement this abstract class themselves using a different external clock,
>> such as an NTP server.
>>>>
>>
>> best regards,
>>
>> -- daniel
>>
>> [2] http://download.java.net/java/jdk9/docs/api/java/time/Clock.html
>>
>>
>>
>>
>>>
>>> Is anyone willing to take this up as a JDK 9 bug?
>>>
>>> thanks
>>> Stephen
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730
>>>
>>


From scolebourne at joda.org  Tue May 16 14:48:23 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 16 May 2017 15:48:23 +0100
Subject: Java-Time Clock Implementation Note
In-Reply-To: 
References: 
 <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>
 
 
Message-ID: 

I'll let you log the issue, as you'll know what flags to set to get it
through the process!
Stephen

On 16 May 2017 at 15:39, Daniel Fuchs  wrote:
> Thanks Stephen,
>
> On 16/05/2017 15:32, Stephen Colebourne wrote:
>>
>> Its not terrible, but I think confusing enough it should be fixed.
>>
>> Maybe:
>> "The clock implementation provided here is based on the same
>> underlying clock as System.currentTimeMillis(), but may have a
>> precision finer
>> than milliseconds if available. However, little to no guarantee is
>> provided about the accuracy of the underlying clock. Applications
>> requiring a more accurate clock must implement this abstract class
>> themselves using a different external clock, such as an NTP server."
>
>
> I like this. Let's turn it into a docs-only bug for JDK 9: we can
> still fix those... I will log the issue - unless you prefer to do it?
>
> best regards,
>
> -- daniel
>
>>
>> Stephen
>>
>>
>>
>> On 16 May 2017 at 11:59, Daniel Fuchs  wrote:
>>>
>>> Hi Stephen,
>>>
>>> Thanks for pointing that out.
>>>
>>> On 16/05/2017 11:27, Stephen Colebourne wrote:
>>>>
>>>>
>>>> In JDK 9, the implementation of Clock has been improved to be better
>>>> than millisecond in most cases [1]. However, I've just noticed that
>>>> the Javadoc of the "Implementation Note" is now wrong. It says:
>>>>
>>>> "The clock implementation provided here is based on
>>>> System.currentTimeMillis(). That method provides little to no
>>>> guarantee about the accuracy of the clock. Applications requiring a
>>>> more accurate clock must implement this abstract class themselves
>>>> using a different external clock, such as an NTP server."
>>>>
>>>> This needs to be updated to indicate that the implementation is no
>>>> longer based on System.currentTimeMillis(). Since this is an
>>>> "implementation note" I hope that this doesn't affect the
>>>> specification, or need too much process.
>>>
>>>
>>>
>>> Strictly speaking the implementation is based on the *same* clock
>>> than System.currentTimeMillis() is based on. This is very important
>>> as it means that times obtained by System.currentTimeMillis() and
>>> times obtained by the system clock are consistent with each other.
>>>
>>> So I am not sure the note [2] is actually wrong?
>>>
>>> Would the following be a better wording (syntax/grammar may need
>>> correction)?
>>>
>>> <<
>>> The clock implementation provided here is based on the same clock than
>>> System.currentTimeMillis() is based on, but may have a precision finer
>>> than milliseconds if provided by the underlying clock.
>>> However, little to no guarantee is provided about the accuracy of the
>>> underlying clock. Applications requiring a more accurate clock must
>>> implement this abstract class themselves using a different external
>>> clock,
>>> such as an NTP server.
>>>>>
>>>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> [2] http://download.java.net/java/jdk9/docs/api/java/time/Clock.html
>>>
>>>
>>>
>>>
>>>>
>>>> Is anyone willing to take this up as a JDK 9 bug?
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730
>>>>
>>>
>

From igor.ignatyev at oracle.com  Tue May 16 15:27:42 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 May 2017 08:27:42 -0700
Subject: RFR(S): 8180195: remove jaxp testlibrary
In-Reply-To: <72ceab50-4e34-59d7-fcc8-8b870b2f6b4b@oracle.com>
References: <6E0DF973-A303-44A6-A1D6-8113D2ADDE61@oracle.com>
 <029a01d2cdef$33ad29f0$9b077dd0$@oracle.com>
 <72ceab50-4e34-59d7-fcc8-8b870b2f6b4b@oracle.com>
Message-ID: 

Hi Joe, Frank,

thank you for the review!

Cheers,
-- Igor

> On May 15, 2017, at 8:21 PM, huizhe wang  wrote:
> 
> +1. Thanks Frank for checking.
> 
> -Joe
> 
> On 5/15/2017 7:50 PM, Frank Yuan wrote:
>> Looks fine, although I am not a reviewer.
>> 
>> Thanks
>> Frank
>> 
>>> -----Original Message-----
>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf Of Igor Ignatyev
>>> Subject: RFR(S): 8180195: remove jaxp testlibrary
>>> 
>>> http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
>>>> 3049 lines changed: 114 ins; 2927 del; 8 mod;
>>> Hi all,
>>> 
>>> could you please review this small patch which removes a fork of testlibrary from jaxp repo? there were a few differences b/w the
>> testlibraries:
>>> top level testlibrary did not have CompilerUtils class, its ProcessTools did not have executeTestJava (which is basically an alias
>> for
>>> executeTestJvm) and its OutputAnalyzer did not have methods to dump stdout, stderr into specific streams.
>>> 
>>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>>> 
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180195
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8180195/webrev.00/index.html
>>> testing: :jaxp_all
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8075327
>>> 
>>> Thanks,
>>> -- Igor
>> 
> 


From Roger.Riggs at Oracle.com  Tue May 16 16:54:55 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 16 May 2017 12:54:55 -0400
Subject: RFR 8u Backport: 8179515: Class
 java.util.concurrent.ThreadLocalRandom fails to Initialize when using
 SecurityManager
In-Reply-To: 
References: 
Message-ID: <704438c3-9704-85b2-95e2-71f337ff1396@Oracle.com>

Hi David,

Looks fine.

Roger


On 5/16/2017 3:02 AM, David Holmes wrote:
> The existing code in 8u was a little different to 9, but the new code 
> is identical (other than package names):
>
> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
> 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
> 9 review thread: 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html
>
> Thanks,
> David


From sanne at redhat.com  Tue May 16 16:57:56 2017
From: sanne at redhat.com (Sanne Grinovero)
Date: Tue, 16 May 2017 17:57:56 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <3afcb469-72bf-a056-cf04-b47909a6da2a@gmail.com>
 
Message-ID: 

Hi C?dric,

we use Gradle a lot in our team (Hibernate) and all your efforts to
make it faster are highly appreciated.

I can assure you that during a normal day of work while we might
rebuild a project a few hundred times, I'll rarely have to change
environment variables.

Obviously I don't represent all users, but as you said yourself the
need to change environment variables is both something you have to
support and something which is extremely rare.
So can't you simply keep the daemon around, as long as environment
variables don't change?

For the rare case in which environment variables have been mutated,
you could trigger a full restart.

As a second step, I should mention that on a typical workstation I
might have multiple terminals open, each configured with a different
environment and possibly working on a different project or different
branch - or just testing on a different environment.
It would be even nicer if one could have a different Gradle daemon
instances running for each environment; incidentally this might have
other benefits, like we often need to switch JDK build or even vendor.
I'd be happy to be able to give them some name as identifier.

I think this solution would improve Gradle and allow the JDK to move
on with this quite nice cleanup.

HTH

Thanks,
Sanne


On Tue, May 16, 2017 at 11:05 AM, C?dric Champeau
 wrote:
> Thanks Peter for your thoughts, but I don't think it's as simple as that.
> As I explained in my original email, there are multiple ways the
> environment variables can be mutated, and it can be done _externally_.
> Typically, during a task execution, a JNI call performed by a random native
> tool could mutate the environment. That's something we, as a build tool,
> have to consider as a use case. It's very unlikely but it can happen. This
> means that for the same classloader, the environment can change. And for
> performance reasons, we cache classloaders between builds, and reuse them
> as much as possible (because classloading is far from being cheap).
>
> 2017-05-14 19:51 GMT+02:00 Peter Levart :
>
>> Hi Cedric,
>>
>> Chiming in with my thoughts...
>>
>> It's unfortunate that Gradle plugins or libraries used by plugins use
>> environment variables at all. I wonder who was the first? Did Gradle
>> introduce the feature of passing client environment to the daemon and
>> establishing the view of System.getenv for plugins 1st or did libraries
>> used by plugins happen to use environment variables using System.getenv and
>> Gradle was just kind enough to provide them a dynamic view controlled by
>> client?
>>
>> In the end it doesn't matter. The fact is that System.getenv is part of
>> standard Java API and anyone using it should be aware that by doing so,
>> they are limiting their software to be (re)configured only by spawning new
>> process(es). UNIX environment was not designed to be mutated during the
>> course of a long-running process. Maybe just at process startup/setup when
>> conditions are under control (i.e. a single running thread) but later, the
>> environment is meant to be read only.
>>
>> Maybe there is a solution for Gradle and othert though. But that solution,
>> I think, is not in exposing a "live" view of process environment through
>> System.getenv or new methods to "refresh" the view as you are proposing,
>> since that would only encourage people to mutate the process environment
>> which, as was established on this thread, is not safe in a long-running
>> multi-threaded process, which Java processes usually are. Perhaps the
>> solution is in extending the System.getenv API with ways to provide
>> "custom" views of variables for code that runs in a "container".
>>
>> Gradle is, among other things, a container for plugins. Is Gradle running
>> plugins in a separate ClassLoader? Does it use a separate ClassLoader for
>> each "build" which might bring with it a new set of environment variables
>> from the client? In such a setup, one could provide a separate set of
>> environment variables for each ClassLoader, simply by passing them to the
>> ClassLoader constructor. System.getenv would need to be a @CallerSensitive
>> method which would return caller's ClassLoader view of variables, if any
>> such view was established, or simply the view inherited from the parent
>> ClassLoader.
>>
>> Such would be a "functional" approach, which would keep environment
>> variables immutable, but allow child "contexts" to have different views of
>> them. Such approach would also play well with idioms like:
>>
>> class AbcPlugin {
>>     static final String SOME_SETTING = System.getenv("SOME_SETTING");
>>
>> ...and would also help other containers (such as app servers) support
>> existing libraries that use environment variables to be configured
>> differently in different apps deployed in the same VM process.
>>
>> Just a thought.
>>
>> Regards, Peter
>>
>>
>>
>> On 05/11/2017 09:02 AM, C?dric Champeau wrote:
>>
>> Thanks for the answers, folks, but I think they are kind of missing the
>> point. The fact is that environment variables *are* mutable. Java happens
>> to return an immutable view of the environment variables when the VM was
>> started, which is not the reality. We cannot trust what `System.geteenv`
>> returns. The Javadocs say "current system environment" but it's just not
>> true. The method should be called `getEnvWhenTheVMWasStarted`.
>>
>> We also have the problem that the environment of the client and the daemon
>> differ over time, as I explained in the previous email. And it is pretty
>> easy to understand that _when the build runs_, we need to get the
>> environment variables of the _client_, not the daemon. Imagine something as
>> simple as this:
>>
>> String toolPath = System.getenv('SOMETOOL_HOME')
>>
>> and imagine that this code runs in the daemon. When the daemon is started,
>> there's absolutely no guarantee that this variable is going to exist.
>> However, we know that when we're going to execute the build, this variable
>> *has* to be defined. Obviously, it's going to be done from the CLI:
>>
>> $ export SOMETOOL_HOME = ...
>> $ ./gradlew run ---> connects to the daemon, passes environment variables,
>> mutates those of the daemon, which then executes the build
>>
>> Similarly, from a *single* CLI/terminal, it's very common to change the
>> values of environment variables (because, hey, they are mutable!):
>>
>> $ export SOMETOOL_HOME = another path I want to try out
>> $ ./gradlew run --> ... must update env vars again
>>
>> So, to work around the problem that Java doesn't provide a way to mutate
>> the current environment variables, we perform a JNI call to do it. *Then*
>> we need to mutate the "immutable view" that Java provides, or all Java code
>> is going to get wrong information, and we would never succeed. Note that
>> having to resort on JNI to mutate the environment is not the problem. We
>> can live with that. Once can think it's a bad idea to allow mutation, in
>> practice, it is necessary, but I reckon it could be a bad idea to have an
>> API for this. The *real* issue is that `System.getenv` does *not* return
>> the real values, because it's an immutable view of what existed at the VM
>> startup.
>>
>> Note that it's not recommended to mutate environment variables in a
>> multi-threaded environment. But in practice, you can assimilate what we do
>> to the VM startup: we get environment variables, mutate them, _then_ the
>> build runs (and only at that moment we would effectively be
>> multi-threaded). We can live with potential issues of mutating the
>> environment: the benefits outperforms the drawbacks by orders of magnitude.
>> When the daemon is activated, we're not talking about 10% faster builds.
>> They can effectively be 3, 5 or 10x faster!
>>
>> Now, back to the problem with JDK 9:
>>
>> - first, the implementation has changed. But we could adapt our code.
>> - second, calling `setAccessible` is not allowed anymore. And this is a
>> MAJOR pita. The problem is that we're trying to access the java base
>> module, and reflection on that module is not allowed anymore. There are no
>> good solutions for this: we could write a JVM agent, like you suggested,
>> that rewrites bytecode. But since we're trying to rewrite a core class, it
>> would have to be found on the invocation of `java` command itself, and
>> cannot be dynamically loaded. In addition, we would have to add a flag to
>> open core classes to rewrite. There are multiple problems with this
>> approach: first, we don't know on which environment we run before we're
>> started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
>> script which tries to infer the version from whatever it finds, this is not
>> realistic and would add unacceptable latency on the client side (plus, a
>> lot of headaches to support the various environments we support: Linux,
>> Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
>> example, if the build runs in Travis CI, Amazon, or whatever cloudish thing
>> that spawns its own containers, we cannot tweak the VM arguments. We just
>> have to use whatever is there. Last, rewriting bytecode has a cost, that
>> you pay at startup.
>>
>> Again, what we need is that Java just returns the live view of the
>> environment variables. Allowing *mutation* is not necessary, technically
>> speaking, because we can rely on JNI. However, I reckon that returning an
>> immutable view is done for performance reasons. That's why adding a way to
>> mutate "the view" would be an acceptable thing I think. No reflection, no
>> bytecode rewriting, just give a way to mutate the map that
>> `ProcessEnvironment` retains. The advantage of this is that you would not
>> effectively mutate the environment variables, so you, on the JVM side,
>> would be safe. What you would mutate is the view you are retaining.
>> Alternatively, provide us with an API to "refresh" the view. Like,
>> `System.getenv(true)`. The benefit would be that you would only have to get
>> the new view of environment variables if the user asks for it. And,
>> subsequent callers would get the refreshed view, so people using `gettenv`
>> in their code would be up-to-date.
>>
>> I'm really concerned that this problem is not taken seriously. It's a major
>> performance problem for the most widely used build tool out there
>> (considering all users, from native to Java and Android). Just saying
>> "you're doing something nasty" is not a valid answer: we have to do it, and
>> do it for good reasons.
>>
>>
>> 2017-05-11 4:50 GMT+02:00 Martin Buchholz  :
>>
>>
>> Since you're OK with doing brain surgery on the JDK and you control the
>> entire process, consider controlling your daemon with a bytecode rewriting
>> agent (e.g. byteman) that changes the definition of System.getenv etc.
>>
>> (Whose side are you on Martin?! ...  I confess I also wish for a faster
>> gradle ...)
>>
>>
>>
>>

From cedric.champeau at gmail.com  Tue May 16 17:08:01 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 19:08:01 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <3afcb469-72bf-a056-cf04-b47909a6da2a@gmail.com>
 
 
Message-ID: 

2017-05-16 18:57 GMT+02:00 Sanne Grinovero :

> Hi C?dric,
>
> we use Gradle a lot in our team (Hibernate) and all your efforts to
> make it faster are highly appreciated.
>
> I can assure you that during a normal day of work while we might
> rebuild a project a few hundred times, I'll rarely have to change
> environment variables.
>
> Obviously I don't represent all users, but as you said yourself the
> need to change environment variables is both something you have to
> support and something which is extremely rare.

So can't you simply keep the daemon around, as long as environment
> variables don't change?
>

That's one of the suggestions in the original email, but as you can see,
it's not uncommon to have environment variables mutated "behind you back",
even in a simple command line. Sometimes, it's as easy as having 2
different terminals open (which I think is far from being a rare case):
then you cannot share the same daemon instance, which is either very bad
for performance or memory usage. Why? Because the open terminal has some
specific variables (WINDOWID, ...).


>
> For the rare case in which environment variables have been mutated,
> you could trigger a full restart.
>
> As a second step, I should mention that on a typical workstation I
> might have multiple terminals open, each configured with a different
> environment and possibly working on a different project or different
> branch - or just testing on a different environment.
> It would be even nicer if one could have a different Gradle daemon
> instances running for each environment; incidentally this might have
> other benefits, like we often need to switch JDK build or even vendor.
> I'd be happy to be able to give them some name as identifier.
>
>
That's something we consider, but it's not the same use case at all (my
typical setup is pretty much the opposite: a lot of terminals open for the
same environment/build), so it has to be supported differently. I don't
think we should mix this in the game.


> I think this solution would improve Gradle and allow the JDK to move
> on with this quite nice cleanup.
>
> HTH
>
> Thanks,
> Sanne
>
>
> On Tue, May 16, 2017 at 11:05 AM, C?dric Champeau
>  wrote:
> > Thanks Peter for your thoughts, but I don't think it's as simple as that.
> > As I explained in my original email, there are multiple ways the
> > environment variables can be mutated, and it can be done _externally_.
> > Typically, during a task execution, a JNI call performed by a random
> native
> > tool could mutate the environment. That's something we, as a build tool,
> > have to consider as a use case. It's very unlikely but it can happen.
> This
> > means that for the same classloader, the environment can change. And for
> > performance reasons, we cache classloaders between builds, and reuse them
> > as much as possible (because classloading is far from being cheap).
> >
> > 2017-05-14 19:51 GMT+02:00 Peter Levart :
> >
> >> Hi Cedric,
> >>
> >> Chiming in with my thoughts...
> >>
> >> It's unfortunate that Gradle plugins or libraries used by plugins use
> >> environment variables at all. I wonder who was the first? Did Gradle
> >> introduce the feature of passing client environment to the daemon and
> >> establishing the view of System.getenv for plugins 1st or did libraries
> >> used by plugins happen to use environment variables using System.getenv
> and
> >> Gradle was just kind enough to provide them a dynamic view controlled by
> >> client?
> >>
> >> In the end it doesn't matter. The fact is that System.getenv is part of
> >> standard Java API and anyone using it should be aware that by doing so,
> >> they are limiting their software to be (re)configured only by spawning
> new
> >> process(es). UNIX environment was not designed to be mutated during the
> >> course of a long-running process. Maybe just at process startup/setup
> when
> >> conditions are under control (i.e. a single running thread) but later,
> the
> >> environment is meant to be read only.
> >>
> >> Maybe there is a solution for Gradle and othert though. But that
> solution,
> >> I think, is not in exposing a "live" view of process environment through
> >> System.getenv or new methods to "refresh" the view as you are proposing,
> >> since that would only encourage people to mutate the process environment
> >> which, as was established on this thread, is not safe in a long-running
> >> multi-threaded process, which Java processes usually are. Perhaps the
> >> solution is in extending the System.getenv API with ways to provide
> >> "custom" views of variables for code that runs in a "container".
> >>
> >> Gradle is, among other things, a container for plugins. Is Gradle
> running
> >> plugins in a separate ClassLoader? Does it use a separate ClassLoader
> for
> >> each "build" which might bring with it a new set of environment
> variables
> >> from the client? In such a setup, one could provide a separate set of
> >> environment variables for each ClassLoader, simply by passing them to
> the
> >> ClassLoader constructor. System.getenv would need to be a
> @CallerSensitive
> >> method which would return caller's ClassLoader view of variables, if any
> >> such view was established, or simply the view inherited from the parent
> >> ClassLoader.
> >>
> >> Such would be a "functional" approach, which would keep environment
> >> variables immutable, but allow child "contexts" to have different views
> of
> >> them. Such approach would also play well with idioms like:
> >>
> >> class AbcPlugin {
> >>     static final String SOME_SETTING = System.getenv("SOME_SETTING");
> >>
> >> ...and would also help other containers (such as app servers) support
> >> existing libraries that use environment variables to be configured
> >> differently in different apps deployed in the same VM process.
> >>
> >> Just a thought.
> >>
> >> Regards, Peter
> >>
> >>
> >>
> >> On 05/11/2017 09:02 AM, C?dric Champeau wrote:
> >>
> >> Thanks for the answers, folks, but I think they are kind of missing the
> >> point. The fact is that environment variables *are* mutable. Java
> happens
> >> to return an immutable view of the environment variables when the VM was
> >> started, which is not the reality. We cannot trust what `System.geteenv`
> >> returns. The Javadocs say "current system environment" but it's just not
> >> true. The method should be called `getEnvWhenTheVMWasStarted`.
> >>
> >> We also have the problem that the environment of the client and the
> daemon
> >> differ over time, as I explained in the previous email. And it is pretty
> >> easy to understand that _when the build runs_, we need to get the
> >> environment variables of the _client_, not the daemon. Imagine
> something as
> >> simple as this:
> >>
> >> String toolPath = System.getenv('SOMETOOL_HOME')
> >>
> >> and imagine that this code runs in the daemon. When the daemon is
> started,
> >> there's absolutely no guarantee that this variable is going to exist.
> >> However, we know that when we're going to execute the build, this
> variable
> >> *has* to be defined. Obviously, it's going to be done from the CLI:
> >>
> >> $ export SOMETOOL_HOME = ...
> >> $ ./gradlew run ---> connects to the daemon, passes environment
> variables,
> >> mutates those of the daemon, which then executes the build
> >>
> >> Similarly, from a *single* CLI/terminal, it's very common to change the
> >> values of environment variables (because, hey, they are mutable!):
> >>
> >> $ export SOMETOOL_HOME = another path I want to try out
> >> $ ./gradlew run --> ... must update env vars again
> >>
> >> So, to work around the problem that Java doesn't provide a way to mutate
> >> the current environment variables, we perform a JNI call to do it.
> *Then*
> >> we need to mutate the "immutable view" that Java provides, or all Java
> code
> >> is going to get wrong information, and we would never succeed. Note that
> >> having to resort on JNI to mutate the environment is not the problem. We
> >> can live with that. Once can think it's a bad idea to allow mutation, in
> >> practice, it is necessary, but I reckon it could be a bad idea to have
> an
> >> API for this. The *real* issue is that `System.getenv` does *not* return
> >> the real values, because it's an immutable view of what existed at the
> VM
> >> startup.
> >>
> >> Note that it's not recommended to mutate environment variables in a
> >> multi-threaded environment. But in practice, you can assimilate what we
> do
> >> to the VM startup: we get environment variables, mutate them, _then_ the
> >> build runs (and only at that moment we would effectively be
> >> multi-threaded). We can live with potential issues of mutating the
> >> environment: the benefits outperforms the drawbacks by orders of
> magnitude.
> >> When the daemon is activated, we're not talking about 10% faster builds.
> >> They can effectively be 3, 5 or 10x faster!
> >>
> >> Now, back to the problem with JDK 9:
> >>
> >> - first, the implementation has changed. But we could adapt our code.
> >> - second, calling `setAccessible` is not allowed anymore. And this is a
> >> MAJOR pita. The problem is that we're trying to access the java base
> >> module, and reflection on that module is not allowed anymore. There are
> no
> >> good solutions for this: we could write a JVM agent, like you suggested,
> >> that rewrites bytecode. But since we're trying to rewrite a core class,
> it
> >> would have to be found on the invocation of `java` command itself, and
> >> cannot be dynamically loaded. In addition, we would have to add a flag
> to
> >> open core classes to rewrite. There are multiple problems with this
> >> approach: first, we don't know on which environment we run before we're
> >> started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
> >> script which tries to infer the version from whatever it finds, this is
> not
> >> realistic and would add unacceptable latency on the client side (plus, a
> >> lot of headaches to support the various environments we support: Linux,
> >> Mac, Windows, ...). Second, we may not have a hand on the CLI at all.
> For
> >> example, if the build runs in Travis CI, Amazon, or whatever cloudish
> thing
> >> that spawns its own containers, we cannot tweak the VM arguments. We
> just
> >> have to use whatever is there. Last, rewriting bytecode has a cost, that
> >> you pay at startup.
> >>
> >> Again, what we need is that Java just returns the live view of the
> >> environment variables. Allowing *mutation* is not necessary, technically
> >> speaking, because we can rely on JNI. However, I reckon that returning
> an
> >> immutable view is done for performance reasons. That's why adding a way
> to
> >> mutate "the view" would be an acceptable thing I think. No reflection,
> no
> >> bytecode rewriting, just give a way to mutate the map that
> >> `ProcessEnvironment` retains. The advantage of this is that you would
> not
> >> effectively mutate the environment variables, so you, on the JVM side,
> >> would be safe. What you would mutate is the view you are retaining.
> >> Alternatively, provide us with an API to "refresh" the view. Like,
> >> `System.getenv(true)`. The benefit would be that you would only have to
> get
> >> the new view of environment variables if the user asks for it. And,
> >> subsequent callers would get the refreshed view, so people using
> `gettenv`
> >> in their code would be up-to-date.
> >>
> >> I'm really concerned that this problem is not taken seriously. It's a
> major
> >> performance problem for the most widely used build tool out there
> >> (considering all users, from native to Java and Android). Just saying
> >> "you're doing something nasty" is not a valid answer: we have to do it,
> and
> >> do it for good reasons.
> >>
> >>
> >> 2017-05-11 4:50 GMT+02:00 Martin Buchholz  <
> martinrb at google.com>:
> >>
> >>
> >> Since you're OK with doing brain surgery on the JDK and you control the
> >> entire process, consider controlling your daemon with a bytecode
> rewriting
> >> agent (e.g. byteman) that changes the definition of System.getenv etc.
> >>
> >> (Whose side are you on Martin?! ...  I confess I also wish for a faster
> >> gradle ...)
> >>
> >>
> >>
> >>
>

From uschindler at apache.org  Tue May 16 17:46:19 2017
From: uschindler at apache.org (Uwe Schindler)
Date: Tue, 16 May 2017 19:46:19 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
Message-ID: <00f301d2ce6c$55611020$00233060$@apache.org>

Hi,

I still don't understand why you need to change the environment variables of the actual process. I was talking with R?mi about that last week, and it's not obvious to me why you need that. Sure, it is easier to change the environment of the actual process and then spawn a child process for some non-java build tool like GCC or even another standalone java program with option fork=true. But: Why not use the ProcessBuilder API when spawning those childs? So you just add an "official" build API inside Gradle (an official one, documented that allows Gradle plugins to modify the environment variables for the current build running). If you missed to add such an API from the beginning (IMHO its essential for a build system like Gradle), then you now have to tell your users: "Sorry we did something wrong and all our (bad) hacks to allow you to change environment variables are no longer working in the future, so please change your code. We are so sorry!"

If some plugin is not using that new API, then it's not your problem. You document that you *have* to use the Environment API, because plugins cannot rely on the fact that another plugin or maybe another build running at a later time is changing the Gradle process environment.

At some point you have to break backwards compatibility and tell users: Please update your code, otherwise plugin won't work anymore with Gradle version x.y (the one that's compatible to Java 9).

Uwe

-----
Uwe Schindler
uschindler at apache.org 
ASF Member, Apache Lucene PMC / Committer
Bremen, Germany
http://lucene.apache.org/

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of C?dric Champeau
> Sent: Thursday, May 11, 2017 9:02 AM
> To: Martin Buchholz 
> Cc: core-libs-dev 
> Subject: Re: Getting a live view of environment variables (Gradle and JDK 9)
> 
> Thanks for the answers, folks, but I think they are kind of missing the
> point. The fact is that environment variables *are* mutable. Java happens
> to return an immutable view of the environment variables when the VM was
> started, which is not the reality. We cannot trust what `System.geteenv`
> returns. The Javadocs say "current system environment" but it's just not
> true. The method should be called `getEnvWhenTheVMWasStarted`.
> 
> We also have the problem that the environment of the client and the
> daemon
> differ over time, as I explained in the previous email. And it is pretty
> easy to understand that _when the build runs_, we need to get the
> environment variables of the _client_, not the daemon. Imagine something
> as
> simple as this:
> 
> String toolPath = System.getenv('SOMETOOL_HOME')
> 
> and imagine that this code runs in the daemon. When the daemon is started,
> there's absolutely no guarantee that this variable is going to exist.
> However, we know that when we're going to execute the build, this variable
> *has* to be defined. Obviously, it's going to be done from the CLI:
> 
> $ export SOMETOOL_HOME = ...
> $ ./gradlew run ---> connects to the daemon, passes environment variables,
> mutates those of the daemon, which then executes the build
> 
> Similarly, from a *single* CLI/terminal, it's very common to change the
> values of environment variables (because, hey, they are mutable!):
> 
> $ export SOMETOOL_HOME = another path I want to try out
> $ ./gradlew run --> ... must update env vars again
> 
> So, to work around the problem that Java doesn't provide a way to mutate
> the current environment variables, we perform a JNI call to do it. *Then*
> we need to mutate the "immutable view" that Java provides, or all Java code
> is going to get wrong information, and we would never succeed. Note that
> having to resort on JNI to mutate the environment is not the problem. We
> can live with that. Once can think it's a bad idea to allow mutation, in
> practice, it is necessary, but I reckon it could be a bad idea to have an
> API for this. The *real* issue is that `System.getenv` does *not* return
> the real values, because it's an immutable view of what existed at the VM
> startup.
> 
> Note that it's not recommended to mutate environment variables in a
> multi-threaded environment. But in practice, you can assimilate what we do
> to the VM startup: we get environment variables, mutate them, _then_ the
> build runs (and only at that moment we would effectively be
> multi-threaded). We can live with potential issues of mutating the
> environment: the benefits outperforms the drawbacks by orders of
> magnitude.
> When the daemon is activated, we're not talking about 10% faster builds.
> They can effectively be 3, 5 or 10x faster!
> 
> Now, back to the problem with JDK 9:
> 
> - first, the implementation has changed. But we could adapt our code.
> - second, calling `setAccessible` is not allowed anymore. And this is a
> MAJOR pita. The problem is that we're trying to access the java base
> module, and reflection on that module is not allowed anymore. There are no
> good solutions for this: we could write a JVM agent, like you suggested,
> that rewrites bytecode. But since we're trying to rewrite a core class, it
> would have to be found on the invocation of `java` command itself, and
> cannot be dynamically loaded. In addition, we would have to add a flag to
> open core classes to rewrite. There are multiple problems with this
> approach: first, we don't know on which environment we run before we're
> started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
> script which tries to infer the version from whatever it finds, this is not
> realistic and would add unacceptable latency on the client side (plus, a
> lot of headaches to support the various environments we support: Linux,
> Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
> example, if the build runs in Travis CI, Amazon, or whatever cloudish thing
> that spawns its own containers, we cannot tweak the VM arguments. We just
> have to use whatever is there. Last, rewriting bytecode has a cost, that
> you pay at startup.
> 
> Again, what we need is that Java just returns the live view of the
> environment variables. Allowing *mutation* is not necessary, technically
> speaking, because we can rely on JNI. However, I reckon that returning an
> immutable view is done for performance reasons. That's why adding a way
> to
> mutate "the view" would be an acceptable thing I think. No reflection, no
> bytecode rewriting, just give a way to mutate the map that
> `ProcessEnvironment` retains. The advantage of this is that you would not
> effectively mutate the environment variables, so you, on the JVM side,
> would be safe. What you would mutate is the view you are retaining.
> Alternatively, provide us with an API to "refresh" the view. Like,
> `System.getenv(true)`. The benefit would be that you would only have to get
> the new view of environment variables if the user asks for it. And,
> subsequent callers would get the refreshed view, so people using `gettenv`
> in their code would be up-to-date.
> 
> I'm really concerned that this problem is not taken seriously. It's a major
> performance problem for the most widely used build tool out there
> (considering all users, from native to Java and Android). Just saying
> "you're doing something nasty" is not a valid answer: we have to do it, and
> do it for good reasons.
> 
> 
> 2017-05-11 4:50 GMT+02:00 Martin Buchholz :
> 
> > Since you're OK with doing brain surgery on the JDK and you control the
> > entire process, consider controlling your daemon with a bytecode rewriting
> > agent (e.g. byteman) that changes the definition of System.getenv etc.
> >
> > (Whose side are you on Martin?! ...  I confess I also wish for a faster
> > gradle ...)
> >


From cedric.champeau at gmail.com  Tue May 16 18:11:10 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 20:11:10 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <00f301d2ce6c$55611020$00233060$@apache.org>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
Message-ID: 

Hi Uwe,

I already explained multiple times why we need this. Short answer: because
we must. Slightly longer answer: because the build environment, the daemon,
has to reflect the environment from the CLI (or the IDE, in case we call
using the tooling API), at the moment the build is executed. Why? Because a
user wouldn't understand that a script which does:

println System.getenv('MY_VAR')

doesn't print "foo" after doing:

MY_VAR=foo gradle printVar

(that's a silly example, but the simplest we can come with). Not everything
runs in a separate process: there are things that execute in the daemon
itself. A lot of things (starting from build scripts). And yes, we can
provide a different API to get environment variables, but:

1. it's a breaking change
2. there are lots of plugins which use libraries, which do NOT depend on
the Gradle API, so that API wouldn't be available

I'm honestly starting to get tired of explaining again and again WHY we
need this. If it was easy, we would have done it differently for years. We
worked around a bug in the JDK, which doesn't return the true environment
variables but the ones snapshotted when the process started. Now in JDK 9
we cannot workaround anymore, which either just kills Gradle performance or
forces us to write even nastier code with bytecode manipulating agents to
replace what `System.getenv` does.

2017-05-16 19:46 GMT+02:00 Uwe Schindler :

> Hi,
>
> I still don't understand why you need to change the environment variables
> of the actual process. I was talking with R?mi about that last week, and
> it's not obvious to me why you need that. Sure, it is easier to change the
> environment of the actual process and then spawn a child process for some
> non-java build tool like GCC or even another standalone java program with
> option fork=true. But: Why not use the ProcessBuilder API when spawning
> those childs? So you just add an "official" build API inside Gradle (an
> official one, documented that allows Gradle plugins to modify the
> environment variables for the current build running). If you missed to add
> such an API from the beginning (IMHO its essential for a build system like
> Gradle), then you now have to tell your users: "Sorry we did something
> wrong and all our (bad) hacks to allow you to change environment variables
> are no longer working in the future, so please change your code. We are so
> sorry!"
>
> If some plugin is not using that new API, then it's not your problem. You
> document that you *have* to use the Environment API, because plugins cannot
> rely on the fact that another plugin or maybe another build running at a
> later time is changing the Gradle process environment.
>
> At some point you have to break backwards compatibility and tell users:
> Please update your code, otherwise plugin won't work anymore with Gradle
> version x.y (the one that's compatible to Java 9).
>
> Uwe
>
> -----
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Apache Lucene PMC / Committer
> Bremen, Germany
> http://lucene.apache.org/
>
> > -----Original Message-----
> > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> > Behalf Of C?dric Champeau
> > Sent: Thursday, May 11, 2017 9:02 AM
> > To: Martin Buchholz 
> > Cc: core-libs-dev 
> > Subject: Re: Getting a live view of environment variables (Gradle and
> JDK 9)
> >
> > Thanks for the answers, folks, but I think they are kind of missing the
> > point. The fact is that environment variables *are* mutable. Java happens
> > to return an immutable view of the environment variables when the VM was
> > started, which is not the reality. We cannot trust what `System.geteenv`
> > returns. The Javadocs say "current system environment" but it's just not
> > true. The method should be called `getEnvWhenTheVMWasStarted`.
> >
> > We also have the problem that the environment of the client and the
> > daemon
> > differ over time, as I explained in the previous email. And it is pretty
> > easy to understand that _when the build runs_, we need to get the
> > environment variables of the _client_, not the daemon. Imagine something
> > as
> > simple as this:
> >
> > String toolPath = System.getenv('SOMETOOL_HOME')
> >
> > and imagine that this code runs in the daemon. When the daemon is
> started,
> > there's absolutely no guarantee that this variable is going to exist.
> > However, we know that when we're going to execute the build, this
> variable
> > *has* to be defined. Obviously, it's going to be done from the CLI:
> >
> > $ export SOMETOOL_HOME = ...
> > $ ./gradlew run ---> connects to the daemon, passes environment
> variables,
> > mutates those of the daemon, which then executes the build
> >
> > Similarly, from a *single* CLI/terminal, it's very common to change the
> > values of environment variables (because, hey, they are mutable!):
> >
> > $ export SOMETOOL_HOME = another path I want to try out
> > $ ./gradlew run --> ... must update env vars again
> >
> > So, to work around the problem that Java doesn't provide a way to mutate
> > the current environment variables, we perform a JNI call to do it. *Then*
> > we need to mutate the "immutable view" that Java provides, or all Java
> code
> > is going to get wrong information, and we would never succeed. Note that
> > having to resort on JNI to mutate the environment is not the problem. We
> > can live with that. Once can think it's a bad idea to allow mutation, in
> > practice, it is necessary, but I reckon it could be a bad idea to have an
> > API for this. The *real* issue is that `System.getenv` does *not* return
> > the real values, because it's an immutable view of what existed at the VM
> > startup.
> >
> > Note that it's not recommended to mutate environment variables in a
> > multi-threaded environment. But in practice, you can assimilate what we
> do
> > to the VM startup: we get environment variables, mutate them, _then_ the
> > build runs (and only at that moment we would effectively be
> > multi-threaded). We can live with potential issues of mutating the
> > environment: the benefits outperforms the drawbacks by orders of
> > magnitude.
> > When the daemon is activated, we're not talking about 10% faster builds.
> > They can effectively be 3, 5 or 10x faster!
> >
> > Now, back to the problem with JDK 9:
> >
> > - first, the implementation has changed. But we could adapt our code.
> > - second, calling `setAccessible` is not allowed anymore. And this is a
> > MAJOR pita. The problem is that we're trying to access the java base
> > module, and reflection on that module is not allowed anymore. There are
> no
> > good solutions for this: we could write a JVM agent, like you suggested,
> > that rewrites bytecode. But since we're trying to rewrite a core class,
> it
> > would have to be found on the invocation of `java` command itself, and
> > cannot be dynamically loaded. In addition, we would have to add a flag to
> > open core classes to rewrite. There are multiple problems with this
> > approach: first, we don't know on which environment we run before we're
> > started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
> > script which tries to infer the version from whatever it finds, this is
> not
> > realistic and would add unacceptable latency on the client side (plus, a
> > lot of headaches to support the various environments we support: Linux,
> > Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
> > example, if the build runs in Travis CI, Amazon, or whatever cloudish
> thing
> > that spawns its own containers, we cannot tweak the VM arguments. We just
> > have to use whatever is there. Last, rewriting bytecode has a cost, that
> > you pay at startup.
> >
> > Again, what we need is that Java just returns the live view of the
> > environment variables. Allowing *mutation* is not necessary, technically
> > speaking, because we can rely on JNI. However, I reckon that returning an
> > immutable view is done for performance reasons. That's why adding a way
> > to
> > mutate "the view" would be an acceptable thing I think. No reflection, no
> > bytecode rewriting, just give a way to mutate the map that
> > `ProcessEnvironment` retains. The advantage of this is that you would not
> > effectively mutate the environment variables, so you, on the JVM side,
> > would be safe. What you would mutate is the view you are retaining.
> > Alternatively, provide us with an API to "refresh" the view. Like,
> > `System.getenv(true)`. The benefit would be that you would only have to
> get
> > the new view of environment variables if the user asks for it. And,
> > subsequent callers would get the refreshed view, so people using
> `gettenv`
> > in their code would be up-to-date.
> >
> > I'm really concerned that this problem is not taken seriously. It's a
> major
> > performance problem for the most widely used build tool out there
> > (considering all users, from native to Java and Android). Just saying
> > "you're doing something nasty" is not a valid answer: we have to do it,
> and
> > do it for good reasons.
> >
> >
> > 2017-05-11 4:50 GMT+02:00 Martin Buchholz :
> >
> > > Since you're OK with doing brain surgery on the JDK and you control the
> > > entire process, consider controlling your daemon with a bytecode
> rewriting
> > > agent (e.g. byteman) that changes the definition of System.getenv etc.
> > >
> > > (Whose side are you on Martin?! ...  I confess I also wish for a faster
> > > gradle ...)
> > >
>
>

From naoto.sato at oracle.com  Tue May 16 18:14:25 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 16 May 2017 11:14:25 -0700
Subject: [9] RFR: 8180375: Rename Provider to
 .spi.Provider
Message-ID: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>

Hello,

Please review the changes to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8180375

The proposed fix is located at:

http://cr.openjdk.java.net/~naoto/8180375/webrev.00/

This is to change the package name of the resource bundle provider to a 
different one, by appending ".spi" to the original package name. This 
change effectively avoids possible split package issue if resource 
bundles are provided from other named modules.

Naoto

From brian.goetz at oracle.com  Tue May 16 18:23:25 2017
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 16 May 2017 11:23:25 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
Message-ID: <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>

I?m sorry you find it tiring, but I think you underestimate how high the bar is (and should be) for changing how Java works just because it?s inconvenient for your situation.  In my view, you?re not remotely there on justifying this.  By all means continue, but ?this is too tiring? isn?t a valid argument.  

> I'm honestly starting to get tired of explaining again and again WHY we
> need this. 

From cedric.champeau at gmail.com  Tue May 16 18:38:50 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 20:38:50 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
Message-ID: 

Let me rephrase: it's tiring to have to repeat why we need it, and why we
honor the contract of environment variables. Why is it so hard to admit the
JDK has a bug? I proposed different solutions for this, including non
breaking changes (a new method). All I have in return is suggestions to
change how *we* work, while discarding why it is important for us that the
contract of environment variables is respected. And let me say that this is
not inconvenient for *us* at Gradle. It's inconvenient for thousands of
developers who will suffer slow build times if we don't find a solution. My
personal situation doesn't matter. I care about what users will see
(including the larger ecosystem, Android and native).

2017-05-16 20:23 GMT+02:00 Brian Goetz :

> I?m sorry you find it tiring, but I think you underestimate how high the
> bar is (and should be) for changing how Java works just because it?s
> inconvenient for your situation.  In my view, you?re not remotely there on
> justifying this.  By all means continue, but ?this is too tiring? isn?t a
> valid argument.
>
> > I'm honestly starting to get tired of explaining again and again WHY we
> > need this.
>

From neugens.limasoftware at gmail.com  Tue May 16 19:19:22 2017
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Tue, 16 May 2017 21:19:22 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
Message-ID: 

2017-05-16 20:38 GMT+02:00 C?dric Champeau :
> Let me rephrase: it's tiring to have to repeat why we need it, and why we
> honor the contract of environment variables. Why is it so hard to admit the
> JDK has a bug?

Hello C?dric,

I hope you don't take it wrong or personal, but we really are here to
help, unfortunately this attitude is not helping us helping you. I
suggest to re-read what Brian just said.

The reason why you get suggestion to change how you work is because
changing the JDK effect billions of users that may be affected
negatively by the changes.

Regarding your example:

"""
println System.getenv('MY_VAR')

doesn't print "foo" after doing:

MY_VAR=foo gradle printVar
"""

I agree that the environment variables may change during the program
execution and that perhaps Java may eventually need to reflect that,
but this example is not really appropriate, the Java process started
with an environment variable not set, the one that starts with
MY_VAR=foo is technically a different process...

Cheers,
Mario

-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/

From chris.hegarty at oracle.com  Tue May 16 19:29:23 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 16 May 2017 20:29:23 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
 
Message-ID: 


> On 16 May 2017, at 20:19, Mario Torre  wrote:
> ..
> Regarding your example:
> 
> """
> println System.getenv('MY_VAR')
> 
> doesn't print "foo" after doing:
> 
> MY_VAR=foo gradle printVar
> """
> 
> I agree that the environment variables may change during the program
> execution and that perhaps Java may eventually need to reflect that,
> but this example is not really appropriate, the Java process started
> with an environment variable not set, the one that starts with
> MY_VAR=foo is technically a different process?

Sure, but the ?daemon? ( in terms of Gradle ) should behave ?as if? it were
the initiating process. I have some sympathy for this.

Re-reading/refreshing the env variables has come up before, in other
contexts. As David pointed out [1], re-reading introduces no more risk than
is already there ( if specified correctly ).

-Chris.

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047668.html

From cedric.champeau at gmail.com  Tue May 16 19:31:23 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 21:31:23 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
 
Message-ID: 

Hi Mario,

I'm not suggesting to change the JDK. My original email is about having a
new API to get a live view. Alternatives, like new methods to refresh the
view, are non-breaking (I think). I perfectly understand, and fully
respect, the willingness not to break millions of developers, and that's
not what I'm suggesting.

>
> Regarding your example:
>
> """
> println System.getenv('MY_VAR')
>
> doesn't print "foo" after doing:
>
> MY_VAR=foo gradle printVar
> """
>
> I agree that the environment variables may change during the program
> execution and that perhaps Java may eventually need to reflect that,
> but this example is not really appropriate, the Java process started
> with an environment variable not set, the one that starts with
> MY_VAR=foo is technically a different process...
>

Yes, that's one of our use cases. We mutate the environment variables so
that the process of the daemon sees the new environment variables, as well
as all Java code running there, because that's what users, and tools
executed from Gradle, expect. For forked process we can have our own API
which reads environment variables and passes them to the forked process
(which can itself be a long running process, when we re-use workers). The
issue is mostly with Java code running in the daemon itself (people calling
getenv, be it in a plugin, or in libraries).

So far the only suitable workaround I can think of is an agent that would
rewrite `System.getenv` to call our internal APIs. I'll suggest that in our
next meeting (which is happening 30 mins from now).

From brian.burkhalter at oracle.com  Tue May 16 19:54:14 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 16 May 2017 12:54:14 -0700
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation
 does not indicate properly whether files get truncated or not
In-Reply-To: <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>
References: 
 <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>
Message-ID: 

Hi Chris,

Thanks for the review. Here is a revised version, thanks to a comment from Daniel, which I think might be better:

Thanks,

Brian

--- a/src/java.base/share/classes/java/io/FileOutputStream.java
+++ b/src/java.base/share/classes/java/io/FileOutputStream.java
@@ -91,6 +91,10 @@
      * If the file exists but is a directory rather than a regular file, does
      * not exist but cannot be created, or cannot be opened for any other
      * reason then a FileNotFoundException is thrown.
+     * 

+     * Invoking this constructor with the parameter {@code name} is equivalent
+     * to invoking {@link #FileOutputStream(String,boolean)
+     * new FileOutputStream(name, false)}.
      *
      * @param      name   the system-dependent filename
      * @exception  FileNotFoundException  if the file exists but is a directory

On May 16, 2017, at 1:05 AM, Chris Hegarty  wrote:

> Looks good Brian.
> 
> -Chris.
> 
>> On 16 May 2017, at 02:27, Brian Burkhalter  wrote:
>> 
>> Please review at your convenience.
>> 
>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8180353
>> Patch:	[1]
>> 
>> Thanks,
>> 
>> Brian
>> 
>> [1] Hg diff
>> 
>> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
>> @@ -91,6 +91,12 @@
>>     * If the file exists but is a directory rather than a regular file, does
>>     * not exist but cannot be created, or cannot be opened for any other
>>     * reason then a FileNotFoundException is thrown.
>> +     * 

>> +     * Invoking this constructor with the parameter {@code name} is equivalent
>> +     * to invoking the constructor {@link #FileOutputStream(String,boolean)
>> +     * FileOutputStream(name,append)} with the same {@code String} parameter
>> +     * {@code name} and the {@code boolean} parameter {@code append} equal to
>> +     * {@code false}.
>>     *
>>     * @param      name   the system-dependent filename
>>     * @exception  FileNotFoundException  if the file exists but is a directory
> 


From uschindler at apache.org  Tue May 16 19:56:26 2017
From: uschindler at apache.org (Uwe Schindler)
Date: Tue, 16 May 2017 19:56:26 +0000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
Message-ID: <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>

Hi,

Another example is not having your problem is Jenkins CI: It maintains a map of environment variables throughout the build. And you have to use that a a state container throughout the build. I have never seen a plug-in not using that, because it's fundamental to the whole build server.

If you don't have that, then you have a fundamental API design problem! I don't think Java should take care of that. Backwards compatibility for some broken plugins is a no-go. You have to communicate that to developers. I'd run the build in a security manager and whenever somebody calls getenv() print a warning and in later version fail completely. Elasticsearch is doing similar stuff for their plugins.

Uwe

Am 16. Mai 2017 20:11:10 MESZ schrieb "C?dric Champeau" :
>Hi Uwe,
>
>I already explained multiple times why we need this. Short answer:
>because
>we must. Slightly longer answer: because the build environment, the
>daemon,
>has to reflect the environment from the CLI (or the IDE, in case we
>call
>using the tooling API), at the moment the build is executed. Why?
>Because a
>user wouldn't understand that a script which does:
>
>println System.getenv('MY_VAR')
>
>doesn't print "foo" after doing:
>
>MY_VAR=foo gradle printVar
>
>(that's a silly example, but the simplest we can come with). Not
>everything
>runs in a separate process: there are things that execute in the daemon
>itself. A lot of things (starting from build scripts). And yes, we can
>provide a different API to get environment variables, but:
>
>1. it's a breaking change
>2. there are lots of plugins which use libraries, which do NOT depend
>on
>the Gradle API, so that API wouldn't be available
>
>I'm honestly starting to get tired of explaining again and again WHY we
>need this. If it was easy, we would have done it differently for years.
>We
>worked around a bug in the JDK, which doesn't return the true
>environment
>variables but the ones snapshotted when the process started. Now in JDK
>9
>we cannot workaround anymore, which either just kills Gradle
>performance or
>forces us to write even nastier code with bytecode manipulating agents
>to
>replace what `System.getenv` does.
>
>2017-05-16 19:46 GMT+02:00 Uwe Schindler :
>
>> Hi,
>>
>> I still don't understand why you need to change the environment
>variables
>> of the actual process. I was talking with R?mi about that last week,
>and
>> it's not obvious to me why you need that. Sure, it is easier to
>change the
>> environment of the actual process and then spawn a child process for
>some
>> non-java build tool like GCC or even another standalone java program
>with
>> option fork=true. But: Why not use the ProcessBuilder API when
>spawning
>> those childs? So you just add an "official" build API inside Gradle
>(an
>> official one, documented that allows Gradle plugins to modify the
>> environment variables for the current build running). If you missed
>to add
>> such an API from the beginning (IMHO its essential for a build system
>like
>> Gradle), then you now have to tell your users: "Sorry we did
>something
>> wrong and all our (bad) hacks to allow you to change environment
>variables
>> are no longer working in the future, so please change your code. We
>are so
>> sorry!"
>>
>> If some plugin is not using that new API, then it's not your problem.
>You
>> document that you *have* to use the Environment API, because plugins
>cannot
>> rely on the fact that another plugin or maybe another build running
>at a
>> later time is changing the Gradle process environment.
>>
>> At some point you have to break backwards compatibility and tell
>users:
>> Please update your code, otherwise plugin won't work anymore with
>Gradle
>> version x.y (the one that's compatible to Java 9).
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> uschindler at apache.org
>> ASF Member, Apache Lucene PMC / Committer
>> Bremen, Germany
>> http://lucene.apache.org/
>>
>> > -----Original Message-----
>> > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net]
>On
>> > Behalf Of C?dric Champeau
>> > Sent: Thursday, May 11, 2017 9:02 AM
>> > To: Martin Buchholz 
>> > Cc: core-libs-dev 
>> > Subject: Re: Getting a live view of environment variables (Gradle
>and
>> JDK 9)
>> >
>> > Thanks for the answers, folks, but I think they are kind of missing
>the
>> > point. The fact is that environment variables *are* mutable. Java
>happens
>> > to return an immutable view of the environment variables when the
>VM was
>> > started, which is not the reality. We cannot trust what
>`System.geteenv`
>> > returns. The Javadocs say "current system environment" but it's
>just not
>> > true. The method should be called `getEnvWhenTheVMWasStarted`.
>> >
>> > We also have the problem that the environment of the client and the
>> > daemon
>> > differ over time, as I explained in the previous email. And it is
>pretty
>> > easy to understand that _when the build runs_, we need to get the
>> > environment variables of the _client_, not the daemon. Imagine
>something
>> > as
>> > simple as this:
>> >
>> > String toolPath = System.getenv('SOMETOOL_HOME')
>> >
>> > and imagine that this code runs in the daemon. When the daemon is
>> started,
>> > there's absolutely no guarantee that this variable is going to
>exist.
>> > However, we know that when we're going to execute the build, this
>> variable
>> > *has* to be defined. Obviously, it's going to be done from the CLI:
>> >
>> > $ export SOMETOOL_HOME = ...
>> > $ ./gradlew run ---> connects to the daemon, passes environment
>> variables,
>> > mutates those of the daemon, which then executes the build
>> >
>> > Similarly, from a *single* CLI/terminal, it's very common to change
>the
>> > values of environment variables (because, hey, they are mutable!):
>> >
>> > $ export SOMETOOL_HOME = another path I want to try out
>> > $ ./gradlew run --> ... must update env vars again
>> >
>> > So, to work around the problem that Java doesn't provide a way to
>mutate
>> > the current environment variables, we perform a JNI call to do it.
>*Then*
>> > we need to mutate the "immutable view" that Java provides, or all
>Java
>> code
>> > is going to get wrong information, and we would never succeed. Note
>that
>> > having to resort on JNI to mutate the environment is not the
>problem. We
>> > can live with that. Once can think it's a bad idea to allow
>mutation, in
>> > practice, it is necessary, but I reckon it could be a bad idea to
>have an
>> > API for this. The *real* issue is that `System.getenv` does *not*
>return
>> > the real values, because it's an immutable view of what existed at
>the VM
>> > startup.
>> >
>> > Note that it's not recommended to mutate environment variables in a
>> > multi-threaded environment. But in practice, you can assimilate
>what we
>> do
>> > to the VM startup: we get environment variables, mutate them,
>_then_ the
>> > build runs (and only at that moment we would effectively be
>> > multi-threaded). We can live with potential issues of mutating the
>> > environment: the benefits outperforms the drawbacks by orders of
>> > magnitude.
>> > When the daemon is activated, we're not talking about 10% faster
>builds.
>> > They can effectively be 3, 5 or 10x faster!
>> >
>> > Now, back to the problem with JDK 9:
>> >
>> > - first, the implementation has changed. But we could adapt our
>code.
>> > - second, calling `setAccessible` is not allowed anymore. And this
>is a
>> > MAJOR pita. The problem is that we're trying to access the java
>base
>> > module, and reflection on that module is not allowed anymore. There
>are
>> no
>> > good solutions for this: we could write a JVM agent, like you
>suggested,
>> > that rewrites bytecode. But since we're trying to rewrite a core
>class,
>> it
>> > would have to be found on the invocation of `java` command itself,
>and
>> > cannot be dynamically loaded. In addition, we would have to add a
>flag to
>> > open core classes to rewrite. There are multiple problems with this
>> > approach: first, we don't know on which environment we run before
>we're
>> > started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a
>startup
>> > script which tries to infer the version from whatever it finds,
>this is
>> not
>> > realistic and would add unacceptable latency on the client side
>(plus, a
>> > lot of headaches to support the various environments we support:
>Linux,
>> > Mac, Windows, ...). Second, we may not have a hand on the CLI at
>all. For
>> > example, if the build runs in Travis CI, Amazon, or whatever
>cloudish
>> thing
>> > that spawns its own containers, we cannot tweak the VM arguments.
>We just
>> > have to use whatever is there. Last, rewriting bytecode has a cost,
>that
>> > you pay at startup.
>> >
>> > Again, what we need is that Java just returns the live view of the
>> > environment variables. Allowing *mutation* is not necessary,
>technically
>> > speaking, because we can rely on JNI. However, I reckon that
>returning an
>> > immutable view is done for performance reasons. That's why adding a
>way
>> > to
>> > mutate "the view" would be an acceptable thing I think. No
>reflection, no
>> > bytecode rewriting, just give a way to mutate the map that
>> > `ProcessEnvironment` retains. The advantage of this is that you
>would not
>> > effectively mutate the environment variables, so you, on the JVM
>side,
>> > would be safe. What you would mutate is the view you are retaining.
>> > Alternatively, provide us with an API to "refresh" the view. Like,
>> > `System.getenv(true)`. The benefit would be that you would only
>have to
>> get
>> > the new view of environment variables if the user asks for it. And,
>> > subsequent callers would get the refreshed view, so people using
>> `gettenv`
>> > in their code would be up-to-date.
>> >
>> > I'm really concerned that this problem is not taken seriously. It's
>a
>> major
>> > performance problem for the most widely used build tool out there
>> > (considering all users, from native to Java and Android). Just
>saying
>> > "you're doing something nasty" is not a valid answer: we have to do
>it,
>> and
>> > do it for good reasons.
>> >
>> >
>> > 2017-05-11 4:50 GMT+02:00 Martin Buchholz :
>> >
>> > > Since you're OK with doing brain surgery on the JDK and you
>control the
>> > > entire process, consider controlling your daemon with a bytecode
>> rewriting
>> > > agent (e.g. byteman) that changes the definition of System.getenv
>etc.
>> > >
>> > > (Whose side are you on Martin?! ...  I confess I also wish for a
>faster
>> > > gradle ...)
>> > >
>>
>>

From cedric.champeau at gmail.com  Tue May 16 19:57:41 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Tue, 16 May 2017 21:57:41 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>
Message-ID: 

I don't deny some people do not have the problem :)

2017-05-16 21:56 GMT+02:00 Uwe Schindler :

> Hi,
>
> Another example is not having your problem is Jenkins CI: It maintains a
> map of environment variables throughout the build. And you have to use that
> a a state container throughout the build. I have never seen a plug-in not
> using that, because it's fundamental to the whole build server.
>
> If you don't have that, then you have a fundamental API design problem! I
> don't think Java should take care of that. Backwards compatibility for some
> broken plugins is a no-go. You have to communicate that to developers. I'd
> run the build in a security manager and whenever somebody calls getenv()
> print a warning and in later version fail completely. Elasticsearch is
> doing similar stuff for their plugins.
>
> Uwe
>
>
> Am 16. Mai 2017 20:11:10 MESZ schrieb "C?dric Champeau" <
> cedric.champeau at gmail.com>:
>>
>> Hi Uwe,
>>
>> I already explained multiple times why we need this. Short answer:
>> because we must. Slightly longer answer: because the build environment, the
>> daemon, has to reflect the environment from the CLI (or the IDE, in case we
>> call using the tooling API), at the moment the build is executed. Why?
>> Because a user wouldn't understand that a script which does:
>>
>> println System.getenv('MY_VAR')
>>
>> doesn't print "foo" after doing:
>>
>> MY_VAR=foo gradle printVar
>>
>> (that's a silly example, but the simplest we can come with). Not
>> everything runs in a separate process: there are things that execute in the
>> daemon itself. A lot of things (starting from build scripts). And yes, we
>> can provide a different API to get environment variables, but:
>>
>> 1. it's a breaking change
>> 2. there are lots of plugins which use libraries, which do NOT depend on
>> the Gradle API, so that API wouldn't be available
>>
>> I'm honestly starting to get tired of explaining again and again WHY we
>> need this. If it was easy, we would have done it differently for years. We
>> worked around a bug in the JDK, which doesn't return the true environment
>> variables but the ones snapshotted when the process started. Now in JDK 9
>> we cannot workaround anymore, which either just kills Gradle performance or
>> forces us to write even nastier code with bytecode manipulating agents to
>> replace what `System.getenv` does.
>>
>> 2017-05-16 19:46 GMT+02:00 Uwe Schindler :
>>
>>> Hi,
>>>
>>> I still don't understand why you need to change the environment
>>> variables of the actual process. I was talking with R?mi about that last
>>> week, and it's not obvious to me why you need that. Sure, it is easier to
>>> change the environment of the actual process and then spawn a child process
>>> for some non-java build tool like GCC or even another standalone java
>>> program with option fork=true. But: Why not use the ProcessBuilder API when
>>> spawning those childs? So you just add an "official" build API inside
>>> Gradle (an official one, documented that allows Gradle plugins to modify
>>> the environment variables for the current build running). If you missed to
>>> add such an API from the beginning (IMHO its essential for a build system
>>> like Gradle), then you now have to tell your users: "Sorry we did something
>>> wrong and all our (bad) hacks to allow you to change environment variables
>>> are no longer working in the future, so please change your code. We are so
>>> sorry!"
>>>
>>> If some plugin is not using that new API, then it's not your problem.
>>> You document that you *have* to use the Environment API, because plugins
>>> cannot rely on the fact that another plugin or maybe another build running
>>> at a later time is changing the Gradle process environment.
>>>
>>> At some point you have to break backwards compatibility and tell users:
>>> Please update your code, otherwise plugin won't work anymore with Gradle
>>> version x.y (the one that's compatible to Java 9).
>>>
>>> Uwe
>>>
>>> -----
>>> Uwe Schindler
>>> uschindler at apache.org
>>> ASF Member, Apache Lucene PMC / Committer
>>> Bremen, Germany
>>> http://lucene.apache.org/
>>>
>>> > -----Original Message-----
>>> > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
>>> > Behalf Of C?dric Champeau
>>> > Sent: Thursday, May 11, 2017 9:02 AM
>>> > To: Martin Buchholz 
>>> > Cc: core-libs-dev 
>>> > Subject: Re: Getting a live view of environment variables (Gradle and
>>> JDK 9)
>>> >
>>> > Thanks for the answers, folks, but I think they are kind of missing the
>>> > point. The fact is that environment variables *are* mutable. Java
>>> happens
>>> > to return an immutable view of the environment variables when the VM
>>> was
>>> > started, which is not the reality. We cannot trust what
>>> `System.geteenv`
>>> > returns. The Javadocs say "current system environment" but it's just
>>> not
>>> > true. The method should be called `getEnvWhenTheVMWasStarted`.
>>> >
>>> > We also have the problem that the environment of the client and the
>>> > daemon
>>> > differ over time, as I explained in the previous email. And it is
>>> pretty
>>> > easy to understand that _when the build runs_, we need to get the
>>> > environment variables of the _client_, not the daemon. Imagine
>>> something
>>> > as
>>> > simple as this:
>>> >
>>> > String toolPath = System.getenv('SOMETOOL_HOME')
>>> >
>>> > and imagine that this code runs in the daemon. When the daemon is
>>> started,
>>> > there's absolutely no guarantee that this variable is going to exist.
>>> > However, we know that when we're going to execute the build, this
>>> variable
>>> > *has* to be defined. Obviously, it's going to be done from the CLI:
>>> >
>>> > $ export SOMETOOL_HOME = ...
>>> > $ ./gradlew run ---> connects to the daemon, passes environment
>>> variables,
>>> > mutates those of the daemon, which then executes the build
>>> >
>>> > Similarly, from a *single* CLI/terminal, it's very common to change the
>>> > values of environment variables (because, hey, they are mutable!):
>>> >
>>> > $ export SOMETOOL_HOME = another path I want to try out
>>> > $ ./gradlew run --> ... must update env vars again
>>> >
>>> > So, to work around the problem that Java doesn't provide a way to
>>> mutate
>>> > the current environment variables, we perform a JNI call to do it.
>>> *Then*
>>> > we need to mutate the "immutable view" that Java provides, or all Java
>>> code
>>> > is going to get wrong information, and we would never succeed. Note
>>> that
>>> > having to resort on JNI to mutate the environment is not the problem.
>>> We
>>> > can live with that. Once can think it's a bad idea to allow mutation,
>>> in
>>> > practice, it is necessary, but I reckon it could be a bad idea to have
>>> an
>>> > API for this. The *real* issue is that `System.getenv` does *not*
>>> return
>>> > the real values, because it's an immutable view of what existed at the
>>> VM
>>> > startup.
>>> >
>>> > Note that it's not recommended to mutate environment variables in a
>>> > multi-threaded environment. But in practice, you can assimilate what
>>> we do
>>> > to the VM startup: we get environment variables, mutate them, _then_
>>> the
>>> > build runs (and only at that moment we would effectively be
>>> > multi-threaded). We can live with potential issues of mutating the
>>> > environment: the benefits outperforms the drawbacks by orders of
>>> > magnitude.
>>> > When the daemon is activated, we're not talking about 10% faster
>>> builds.
>>> > They can effectively be 3, 5 or 10x faster!
>>> >
>>> > Now, back to the problem with JDK 9:
>>> >
>>> > - first, the implementation has changed. But we could adapt our code.
>>> > - second, calling `setAccessible` is not allowed anymore. And this is a
>>> > MAJOR pita. The problem is that we're trying to access the java base
>>> > module, and reflection on that module is not allowed anymore. There
>>> are no
>>> > good solutions for this: we could write a JVM agent, like you
>>> suggested,
>>> > that rewrites bytecode. But since we're trying to rewrite a core
>>> class, it
>>> > would have to be found on the invocation of `java` command itself, and
>>> > cannot be dynamically loaded. In addition, we would have to add a flag
>>> to
>>> > open core classes to rewrite. There are multiple problems with this
>>> > approach: first, we don't know on which environment we run before we're
>>> > started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a
>>> startup
>>> > script which tries to infer the version from whatever it finds, this
>>> is not
>>> > realistic and would add unacceptable latency on the client side (plus,
>>> a
>>> > lot of headaches to support the various environments we support: Linux,
>>> > Mac, Windows, ...). Second, we may not have a hand on the CLI at all.
>>> For
>>> > example, if the build runs in Travis CI, Amazon, or whatever cloudish
>>> thing
>>> > that spawns its own containers, we cannot tweak the VM arguments. We
>>> just
>>> > have to use whatever is there. Last, rewriting bytecode has a cost,
>>> that
>>> > you pay at startup.
>>> >
>>> > Again, what we need is that Java just returns the live view of the
>>> > environment variables. Allowing *mutation* is not necessary,
>>> technically
>>> > speaking, because we can rely on JNI. However, I reckon that returning
>>> an
>>> > immutable view is done for performance reasons. That's why adding a way
>>> > to
>>> > mutate "the view" would be an acceptable thing I think. No reflection,
>>> no
>>> > bytecode rewriting, just give a way to mutate the map that
>>> > `ProcessEnvironment` retains. The advantage of this is that you would
>>> not
>>> > effectively mutate the environment variables, so you, on the JVM side,
>>> > would be safe. What you would mutate is the view you are retaining.
>>> > Alternatively, provide us with an API to "refresh" the view. Like,
>>> > `System.getenv(true)`. The benefit would be that you would only have
>>> to get
>>> > the new view of environment variables if the user asks for it. And,
>>> > subsequent callers would get the refreshed view, so people using
>>> `gettenv`
>>> > in their code would be up-to-date.
>>> >
>>> > I'm really concerned that this problem is not taken seriously. It's a
>>> major
>>> > performance problem for the most widely used build tool out there
>>> > (considering all users, from native to Java and Android). Just saying
>>> > "you're doing something nasty" is not a valid answer: we have to do
>>> it, and
>>> > do it for good reasons.
>>> >
>>> >
>>> > 2017-05-11 4:50 GMT+02:00 Martin Buchholz :
>>> >
>>> > > Since you're OK with doing brain surgery on the JDK and you control
>>> the
>>> > > entire process, consider controlling your daemon with a bytecode
>>> rewriting
>>> > > agent (e.g. byteman) that changes the definition of System.getenv
>>> etc.
>>> > >
>>> > > (Whose side are you on Martin?! ...  I confess I also wish for a
>>> faster
>>> > > gradle ...)
>>> > >
>>>
>>>
>>

From jbluettduncan at gmail.com  Tue May 16 20:03:49 2017
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Tue, 16 May 2017 21:03:49 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>
 
Message-ID: 

Hi C?dric,

I don't know if it's been considered, but has anyone from the Gradle team
asked the Bazel team about this problem?

They may have useful insight about this problem with `System.getenv`,
considering that Bazel is apparently very fast and (partially) written in
Java.

I hope this helps.

Best regards,
Jonathan

From martinrb at google.com  Tue May 16 20:21:08 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 May 2017 13:21:08 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
 
 
Message-ID: 

On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty 
wrote:

>
> Re-reading/refreshing the env variables has come up before, in other
> contexts. As David pointed out [1], re-reading introduces no more risk than
> is already there ( if specified correctly ).
>

Adding a Java API for re-reading would be really weird because there would
be no Java API for writing, and there's no way on a Unix system to write at
all without introducing a risk of SEGV.


> -Chris.
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-
> May/047668.html

From martinrb at google.com  Tue May 16 20:29:42 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 May 2017 13:29:42 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>
 
 
Message-ID: 

On Tue, May 16, 2017 at 1:03 PM, Jonathan Bluett-Duncan <
jbluettduncan at gmail.com> wrote:

> Hi C?dric,
>
> I don't know if it's been considered, but has anyone from the Gradle team
> asked the Bazel team about this problem?
>

I'm not on the Bazel team, but ... they are focused on being hermetic - if
they had any kind of build server process, I guess it would simply not
incorporate user environment variables, which are highly non-hermetic.


> They may have useful insight about this problem with `System.getenv`,
> considering that Bazel is apparently very fast and (partially) written in
> Java.
>

From forax at univ-mlv.fr  Tue May 16 20:31:27 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 May 2017 22:31:27 +0200 (CEST)
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <6AC96331-EF2D-42C4-9F0E-C73DB33FD4A0@apache.org>
 
 
Message-ID: <309145140.1490158.1494966687507.JavaMail.zimbra@u-pem.fr>

Hi Jonathan,
Bazel is a cathedral when Gradle is a bazaar,
Bazel uses a controlled subset of Python as build language, and a strictly defined API that do not let you extend Bazel in an arbitrary way. 

Those two approaches, a strict DSL or a general purpose languages retargeted to be used as a DSL have both there advantages and inconveniences, but i'm sure that everybody will agree that for the extensions/plugins migration, it's better to have a cleanly sandboxed environment. 

R?mi

----- Mail original -----
> De: "Jonathan Bluett-Duncan" 
> ?: "C?dric Champeau" 
> Cc: "core-libs-dev" 
> Envoy?: Mardi 16 Mai 2017 22:03:49
> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)

> Hi C?dric,
> 
> I don't know if it's been considered, but has anyone from the Gradle team
> asked the Bazel team about this problem?
> 
> They may have useful insight about this problem with `System.getenv`,
> considering that Bazel is apparently very fast and (partially) written in
> Java.
> 
> I hope this helps.
> 
> Best regards,
> Jonathan

From martinrb at google.com  Tue May 16 20:37:22 2017
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 16 May 2017 13:37:22 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
 
 
Message-ID: 

On Tue, May 16, 2017 at 12:31 PM, C?dric Champeau  wrote:

>
> So far the only suitable workaround I can think of is an agent that would
> rewrite `System.getenv` to call our internal APIs. I'll suggest that in our
> next meeting (which is happening 30 mins from now).
>

Yes, given that you have control over your java processes, I think this is
what you should do, at least medium-term.  Longer-term, figure out some way
to migrate to a strategy that does not involve accessing jdk internals.

From mandy.chung at oracle.com  Tue May 16 21:52:15 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 16 May 2017 14:52:15 -0700
Subject: [9] RFR: 8180375: Rename Provider to
 .spi.Provider
In-Reply-To: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>
References: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>
Message-ID: <28128F8D-879C-499C-ADFF-D53DE838A4C9@oracle.com>


> On May 16, 2017, at 11:14 AM, Naoto Sato  wrote:
> 
> Hello,
> 
> Please review the changes to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180375
> 
> The proposed fix is located at:
> 
> http://cr.openjdk.java.net/~naoto/8180375/webrev.00/
> 
> This is to change the package name of the resource bundle provider to a different one, by appending ".spi" to the original package name. This change effectively avoids possible split package issue if resource bundles are provided from other named modules.

This would ease migration in particular when the provider modules are loaded in a layer defined to multiple loader.  Existing resource bundles can be kept in the same package.

 247  * The service type is designated by {@code package name + ".spi." + simple name +"Provider"}. For

It may be clearer to say {@code  + ?.spi.? +  + ?Provider?}.


test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
   - they are provider implmentation classes.  They don?t need to be renamed. If you want to rename them, maybe better to move them to jdk.test.resources.internal package.

test/java/util/ResourceBundle/modules/layer/src/Main.java
test/java/util/ResourceBundle/modules/layer/src/m1/p/Main.java
   Nit: several long lines that can be wrapped.

Otherwise looks fine.

Mandy

From mandy.chung at oracle.com  Tue May 16 22:09:13 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 16 May 2017 15:09:13 -0700
Subject: [9] RFR: 8180375: Rename Provider to
 .spi.Provider
In-Reply-To: <28128F8D-879C-499C-ADFF-D53DE838A4C9@oracle.com>
References: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>
 <28128F8D-879C-499C-ADFF-D53DE838A4C9@oracle.com>
Message-ID: <35C52E7A-539C-4AF2-B123-BC500357383F@oracle.com>

Naoto,

The javadoc of getBundle(String, Module) and getBundle(String,Locale,Module) methods also mention the service type ?baseName?Provider that needs update as well.

Mandy

> On May 16, 2017, at 2:52 PM, Mandy Chung  wrote:
> 
> 
>> On May 16, 2017, at 11:14 AM, Naoto Sato  wrote:
>> 
>> Hello,
>> 
>> Please review the changes to the following issue:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180375
>> 
>> The proposed fix is located at:
>> 
>> http://cr.openjdk.java.net/~naoto/8180375/webrev.00/
>> 
>> This is to change the package name of the resource bundle provider to a different one, by appending ".spi" to the original package name. This change effectively avoids possible split package issue if resource bundles are provided from other named modules.
> 
> This would ease migration in particular when the provider modules are loaded in a layer defined to multiple loader.  Existing resource bundles can be kept in the same package.
> 
> 247  * The service type is designated by {@code package name + ".spi." + simple name +"Provider"}. For
> 
> It may be clearer to say {@code  + ?.spi.? +  + ?Provider?}.
> 
> 
> test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
> test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
>   - they are provider implmentation classes.  They don?t need to be renamed. If you want to rename them, maybe better to move them to jdk.test.resources.internal package.
> 
> test/java/util/ResourceBundle/modules/layer/src/Main.java
> test/java/util/ResourceBundle/modules/layer/src/m1/p/Main.java
>   Nit: several long lines that can be wrapped.
> 
> Otherwise looks fine.
> 
> Mandy


From jonathan.gibbons at oracle.com  Tue May 16 22:27:31 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 16 May 2017 15:27:31 -0700
Subject: RFR: 8180385: fix HTML issues in java.xml module
Message-ID: <591B7CD3.6010705@oracle.com>

Please review these fixes to update the public doc comments in the java.xml
module for HTML 5.

Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/
API: http://cr.openjdk.java.net/~jjg/8180385/api.02/

-- Jon

From kirk.pepperdine at gmail.com  Tue May 16 22:53:02 2017
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Wed, 17 May 2017 07:53:02 +0900
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
Message-ID: <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>

Hi,


> On May 17, 2017, at 3:11 AM, C?dric Champeau  wrote:
> 
> Hi Uwe,
> 
> I already explained multiple times why we need this. Short answer: because
> we must. Slightly longer answer: because the build environment, the daemon,
> has to reflect the environment from the CLI (or the IDE, in case we call
> using the tooling API), at the moment the build is executed. Why? Because a
> user wouldn't understand that a script which does:
> 
> println System.getenv('MY_VAR')
> 
> doesn't print "foo" after doing:
> 
> MY_VAR=foo gradle printVar

I disagree, this would be totally expected behavior. The daemon and this process would run in different shells and I am unaware of any daemon process that auto-magically reconfigures it?s self to adapt to any other arbitrary shell?s changed environment variables. In fact, IMHO, this seems like a fundamentally flawed way for the deamon process to behave. I believe the client communicating with the deamon that should be providing information to the daemon.

Kind regards,
Kirk


From lance.andersen at oracle.com  Tue May 16 22:55:04 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 16 May 2017 18:55:04 -0400
Subject: RFR: 8180385: fix HTML issues in java.xml module
In-Reply-To: <591B7CD3.6010705@oracle.com>
References: <591B7CD3.6010705@oracle.com>
Message-ID: <0B557AB8-6192-4938-A475-9B67EF23887D@oracle.com>

Hi Jon

src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java  -  Was there a reason you omitted {@code getNamespaceURI(prefix)} when creating the caption?

Looks pretty good otherwise

> On May 16, 2017, at 6:27 PM, Jonathan Gibbons  wrote:
> 
> Please review these fixes to update the public doc comments in the java.xml
> module for HTML 5.
> 
> Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/
> API: http://cr.openjdk.java.net/~jjg/8180385/api.02/
> 
> -- Jon

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From huizhe.wang at oracle.com  Tue May 16 23:00:55 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 16 May 2017 16:00:55 -0700
Subject: RFR: 8180385: fix HTML issues in java.xml module
In-Reply-To: <591B7CD3.6010705@oracle.com>
References: <591B7CD3.6010705@oracle.com>
Message-ID: 

Hi Jon,

Looks good. Thanks again!

-Joe

On 5/16/2017 3:27 PM, Jonathan Gibbons wrote:
> Please review these fixes to update the public doc comments in the 
> java.xml
> module for HTML 5.
>
> Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/
> API: http://cr.openjdk.java.net/~jjg/8180385/api.02/
>
> -- Jon


From jonathan.gibbons at oracle.com  Tue May 16 23:02:57 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 16 May 2017 16:02:57 -0700
Subject: RFR: 8180385: fix HTML issues in java.xml module
In-Reply-To: <0B557AB8-6192-4938-A475-9B67EF23887D@oracle.com>
References: <591B7CD3.6010705@oracle.com>
 <0B557AB8-6192-4938-A475-9B67EF23887D@oracle.com>
Message-ID: <591B8521.1060104@oracle.com>

Lance,

The name seemed unnecessary given the context of the method associated 
with the doc comment (i.e getNamespaceURI) and the preceding sentence:

 >> the following table describes the returned Namespace URI value for 
all possible prefix values:

If that was editorial overreach, I apologise, and can add the text back, 
if you would prefer.

See 
http://cr.openjdk.java.net/~jjg/8180385/api.02/javax/xml/namespace/NamespaceContext.html#getNamespaceURI-java.lang.String-

-- Jon

On 05/16/2017 03:55 PM, Lance Andersen wrote:
> Hi Jon
>
> src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java  -  Was there a reason you omitted {@code getNamespaceURI(prefix)} when creating the caption?
> Looks pretty good otherwise
>> On May 16, 2017, at 6:27 PM, Jonathan Gibbons 
>> > wrote:
>>
>> Please review these fixes to update the public doc comments in the 
>> java.xml
>> module for HTML 5.
>>
>> Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/ 
>> 
>> API: http://cr.openjdk.java.net/~jjg/8180385/api.02/ 
>> 
>>
>> -- Jon
>
> 
> 
> Lance 
> Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
>
>
>


From lance.andersen at oracle.com  Tue May 16 23:26:13 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 16 May 2017 19:26:13 -0400
Subject: RFR: 8180385: fix HTML issues in java.xml module
In-Reply-To: <591B8521.1060104@oracle.com>
References: <591B7CD3.6010705@oracle.com>
 <0B557AB8-6192-4938-A475-9B67EF23887D@oracle.com>
 <591B8521.1060104@oracle.com>
Message-ID: 

Hi Jon,

Thank you for the explanation.  Makes sense.  No worries :-)

Best
Lance
> On May 16, 2017, at 7:02 PM, Jonathan Gibbons  wrote:
> 
> Lance,
> 
> The name seemed unnecessary given the context of the method associated with the doc comment (i.e getNamespaceURI) and the preceding sentence:
> 
> >> the following table describes the returned Namespace URI value for all possible prefix values: 
> 
> If that was editorial overreach, I apologise, and can add the text back, if you would prefer.
> 
> See http://cr.openjdk.java.net/~jjg/8180385/api.02/javax/xml/namespace/NamespaceContext.html#getNamespaceURI-java.lang.String -
> 
> -- Jon
> 
> On 05/16/2017 03:55 PM, Lance Andersen wrote:
>> Hi Jon
>> 
>> src/java.xml/share/classes/javax/xml/namespace/NamespaceContext.java  -  Was there a reason you omitted {@code getNamespaceURI(prefix)} when creating the caption?
>> Looks pretty good otherwise
>>> On May 16, 2017, at 6:27 PM, Jonathan Gibbons > wrote:
>>> 
>>> Please review these fixes to update the public doc comments in the java.xml
>>> module for HTML 5.
>>> 
>>> Webrev: http://cr.openjdk.java.net/~jjg/8180385/webrev.02/ 
>>> API: http://cr.openjdk.java.net/~jjg/8180385/api.02/ 
>>> 
>>> -- Jon
>> 
>>  
>>   
>>  Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering 
>> 1 Network Drive 
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com 
>> 
>> 
>> 
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From igor.ignatyev at oracle.com  Tue May 16 23:52:35 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 May 2017 16:52:35 -0700
Subject: RFR(S): 8180391: move SerializationUtils to top level testlibrary
Message-ID: <64B001DD-5641-4966-9E3A-EB263FE72E43@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180391/webrev.00/index.html
> 119 lines changed: 56 ins; 54 del; 9 mod;

Hi all,

could you please review this small fix which move SerializationUtils class from jdk testlibrary to top level testlibrary? jdk.testlibrary.SerializationUtils does not have dependency on any other test library classes, so we can simply move it to the top level testlibrary and update the tests which use it.

this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

webrev: http://cr.openjdk.java.net/~iignatyev//8180391/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180391
testing: affected tests (java/lang)

[1] https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor

From igor.ignatyev at oracle.com  Wed May 17 00:01:32 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 May 2017 17:01:32 -0700
Subject: RFR(XS): move FilterClassLoader and ParentLastURLClassLoader to top
 level testlibrary
Message-ID: <44B9E33B-2B83-4C28-B654-6667388A5AC6@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
> 200 lines changed: 101 ins; 99 del; 0 mod;

Hi all,

could you please review this small fix which move FilterClassLoader and ParentLastURLClassLoader class from jdk testlibrary to top level testlibrary?
this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

webrev: http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180395

[1]  https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor

From igor.ignatyev at oracle.com  Wed May 17 00:14:07 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 May 2017 17:14:07 -0700
Subject: RFR(S) : 8180397 : remove jdk.testlibrary.IOUtils 
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
> 92 lines changed: 0 ins; 81 del; 11 mod; 

Hi all,

could you please review this small clean-up which removes jdk.testlibrary.IOUtils class from test library?
IOUtils provides one method readFully(InputStream), which can be replaced by InputStream::readAllBytes() introduced in JDK 9.

this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180397
testing: affected tests

[1]  https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor



From david.holmes at oracle.com  Wed May 17 00:40:02 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 10:40:02 +1000
Subject: Java-Time Clock Implementation Note
In-Reply-To: 
References: 
 <942cbb64-9767-53f0-bfb6-ed1bdf1e6291@oracle.com>
 
 
Message-ID: 

+1

Thanks,
David

On 17/05/2017 12:39 AM, Daniel Fuchs wrote:
> Thanks Stephen,
>
> On 16/05/2017 15:32, Stephen Colebourne wrote:
>> Its not terrible, but I think confusing enough it should be fixed.
>>
>> Maybe:
>> "The clock implementation provided here is based on the same
>> underlying clock as System.currentTimeMillis(), but may have a
>> precision finer
>> than milliseconds if available. However, little to no guarantee is
>> provided about the accuracy of the underlying clock. Applications
>> requiring a more accurate clock must implement this abstract class
>> themselves using a different external clock, such as an NTP server."
>
> I like this. Let's turn it into a docs-only bug for JDK 9: we can
> still fix those... I will log the issue - unless you prefer to do it?
>
> best regards,
>
> -- daniel
>
>>
>> Stephen
>>
>>
>>
>> On 16 May 2017 at 11:59, Daniel Fuchs  wrote:
>>> Hi Stephen,
>>>
>>> Thanks for pointing that out.
>>>
>>> On 16/05/2017 11:27, Stephen Colebourne wrote:
>>>>
>>>> In JDK 9, the implementation of Clock has been improved to be better
>>>> than millisecond in most cases [1]. However, I've just noticed that
>>>> the Javadoc of the "Implementation Note" is now wrong. It says:
>>>>
>>>> "The clock implementation provided here is based on
>>>> System.currentTimeMillis(). That method provides little to no
>>>> guarantee about the accuracy of the clock. Applications requiring a
>>>> more accurate clock must implement this abstract class themselves
>>>> using a different external clock, such as an NTP server."
>>>>
>>>> This needs to be updated to indicate that the implementation is no
>>>> longer based on System.currentTimeMillis(). Since this is an
>>>> "implementation note" I hope that this doesn't affect the
>>>> specification, or need too much process.
>>>
>>>
>>> Strictly speaking the implementation is based on the *same* clock
>>> than System.currentTimeMillis() is based on. This is very important
>>> as it means that times obtained by System.currentTimeMillis() and
>>> times obtained by the system clock are consistent with each other.
>>>
>>> So I am not sure the note [2] is actually wrong?
>>>
>>> Would the following be a better wording (syntax/grammar may need
>>> correction)?
>>>
>>> <<
>>> The clock implementation provided here is based on the same clock than
>>> System.currentTimeMillis() is based on, but may have a precision finer
>>> than milliseconds if provided by the underlying clock.
>>> However, little to no guarantee is provided about the accuracy of the
>>> underlying clock. Applications requiring a more accurate clock must
>>> implement this abstract class themselves using a different external
>>> clock,
>>> such as an NTP server.
>>>>>
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> [2] http://download.java.net/java/jdk9/docs/api/java/time/Clock.html
>>>
>>>
>>>
>>>
>>>>
>>>> Is anyone willing to take this up as a JDK 9 bug?
>>>>
>>>> thanks
>>>> Stephen
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8068730
>>>>
>>>
>

From david.holmes at oracle.com  Wed May 17 00:40:44 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 10:40:44 +1000
Subject: RFR 8u Backport: 8179515: Class
 java.util.concurrent.ThreadLocalRandom fails to Initialize when using
 SecurityManager
In-Reply-To: <704438c3-9704-85b2-95e2-71f337ff1396@Oracle.com>
References: 
 <704438c3-9704-85b2-95e2-71f337ff1396@Oracle.com>
Message-ID: 

Thanks Roger!

David

On 17/05/2017 2:54 AM, Roger Riggs wrote:
> Hi David,
>
> Looks fine.
>
> Roger
>
>
> On 5/16/2017 3:02 AM, David Holmes wrote:
>> The existing code in 8u was a little different to 9, but the new code
>> is identical (other than package names):
>>
>> webrev: http://cr.openjdk.java.net/~dholmes/8179515/webrev.8u/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8179515
>> 9 changeset: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/bb4cdc198dc0
>> 9 review thread:
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047615.html
>>
>> Thanks,
>> David
>

From brian.burkhalter at oracle.com  Wed May 17 01:34:38 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 16 May 2017 18:34:38 -0700
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation
 does not indicate properly whether files get truncated or not
In-Reply-To: 
References: 
 <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>
 
Message-ID: <5D4059E0-BC42-45BC-832E-5F771FC041DA@oracle.com>

Hi Chris,

Let?s skip the first revision (May 16, 2017, at 12:54 PM PDT) of the patch and go for this one instead:

--- a/src/java.base/share/classes/java/io/FileOutputStream.java
+++ b/src/java.base/share/classes/java/io/FileOutputStream.java
@@ -91,6 +91,10 @@
      * If the file exists but is a directory rather than a regular file, does
      * not exist but cannot be created, or cannot be opened for any other
      * reason then a FileNotFoundException is thrown.
+     * 

+     * @implSpec Invoking this constructor with the parameter {@code name} is
+     * equivalent to invoking {@link #FileOutputStream(String,boolean)
+     * new FileOutputStream(name, false)}.
      *
      * @param      name   the system-dependent filename
      * @exception  FileNotFoundException  if the file exists but is a directory

Thanks,

Brian

On May 16, 2017, at 12:54 PM, Brian Burkhalter  wrote:

> Hi Chris,
> 
> Thanks for the review. Here is a revised version, thanks to a comment from Daniel, which I think might be better:
> 
> Thanks,
> 
> Brian
> 
> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
> @@ -91,6 +91,10 @@
>      * If the file exists but is a directory rather than a regular file, does
>      * not exist but cannot be created, or cannot be opened for any other
>      * reason then a FileNotFoundException is thrown.
> +     * 

> +     * Invoking this constructor with the parameter {@code name} is equivalent
> +     * to invoking {@link #FileOutputStream(String,boolean)
> +     * new FileOutputStream(name, false)}.
>      *
>      * @param      name   the system-dependent filename
>      * @exception  FileNotFoundException  if the file exists but is a directory
> 
> On May 16, 2017, at 1:05 AM, Chris Hegarty  wrote:
> 
>> Looks good Brian.
>> 
>> -Chris.
>> 
>>> On 16 May 2017, at 02:27, Brian Burkhalter  wrote:
>>> 
>>> Please review at your convenience.
>>> 
>>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8180353
>>> Patch:	[1]
>>> 
>>> Thanks,
>>> 
>>> Brian
>>> 
>>> [1] Hg diff
>>> 
>>> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
>>> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
>>> @@ -91,6 +91,12 @@
>>>    * If the file exists but is a directory rather than a regular file, does
>>>    * not exist but cannot be created, or cannot be opened for any other
>>>    * reason then a FileNotFoundException is thrown.
>>> +     * 

>>> +     * Invoking this constructor with the parameter {@code name} is equivalent
>>> +     * to invoking the constructor {@link #FileOutputStream(String,boolean)
>>> +     * FileOutputStream(name,append)} with the same {@code String} parameter
>>> +     * {@code name} and the {@code boolean} parameter {@code append} equal to
>>> +     * {@code false}.
>>>    *
>>>    * @param      name   the system-dependent filename
>>>    * @exception  FileNotFoundException  if the file exists but is a directory
>> 
> 


From david.holmes at oracle.com  Wed May 17 02:37:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 12:37:00 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <58B88262-9781-4111-898E-D9EE4B1D03B9@oracle.com>
 
 
 
 
Message-ID: 

On 17/05/2017 6:21 AM, Martin Buchholz wrote:
> On Tue, May 16, 2017 at 12:29 PM, Chris Hegarty 
> wrote:
>
>>
>> Re-reading/refreshing the env variables has come up before, in other
>> contexts. As David pointed out [1], re-reading introduces no more risk than
>> is already there ( if specified correctly ).
>>
>
> Adding a Java API for re-reading would be really weird because there would
> be no Java API for writing

I don't see that as weird. We don't want an API for writing because 
writing from Java is a bad idea. The API for re-reading is a concession 
that in reality the process environment can change outside of the JVMs 
control. I view it as part of the process meta-data, for which we only 
provide read APIs in Java.

> and there's no way on a Unix system to write at
> all without introducing a risk of SEGV.

But the reality is that it is a technique that people use and have used 
for years without harm. Are they doing the "wrong thing"? - probably. 
But I have some sympathy to Gradle's predicament given:

a) Java never documented that getenv took an immutable snapshot
b) The env that is read depends on when the first call to getenv occurs 
(there is an 8u bug where an app suddenly started failing because JDK 
code started using getenv internally and so took the snapshot much earlier!)
c) this has only stopped working because of Jigsaw's strong 
encapsulation enforcement

As I said previously any such API must come with a very strong caveat 
that it is a "use at own risk" API. I know that doesn't sound very 
Java-ish, but getenv by its nature is not very Java-ish IMHO.

David
-----

>
>> -Chris.
>>
>> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-
>> May/047668.html

From igor.ignatyev at oracle.com  Wed May 17 04:21:39 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 16 May 2017 21:21:39 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the top
 level test library	 
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html
> 186 lines changed: 87 ins; 90 del; 9 mod; 

Hi all,

could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library?
this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].

webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180397
testing: affected tests

[1]  https://bugs.openjdk.java.net/browse/JDK-8075327

Thanks,
-- Igor



From dalibor.topic at oracle.com  Wed May 17 06:50:58 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 17 May 2017 08:50:58 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
Message-ID: <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>

On 17.05.2017 00:53, Kirk Pepperdine wrote:
>> println System.getenv('MY_VAR')
>>
>> doesn't print "foo" after doing:
>>
>> MY_VAR=foo gradle printVar
>
> I disagree, this would be totally expected behavior. The daemon and this process would run in different shells and I am unaware of any daemon process that auto-magically reconfigures it?s self to adapt to any other arbitrary shell?s changed environment variables. In fact, IMHO, this seems like a fundamentally flawed way for the deamon process to behave. I believe the client communicating with the deamon that should be providing information to the daemon.

It might open a grab bag of exciting behavior depending on what, if any, 
filtering is done on the type and content of environment variables being 
set.

The $PATH to /tmp/.dr0pp3r/.h3ll/ is paved with good intentions.

cheers,
dalibor topic
-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

From Alan.Bateman at oracle.com  Wed May 17 06:52:06 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 May 2017 07:52:06 +0100
Subject: RFR(S) : 8180397 : remove jdk.testlibrary.IOUtils
In-Reply-To: 
References: 
Message-ID: 



On 17/05/2017 01:14, Igor Ignatyev wrote:
> :
> Hi all,
>
> could you please review this small clean-up which removes jdk.testlibrary.IOUtils class from test library?
> IOUtils provides one method readFully(InputStream), which can be replaced by InputStream::readAllBytes() introduced in JDK 9.
>
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
>
This looks fine.

From cedric.champeau at gmail.com  Wed May 17 07:21:33 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Wed, 17 May 2017 09:21:33 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
Message-ID: 

>
>
>> I disagree, this would be totally expected behavior. The daemon and this
>> process would run in different shells and I am unaware of any daemon
>> process that auto-magically reconfigures it?s self to adapt to any other
>> arbitrary shell?s changed environment variables.
>
>
The thing is that the daemon is an "implementation detail". The user
doesn't even need to know there's one. It's here for performance reasons.
If we could get the same level of performance, and startup time, right from
the process start, there wouldn't be any need for a daemon. But the truth
is different: with classloading, in-memory dependency management caches,
and the JIT, the daemon is required. So imagine the surprise if a user just
does a "cd subproject" and start Gradle, and we spawn a new daemon, just
because the "PWD" environment variable has changed. It doesn't make sense.
Also it can lead to surprising behaviors: if you run 2 builds concurrently
(this happens, yes, we have thousands of users so all scenarios exist in
the wild), then depending on whether the daemon was busy when you start the
build, you would get different environment variables: the busy one would
get the environment variables when it was started, and the fresh one to run
the 2d build would get the refreshed ones, because started at a different
point in time.

Another scenario: one might think (we do) that it's better to use project
properties than environment variables to communicate runtime specific
configuration. But the reality is always more complex. For example, our
build scripts may require calling a Perl library at some point (imagine,
for example, calling FlameGraph). If that library is configured through
environment variables (say, it requires FLAMEGRAPH_HOME to be set), then
it's better to check beforehand if the environment variable is set, rather
than executing the build and failing when we try to call it. So, the build
script needs to check that this environment variable is set. If we don't
propagage the client environment variables to the daemon, then 2 things
happen:

1. the check to verify that the environment variable is set would fail,
even if it has been set in the CLI
2. we wouldn't be able to set the environment variables of the forked
process running Perl to the appropriate set of variables

From forax at univ-mlv.fr  Wed May 17 10:45:36 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 17 May 2017 12:45:36 +0200 (CEST)
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
Message-ID: <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>

What i really like in Java is the diversity of options.

We are discussing here to add or not a way to get the live environment in a Java process,
at the same time on hotspot-compiler-dev Yasumasa posts a message with a set of examples that shows how to do any C syscalls from Java using JVMCI (and Panama is not far away)
and since a long time, people can use JNR to access to a POSIX API from Java [2].

So knowing that, do we really need to have getenv/putenv/setenv in the JDK API ?

R?mi

[1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026232.html
[2] https://github.com/jnr/jnr-posix/blob/master/src/main/java/jnr/posix/POSIX.java

----- Mail original -----
> De: "C?dric Champeau" 
> ?: "dalibor topic" 
> Cc: "core-libs-dev" 
> Envoy?: Mercredi 17 Mai 2017 09:21:33
> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)

>>
>>
>>> I disagree, this would be totally expected behavior. The daemon and this
>>> process would run in different shells and I am unaware of any daemon
>>> process that auto-magically reconfigures it?s self to adapt to any other
>>> arbitrary shell?s changed environment variables.
>>
>>
> The thing is that the daemon is an "implementation detail". The user
> doesn't even need to know there's one. It's here for performance reasons.
> If we could get the same level of performance, and startup time, right from
> the process start, there wouldn't be any need for a daemon. But the truth
> is different: with classloading, in-memory dependency management caches,
> and the JIT, the daemon is required. So imagine the surprise if a user just
> does a "cd subproject" and start Gradle, and we spawn a new daemon, just
> because the "PWD" environment variable has changed. It doesn't make sense.
> Also it can lead to surprising behaviors: if you run 2 builds concurrently
> (this happens, yes, we have thousands of users so all scenarios exist in
> the wild), then depending on whether the daemon was busy when you start the
> build, you would get different environment variables: the busy one would
> get the environment variables when it was started, and the fresh one to run
> the 2d build would get the refreshed ones, because started at a different
> point in time.
> 
> Another scenario: one might think (we do) that it's better to use project
> properties than environment variables to communicate runtime specific
> configuration. But the reality is always more complex. For example, our
> build scripts may require calling a Perl library at some point (imagine,
> for example, calling FlameGraph). If that library is configured through
> environment variables (say, it requires FLAMEGRAPH_HOME to be set), then
> it's better to check beforehand if the environment variable is set, rather
> than executing the build and failing when we try to call it. So, the build
> script needs to check that this environment variable is set. If we don't
> propagage the client environment variables to the daemon, then 2 things
> happen:
> 
> 1. the check to verify that the environment variable is set would fail,
> even if it has been set in the CLI
> 2. we wouldn't be able to set the environment variables of the forked
> process running Perl to the appropriate set of variables

From david.holmes at oracle.com  Wed May 17 12:01:52 2017
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 May 2017 22:01:52 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
Message-ID: <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>

On 17/05/2017 8:45 PM, Remi Forax wrote:
> What i really like in Java is the diversity of options.
>
> We are discussing here to add or not a way to get the live environment in a Java process,
> at the same time on hotspot-compiler-dev Yasumasa posts a message with a set of examples that shows how to do any C syscalls from Java using JVMCI (and Panama is not far away)
> and since a long time, people can use JNR to access to a POSIX API from Java [2].
>
> So knowing that, do we really need to have getenv/putenv/setenv in the JDK API ?

As long as we have JDK classes that support configuration via 
environment variables then yes the JDK needs an API to enable that. 
Maybe a version or two after Panama is available we could deprecate it.

David

> R?mi
>
> [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-May/026232.html
> [2] https://github.com/jnr/jnr-posix/blob/master/src/main/java/jnr/posix/POSIX.java
>
> ----- Mail original -----
>> De: "C?dric Champeau" 
>> ?: "dalibor topic" 
>> Cc: "core-libs-dev" 
>> Envoy?: Mercredi 17 Mai 2017 09:21:33
>> Objet: Re: Getting a live view of environment variables (Gradle and JDK 9)
>
>>>
>>>
>>>> I disagree, this would be totally expected behavior. The daemon and this
>>>> process would run in different shells and I am unaware of any daemon
>>>> process that auto-magically reconfigures it?s self to adapt to any other
>>>> arbitrary shell?s changed environment variables.
>>>
>>>
>> The thing is that the daemon is an "implementation detail". The user
>> doesn't even need to know there's one. It's here for performance reasons.
>> If we could get the same level of performance, and startup time, right from
>> the process start, there wouldn't be any need for a daemon. But the truth
>> is different: with classloading, in-memory dependency management caches,
>> and the JIT, the daemon is required. So imagine the surprise if a user just
>> does a "cd subproject" and start Gradle, and we spawn a new daemon, just
>> because the "PWD" environment variable has changed. It doesn't make sense.
>> Also it can lead to surprising behaviors: if you run 2 builds concurrently
>> (this happens, yes, we have thousands of users so all scenarios exist in
>> the wild), then depending on whether the daemon was busy when you start the
>> build, you would get different environment variables: the busy one would
>> get the environment variables when it was started, and the fresh one to run
>> the 2d build would get the refreshed ones, because started at a different
>> point in time.
>>
>> Another scenario: one might think (we do) that it's better to use project
>> properties than environment variables to communicate runtime specific
>> configuration. But the reality is always more complex. For example, our
>> build scripts may require calling a Perl library at some point (imagine,
>> for example, calling FlameGraph). If that library is configured through
>> environment variables (say, it requires FLAMEGRAPH_HOME to be set), then
>> it's better to check beforehand if the environment variable is set, rather
>> than executing the build and failing when we try to call it. So, the build
>> script needs to check that this environment variable is set. If we don't
>> propagage the client environment variables to the daemon, then 2 things
>> happen:
>>
>> 1. the check to verify that the environment variable is set would fail,
>> even if it has been set in the CLI
>> 2. we wouldn't be able to set the environment variables of the forked
>> process running Perl to the appropriate set of variables

From daniel.fuchs at oracle.com  Wed May 17 14:55:50 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 17 May 2017 15:55:50 +0100
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation
 does not indicate properly whether files get truncated or not
In-Reply-To: <5D4059E0-BC42-45BC-832E-5F771FC041DA@oracle.com>
References: 
 <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>
 
 <5D4059E0-BC42-45BC-832E-5F771FC041DA@oracle.com>
Message-ID: <6bda6fe8-e12e-b266-6a51-256c0c21153b@oracle.com>

On 17/05/2017 02:34, Brian Burkhalter wrote:
> Hi Chris,
>
> Let?s skip the first revision (May 16, 2017, at 12:54 PM PDT) of the patch and go for this one instead:
>
> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
> @@ -91,6 +91,10 @@
>       * If the file exists but is a directory rather than a regular file, does
>       * not exist but cannot be created, or cannot be opened for any other
>       * reason then a FileNotFoundException is thrown.
> +     * 

> +     * @implSpec Invoking this constructor with the parameter {@code name} is
> +     * equivalent to invoking {@link #FileOutputStream(String,boolean)
> +     * new FileOutputStream(name, false)}.
>       *
>       * @param      name   the system-dependent filename
>       * @exception  FileNotFoundException  if the file exists but is a directory
>
> Thanks,

Looks fine!

best regards,

-- daniel

>
> Brian
>
> On May 16, 2017, at 12:54 PM, Brian Burkhalter  wrote:
>
>> Hi Chris,
>>
>> Thanks for the review. Here is a revised version, thanks to a comment from Daniel, which I think might be better:
>>
>> Thanks,
>>
>> Brian
>>
>> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
>> @@ -91,6 +91,10 @@
>>      * If the file exists but is a directory rather than a regular file, does
>>      * not exist but cannot be created, or cannot be opened for any other
>>      * reason then a FileNotFoundException is thrown.
>> +     * 

>> +     * Invoking this constructor with the parameter {@code name} is equivalent
>> +     * to invoking {@link #FileOutputStream(String,boolean)
>> +     * new FileOutputStream(name, false)}.
>>      *
>>      * @param      name   the system-dependent filename
>>      * @exception  FileNotFoundException  if the file exists but is a directory
>>
>> On May 16, 2017, at 1:05 AM, Chris Hegarty  wrote:
>>
>>> Looks good Brian.
>>>
>>> -Chris.
>>>
>>>> On 16 May 2017, at 02:27, Brian Burkhalter  wrote:
>>>>
>>>> Please review at your convenience.
>>>>
>>>> Issue:	https://bugs.openjdk.java.net/browse/JDK-8180353
>>>> Patch:	[1]
>>>>
>>>> Thanks,
>>>>
>>>> Brian
>>>>
>>>> [1] Hg diff
>>>>
>>>> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
>>>> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
>>>> @@ -91,6 +91,12 @@
>>>>    * If the file exists but is a directory rather than a regular file, does
>>>>    * not exist but cannot be created, or cannot be opened for any other
>>>>    * reason then a FileNotFoundException is thrown.
>>>> +     * 

>>>> +     * Invoking this constructor with the parameter {@code name} is equivalent
>>>> +     * to invoking the constructor {@link #FileOutputStream(String,boolean)
>>>> +     * FileOutputStream(name,append)} with the same {@code String} parameter
>>>> +     * {@code name} and the {@code boolean} parameter {@code append} equal to
>>>> +     * {@code false}.
>>>>    *
>>>>    * @param      name   the system-dependent filename
>>>>    * @exception  FileNotFoundException  if the file exists but is a directory
>>>
>>
>


From chris.hegarty at oracle.com  Wed May 17 15:06:34 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 17 May 2017 16:06:34 +0100
Subject: JDK 9 doc-only RFR of 8180353: FileOutputStream documentation
 does not indicate properly whether files get truncated or not
In-Reply-To: <6bda6fe8-e12e-b266-6a51-256c0c21153b@oracle.com>
References: 
 <237B44DE-4CA0-4810-80DF-B56BA1781A69@oracle.com>
 
 <5D4059E0-BC42-45BC-832E-5F771FC041DA@oracle.com>
 <6bda6fe8-e12e-b266-6a51-256c0c21153b@oracle.com>
Message-ID: 


> On 17 May 2017, at 15:55, Daniel Fuchs  wrote:
> 
> On 17/05/2017 02:34, Brian Burkhalter wrote:
>> Hi Chris,
>> 
>> Let?s skip the first revision (May 16, 2017, at 12:54 PM PDT) of the patch and go for this one instead:
>> 
>> --- a/src/java.base/share/classes/java/io/FileOutputStream.java
>> +++ b/src/java.base/share/classes/java/io/FileOutputStream.java
>> @@ -91,6 +91,10 @@
>>      * If the file exists but is a directory rather than a regular file, does
>>      * not exist but cannot be created, or cannot be opened for any other
>>      * reason then a FileNotFoundException is thrown.
>> +     * 

>> +     * @implSpec Invoking this constructor with the parameter {@code name} is
>> +     * equivalent to invoking {@link #FileOutputStream(String,boolean)
>> +     * new FileOutputStream(name, false)}.
>>      *
>>      * @param      name   the system-dependent filename
>>      * @exception  FileNotFoundException  if the file exists but is a directory
>> 
>> Thanks,
> 
> Looks fine!

+1

-Chris.

From martinrb at google.com  Wed May 17 16:36:27 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 May 2017 09:36:27 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
Message-ID: 

Stop trying to add APIs to mutate environment variables.  It's not going to
happen!  There is no known way to mutate environment variables in a
multithreaded Unix process without risk of native crashes (and I have worn
the hat of poor support engineer trying to diagnose SEGV in getenv).  IIRC
we made the decision 13 years ago to cache the environment on first access,
and that was before the thread-unsafety of putenv was fully appreciated.

Yes, Java still has a serious startup performance problem; that should be
attacked more directly.

From henry.jen at oracle.com  Wed May 17 18:46:33 2017
From: henry.jen at oracle.com (Henry Jen)
Date: Wed, 17 May 2017 11:46:33 -0700
Subject: RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an
 application fail to launch
Message-ID: 

Hi,

Please review a trivial fix for JDK-8180447[1], which we also makes the output of options picked up by the environment variable in one line instead of two for easier extraction from output.

Cheers,
Henry

[1] http://cr.openjdk.java.net/~henryjen/jdk9/8180447/webrev/

From Alan.Bateman at oracle.com  Wed May 17 18:52:42 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 May 2017 19:52:42 +0100
Subject: RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an
 application fail to launch
In-Reply-To: 
References: 
Message-ID: 



On 17/05/2017 19:46, Henry Jen wrote:
> Hi,
>
> Please review a trivial fix for JDK-8180447[1], which we also makes the output of options picked up by the environment variable in one line instead of two for easier extraction from output.
>
> Cheers,
> Henry
>
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8180447/webrev/
This looks goods to me.

-Alan

From brian.burkhalter at oracle.com  Wed May 17 19:16:00 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 May 2017 12:16:00 -0700
Subject: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy
 as well as resolution
Message-ID: <0A7E4A90-B490-4B73-A41A-94E649717D37@oracle.com>

Please review at your convenience.

Issue:	https://bugs.openjdk.java.net/browse/JDK-7086489
Patch:	[1]

Thanks,

Brian

[1] Hg mq diff

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -923,6 +923,12 @@
      * java.nio.file.Files#readAttributes(Path,Class,LinkOption[])
      * Files.readAttributes} method may be used.
      *
+     * @implSpec While the unit of the returned value is milliseconds, this
+     * does not imply that its accuracy is to the millisecond as some platforms
+     * may truncate the last-modified time to a less accurate value. For
+     * example if the value were truncated to seconds, then the last three
+     * digits of the returned value would all be zero.
+     *
      * @return  A long value representing the time the file was
      *          last modified, measured in milliseconds since the epoch
      *          (00:00:00 GMT, January 1, 1970), or 0L if the

From stuart.marks at oracle.com  Wed May 17 20:15:21 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 17 May 2017 13:15:21 -0700
Subject: JDK 9 doc-api-only RFR of 7086489: File.lastModified should
 accuracy as well as resolution
In-Reply-To: <0A7E4A90-B490-4B73-A41A-94E649717D37@oracle.com>
References: <0A7E4A90-B490-4B73-A41A-94E649717D37@oracle.com>
Message-ID: <8677c2d1-b603-016e-a925-24db6174a373@oracle.com>

This is for JDK 9, right, so we want only non-normative doc changes?

I'd think this should be an @apiNote instead of @implSpec. The @apiNote 
clarifies but doesn't change the semantics, whereas @implSpec can impose 
requirements on the implementation and is thus normative.

The intent of the wording is correct, but I also think it's potentially 
confusing, particularly regarding "truncation." If the time resolution (or 
"granularity") in a particular file system is one second, the value returned is 
converted from seconds to milliseconds and no truncation occurs. The "last three 
digits...zero" assumes the value is expressed in decimal, which isn't incorrect, 
but it seems to require more explanation to make sense. I'd leave it out.

For APIs with similar issues, see System.currentTimeMillis() and 
System.nanoTime(). In particular, currentTimeMillis() says:

      * Returns the current time in milliseconds.  Note that
      * while the unit of time of the return value is a millisecond,
      * the granularity of the value depends on the underlying
      * operating system and may be larger.  For example, many
      * operating systems measure time in units of tens of
      * milliseconds.

I'm not sure "granularity" is the best term, but it seems OK. Maybe the best 
thing to do would be to use this wording and adjust "operating system" to "file 
system".

s'marks

On 5/17/17 12:16 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-7086489
> Patch:	[1]
>
> Thanks,
>
> Brian
>
> [1] Hg mq diff
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -923,6 +923,12 @@
>       * java.nio.file.Files#readAttributes(Path,Class,LinkOption[])
>       * Files.readAttributes} method may be used.
>       *
> +     * @implSpec While the unit of the returned value is milliseconds, this
> +     * does not imply that its accuracy is to the millisecond as some platforms
> +     * may truncate the last-modified time to a less accurate value. For
> +     * example if the value were truncated to seconds, then the last three
> +     * digits of the returned value would all be zero.
> +     *
>       * @return  A long value representing the time the file was
>       *          last modified, measured in milliseconds since the epoch
>       *          (00:00:00 GMT, January 1, 1970), or 0L if the
>

From brian.burkhalter at oracle.com  Wed May 17 20:28:02 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 May 2017 13:28:02 -0700
Subject: JDK 9 doc-api-only RFR of 7086489: File.lastModified should
 accuracy as well as resolution
In-Reply-To: <8677c2d1-b603-016e-a925-24db6174a373@oracle.com>
References: <0A7E4A90-B490-4B73-A41A-94E649717D37@oracle.com>
 <8677c2d1-b603-016e-a925-24db6174a373@oracle.com>
Message-ID: 

Hi Stuart,

Thanks for the careful reading and comments.

On May 17, 2017, at 1:15 PM, Stuart Marks  wrote:

> This is for JDK 9, right, so we want only non-normative doc changes?
> 
> I'd think this should be an @apiNote instead of @implSpec. The @apiNote clarifies but doesn't change the semantics, whereas @implSpec can impose requirements on the implementation and is thus normative.
> 
> The intent of the wording is correct, but I also think it's potentially confusing, particularly regarding "truncation." If the time resolution (or "granularity") in a particular file system is one second, the value returned is converted from seconds to milliseconds and no truncation occurs. The "last three digits...zero" assumes the value is expressed in decimal, which isn't incorrect, but it seems to require more explanation to make sense. I'd leave it out.

Good points.

> For APIs with similar issues, see System.currentTimeMillis() and System.nanoTime(). In particular, currentTimeMillis() says:
> 
>     * Returns the current time in milliseconds.  Note that
>     * while the unit of time of the return value is a millisecond,

This wording "the unit of time of the return value is a millisecond? sounds weird. I would have written "the unit of time of the return value is milliseconds.?

>     * the granularity of the value depends on the underlying
>     * operating system and may be larger.  For example, many
>     * operating systems measure time in units of tens of
>     * milliseconds.
> 
> I'm not sure "granularity" is the best term, but it seems OK. Maybe the best thing to do would be to use this wording and adjust "operating system" to "file system".

How about then (ignore formatting)?

    * @apiNote
    * While the unit of time of the return value is milliseconds,
    * the granularity of the value depends on the underlying
    * file system and may be larger.  For example, some
    * file systems use time stamps in units of seconds.

Thanks,

Brian

From brian.burkhalter at oracle.com  Wed May 17 20:54:44 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 17 May 2017 13:54:44 -0700
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
Message-ID: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>

Please review at your convenience:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8177809
Patch:	http://cr.openjdk.java.net/~bpb/8177809/webrev.00/

Change the native portion of the Unix implementation to use the full time structure available. Note that for macOS, at least with HFS Plus, this will not increase the accuracy as in that case dates are stored in unsigned 32-bit integers containing the number of seconds since midnight, January 1, 1904, GMT, therefore millisecond granularity is unavailable on that platform.

To verify the results, regression test jobs without the patch were run against JDK 9 and with the patch against JDK 10. These tests verified that the change affects the value returned by File.lastModified() for linux_i586, linux_x64, solaris_sparcv9, and solaris_x64 making them be the same as that returned for windows_i586 and windows_x64. The value returned on macOS is unchanged (running HFS+).

One arguable objection to making this change is that it might be incompatible as some applications could depend on the value's being less accurate.

Thanks,

Brian

From stuart.marks at oracle.com  Wed May 17 21:09:26 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 17 May 2017 14:09:26 -0700
Subject: JDK 9 doc-api-only RFR of 7086489: File.lastModified should
 accuracy as well as resolution
In-Reply-To: 
References: <0A7E4A90-B490-4B73-A41A-94E649717D37@oracle.com>
 <8677c2d1-b603-016e-a925-24db6174a373@oracle.com>
 
Message-ID: <01bb5cdf-2c9f-7c52-fbc9-e27303111005@oracle.com>

On 5/17/17 1:28 PM, Brian Burkhalter wrote:
> This wording "the unit of time of the return value is a millisecond? sounds 
> weird. I would have written "the unit of time of the return value is 
> milliseconds.?
OK.
> How about then (ignore formatting)?
>
>     * @apiNote
>     * While the unit of time of the return value is milliseconds,
>     * the granularity of the value depends on the underlying
>     * file system and may be larger.  For example, some
>     * file systems use time stamps in units of seconds.
This looks good! I trust you with the formatting. You can go ahead and push; I 
don't need another review.

Thanks,

s'marks


From david.holmes at oracle.com  Wed May 17 21:15:18 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 07:15:18 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
Message-ID: <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>

On 18/05/2017 2:36 AM, Martin Buchholz wrote:
> Stop trying to add APIs to mutate environment variables.  It's not going
> to happen!

Not sure who or what you are directing this at Martin. Certainly I'm not 
suggesting any API to mutate environment variables. This is about an API 
to re-read an already potentially mutated external environment.

> There is no known way to mutate environment variables in a
> multithreaded Unix process without risk of native crashes (and I have
> worn the hat of poor support engineer trying to diagnose SEGV in
> getenv).  IIRC we made the decision 13 years ago to cache the
> environment on first access, and that was before the thread-unsafety of
> putenv was fully appreciated.
>
> Yes, Java still has a serious startup performance problem; that should
> be attacked more directly.

?? Not sure what startup has to do with the topic here.

David

From mandy.chung at oracle.com  Wed May 17 21:27:33 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 May 2017 14:27:33 -0700
Subject: RFR: JDK-8180447: Trailing space in JDK_JAVA_OPTIONS causes an
 application fail to launch
In-Reply-To: 
References: 
Message-ID: <6641A7B3-68DE-4031-AFED-3E009B6CFD2B@oracle.com>


> On May 17, 2017, at 11:46 AM, Henry Jen  wrote:
> 
> Hi,
> 
> Please review a trivial fix for JDK-8180447[1], which we also makes the output of options picked up by the environment variable in one line instead of two for easier extraction from output.
> 
> Cheers,
> Henry
> 
> [1] http://cr.openjdk.java.net/~henryjen/jdk9/8180447/webrev/

Looks good.

Thanks
Mandy

From naoto.sato at oracle.com  Wed May 17 22:06:28 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 17 May 2017 15:06:28 -0700
Subject: [9] RFR: 8180375: Rename Provider to
 .spi.Provider
In-Reply-To: <35C52E7A-539C-4AF2-B123-BC500357383F@oracle.com>
References: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>
 <28128F8D-879C-499C-ADFF-D53DE838A4C9@oracle.com>
 <35C52E7A-539C-4AF2-B123-BC500357383F@oracle.com>
Message-ID: <234e2f91-3f64-c3ab-cbbe-5eb7b3848697@oracle.com>

Revised the fix according to your suggestions:

http://cr.openjdk.java.net/~naoto/8180375/webrev.01/
http://cr.openjdk.java.net/~naoto/8180375/webrev.01-00/ (change since 
ver.00)

Naoto

On 5/16/17 3:09 PM, Mandy Chung wrote:
> Naoto,
>
> The javadoc of getBundle(String, Module) and getBundle(String,Locale,Module) methods also mention the service type ?baseName?Provider that needs update as well.
>
> Mandy
>
>> On May 16, 2017, at 2:52 PM, Mandy Chung  wrote:
>>
>>
>>> On May 16, 2017, at 11:14 AM, Naoto Sato  wrote:
>>>
>>> Hello,
>>>
>>> Please review the changes to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8180375
>>>
>>> The proposed fix is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8180375/webrev.00/
>>>
>>> This is to change the package name of the resource bundle provider to a different one, by appending ".spi" to the original package name. This change effectively avoids possible split package issue if resource bundles are provided from other named modules.
>>
>> This would ease migration in particular when the provider modules are loaded in a layer defined to multiple loader.  Existing resource bundles can be kept in the same package.
>>
>> 247  * The service type is designated by {@code package name + ".spi." + simple name +"Provider"}. For
>>
>> It may be clearer to say {@code  + ?.spi.? +  + ?Provider?}.
>>
>>
>> test/java/util/ResourceBundle/modules/appbasic/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
>> test/java/util/ResourceBundle/modules/appbasic2/src/test/jdk/test/resources/spi/MyResourcesProviderImpl.java
>>   - they are provider implmentation classes.  They don?t need to be renamed. If you want to rename them, maybe better to move them to jdk.test.resources.internal package.
>>
>> test/java/util/ResourceBundle/modules/layer/src/Main.java
>> test/java/util/ResourceBundle/modules/layer/src/m1/p/Main.java
>>   Nit: several long lines that can be wrapped.
>>
>> Otherwise looks fine.
>>
>> Mandy
>

From mandy.chung at oracle.com  Wed May 17 22:11:23 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 17 May 2017 15:11:23 -0700
Subject: [9] RFR: 8180375: Rename Provider to
 .spi.Provider
In-Reply-To: <234e2f91-3f64-c3ab-cbbe-5eb7b3848697@oracle.com>
References: <10786411-aef4-2035-3063-c40ae67d4bbc@oracle.com>
 <28128F8D-879C-499C-ADFF-D53DE838A4C9@oracle.com>
 <35C52E7A-539C-4AF2-B123-BC500357383F@oracle.com>
 <234e2f91-3f64-c3ab-cbbe-5eb7b3848697@oracle.com>
Message-ID: <34A2D59C-06CD-4854-A55C-51C4DC8C598A@oracle.com>


> On May 17, 2017, at 3:06 PM, Naoto Sato  wrote:
> 
> Revised the fix according to your suggestions:
> 
> http://cr.openjdk.java.net/~naoto/8180375/webrev.01/
> http://cr.openjdk.java.net/~naoto/8180375/webrev.01-00/ (change since ver.00)

Looks okay to me.

Thanks
Mandy

From aguibert at us.ibm.com  Wed May 17 22:20:39 2017
From: aguibert at us.ibm.com (Andrew Guibert)
Date: Wed, 17 May 2017 17:20:39 -0500
Subject: Proposal:
 javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
In-Reply-To: <7ecfcdef-af59-7760-d3b8-99de47b1e2bf@oracle.com>
References: 
 
 
 <7ecfcdef-af59-7760-d3b8-99de47b1e2bf@oracle.com>
Message-ID: 


> From: Alan Bateman 
> To: Andrew Guibert 
> Cc: core-libs-dev at openjdk.java.net
> Date: 05/12/2017 04:02 AM
> Subject: Re: Proposal:
> javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
>
> On 11/05/2017 22:25, Andrew Guibert wrote:
> Alan, could you please commit this patch for me? We've tested it
> locally and all of the jdk_other tests pass with this change on jdk9.
>
> 93d92
> < * Once installed, the builder cannot be replaced.
> 101d99
> < * @exception IllegalStateException If a factory has already been
installed.
> 109,111d106
> < if (object_factory_builder != null)
> < throw new IllegalStateException("ObjectFactoryBuilder already set");
> <
> 739,740c734
> < * the security manager to do so. Once installed, the builder cannot
> < * be replaced.
> ---
> > * the security manager to do so.
> 747d740
> < * @exception IllegalStateException If a builder was previous installed.
> 754,757d746
> < if (initctx_factory_builder != null)
> < throw new IllegalStateException(
> < "InitialContextFactoryBuilder already set");
> <
> I assume you will be able to get an IBM contributor to sponsor this.
> It will need an issue in JIRA and tests. All API changes for Java SE
> 10 and beyond will be reviewed by the CSR group [1], that process
> will be opening soon.
>
> -Alan
>
> [1] https://wiki.openjdk.java.net/display/csr/Main

Hi Alan, I've checked within IBM and it appears we do not have any OpenJDK
committers.  Still trying to chase down if we have anyone in IBM who can
drive this commit.  Do you know of anyone?

Also, you mentioned adding this API change to Java SE *10*.  Are we past
the cutoff for making changes in JDK 9?  I was hoping this (and a handful
of other proposals I have brewing) could be made for JDK 9.  If not, we're
going to be stuck using the JVM options for the lifetime of JDK 9.

From paul.sandoz at oracle.com  Wed May 17 23:59:53 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 17 May 2017 16:59:53 -0700
Subject: RFR(S): 8180391: move SerializationUtils to top level testlibrary
In-Reply-To: <64B001DD-5641-4966-9E3A-EB263FE72E43@oracle.com>
References: <64B001DD-5641-4966-9E3A-EB263FE72E43@oracle.com>
Message-ID: <11A830AB-0877-4E4A-8913-E1D85516809B@oracle.com>

+1

Paul.

> On 16 May 2017, at 16:52, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180391/webrev.00/index.html
>> 119 lines changed: 56 ins; 54 del; 9 mod;
> 
> Hi all,
> 
> could you please review this small fix which move SerializationUtils class from jdk testlibrary to top level testlibrary? jdk.testlibrary.SerializationUtils does not have dependency on any other test library classes, so we can simply move it to the top level testlibrary and update the tests which use it.
> 
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180391/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180391
> testing: affected tests (java/lang)
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> Thanks,
> -- Igor


From paul.sandoz at oracle.com  Thu May 18 00:02:40 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 17 May 2017 17:02:40 -0700
Subject: RFR(XS): move FilterClassLoader and ParentLastURLClassLoader to
 top level testlibrary
In-Reply-To: <44B9E33B-2B83-4C28-B654-6667388A5AC6@oracle.com>
References: <44B9E33B-2B83-4C28-B654-6667388A5AC6@oracle.com>
Message-ID: <9B29C098-5420-4595-991D-AE8F466F3BA2@oracle.com>

Are these classes used? If not should they be deleted?

Paul.

> On 16 May 2017, at 17:01, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
>> 200 lines changed: 101 ins; 99 del; 0 mod;
> 
> Hi all,
> 
> could you please review this small fix which move FilterClassLoader and ParentLastURLClassLoader class from jdk testlibrary to top level testlibrary?
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180395
> 
> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> Thanks,
> -- Igor


From paul.sandoz at oracle.com  Thu May 18 00:13:28 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 17 May 2017 17:13:28 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the
 top level test library
In-Reply-To: 
References: 
Message-ID: <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>


It?s this one :-)

  https://bugs.openjdk.java.net/browse/JDK-8180399 
  http://cr.openjdk.java.net/~iignatyev/8180399/webrev.00/ 

Does the Locks test need to depend on stuff in /lib/testlibrary ?

Paul.

> On 16 May 2017, at 21:21, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html
>> 186 lines changed: 87 ins; 90 del; 9 mod;
> 
> Hi all,
> 
> could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library?
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180397
> testing: affected tests
> 
> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> Thanks,
> -- Igor
> 
> 


From martinrb at google.com  Thu May 18 02:46:52 2017
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 17 May 2017 19:46:52 -0700
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
Message-ID: 

On Wed, May 17, 2017 at 2:15 PM, David Holmes 
wrote:

> On 18/05/2017 2:36 AM, Martin Buchholz wrote:
>
>>
>> Yes, Java still has a serious startup performance problem; that should
>> be attacked more directly.
>>
>
> ?? Not sure what startup has to do with the topic here.


There would be less need to reuse a Java process for performance if
creating and warming up a new one were fast.

From peter.levart at gmail.com  Thu May 18 07:23:14 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Thu, 18 May 2017 09:23:14 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <3afcb469-72bf-a056-cf04-b47909a6da2a@gmail.com>
 
Message-ID: <8616ed28-7a4d-b54e-a50d-cc4a78145247@gmail.com>

Hi Cedric,

On 05/16/2017 12:05 PM, C?dric Champeau wrote:
> Thanks Peter for your thoughts, but I don't think it's as simple as 
> that. As I explained in my original email, there are multiple ways the 
> environment variables can be mutated, and it can be done _externally_. 
> Typically, during a task execution, a JNI call performed by a random 
> native tool could mutate the environment. That's something we, as a 
> build tool, have to consider as a use case. It's very unlikely but it 
> can happen. This means that for the same classloader, the environment 
> can change.

Reading the updated environment could be performed by Gradle using JNI 
after such plugin has finished, right?

> And for performance reasons, we cache classloaders between builds, and 
> reuse them as much as possible (because classloading is far from being 
> cheap).

What about that instead of re-spawning the whole daemon when environment 
changes, Gradle just created new ClassLoader for plugins with updated 
environment variables. This would also account for situations where 
plugins "cache" the result of System.getenv() using static fields like:

public class SomePlugin {
     static final String SOME_CONFIGURATION = 
System.getenv("SOME_CONFIGURATION");

...and if you also keep ClassLoader(s) around for some time (via 
Map>) using a "hash" of the 
environment variables as a key into the Map, the daemon would typically 
stabilize with a set of class loaders invoked from various client 
processes, each having a stable set of environment variables.

Regards, Peter

>
> 2017-05-14 19:51 GMT+02:00 Peter Levart  >:
>
>     Hi Cedric,
>
>     Chiming in with my thoughts...
>
>     It's unfortunate that Gradle plugins or libraries used by plugins
>     use environment variables at all. I wonder who was the first? Did
>     Gradle introduce the feature of passing client environment to the
>     daemon and establishing the view of System.getenv for plugins 1st
>     or did libraries used by plugins happen to use environment
>     variables using System.getenv and Gradle was just kind enough to
>     provide them a dynamic view controlled by client?
>
>     In the end it doesn't matter. The fact is that System.getenv is
>     part of standard Java API and anyone using it should be aware that
>     by doing so, they are limiting their software to be (re)configured
>     only by spawning new process(es). UNIX environment was not
>     designed to be mutated during the course of a long-running
>     process. Maybe just at process startup/setup when conditions are
>     under control (i.e. a single running thread) but later, the
>     environment is meant to be read only.
>
>     Maybe there is a solution for Gradle and othert though. But that
>     solution, I think, is not in exposing a "live" view of process
>     environment through System.getenv or new methods to "refresh" the
>     view as you are proposing, since that would only encourage people
>     to mutate the process environment which, as was established on
>     this thread, is not safe in a long-running multi-threaded process,
>     which Java processes usually are. Perhaps the solution is in
>     extending the System.getenv API with ways to provide "custom"
>     views of variables for code that runs in a "container".
>
>     Gradle is, among other things, a container for plugins. Is Gradle
>     running plugins in a separate ClassLoader? Does it use a separate
>     ClassLoader for each "build" which might bring with it a new set
>     of environment variables from the client? In such a setup, one
>     could provide a separate set of environment variables for each
>     ClassLoader, simply by passing them to the ClassLoader
>     constructor. System.getenv would need to be a @CallerSensitive
>     method which would return caller's ClassLoader view of variables,
>     if any such view was established, or simply the view inherited
>     from the parent ClassLoader.
>
>     Such would be a "functional" approach, which would keep
>     environment variables immutable, but allow child "contexts" to
>     have different views of them. Such approach would also play well
>     with idioms like:
>
>     class AbcPlugin {
>         static final String SOME_SETTING = System.getenv("SOME_SETTING");
>
>     ...and would also help other containers (such as app servers)
>     support existing libraries that use environment variables to be
>     configured differently in different apps deployed in the same VM
>     process.
>
>     Just a thought.
>
>     Regards, Peter
>
>
>
>     On 05/11/2017 09:02 AM, C?dric Champeau wrote:
>>     equalThanks for the answers, folks, but I think they are kind of missing the
>>     point. The fact is that environment variables *are* mutable. Java happens
>>     to return an immutable view of the environment variables when the VM was
>>     started, which is not the reality. We cannot trust what `System.geteenv`
>>     returns. The Javadocs say "current system environment" but it's just not
>>     true. The method should be called `getEnvWhenTheVMWasStarted`.
>>
>>     We also have the problem that the environment of the client and the daemon
>>     differ over time, as I explained in the previous email. And it is pretty
>>     easy to understand that _when the build runs_, we need to get the
>>     environment variables of the _client_, not the daemon. Imagine something as
>>     simple as this:
>>
>>     String toolPath = System.getenv('SOMETOOL_HOME')
>>
>>     and imagine that this code runs in the daemon. When the daemon is started,
>>     there's absolutely no guarantee that this variable is going to exist.
>>     However, we know that when we're going to execute the build, this variable
>>     *has* to be defined. Obviously, it's going to be done from the CLI:
>>
>>     $ export SOMETOOL_HOME = ...
>>     $ ./gradlew run ---> connects to the daemon, passes environment variables,
>>     mutates those of the daemon, which then executes the build
>>
>>     Similarly, from a *single* CLI/terminal, it's very common to change the
>>     values of environment variables (because, hey, they are mutable!):
>>
>>     $ export SOMETOOL_HOME = another path I want to try out
>>     $ ./gradlew run --> ... must update env vars again
>>
>>     So, to work around the problem that Java doesn't provide a way to mutate
>>     the current environment variables, we perform a JNI call to do it. *Then*
>>     we need to mutate the "immutable view" that Java provides, or all Java code
>>     is going to get wrong information, and we would never succeed. Note that
>>     having to resort on JNI to mutate the environment is not the problem. We
>>     can live with that. Once can think it's a bad idea to allow mutation, in
>>     practice, it is necessary, but I reckon it could be a bad idea to have an
>>     API for this. The *real* issue is that `System.getenv` does *not* return
>>     the real values, because it's an immutable view of what existed at the VM
>>     startup.
>>
>>     Note that it's not recommended to mutate environment variables in a
>>     multi-threaded environment. But in practice, you can assimilate what we do
>>     to the VM startup: we get environment variables, mutate them, _then_ the
>>     build runs (and only at that moment we would effectively be
>>     multi-threaded). We can live with potential issues of mutating the
>>     environment: the benefits outperforms the drawbacks by orders of magnitude.
>>     When the daemon is activated, we're not talking about 10% faster builds.
>>     They can effectively be 3, 5 or 10x faster!
>>
>>     Now, back to the problem with JDK 9:
>>
>>     - first, the implementation has changed. But we could adapt our code.
>>     - second, calling `setAccessible` is not allowed anymore. And this is a
>>     MAJOR pita. The problem is that we're trying to access the java base
>>     module, and reflection on that module is not allowed anymore. There are no
>>     good solutions for this: we could write a JVM agent, like you suggested,
>>     that rewrites bytecode. But since we're trying to rewrite a core class, it
>>     would have to be found on the invocation of `java` command itself, and
>>     cannot be dynamically loaded. In addition, we would have to add a flag to
>>     open core classes to rewrite. There are multiple problems with this
>>     approach: first, we don't know on which environment we run before we're
>>     started. Gradle can run on JDK 7, 8, 9, ... and we cannot have a startup
>>     script which tries to infer the version from whatever it finds, this is not
>>     realistic and would add unacceptable latency on the client side (plus, a
>>     lot of headaches to support the various environments we support: Linux,
>>     Mac, Windows, ...). Second, we may not have a hand on the CLI at all. For
>>     example, if the build runs in Travis CI, Amazon, or whatever cloudish thing
>>     that spawns its own containers, we cannot tweak the VM arguments. We just
>>     have to use whatever is there. Last, rewriting bytecode has a cost, that
>>     you pay at startup.
>>
>>     Again, what we need is that Java just returns the live view of the
>>     environment variables. Allowing *mutation* is not necessary, technically
>>     speaking, because we can rely on JNI. However, I reckon that returning an
>>     immutable view is done for performance reasons. That's why adding a way to
>>     mutate "the view" would be an acceptable thing I think. No reflection, no
>>     bytecode rewriting, just give a way to mutate the map that
>>     `ProcessEnvironment` retains. The advantage of this is that you would not
>>     effectively mutate the environment variables, so you, on the JVM side,
>>     would be safe. What you would mutate is the view you are retaining.
>>     Alternatively, provide us with an API to "refresh" the view. Like,
>>     `System.getenv(true)`. The benefit would be that you would only have to get
>>     the new view of environment variables if the user asks for it. And,
>>     subsequent callers would get the refreshed view, so people using `gettenv`
>>     in their code would be up-to-date.
>>
>>     I'm really concerned that this problem is not taken seriously. It's a major
>>     performance problem for the most widely used build tool out there
>>     (considering all users, from native to Java and Android). Just saying
>>     "you're doing something nasty" is not a valid answer: we have to do it, and
>>     do it for good reasons.
>>
>>
>>     2017-05-11 4:50 GMT+02:00 Martin Buchholz :
>>
>>>     Since you're OK with doing brain surgery on the JDK and you control the
>>>     entire process, consider controlling your daemon with a bytecode rewriting
>>>     agent (e.g. byteman) that changes the definition of System.getenv etc.
>>>
>>>     (Whose side are you on Martin?! ...  I confess I also wish for a faster
>>>     gradle ...)
>>>
>
>


From kirk.pepperdine at gmail.com  Thu May 18 07:42:53 2017
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Thu, 18 May 2017 16:42:53 +0900
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
Message-ID: <3D2BF07E-F6D7-4EDA-9EED-F45C98F9E3C5@gmail.com>

Hi Cedric,

I understand what you are trying to do, it is my opinion that you are trying to do this in a completely unexpected way. That the environment variables in the JVM are read only once is an issue in that a nohup should refresh them That all the code in the JVM may (or may not) react to this change is another question. In your case I believe you have painted yourself into a corner by assuming the JVM would be able to read and write shell environment variables. To back off of this assumption 
In this case you will need the client to inform the server of it?s environment and then one possibility is to fork the server with the new variables.

Shells are isolated for a reason. IMHO, changing the JVM to write environment variables based on settings in another shell is a potential security issue.

Kind regards,
Kirk

> On May 17, 2017, at 4:21 PM, C?dric Champeau  wrote:
> 
>> 
>> 
>>> I disagree, this would be totally expected behavior. The daemon and this
>>> process would run in different shells and I am unaware of any daemon
>>> process that auto-magically reconfigures it?s self to adapt to any other
>>> arbitrary shell?s changed environment variables.
>> 
>> 
> The thing is that the daemon is an "implementation detail". The user
> doesn't even need to know there's one. It's here for performance reasons.
> If we could get the same level of performance, and startup time, right from
> the process start, there wouldn't be any need for a daemon. But the truth
> is different: with classloading, in-memory dependency management caches,
> and the JIT, the daemon is required. So imagine the surprise if a user just
> does a "cd subproject" and start Gradle, and we spawn a new daemon, just
> because the "PWD" environment variable has changed. It doesn't make sense.
> Also it can lead to surprising behaviors: if you run 2 builds concurrently
> (this happens, yes, we have thousands of users so all scenarios exist in
> the wild), then depending on whether the daemon was busy when you start the
> build, you would get different environment variables: the busy one would
> get the environment variables when it was started, and the fresh one to run
> the 2d build would get the refreshed ones, because started at a different
> point in time.
> 
> Another scenario: one might think (we do) that it's better to use project
> properties than environment variables to communicate runtime specific
> configuration. But the reality is always more complex. For example, our
> build scripts may require calling a Perl library at some point (imagine,
> for example, calling FlameGraph). If that library is configured through
> environment variables (say, it requires FLAMEGRAPH_HOME to be set), then
> it's better to check beforehand if the environment variable is set, rather
> than executing the build and failing when we try to call it. So, the build
> script needs to check that this environment variable is set. If we don't
> propagage the client environment variables to the daemon, then 2 things
> happen:
> 
> 1. the check to verify that the environment variable is set would fail,
> even if it has been set in the CLI
> 2. we wouldn't be able to set the environment variables of the forked
> process running Perl to the appropriate set of variables


From kirk.pepperdine at gmail.com  Thu May 18 07:46:45 2017
From: kirk.pepperdine at gmail.com (Kirk Pepperdine)
Date: Thu, 18 May 2017 16:46:45 +0900
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
Message-ID: <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>


> On May 18, 2017, at 6:15 AM, David Holmes  wrote:
> 
> On 18/05/2017 2:36 AM, Martin Buchholz wrote:
>> Stop trying to add APIs to mutate environment variables.  It's not going
>> to happen!
> 
> Not sure who or what you are directing this at Martin. Certainly I'm not suggesting any API to mutate environment variables. This is about an API to re-read an already potentially mutated external environment.
> 
>> There is no known way to mutate environment variables in a
>> multithreaded Unix process without risk of native crashes (and I have
>> worn the hat of poor support engineer trying to diagnose SEGV in
>> getenv).  IIRC we made the decision 13 years ago to cache the
>> environment on first access, and that was before the thread-unsafety of
>> putenv was fully appreciated.
>> 
>> Yes, Java still has a serious startup performance problem; that should
>> be attacked more directly.
> 
> ?? Not sure what startup has to do with the topic here.

The reason to use a daemon is to avoid multiple starts of a JVM in-between steps in a build. It is a great idea but the proposed implementation is at issue because it requires a highly questionable API be added to the JDK.

Kind regards,
Kirk


From david.holmes at oracle.com  Thu May 18 08:07:00 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 18:07:00 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
Message-ID: <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>



On 18/05/2017 5:46 PM, Kirk Pepperdine wrote:
>
>> On May 18, 2017, at 6:15 AM, David Holmes  wrote:
>>
>> On 18/05/2017 2:36 AM, Martin Buchholz wrote:
>>> Stop trying to add APIs to mutate environment variables.  It's not going
>>> to happen!
>>
>> Not sure who or what you are directing this at Martin. Certainly I'm not suggesting any API to mutate environment variables. This is about an API to re-read an already potentially mutated external environment.
>>
>>> There is no known way to mutate environment variables in a
>>> multithreaded Unix process without risk of native crashes (and I have
>>> worn the hat of poor support engineer trying to diagnose SEGV in
>>> getenv).  IIRC we made the decision 13 years ago to cache the
>>> environment on first access, and that was before the thread-unsafety of
>>> putenv was fully appreciated.
>>>
>>> Yes, Java still has a serious startup performance problem; that should
>>> be attacked more directly.
>>
>> ?? Not sure what startup has to do with the topic here.
>
> The reason to use a daemon is to avoid multiple starts of a JVM in-between steps in a build.

Yes, though I've been looking at this from the actual API proposal 
perspective, not the "how can we avoid the need for this API" perspective.

> It is a great idea but the proposed implementation is at issue because it requires a highly questionable API be added to the JDK.

I'm quite surprised by some of the reactions here. Given the read-once 
nature of System.getenv was never documented I expected most people to 
be surprised that it took a snapshot-on-first-use, and that reading the 
actual process environment at the time System.getenv was called would be 
the natural expectation as to how this API works.

Cheers,
David

> Kind regards,
> Kirk
>

From david.holmes at oracle.com  Thu May 18 08:14:49 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 18:14:49 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
Message-ID: 

Hi Cedric,

Starting a new sub-thread on this as I want to back up on something.

Can you elaborate as to why specifying the "big kill switch" 
--permit-illegal-access is not viable? Specifically if you use:

-XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access

it should work on 9 and be ignored on earlier releases.

Thanks,
David

On 11/05/2017 7:37 AM, C?dric Champeau wrote:
> Hi all,
>
> I'm writing this on behalf of the Gradle team. This email is closely
> related to the other thread just posted today, but just a timeline
> coincidence (just like the email exchange I had today about this with Alan
> Bateman ;)) and not exactly the same issue.
>
> We are in the process of making sure Gradle runs properly on JDK 9, but
> there's an issue which is unresolved so far, and probably requires a new
> API. It's described at [1], and I have discussed this at Devoxx France with
> R?mi Forax who suggested to post something here.
>
> In short, Gradle is a build tool which supports building a variety of
> different things, from Java to C++. The JVM happens to be its runtime
> environment, and Gradle has what we call the Gradle Daemon [2] which is a
> long running process, benefiting from the JIT, aimed at effectively running
> builds. When the build starts, a client connects to the daemon and sends a
> "build request". A daemon will run a single build at a time, and there are
> several cases which would trigger a new daemon to spawn (the daemon JVM
> arguments are one) but the environment variables are *not*. Since the
> daemon is a long running process, it is possible that the environment
> variables are mutated between the moment the daemon was spawned (in a
> previous build) and the moment the build is executed.
>
> What we do, now, is to send the environment variables of the client to the
> daemon, which *mutates* the existing environment variables map provided by
> System.getenv. This is exactly what is described in [1] as being sneaky (it
> is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
> However, there are valid use cases for this:
>
>    - in practice, environment variables are not immutable. It is especially
>    true for long running process.
>    - native programs can mutate the environment variables. Even if it's not
>    recommended, it is possible and legal.
>    - Gradle runs in a "blackbox": we don't know what plugins are doing.
>    Even if we provide an API which gives access to "environment variables",
>    and that those environment variables are not the ones returned by
>    System.getenv, plugin authors would have to use this new API to get
>    correct information. However, they may use libraries which access
>    System.getenv directly, or use native APIs which would get out-of-sync
>    information.
>    - we need to propagate the environment to forked process (typically,
>    forked compilers and worker daemons)
>
> This means that today, we use JNI to effectively mutate the environment
> variables of running process (that?s one of the purposes of the
> native-platform project). Then, we mutate the backing map of the JDK to
> reflect those changes, otherwise the mutation is not visible from Java code.
>
> What can we do now?
>
>    - Have the JDK honor the fact that environment variables *can* be
>    mutated, because it just happens. In short, don't create an immutable copy
>    of environment variables at startup, but provide a live view of the
>    environment variables (using the existing APIs, System.getenv, would be the
>    best thing because it would be immediately visible to all consumers,
>    including 3rd party code run in plugins). In addition (but not mandatory),
>    you could provide us with an API to set environment variables directly from
>    Java. This would avoid JNI calls to do this. However, it?s not mandatory,
>    because the live view of environment variables would just work in this case.
>    - Last, but we would really, really avoid to do this, spawn a new daemon
>    if we detect that the environment variables have changed (diff between what
>    the client has and the daemon sees). The major drawback of this approach is
>    that it kills performance, since a new daemon would have to be spawned. And
>    it is likely to do so each time something (through native code, for
>    example), mutates environment variables. A very simple example is
> the PWD environment
>    variables on Linux which contains the working directory. Basically changing
>    the directory would be enough to spawn a new daemon. Another example is the
>    TERM_SESSION_ID one, which means that 2 different terminals would force
>    us to spawn 2 different Gradle daemons. We could, of course, have a list of
>    ?blessed? environments variables that we don?t trust, but it?s very easily
>    broken, and no good design. That?s why, even if it?s possible, we don?t
>    consider this a solution.
>
> Thanks for considering our request, which is currently a blocker for us
> (understand, have Gradle running properly under JDK 9).
>
> [1] https://github.com/adammurdoch/native-platform/issues/16
> [2] https://docs.gradle.org/current/userguide/gradle_daemon.html
>

From cedric.champeau at gmail.com  Thu May 18 08:19:32 2017
From: cedric.champeau at gmail.com (=?UTF-8?Q?C=C3=A9dric_Champeau?=)
Date: Thu, 18 May 2017 10:19:32 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
Message-ID: 

>
>
> Can you elaborate as to why specifying the "big kill switch"
> --permit-illegal-access is not viable? Specifically if you use:
>
> -XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access
>
> it should work on 9 and be ignored on earlier releases.
>
>
mmm that's interesting, I actually forgot this flag exists. However, it's
an OpenJDK/Oracle JDK specific flag, right? (Thinking of users running IBM
JDK typically).


> Thanks,
> David
>
> On 11/05/2017 7:37 AM, C?dric Champeau wrote:
>
>> Hi all,
>>
>> I'm writing this on behalf of the Gradle team. This email is closely
>> related to the other thread just posted today, but just a timeline
>> coincidence (just like the email exchange I had today about this with Alan
>> Bateman ;)) and not exactly the same issue.
>>
>> We are in the process of making sure Gradle runs properly on JDK 9, but
>> there's an issue which is unresolved so far, and probably requires a new
>> API. It's described at [1], and I have discussed this at Devoxx France
>> with
>> R?mi Forax who suggested to post something here.
>>
>> In short, Gradle is a build tool which supports building a variety of
>> different things, from Java to C++. The JVM happens to be its runtime
>> environment, and Gradle has what we call the Gradle Daemon [2] which is a
>> long running process, benefiting from the JIT, aimed at effectively
>> running
>> builds. When the build starts, a client connects to the daemon and sends a
>> "build request". A daemon will run a single build at a time, and there are
>> several cases which would trigger a new daemon to spawn (the daemon JVM
>> arguments are one) but the environment variables are *not*. Since the
>> daemon is a long running process, it is possible that the environment
>> variables are mutated between the moment the daemon was spawned (in a
>> previous build) and the moment the build is executed.
>>
>> What we do, now, is to send the environment variables of the client to the
>> daemon, which *mutates* the existing environment variables map provided by
>> System.getenv. This is exactly what is described in [1] as being sneaky
>> (it
>> is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
>> However, there are valid use cases for this:
>>
>>    - in practice, environment variables are not immutable. It is
>> especially
>>    true for long running process.
>>    - native programs can mutate the environment variables. Even if it's
>> not
>>    recommended, it is possible and legal.
>>    - Gradle runs in a "blackbox": we don't know what plugins are doing.
>>    Even if we provide an API which gives access to "environment
>> variables",
>>    and that those environment variables are not the ones returned by
>>    System.getenv, plugin authors would have to use this new API to get
>>    correct information. However, they may use libraries which access
>>    System.getenv directly, or use native APIs which would get out-of-sync
>>    information.
>>    - we need to propagate the environment to forked process (typically,
>>    forked compilers and worker daemons)
>>
>> This means that today, we use JNI to effectively mutate the environment
>> variables of running process (that?s one of the purposes of the
>> native-platform project). Then, we mutate the backing map of the JDK to
>> reflect those changes, otherwise the mutation is not visible from Java
>> code.
>>
>> What can we do now?
>>
>>    - Have the JDK honor the fact that environment variables *can* be
>>    mutated, because it just happens. In short, don't create an immutable
>> copy
>>    of environment variables at startup, but provide a live view of the
>>    environment variables (using the existing APIs, System.getenv, would
>> be the
>>    best thing because it would be immediately visible to all consumers,
>>    including 3rd party code run in plugins). In addition (but not
>> mandatory),
>>    you could provide us with an API to set environment variables directly
>> from
>>    Java. This would avoid JNI calls to do this. However, it?s not
>> mandatory,
>>    because the live view of environment variables would just work in this
>> case.
>>    - Last, but we would really, really avoid to do this, spawn a new
>> daemon
>>    if we detect that the environment variables have changed (diff between
>> what
>>    the client has and the daemon sees). The major drawback of this
>> approach is
>>    that it kills performance, since a new daemon would have to be
>> spawned. And
>>    it is likely to do so each time something (through native code, for
>>    example), mutates environment variables. A very simple example is
>> the PWD environment
>>    variables on Linux which contains the working directory. Basically
>> changing
>>    the directory would be enough to spawn a new daemon. Another example
>> is the
>>    TERM_SESSION_ID one, which means that 2 different terminals would force
>>    us to spawn 2 different Gradle daemons. We could, of course, have a
>> list of
>>    ?blessed? environments variables that we don?t trust, but it?s very
>> easily
>>    broken, and no good design. That?s why, even if it?s possible, we don?t
>>    consider this a solution.
>>
>> Thanks for considering our request, which is currently a blocker for us
>> (understand, have Gradle running properly under JDK 9).
>>
>> [1] https://github.com/adammurdoch/native-platform/issues/16
>> [2] https://docs.gradle.org/current/userguide/gradle_daemon.html
>>
>>

From chris.hegarty at oracle.com  Thu May 18 08:25:42 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 18 May 2017 09:25:42 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
Message-ID: <8A666ED1-DC0F-43AE-B451-1122A5C498D8@oracle.com>


> On 18 May 2017, at 09:07, David Holmes  wrote:
>> ...
>> The reason to use a daemon is to avoid multiple starts of a JVM in-between steps in a build.
> 
> Yes, though I've been looking at this from the actual API proposal perspective, not the "how can we avoid the need for this API" perspective.
> 
>> It is a great idea but the proposed implementation is at issue because it requires a highly questionable API be added to the JDK.
> 
> I'm quite surprised by some of the reactions here. Given the read-once nature of System.getenv was never documented I expected most people to be surprised that it took a snapshot-on-first-use, and that reading the actual process environment at the time System.getenv was called would be the natural expectation as to how this API works.

Agreed. To make sure that the spec aspect of this doesn?t fall through
the cracks, I filed 8180592 [1] to track it.

To help move the discussion forward, I think it would be useful to at least
have an idea with a rough prototype of an API to refresh might look like.
To that end, I put together the following webrev:

  http://cr.openjdk.java.net/~chegar/refreshEnv/

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8180592

From scolebourne at joda.org  Thu May 18 08:35:23 2017
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 18 May 2017 09:35:23 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
Message-ID: 

On 18 May 2017 at 09:07, David Holmes  wrote:
> I'm quite surprised by some of the reactions here. Given the read-once
> nature of System.getenv was never documented I expected most people to be
> surprised that it took a snapshot-on-first-use, and that reading the actual
> process environment at the time System.getenv was called would be the
> natural expectation as to how this API works.

I agree with Daivid that my expectation for the method System.getenv
would be that it calls native code every time it is invoked assuming
that the Javadoc didn't say otherwise (because environment variables
are outside the Java universe). As such, the choice to snapshot looks
like a significant change in behaviour, and thus compatibility.

I also note the method getenv() - the one that returns a Map. It has
the Javadoc "Returns an unmodifiable string map view of the current
system environment". Note the word "current". I take that to imply
*now*. Again, this change seems incompatible. At the very least, the
specification is now wrong.

Stephen

From Alan.Bateman at oracle.com  Thu May 18 08:51:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 18 May 2017 09:51:17 +0100
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
 
 <5E2BE8A0-2DC5-44F8-B313-A0B0F0D1A579@gmail.com>
 <2afd1e96-5982-32f0-b51d-a2f1075c3783@oracle.com>
 
 <332516498.1759975.1495017936693.JavaMail.zimbra@u-pem.fr>
 <37d59cb0-6622-c3a7-c63a-06d084ed90cb@oracle.com>
 
 <25d898ec-5e01-8a9a-9704-1809bfd6ba15@oracle.com>
 <7005624A-D74B-4CD5-8825-C7994D3A6C63@gmail.com>
 <0d72cab0-b061-6f8d-3741-d7211bedb5ea@oracle.com>
 
Message-ID: 

On 18/05/2017 09:35, Stephen Colebourne wrote:

> :
> I agree with Daivid that my expectation for the method System.getenv
> would be that it calls native code every time it is invoked assuming
> that the Javadoc didn't say otherwise (because environment variables
> are outside the Java universe). As such, the choice to snapshot looks
> like a significant change in behaviour, and thus compatibility.
FWIW, this behavior goes back a long time, I think it was JDK 5 when 
this re-worked (by Martin). Since then there have been one or two 
"surprises" when something changes to call System.getenv earlier than 
before.

-Alan

From david.holmes at oracle.com  Thu May 18 09:30:27 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 19:30:27 +1000
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: 
References: 
 
 
Message-ID: <60ccc554-ca2c-f0d9-7c78-5e6d9520134f@oracle.com>

On 18/05/2017 6:19 PM, C?dric Champeau wrote:
>>
>>
>> Can you elaborate as to why specifying the "big kill switch"
>> --permit-illegal-access is not viable? Specifically if you use:
>>
>> -XX:+IgnoreUnrecognizedVMOptions --permit-illegal-access
>>
>> it should work on 9 and be ignored on earlier releases.
>>
>>
> mmm that's interesting, I actually forgot this flag exists. However, it's
> an OpenJDK/Oracle JDK specific flag, right? (Thinking of users running IBM
> JDK typically).

It's an OpenJDK flag, yes. But I would have expected there were already 
differences in how you launch an IBM JVM versus OpenJDK or Oracle JVM - no?

David

>
>> Thanks,
>> David
>>
>> On 11/05/2017 7:37 AM, C?dric Champeau wrote:
>>
>>> Hi all,
>>>
>>> I'm writing this on behalf of the Gradle team. This email is closely
>>> related to the other thread just posted today, but just a timeline
>>> coincidence (just like the email exchange I had today about this with Alan
>>> Bateman ;)) and not exactly the same issue.
>>>
>>> We are in the process of making sure Gradle runs properly on JDK 9, but
>>> there's an issue which is unresolved so far, and probably requires a new
>>> API. It's described at [1], and I have discussed this at Devoxx France
>>> with
>>> R?mi Forax who suggested to post something here.
>>>
>>> In short, Gradle is a build tool which supports building a variety of
>>> different things, from Java to C++. The JVM happens to be its runtime
>>> environment, and Gradle has what we call the Gradle Daemon [2] which is a
>>> long running process, benefiting from the JIT, aimed at effectively
>>> running
>>> builds. When the build starts, a client connects to the daemon and sends a
>>> "build request". A daemon will run a single build at a time, and there are
>>> several cases which would trigger a new daemon to spawn (the daemon JVM
>>> arguments are one) but the environment variables are *not*. Since the
>>> daemon is a long running process, it is possible that the environment
>>> variables are mutated between the moment the daemon was spawned (in a
>>> previous build) and the moment the build is executed.
>>>
>>> What we do, now, is to send the environment variables of the client to the
>>> daemon, which *mutates* the existing environment variables map provided by
>>> System.getenv. This is exactly what is described in [1] as being sneaky
>>> (it
>>> is) and broken in JDK 9 (since the underlying map doesn't exist anymore).
>>> However, there are valid use cases for this:
>>>
>>>    - in practice, environment variables are not immutable. It is
>>> especially
>>>    true for long running process.
>>>    - native programs can mutate the environment variables. Even if it's
>>> not
>>>    recommended, it is possible and legal.
>>>    - Gradle runs in a "blackbox": we don't know what plugins are doing.
>>>    Even if we provide an API which gives access to "environment
>>> variables",
>>>    and that those environment variables are not the ones returned by
>>>    System.getenv, plugin authors would have to use this new API to get
>>>    correct information. However, they may use libraries which access
>>>    System.getenv directly, or use native APIs which would get out-of-sync
>>>    information.
>>>    - we need to propagate the environment to forked process (typically,
>>>    forked compilers and worker daemons)
>>>
>>> This means that today, we use JNI to effectively mutate the environment
>>> variables of running process (that?s one of the purposes of the
>>> native-platform project). Then, we mutate the backing map of the JDK to
>>> reflect those changes, otherwise the mutation is not visible from Java
>>> code.
>>>
>>> What can we do now?
>>>
>>>    - Have the JDK honor the fact that environment variables *can* be
>>>    mutated, because it just happens. In short, don't create an immutable
>>> copy
>>>    of environment variables at startup, but provide a live view of the
>>>    environment variables (using the existing APIs, System.getenv, would
>>> be the
>>>    best thing because it would be immediately visible to all consumers,
>>>    including 3rd party code run in plugins). In addition (but not
>>> mandatory),
>>>    you could provide us with an API to set environment variables directly
>>> from
>>>    Java. This would avoid JNI calls to do this. However, it?s not
>>> mandatory,
>>>    because the live view of environment variables would just work in this
>>> case.
>>>    - Last, but we would really, really avoid to do this, spawn a new
>>> daemon
>>>    if we detect that the environment variables have changed (diff between
>>> what
>>>    the client has and the daemon sees). The major drawback of this
>>> approach is
>>>    that it kills performance, since a new daemon would have to be
>>> spawned. And
>>>    it is likely to do so each time something (through native code, for
>>>    example), mutates environment variables. A very simple example is
>>> the PWD environment
>>>    variables on Linux which contains the working directory. Basically
>>> changing
>>>    the directory would be enough to spawn a new daemon. Another example
>>> is the
>>>    TERM_SESSION_ID one, which means that 2 different terminals would force
>>>    us to spawn 2 different Gradle daemons. We could, of course, have a
>>> list of
>>>    ?blessed? environments variables that we don?t trust, but it?s very
>>> easily
>>>    broken, and no good design. That?s why, even if it?s possible, we don?t
>>>    consider this a solution.
>>>
>>> Thanks for considering our request, which is currently a blocker for us
>>> (understand, have Gradle running properly under JDK 9).
>>>
>>> [1] https://github.com/adammurdoch/native-platform/issues/16
>>> [2] https://docs.gradle.org/current/userguide/gradle_daemon.html
>>>
>>>

From daniel.fuchs at oracle.com  Thu May 18 09:58:53 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Thu, 18 May 2017 10:58:53 +0100
Subject: 9 (docs-only) RFR: 8180428: Clarify implementation note in Clock.java
 to match implementation changes made by JDK-8068730
Message-ID: <7622b53f-ac1b-5cb7-e442-cc1fd78986e9@oracle.com>

Hi,

Please find below a clarification of the implementation note
in Clock.java:

8180428: Clarify implementation note in Clock.java to match 
implementation changes made by JDK-8068730
https://bugs.openjdk.java.net/browse/JDK-8180428

The change below was already discussed here:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047671.html

-- daniel

Here is the proposed diff:

diff --git a/src/java.base/share/classes/java/time/Clock.java 
b/src/java.base/share/classes/java/time/Clock.java
--- a/src/java.base/share/classes/java/time/Clock.java
+++ b/src/java.base/share/classes/java/time/Clock.java
@@ -127,10 +127,13 @@
   * document whether or not they do support serialization.
   *
   * @implNote
- * The clock implementation provided here is based on {@link 
System#currentTimeMillis()}.
- * That method provides little to no guarantee about the accuracy of 
the clock.
- * Applications requiring a more accurate clock must implement this 
abstract class
- * themselves using a different external clock, such as an NTP server.
+ * The clock implementation provided here is based on the same 
underlying clock
+ * as {@link System#currentTimeMillis()}, but may have a precision 
finer than
+ * milliseconds if available.
+ * However, little to no guarantee is provided about the accuracy of the
+ * underlying clock. Applications requiring a more accurate clock must 
implement
+ * this abstract class themselves using a different external clock, 
such as an
+ * NTP server.
   *
   * @since 1.8
   */

From david.holmes at oracle.com  Thu May 18 10:51:06 2017
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 18 May 2017 20:51:06 +1000
Subject: 9 (docs-only) RFR: 8180428: Clarify implementation note in
 Clock.java to match implementation changes made by JDK-8068730
In-Reply-To: <7622b53f-ac1b-5cb7-e442-cc1fd78986e9@oracle.com>
References: <7622b53f-ac1b-5cb7-e442-cc1fd78986e9@oracle.com>
Message-ID: <5018791c-6ecf-728a-a5dd-d51c206f2a5b@oracle.com>

Still looks good to me!

Thanks,
David

On 18/05/2017 7:58 PM, Daniel Fuchs wrote:
> Hi,
>
> Please find below a clarification of the implementation note
> in Clock.java:
>
> 8180428: Clarify implementation note in Clock.java to match
> implementation changes made by JDK-8068730
> https://bugs.openjdk.java.net/browse/JDK-8180428
>
> The change below was already discussed here:
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047671.html
>
> -- daniel
>
> Here is the proposed diff:
>
> diff --git a/src/java.base/share/classes/java/time/Clock.java
> b/src/java.base/share/classes/java/time/Clock.java
> --- a/src/java.base/share/classes/java/time/Clock.java
> +++ b/src/java.base/share/classes/java/time/Clock.java
> @@ -127,10 +127,13 @@
>   * document whether or not they do support serialization.
>   *
>   * @implNote
> - * The clock implementation provided here is based on {@link
> System#currentTimeMillis()}.
> - * That method provides little to no guarantee about the accuracy of
> the clock.
> - * Applications requiring a more accurate clock must implement this
> abstract class
> - * themselves using a different external clock, such as an NTP server.
> + * The clock implementation provided here is based on the same
> underlying clock
> + * as {@link System#currentTimeMillis()}, but may have a precision
> finer than
> + * milliseconds if available.
> + * However, little to no guarantee is provided about the accuracy of the
> + * underlying clock. Applications requiring a more accurate clock must
> implement
> + * this abstract class themselves using a different external clock,
> such as an
> + * NTP server.
>   *
>   * @since 1.8
>   */

From christoph.langer at sap.com  Thu May 18 13:26:49 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 18 May 2017 13:26:49 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: <8c96fd99-cdb2-dc78-7c35-f46d5d181d91@oracle.com>
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
 <8c96fd99-cdb2-dc78-7c35-f46d5d181d91@oracle.com>
Message-ID: 

Hi Matthias,

I have added a jdk9-fix-request label to the bug and added a comment. Let's see if it gets approved for JDK9.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Dmitry Samersoff
> Sent: Dienstag, 16. Mai 2017 13:18
> To: Baesken, Matthias ; Alan Bateman
> ; core-libs-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> 
> Matthias,
> 
> Looks good to me.
> 
> -Dmitry
> 
> On 2017-05-16 13:21, Baesken, Matthias wrote:
> >  Sure, I forward it to  serviceability-dev .
> >
> > -----Original Message-----
> > From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> > Sent: Dienstag, 16. Mai 2017 11:51
> > To: Baesken, Matthias ; core-libs-
> dev at openjdk.java.net
> > Cc: Simonis, Volker 
> > Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> >
> >
> >
> > On 16/05/2017 10:04, Baesken, Matthias wrote:
> >> Hello, could you please review this small change :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
> >>
> >> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it
> is attempted to write to NULL .
> >>
> >> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> >>
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8180413
> >>
> >>
> > Can you bring this to serviceability-dev as that is the mailing list
> > where the JDWP agent is maintained?
> >
> > -Alan
> >
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

From matthias.baesken at sap.com  Thu May 18 13:39:15 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Thu, 18 May 2017 13:39:15 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: 
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
 <8c96fd99-cdb2-dc78-7c35-f46d5d181d91@oracle.com>
 
Message-ID: 

Great, thanks !

-----Original Message-----
From: Langer, Christoph 
Sent: Donnerstag, 18. Mai 2017 15:27
To: Baesken, Matthias 
Cc: Simonis, Volker ; Dmitry Samersoff ; core-libs-dev at openjdk.java.net; serviceability-dev-request at openjdk.java.net
Subject: RE: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Hi Matthias,

I have added a jdk9-fix-request label to the bug and added a comment. Let's see if it gets approved for JDK9.

Best regards
Christoph

> -----Original Message-----
> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On
> Behalf Of Dmitry Samersoff
> Sent: Dienstag, 16. Mai 2017 13:18
> To: Baesken, Matthias ; Alan Bateman
> ; core-libs-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> 
> Matthias,
> 
> Looks good to me.
> 
> -Dmitry
> 
> On 2017-05-16 13:21, Baesken, Matthias wrote:
> >  Sure, I forward it to  serviceability-dev .
> >
> > -----Original Message-----
> > From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> > Sent: Dienstag, 16. Mai 2017 11:51
> > To: Baesken, Matthias ; core-libs-
> dev at openjdk.java.net
> > Cc: Simonis, Volker 
> > Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> >
> >
> >
> > On 16/05/2017 10:04, Baesken, Matthias wrote:
> >> Hello, could you please review this small change :
> >>
> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
> >>
> >> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it
> is attempted to write to NULL .
> >>
> >> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
> >>
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8180413
> >>
> >>
> > Can you bring this to serviceability-dev as that is the mailing list
> > where the JDWP agent is maintained?
> >
> > -Alan
> >
> 
> 
> --
> Dmitry Samersoff
> Oracle Java development team, Saint Petersburg, Russia
> * I would love to change the world, but they won't give me the sources.

From paul.sandoz at oracle.com  Thu May 18 15:49:41 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 18 May 2017 08:49:41 -0700
Subject: RFR(XS): move FilterClassLoader and ParentLastURLClassLoader to
 top level testlibrary
In-Reply-To: <9B29C098-5420-4595-991D-AE8F466F3BA2@oracle.com>
References: <44B9E33B-2B83-4C28-B654-6667388A5AC6@oracle.com>
 <9B29C098-5420-4595-991D-AE8F466F3BA2@oracle.com>
Message-ID: <84800102-3431-4ED8-BB90-BE25CB221078@oracle.com>


> On 17 May 2017, at 17:02, Paul Sandoz  wrote:
> 
> Are these classes used? If not should they be deleted?
> 

+1 I found out that these classes are currently used in other places and it?s very convenient to keep ?em around in the right test library location.

Paul.

> Paul.
> 
>> On 16 May 2017, at 17:01, Igor Ignatyev  wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
>>> 200 lines changed: 101 ins; 99 del; 0 mod;
>> 
>> Hi all,
>> 
>> could you please review this small fix which move FilterClassLoader and ParentLastURLClassLoader class from jdk testlibrary to top level testlibrary?
>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180395/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180395
>> 
>> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327
>> 
>> Thanks,
>> -- Igor
> 


From brian.burkhalter at oracle.com  Thu May 18 16:03:32 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 18 May 2017 09:03:32 -0700
Subject: JDK 10 RFR of 8180519: Windows FILETIME should be converted to and
 from ULARGE_INTEGER not LARGE_INTEGER
Message-ID: <74C7B0DA-EDBD-4178-B17B-0DA54FF97FE8@oracle.com>

Please review this change at your convenience:

Issue:	https://bugs.openjdk.java.net/browse/JDK-8180519
Patch:	http://cr.openjdk.java.net/~bpb/8180519/webrev.00/

This change is probably inconsequential but does make the code consistent with the documentation linked to the issue.

Regression tests have been run successfully against the io and nio tests of the core test set.

Thanks,

Brian

From Roger.Riggs at Oracle.com  Thu May 18 16:58:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 18 May 2017 12:58:28 -0400
Subject: JDK 10 RFR of 8180519: Windows FILETIME should be converted to
 and from ULARGE_INTEGER not LARGE_INTEGER
In-Reply-To: <74C7B0DA-EDBD-4178-B17B-0DA54FF97FE8@oracle.com>
References: <74C7B0DA-EDBD-4178-B17B-0DA54FF97FE8@oracle.com>
Message-ID: <5429e85a-d9f4-4251-8dfd-65f20bf6843a@Oracle.com>

Hi Brian,

Looks fine,

Roger


On 5/18/2017 12:03 PM, Brian Burkhalter wrote:
> Please review this change at your convenience:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8180519
> Patch:	http://cr.openjdk.java.net/~bpb/8180519/webrev.00/
>
> This change is probably inconsequential but does make the code consistent with the documentation linked to the issue.
>
> Regression tests have been run successfully against the io and nio tests of the core test set.
>
> Thanks,
>
> Brian


From igor.ignatyev at oracle.com  Thu May 18 17:36:35 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 May 2017 10:36:35 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the
 top level test library
In-Reply-To: <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
References: 
 <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
Message-ID: 

Paul,

doh, too many review requests in parallel, thank you for providing the correct links.

yes, you are right j/l/m/ThreadMXBean/Locks test does not depend on jdk testlibrary anymore, I have cleaned it up and retested:

>   * @author  Mandy Chung
>   * @author  Jaroslav Bachorik
>   *
> - * @library /lib/testlibrary /test/lib
> + * @library /test/lib
>   *
> - * @build jdk.testlibrary.*
>   * @run main/othervm Locks
>   */
>  import java.lang.management.*;

Thanks,
-- Igor

> On May 17, 2017, at 5:13 PM, Paul Sandoz  wrote:
> 
> 
> It?s this one :-)
> 
>   https://bugs.openjdk.java.net/browse/JDK-8180399 
>   http://cr.openjdk.java.net/~iignatyev/8180399/webrev.00/ 
> 
> Does the Locks test need to depend on stuff in /lib/testlibrary ?
> 
> Paul.
> 
>> On 16 May 2017, at 21:21, Igor Ignatyev > wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html 
>>> 186 lines changed: 87 ins; 90 del; 9 mod; 
>> 
>> Hi all,
>> 
>> could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library?
>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180397
>> testing: affected tests
>> 
>> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327
>> 
>> Thanks,
>> -- Igor
>> 
>> 
> 


From igor.ignatyev at oracle.com  Thu May 18 18:19:43 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 May 2017 11:19:43 -0700
Subject: RFR(S) : 8180621 : remove jdk.testlibrary.management.InputArguments
Message-ID: <381245FC-A05B-40D6-BE1C-13BF2BDD01D1@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html
> 88 lines changed: 0 ins; 88 del; 0 mod;

Hi all,

there is no usage of jdk.testlibrary.management.InputArguments by jdk/test or any other tests, so this test library class can be removed.

webrev: http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180621
testing: tier{1,2,3} + grep -R InputArguments

-- Igor

From mandy.chung at oracle.com  Thu May 18 18:35:53 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 May 2017 11:35:53 -0700
Subject: RFR(S) : 8180621 : remove
 jdk.testlibrary.management.InputArguments
In-Reply-To: <381245FC-A05B-40D6-BE1C-13BF2BDD01D1@oracle.com>
References: <381245FC-A05B-40D6-BE1C-13BF2BDD01D1@oracle.com>
Message-ID: <1B7482FA-8F16-42FC-90DC-31D98476256C@oracle.com>


> On May 18, 2017, at 11:19 AM, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html
>> 88 lines changed: 0 ins; 88 del; 0 mod;
> 
> Hi all,
> 
> there is no usage of jdk.testlibrary.management.InputArguments by jdk/test or any other tests, so this test library class can be removed.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180621/webrev.00/index.html

+1

Mandy


From brent.christian at oracle.com  Thu May 18 18:43:40 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 18 May 2017 11:43:40 -0700
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
Message-ID: <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>

Hi, Brian

This looks fine to me.

This will get some good bake time in 10, a chance for incompatibilities 
(if any) to be revealed.

-Brent

On 5/17/17 1:54 PM, Brian Burkhalter wrote:
> Please review at your convenience:
>
> Issue:	https://bugs.openjdk.java.net/browse/JDK-8177809 Patch:
> http://cr.openjdk.java.net/~bpb/8177809/webrev.00/
>
> Change the native portion of the Unix implementation to use the full
> time structure available. Note that for macOS, at least with HFS
> Plus, this will not increase the accuracy as in that case dates are
> stored in unsigned 32-bit integers containing the number of seconds
> since midnight, January 1, 1904, GMT, therefore millisecond
> granularity is unavailable on that platform.
>
> To verify the results, regression test jobs without the patch were
> run against JDK 9 and with the patch against JDK 10. These tests
> verified that the change affects the value returned by
> File.lastModified() for linux_i586, linux_x64, solaris_sparcv9, and
> solaris_x64 making them be the same as that returned for windows_i586
> and windows_x64. The value returned on macOS is unchanged (running
> HFS+).
>
> One arguable objection to making this change is that it might be
> incompatible as some applications could depend on the value's being
> less accurate.
>
> Thanks,
>
> Brian
>

From brian.burkhalter at oracle.com  Thu May 18 19:23:03 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 18 May 2017 12:23:03 -0700
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
 <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
Message-ID: 

Hi Brent,

On May 18, 2017, at 11:43 AM, Brent Christian  wrote:

> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.

Good point - thanks!

Brian

From brian.burkhalter at oracle.com  Thu May 18 19:34:24 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 18 May 2017 12:34:24 -0700
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: 
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
 <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
 
Message-ID: 

Oh, I guess I need a +1 from a JDK10 Reviewer.

On May 18, 2017, at 12:23 PM, Brian Burkhalter  wrote:

> Hi Brent,
> 
> On May 18, 2017, at 11:43 AM, Brent Christian  wrote:
> 
>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
> 
> Good point - thanks!
> 
> Brian


From Roger.Riggs at Oracle.com  Thu May 18 19:35:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 18 May 2017 15:35:52 -0400
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: 
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
 <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
 
 
Message-ID: <0af72c65-d3ee-fd3f-2d39-974f19b4b83b@Oracle.com>

+1

On 5/18/2017 3:34 PM, Brian Burkhalter wrote:
> Oh, I guess I need a +1 from a JDK10 Reviewer.
>
> On May 18, 2017, at 12:23 PM, Brian Burkhalter  wrote:
>
>> Hi Brent,
>>
>> On May 18, 2017, at 11:43 AM, Brent Christian  wrote:
>>
>>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
>> Good point - thanks!
>>
>> Brian


From igor.ignatyev at oracle.com  Thu May 18 21:24:41 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 May 2017 14:24:41 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
Message-ID: 

Hi,

still looking for a Reviewer.

Cheers,
-- Igor 
> On May 15, 2017, at 2:00 PM, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
>> lines changed: 2 ins; 88 del; 6 mod; 
> 
> Hi all,
> 
> could you please review this small fix which removes TimeLimitedRunner class from jdk testlibrary? we have two TimeLimitedRunner classes one in jdk test library and another in the the toplevel test library, there is no difference b/w these two library classes (besides location and package name), so the tests were simply updated to use TimeLimitedRunner from the toplevel test library.
> 
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180386
> testing: affected tests (java/lang/invoke)
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8075327
> 
> Thanks,
> -- Igor


From mandy.chung at oracle.com  Thu May 18 21:34:16 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 May 2017 14:34:16 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
Message-ID: 


> On May 15, 2017, at 2:00 PM, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
>> lines changed: 2 ins; 88 del; 6 mod; 
> 
> Hi all,
> 
> could you please review this small fix which removes TimeLimitedRunner class from jdk testlibrary? we have two TimeLimitedRunner classes one in jdk test library and another in the the toplevel test library, there is no difference b/w these two library classes (besides location and package name), so the tests were simply updated to use TimeLimitedRunner from the toplevel test library.
> 
> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html

This comment is not related to the change.  The package name `jdk.test.lib.wrappers` is odd.  TimeLimitedRunner and InfiniteLoop classes could simply be in the jdk.test.lib package or jdk.test.lib.util package.

Mandy


From igor.ignatyev at oracle.com  Thu May 18 21:37:00 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 May 2017 14:37:00 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: 
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
 
Message-ID: <8E330394-02DF-4CC5-B822-C9226F9AAB9A@oracle.com>


> On May 18, 2017, at 2:34 PM, Mandy Chung  wrote:
>> On May 15, 2017, at 2:00 PM, Igor Ignatyev  wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
>>> lines changed: 2 ins; 88 del; 6 mod; 
>> 
>> Hi all,
>> 
>> could you please review this small fix which removes TimeLimitedRunner class from jdk testlibrary? we have two TimeLimitedRunner classes one in jdk test library and another in the the toplevel test library, there is no difference b/w these two library classes (besides location and package name), so the tests were simply updated to use TimeLimitedRunner from the toplevel test library.
>> 
>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180386/webrev.00/index.html
> 
> This comment is not related to the change.  The package name `jdk.test.lib.wrappers` is odd.  TimeLimitedRunner and InfiniteLoop classes could simply be in the jdk.test.lib package or jdk.test.lib.util package.
> 
> Mandy
> 

agree, I'll file an RFE to find a better package for TimeLimitedRunner and InfiniteLoop classes.

-- Igor


From mandy.chung at oracle.com  Thu May 18 21:41:09 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 May 2017 14:41:09 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: <8E330394-02DF-4CC5-B822-C9226F9AAB9A@oracle.com>
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
 
 <8E330394-02DF-4CC5-B822-C9226F9AAB9A@oracle.com>
Message-ID: 


> On May 18, 2017, at 2:37 PM, Igor Ignatyev  wrote:
> 
> 
>> On May 18, 2017, at 2:34 PM, Mandy Chung  wrote:
>> This comment is not related to the change.  The package name `jdk.test.lib.wrappers` is odd.  TimeLimitedRunner and InfiniteLoop classes could simply be in the jdk.test.lib package or jdk.test.lib.util package.
>> 
>> Mandy
>> 
> 
> agree, I'll file an RFE to find a better package for TimeLimitedRunner and InfiniteLoop classes.

Why not doing the rename with this patch?

Mandy


From igor.ignatyev at oracle.com  Thu May 18 21:49:17 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 18 May 2017 14:49:17 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: 
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
 
 <8E330394-02DF-4CC5-B822-C9226F9AAB9A@oracle.com>
 
Message-ID: 


> On May 18, 2017, at 2:41 PM, Mandy Chung  wrote:
> 
> 
>> On May 18, 2017, at 2:37 PM, Igor Ignatyev  wrote:
>> 
>> 
>>> On May 18, 2017, at 2:34 PM, Mandy Chung  wrote:
>>> This comment is not related to the change.  The package name `jdk.test.lib.wrappers` is odd.  TimeLimitedRunner and InfiniteLoop classes could simply be in the jdk.test.lib package or jdk.test.lib.util package.
>>> 
>>> Mandy
>>> 
>> 
>> agree, I'll file an RFE to find a better package for TimeLimitedRunner and InfiniteLoop classes.
> 
> Why not doing the rename with this patch?

there are hotspot tests which use jdk.test.lib.wrappers.TimeLimitedRunner and InfiniteLoop, so it will require changes in hotspot repo. I'd prefer to have removing classes from jdk testlibrary and renaming classes in top level testlibrary as separate patches for clarity purposes. 

-- Igor

From brent.christian at oracle.com  Thu May 18 22:59:44 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 18 May 2017 15:59:44 -0700
Subject: RFR 9 : 8180633 : Remove intermittent key from
 java/lang/ClassLoader/Assert.java
Message-ID: <10f1d99f-7e10-4448-ca84-74277e3ad324@oracle.com>

Hi,

The test:
   java/lang/ClassLoader/Assert.java

has been passing consistently on our automated test systems for quite a 
while.  The last recorded failure I found happened ~18 months ago.

I propose that the 'intermittent' jtreg key be removed from this test:

--
diff -r ee3280639210 test/java/lang/ClassLoader/Assert.java
--- a/test/java/lang/ClassLoader/Assert.java	Thu May 18 16:48:37 2017 +0000
+++ b/test/java/lang/ClassLoader/Assert.java	Thu May 18 15:50:23 2017 -0700
@@ -28,7 +28,7 @@
   * @run main/othervm Assert
   * @summary Test the assertion facility
   * @author Mike McCloskey
- * @key randomness intermittent
+ * @key randomness
   */

  import package1.*;
--

Thanks,
-Brent

From joe.darcy at oracle.com  Thu May 18 23:18:42 2017
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 18 May 2017 16:18:42 -0700
Subject: RFR 9 : 8180633 : Remove intermittent key from
 java/lang/ClassLoader/Assert.java
In-Reply-To: <10f1d99f-7e10-4448-ca84-74277e3ad324@oracle.com>
References: <10f1d99f-7e10-4448-ca84-74277e3ad324@oracle.com>
Message-ID: <591E2BD2.2070400@oracle.com>

Sounds fine Brent; thanks,

-Joe

On 5/18/2017 3:59 PM, Brent Christian wrote:
> Hi,
>
> The test:
>   java/lang/ClassLoader/Assert.java
>
> has been passing consistently on our automated test systems for quite 
> a while.  The last recorded failure I found happened ~18 months ago.
>
> I propose that the 'intermittent' jtreg key be removed from this test:
>
> -- 
> diff -r ee3280639210 test/java/lang/ClassLoader/Assert.java
> --- a/test/java/lang/ClassLoader/Assert.java    Thu May 18 16:48:37 
> 2017 +0000
> +++ b/test/java/lang/ClassLoader/Assert.java    Thu May 18 15:50:23 
> 2017 -0700
> @@ -28,7 +28,7 @@
>   * @run main/othervm Assert
>   * @summary Test the assertion facility
>   * @author Mike McCloskey
> - * @key randomness intermittent
> + * @key randomness
>   */
>
>  import package1.*;
> -- 
>
> Thanks,
> -Brent


From serguei.spitsyn at oracle.com  Fri May 19 00:17:40 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 18 May 2017 17:17:40 -0700
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: <444e21a8d38c42338fa5c38093a32e9c@sap.com>
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
Message-ID: <520c56a8-4379-e4b0-42ac-acde1939cc7b@oracle.com>

Hi Matthias,

The fix looks good to me.
It must be tested at least with the JTreg com/sun/jdi tests.
Do you need a sponsor?

Thanks,
Serguei



On 5/16/17 03:21, Baesken, Matthias wrote:
>   Sure, I forward it to  serviceability-dev .
>
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Dienstag, 16. Mai 2017 11:51
> To: Baesken, Matthias ; core-libs-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>
>
>
> On 16/05/2017 10:04, Baesken, Matthias wrote:
>> Hello, could you please review this small change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>>
>> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>>
>> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180413
>>
>>
> Can you bring this to serviceability-dev as that is the mailing list
> where the JDWP agent is maintained?
>
> -Alan


From felix.yang at oracle.com  Fri May 19 01:38:35 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 19 May 2017 09:38:35 +0800
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
In-Reply-To: 
References: 
Message-ID: 

Ping:)

-Felix
> On 16 May 2017, at 4:59 PM, Felix Yang  wrote:
> 
> Hi there,
> 
>    please review the new tests added for ServiceLoader updates for module system.
> 
> Test bug:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8087307
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/
> 
> Related product Changes:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8132026
> 
>    https://bugs.openjdk.java.net/browse/JDK-8047814
> 
> Thanks,
> 
> Felix
> 
> 


From amy.lu at oracle.com  Fri May 19 02:06:06 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 19 May 2017 10:06:06 +0800
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
In-Reply-To: 
References: 
 
Message-ID: <9c5ca3dd-7494-f6cb-a170-2973581edbcd@oracle.com>

Not a reviewer.

Just noticed that tests don't have @modules.
Is it better to include @modules when introducing new test?

Thanks,
Amy

On 5/19/17 9:38 AM, Felix Yang wrote:
> Ping:)
>
> -Felix
>> On 16 May 2017, at 4:59 PM, Felix Yang  wrote:
>>
>> Hi there,
>>
>>     please review the new tests added for ServiceLoader updates for module system.
>>
>> Test bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8087307
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/
>>
>> Related product Changes:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8132026
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8047814
>>
>> Thanks,
>>
>> Felix
>>
>>


From vyom.tewari at oracle.com  Fri May 19 04:05:23 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Fri, 19 May 2017 09:35:23 +0530
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: 
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
 <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
 
 
Message-ID: <8b42cca5-6eaa-c133-db62-e431b93e9179@oracle.com>

Hi Brian,

looks good to me, although i am not JDK10 reviewer, one minor comment i 
think you can combine the below two statements to one

rv = (jlong)sb.st_mtimespec.tv_sec * 1000;
rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; rv= 
(jlong)sb.st_mtimespec.tv_sec * 1000  +(jlong)sb.st_mtimespec.tv_nsec / 1000000;

Thanks,
Vyom


On Friday 19 May 2017 01:04 AM, Brian Burkhalter wrote:
> Oh, I guess I need a +1 from a JDK10 Reviewer.
>
> On May 18, 2017, at 12:23 PM, Brian Burkhalter  wrote:
>
>> Hi Brent,
>>
>> On May 18, 2017, at 11:43 AM, Brent Christian  wrote:
>>
>>> This will get some good bake time in 10, a chance for incompatibilities (if any) to be revealed.
>> Good point - thanks!
>>
>> Brian


From mandy.chung at oracle.com  Fri May 19 05:10:14 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 18 May 2017 22:10:14 -0700
Subject: RFR 9 : 8180633 : Remove intermittent key from
 java/lang/ClassLoader/Assert.java
In-Reply-To: <10f1d99f-7e10-4448-ca84-74277e3ad324@oracle.com>
References: <10f1d99f-7e10-4448-ca84-74277e3ad324@oracle.com>
Message-ID: <94F38A2F-67C3-426B-86BD-895499647817@oracle.com>

+1

Mandy

> On May 18, 2017, at 3:59 PM, Brent Christian  wrote:
> 
> Hi,
> 
> The test:
>  java/lang/ClassLoader/Assert.java
> 
> has been passing consistently on our automated test systems for quite a while.  The last recorded failure I found happened ~18 months ago.
> 
> I propose that the 'intermittent' jtreg key be removed from this test:
> 
> --
> diff -r ee3280639210 test/java/lang/ClassLoader/Assert.java
> --- a/test/java/lang/ClassLoader/Assert.java	Thu May 18 16:48:37 2017 +0000
> +++ b/test/java/lang/ClassLoader/Assert.java	Thu May 18 15:50:23 2017 -0700
> @@ -28,7 +28,7 @@
>  * @run main/othervm Assert
>  * @summary Test the assertion facility
>  * @author Mike McCloskey
> - * @key randomness intermittent
> + * @key randomness
>  */
> 
> import package1.*;
> --
> 
> Thanks,
> -Brent


From huaming.li at oracle.com  Fri May 19 05:57:44 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 19 May 2017 13:57:44 +0800
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
In-Reply-To: 
References: 
 
Message-ID: <52e0929c-6b65-7fd0-f06c-bc55112c100b@oracle.com>

Hi Felix,

I have some comments as below:


1. Possible test gaps for Locating Order
         1.1 providers in named module have high priority than providers 
in unnamed
         1.2 ServiceLoader.load?(ModuleLayer layer, Class service) is 
not tested
2. Possible test gap for automatic module, it is not tested

3. Could you remove unnecessary module dependency on java.scripting, 
replace it with a customized module or java.base? it will make your 
tests run under as many as conditions.

4. For [a|b]filesystem
     could you use URLStreamHandlerProvider rather than 
FileSystemProvider, it will make your test files(FileSystemForInstr, 
AFileSystem, BFileSystem) more simple.

5. MisUsesTest.java and missuse
     missuses: miss => mis? (missuses => mis.uses)
     Possible test gap: add similar use case for unnamed module?

6. OrderingWithInstrTest.java
     Could you use jtreg tag "driver RedefineModuleAgent" rather than 
"@run main/othervm OrderingWithInstrTest" to trigger the preparation of 
test? and move createAgentJar() and main() into RedefineModuleAgent.java.

7. ReloadTest.java
     The test success depends on execution order of tests, so need to 
add priority=N to every @Test method, or separate tests into 2 classes, 
one for negative, one for normal tests.

8. Some additional minor comments:
     8.1 split module name with ".", for e.g. multiprovides => 
multi.provides
     8.2 wrap long lines, and revert unnecessary wrapping too, in 
several files.
     8.3 correct indent, e.g. in PermissionTest.java
     8.4 Is default constructor "public ProviderX() { }" necessary in 
multi.ProviderX ?
     8.5 rename Service to OrderedService?

Thank you

-Hamlin


On 2017/5/19 9:38, Felix Yang wrote:
> Ping:)
>
> -Felix
>> On 16 May 2017, at 4:59 PM, Felix Yang  wrote:
>>
>> Hi there,
>>
>>     please review the new tests added for ServiceLoader updates for module system.
>>
>> Test bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8087307
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/
>>
>> Related product Changes:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8132026
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8047814
>>
>> Thanks,
>>
>> Felix
>>
>>


From blackdrag at gmx.org  Fri May 19 06:02:58 2017
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 19 May 2017 08:02:58 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <00f301d2ce6c$55611020$00233060$@apache.org>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org>
Message-ID: <591E8A92.1040000@gmx.org>

On 16.05.2017 19:46, Uwe Schindler wrote:
> Hi,
>
> I still don't understand why you need to change the environment variables of the actual process. I was talking with R?mi about that last week, and it's not obvious to me why you need that. Sure, it is easier to change the environment of the actual process and then spawn a child process for some non-java build tool like GCC or even another standalone java program with option fork=true. But: Why not use the ProcessBuilder API when spawning those childs? So you just add an "official" build API inside Gradle (an official one, documented that allows Gradle plugins to modify the environment variables for the current build running). If you missed to add such an API from the beginning (IMHO its essential for a build system like Gradle), then you now have to tell your users: "Sorry we did something wrong and all our (bad) hacks to allow you to change environment variables are no longer working in the future, so please change your code. We are so sorry!"

the daemon outlives the gradle call, and the next gradle call can be 
done in a changed environment, thus the need to update the daemon. 
Spawning a child process each time would be very bad for performance.

bye Jochen


From me at noctarius.com  Fri May 19 06:08:06 2017
From: me at noctarius.com (Noctarius)
Date: Fri, 19 May 2017 08:08:06 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <591E8A92.1040000@gmx.org>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org> <591E8A92.1040000@gmx.org>
Message-ID: <51CAC9F9-E6BA-4005-BC6C-D2FFFEF426E0@noctarius.com>

Hey Jochen, 

Couldn't the gradle call transfer his view of the environment? I know that's a workaround but it would solve the issue, wouldn't it? 

Chris 

On May 19, 2017 8:02:58 AM GMT+02:00, Jochen Theodorou  wrote:
>On 16.05.2017 19:46, Uwe Schindler wrote:
>> Hi,
>>
>> I still don't understand why you need to change the environment
>variables of the actual process. I was talking with R?mi about that
>last week, and it's not obvious to me why you need that. Sure, it is
>easier to change the environment of the actual process and then spawn a
>child process for some non-java build tool like GCC or even another
>standalone java program with option fork=true. But: Why not use the
>ProcessBuilder API when spawning those childs? So you just add an
>"official" build API inside Gradle (an official one, documented that
>allows Gradle plugins to modify the environment variables for the
>current build running). If you missed to add such an API from the
>beginning (IMHO its essential for a build system like Gradle), then you
>now have to tell your users: "Sorry we did something wrong and all our
>(bad) hacks to allow you to change environment variables are no longer
>working in the future, so please change your code. We are so sorry!"
>
>the daemon outlives the gradle call, and the next gradle call can be 
>done in a changed environment, thus the need to update the daemon. 
>Spawning a child process each time would be very bad for performance.
>
>bye Jochen

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

From blackdrag at gmx.org  Fri May 19 06:18:16 2017
From: blackdrag at gmx.org (Jochen Theodorou)
Date: Fri, 19 May 2017 08:18:16 +0200
Subject: Getting a live view of environment variables (Gradle and JDK 9)
In-Reply-To: <51CAC9F9-E6BA-4005-BC6C-D2FFFEF426E0@noctarius.com>
References: 
 <4b2f1d0d-bd7a-8bff-6a7c-0d28537ab42d@oracle.com>
 
 
 <00f301d2ce6c$55611020$00233060$@apache.org> <591E8A92.1040000@gmx.org>
 <51CAC9F9-E6BA-4005-BC6C-D2FFFEF426E0@noctarius.com>
Message-ID: <591E8E28.3010702@gmx.org>

On 19.05.2017 08:08, Noctarius wrote:
> Hey Jochen,
>
> Couldn't the gradle call transfer his view of the environment? I know
> that's a workaround but it would solve the issue, wouldn't it?

IMHO it could so by calling native code using posix functions. But what 
does it matter if getEnv is not updated? So you need to bytecode-rewrite 
that... and frankly, then you will no longer need the native code approach.

bye Jochen


From Alan.Bateman at oracle.com  Fri May 19 06:42:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 19 May 2017 07:42:48 +0100
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
In-Reply-To: 
References: 
 
Message-ID: <0d528fe7-bdb2-f1a2-b4b1-e74893f697e9@oracle.com>

On 19/05/2017 02:38, Felix Yang wrote:

> Ping:)
>
> -Felix
>
I have this on my list to see how it fits with the other tests that we 
did for SL in JDK 9. From a quick scan then some clean-up will be needed 
and I think we will need to change some of the service types to allow 
these tests be easily maintained.

-Alan

From brian.burkhalter at oracle.com  Fri May 19 14:36:44 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 May 2017 07:36:44 -0700
Subject: JDK 10 RFR of 8177809: File.lastModified() is losing milliseconds
 (always ends in 000)
In-Reply-To: <8b42cca5-6eaa-c133-db62-e431b93e9179@oracle.com>
References: <534EA4ED-36A3-45D1-8F6A-5ECE0F16D360@oracle.com>
 <817ce58b-7862-0a37-9c9e-a187ccdec4c8@oracle.com>
 
 
 <8b42cca5-6eaa-c133-db62-e431b93e9179@oracle.com>
Message-ID: <1C886656-2987-4A3C-AD72-169EE2277057@oracle.com>

Hi Vyom,

I agree with you but it?s already pushed and I doubt it is worth an issue just to make this small change.

Thanks,

Brian

On May 18, 2017, at 9:05 PM, Vyom Tewari  wrote:

> looks good to me, although i am not JDK10 reviewer, one minor comment i think you can combine the below two statements to one
> 
> rv = (jlong)sb.st_mtimespec.tv_sec * 1000;
> rv += (jlong)sb.st_mtimespec.tv_nsec / 1000000; rv= (jlong)sb.st_mtimespec.tv_sec * 1000  +(jlong)sb.st_mtimespec.tv_nsec / 1000000;


From stuart.marks at oracle.com  Fri May 19 16:37:47 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 19 May 2017 09:37:47 -0700
Subject: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files
Message-ID: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>

Hi all,

Please review this updated webrev [1] to migrate some collections 
technotes/guides into the JDK's javadoc doc-files.

This is an update of a webrev, previously reviewed. [2] In response to some 
comments from Mandy, I've removed the collections version history from this 
changeset. While I like having version history around, it does add clutter and 
more docs to keep maintained. I've also included some markup changes suggested 
by Brent Christian.

Thanks,

s'marks



[1] http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.1/

[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047082.html

From martinrb at google.com  Fri May 19 17:18:01 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 19 May 2017 10:18:01 -0700
Subject: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
References: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
Message-ID: 

Looks good.

Not sure what "the internationalization facility" is. My view is that this
package has "some" collection classes and "some" classes related to
internationalization.

On Fri, May 19, 2017 at 9:37 AM, Stuart Marks 
wrote:

> Hi all,
>
> Please review this updated webrev [1] to migrate some collections
> technotes/guides into the JDK's javadoc doc-files.
>
> This is an update of a webrev, previously reviewed. [2] In response to
> some comments from Mandy, I've removed the collections version history from
> this changeset. While I like having version history around, it does add
> clutter and more docs to keep maintained. I've also included some markup
> changes suggested by Brent Christian.
>
> Thanks,
>
> s'marks
>
>
>
> [1] http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.1/
>
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-Ap
> ril/047082.html
>

From martinrb at google.com  Fri May 19 17:19:39 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 19 May 2017 10:19:39 -0700
Subject: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: 
References: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
 
Message-ID: 

Oh, and very happy to see these files I contributed to long ago finally
make it into openjdk!

On Fri, May 19, 2017 at 10:18 AM, Martin Buchholz 
wrote:

> Looks good.
>
> Not sure what "the internationalization facility" is. My view is that
> this package has "some" collection classes and "some" classes related to
> internationalization.
>
> On Fri, May 19, 2017 at 9:37 AM, Stuart Marks 
> wrote:
>
>> Hi all,
>>
>> Please review this updated webrev [1] to migrate some collections
>> technotes/guides into the JDK's javadoc doc-files.
>>
>> This is an update of a webrev, previously reviewed. [2] In response to
>> some comments from Mandy, I've removed the collections version history from
>> this changeset. While I like having version history around, it does add
>> clutter and more docs to keep maintained. I've also included some markup
>> changes suggested by Brent Christian.
>>
>> Thanks,
>>
>> s'marks
>>
>>
>>
>> [1] http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.1/
>>
>> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-Ap
>> ril/047082.html
>>
>
>

From stuart.marks at oracle.com  Fri May 19 17:23:26 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 19 May 2017 10:23:26 -0700
Subject: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: 
References: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
 
Message-ID: 

On 5/19/17 10:18 AM, Martin Buchholz wrote:
> Not sure what "the internationalization facility" is. My view is that this
> package has "some" collection classes and "some" classes related to
> internationalization.

I'll reword that to mention "some internationalization support classes" or 
something similar.

s'marks


From igor.ignatyev at oracle.com  Fri May 19 17:43:54 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 May 2017 10:43:54 -0700
Subject: RFR(S) : 8180644: move jdk.testlibrary.NetworkConfiguration to the
 top level test library
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
> 698 lines changed: 287 ins; 376 del; 35 mod; 

Hi all,

could you please review this patch which moves NetworkConfiguration  class to the top level test library? there were two instances of NetworkConfiguration: one in jdk testlibrary, another in java/nio/channels/DatagramChannel. they are almost identical, the only significant difference is that *interfaces methods of the latter return only the interfaces which support multicast, the former has special methods for that. NetworkConfiguration has been moved to the top level library and the tests were updated accordingly. 

webrev: http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
JBS: https://bugs.openjdk.java.net/browse/JDK-8180644
testing: affected tests, :jdk_net, :jdk_nio

Thanks,
-- Igor

From dhiller at twitter.com  Thu May 18 20:57:50 2017
From: dhiller at twitter.com (Dean Hiller)
Date: Thu, 18 May 2017 14:57:50 -0600
Subject: curious if there is a Local.java in the works for CompletableFutures
 like scala has
Message-ID: 

Way more detail here...

http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context

So I was wondering if this was going to be added at some point to the jdk
as I could not figure out how to set something so it was still available on
the thread at a later time when traversing async thenCompose, thenAccept.

thanks,
Dean

From paul.sandoz at oracle.com  Fri May 19 18:58:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 May 2017 11:58:00 -0700
Subject: RFR(S) : 8180644: move jdk.testlibrary.NetworkConfiguration to
 the top level test library
In-Reply-To: 
References: 
Message-ID: <0C863E99-E668-4E98-907D-D4355E8AE562@oracle.com>


JoinLeave
?

  29  * @build jdk.test.lib.NetworkConfiguration

is this line required?


BasicMulticastTests
?

 210         NetworkInterface nif = config.ip6MulticastInterfaces().iterator().next();
 211         InetAddress anySource = config.ip4Addresses(nif).iterator().next();
 212         membershipKeyTests(nif, ip4Group, anySource);
 213         exceptionTests(nif);
 214
 215         // re-run the membership key tests with IPv6 if available
 216
 217         Iterator iter = config.ip6MulticastInterfaces().iterator();
 218         if (iter.hasNext()) {

#210 should be ip4

Paul.

> On 19 May 2017, at 10:43, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
>> 698 lines changed: 287 ins; 376 del; 35 mod;
> 
> Hi all,
> 
> could you please review this patch which moves NetworkConfiguration  class to the top level test library? there were two instances of NetworkConfiguration: one in jdk testlibrary, another in java/nio/channels/DatagramChannel. they are almost identical, the only significant difference is that *interfaces methods of the latter return only the interfaces which support multicast, the former has special methods for that. NetworkConfiguration has been moved to the top level library and the tests were updated accordingly.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180644
> testing: affected tests, :jdk_net, :jdk_nio
> 
> Thanks,
> -- Igor


From brian.burkhalter at oracle.com  Fri May 19 18:59:59 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 May 2017 11:59:59 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
Message-ID: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>

Please review at your convenience.

https://bugs.openjdk.java.net/browse/JDK-6791812

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
      * @return  A long value representing the time the file was
      *          last modified, measured in milliseconds since the epoch
      *          (00:00:00 GMT, January 1, 1970), or 0L if the
-     *          file does not exist or if an I/O error occurs
+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative in which case its absolute value indicates the
+     *          number of milliseconds before the epoch
      *
      * @throws  SecurityException
      *          If a security manager exists and its {@link

The weird thing here is that if this method were invoked on a file last modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the file does not exist or whether its last-modified time is the epoch. It seems to me that if the file does not exist it would be better to throw a FileNotFoundException but that is not an issue for JDK 9 at this stage of game.

Thanks,

Brian

From Roger.Riggs at Oracle.com  Fri May 19 19:08:08 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 19 May 2017 15:08:08 -0400
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
Message-ID: <11b8e16c-124c-61b2-3257-6ede17bae984@Oracle.com>

Hi Brian,

That looks ok.

The ambiguity (of zero) can't easily be resolved, but I would be inclined,
if the file exists and was created exactly at the epoch to bump the 
create time by 1.

Roger


On 5/19/2017 2:59 PM, Brian Burkhalter wrote:
> Please review at your convenience.
>
> https://bugs.openjdk.java.net/browse/JDK-6791812
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>        * @return  A long value representing the time the file was
>        *          last modified, measured in milliseconds since the epoch
>        *          (00:00:00 GMT, January 1, 1970), or 0L if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative in which case its absolute value indicates the
> +     *          number of milliseconds before the epoch
>        *
>        * @throws  SecurityException
>        *          If a security manager exists and its {@link
>
> The weird thing here is that if this method were invoked on a file last modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the file does not exist or whether its last-modified time is the epoch. It seems to me that if the file does not exist it would be better to throw a FileNotFoundException but that is not an issue for JDK 9 at this stage of game.
>
> Thanks,
>
> Brian


From brian.burkhalter at oracle.com  Fri May 19 19:12:22 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 19 May 2017 12:12:22 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <11b8e16c-124c-61b2-3257-6ede17bae984@Oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <11b8e16c-124c-61b2-3257-6ede17bae984@Oracle.com>
Message-ID: <1A14CB08-387F-4EB4-959F-023042DBB463@oracle.com>

Hi Roger,

On May 19, 2017, at 12:08 PM, Roger Riggs  wrote:

> That looks ok.

Thanks.

> The ambiguity (of zero) can't easily be resolved, but I would be inclined,
> if the file exists and was created exactly at the epoch to bump the create time by 1.

At least that would not be an incompatible change unlike throwing a FileNotFoundException. I doubt a lot of files with the exact epoch timestamp are encountered much at all anyway. In any case either of those solutions would be for JDK 10.

Brian

From igor.ignatyev at oracle.com  Fri May 19 19:55:14 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 May 2017 12:55:14 -0700
Subject: RFR(S) : 8180644: move jdk.testlibrary.NetworkConfiguration to
 the top level test library
In-Reply-To: <0C863E99-E668-4E98-907D-D4355E8AE562@oracle.com>
References: 
 <0C863E99-E668-4E98-907D-D4355E8AE562@oracle.com>
Message-ID: 

Hi Paul,

nice catches, I have corrected and rerun these two tests, here is the new webrev -- http://cr.openjdk.java.net/~iignatyev//8180644/webrev.01/index.html 

-- Igor

> On May 19, 2017, at 11:58 AM, Paul Sandoz  wrote:
> 
> 
> JoinLeave
> ?
> 
>  29  * @build jdk.test.lib.NetworkConfiguration
> 
> is this line required?
> 
> 
> BasicMulticastTests
> ?
> 
> 210         NetworkInterface nif = config.ip6MulticastInterfaces().iterator().next();
> 211         InetAddress anySource = config.ip4Addresses(nif).iterator().next();
> 212         membershipKeyTests(nif, ip4Group, anySource);
> 213         exceptionTests(nif);
> 214
> 215         // re-run the membership key tests with IPv6 if available
> 216
> 217         Iterator iter = config.ip6MulticastInterfaces().iterator();
> 218         if (iter.hasNext()) {
> 
> #210 should be ip4
> 
> Paul.
> 
>> On 19 May 2017, at 10:43, Igor Ignatyev  wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
>>> 698 lines changed: 287 ins; 376 del; 35 mod;
>> 
>> Hi all,
>> 
>> could you please review this patch which moves NetworkConfiguration  class to the top level test library? there were two instances of NetworkConfiguration: one in jdk testlibrary, another in java/nio/channels/DatagramChannel. they are almost identical, the only significant difference is that *interfaces methods of the latter return only the interfaces which support multicast, the former has special methods for that. NetworkConfiguration has been moved to the top level library and the tests were updated accordingly.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180644/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180644
>> testing: affected tests, :jdk_net, :jdk_nio
>> 
>> Thanks,
>> -- Igor
> 


From paul.sandoz at oracle.com  Fri May 19 19:59:00 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Fri, 19 May 2017 12:59:00 -0700
Subject: RFR(S) : 8180644: move jdk.testlibrary.NetworkConfiguration to
 the top level test library
In-Reply-To: 
References: 
 <0C863E99-E668-4E98-907D-D4355E8AE562@oracle.com>
 
Message-ID: <1ACECB4A-7F21-4056-A691-FE9EB3A1BAB2@oracle.com>


> On 19 May 2017, at 12:55, Igor Ignatyev  wrote:
> 
> Hi Paul,
> 
> nice catches, I have corrected and rerun these two tests, here is the new webrev -- http://cr.openjdk.java.net/~iignatyev//8180644/webrev.01/index.html 
+1

Paul.

From pavel.rappo at oracle.com  Fri May 19 20:16:04 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Fri, 19 May 2017 21:16:04 +0100
Subject: curious if there is a Local.java in the works for
 CompletableFutures like scala has
In-Reply-To: 
References: 
Message-ID: <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>

General questions on concurrency in Java should be asked here:

   http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

> On 18 May 2017, at 21:57, Dean Hiller  wrote:
> 
> Way more detail here...
> 
> http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context
> 
> So I was wondering if this was going to be added at some point to the jdk
> as I could not figure out how to set something so it was still available on
> the thread at a later time when traversing async thenCompose, thenAccept.
> 
> thanks,
> Dean


From joe.darcy at oracle.com  Fri May 19 21:31:58 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Fri, 19 May 2017 14:31:58 -0700
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
Message-ID: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>

Hello,

Please review the webrev to fix

     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
     http://cr.openjdk.java.net/~darcy/8074977.3/

To condense a complicated situation, there are cases where the number of 
parameters present for a constructor in source code and the number of 
parameters present for that constructor in the class file differ. One of 
those cases occurs for the constructor of a non-static member class [1] 
where there is a leading parameter to accept the outer this argument.

Bug JDK-8074977 reports on a situation where the type annotations on 
constructor parameters are incorrectly reported. Essentially, an 
off-by-one error is the cause since the annotation information is stored 
with respect to the number of parameters present in the source and an 
additional parameter is present at runtime.

An analogous situation exists for declaration annotations and 
constructor parameters, declaration annotations being the traditional 
flavor of annotations.

Type annotations and declaration annotations are read using different 
APIs so require separate fixes to detect the additional parameter and 
make the necessary adjustments in the returned information.

The regression tests cover both the type annotation reading API and the 
two ways of reading declaration annotations on parameters, calling 
getParameterAnnotations on the constructor or call getParameters on the 
constructor and then calling getAnnotations on each parameter. The 
getParameters API was added in JDK 8.

Static member and non-static member classes are used as test cases, as 
are constructors with and without generic type information.

Thanks,

-Joe

[1] 
https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes


From mandy.chung at oracle.com  Fri May 19 22:15:12 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 19 May 2017 15:15:12 -0700
Subject: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files
In-Reply-To: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
References: <75577e1b-e517-f1ef-975f-395dadb7bd46@oracle.com>
Message-ID: <2D2502C7-DE76-4594-AB52-0FDA6254C2FD@oracle.com>

Looks good.

Mandy

> On May 19, 2017, at 9:37 AM, Stuart Marks  wrote:
> 
> Hi all,
> 
> Please review this updated webrev [1] to migrate some collections technotes/guides into the JDK's javadoc doc-files.
> 
> This is an update of a webrev, previously reviewed. [2] In response to some comments from Mandy, I've removed the collections version history from this changeset. While I like having version history around, it does add clutter and more docs to keep maintained. I've also included some markup changes suggested by Brent Christian.
> 
> Thanks,
> 
> s'marks
> 
> 
> 
> [1] http://cr.openjdk.java.net/~smarks/reviews/8177788/webrev.1/
> 
> [2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047082.html


From igor.ignatyev at oracle.com  Fri May 19 23:29:04 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 19 May 2017 16:29:04 -0700
Subject: RFR(S) : 8180724: move ModuleInfoMaker to the top level testlibrary
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
> 295 lines changed: 139 ins; 140 del; 16 mod;

Hi all,

could you please review this small fix which moves ModuleInfoMaker class from jdk testlibrary to the top level testlibrary? since ModuleInfoMaker depends on CompilerUtil and thus on jdk.compiler module, it has been placed to jdk.test.lib.compiler package to avoid unneeded module dependency in tests. HashesTest has been updated to use ModuleInfoMaker::compile instead of using CompilerUtils::compile directly.

webrev: http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180724
testing: affected tests (jdk/test/tools/launcher)

Thanks,
-- Igor 

From peter.levart at gmail.com  Sat May 20 18:00:25 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 May 2017 20:00:25 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
Message-ID: 

Hi Joe,

So enum classes, anonymous classes and local classes don't have a 
standard way of passing synthetic/implicit constructor parameters? Do 
various compilers do it differently than javac?

It's unfortunate but if # of parameter annotations arrays is less than 
the # of parameters, Parameter.getAnnotations() may return wrong 
annotations or throw IndexOutOfBoundException for enums, anonymous and 
local classes. Can't we do anything for them? At least for code compiled 
by javac?

For example, javac compiles enum classes so that they always prefix 
constructor source parameters with a pair of (String name, int ordinal, 
...) and so do anonymous enum subclasses provided by enum constants 
(i.e. clazz.isAnonymousClass() && clazz.getSuperclass().isEnum())

Non-static local classes are compiled so that constructor source 
parameters are prefixed with a single parameter (OuterClass 
outerInstance, ...), while any captured variables follow source parameters

Static local classes are compiled so that constructor source parameters 
come 1st, followed by any captured variables.

etc...

Regards, Peter


On 05/19/2017 11:31 PM, joe darcy wrote:
> Hello,
>
> Please review the webrev to fix
>
>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong 
> value
>     http://cr.openjdk.java.net/~darcy/8074977.3/
>
> To condense a complicated situation, there are cases where the number 
> of parameters present for a constructor in source code and the number 
> of parameters present for that constructor in the class file differ. 
> One of those cases occurs for the constructor of a non-static member 
> class [1] where there is a leading parameter to accept the outer this 
> argument.
>
> Bug JDK-8074977 reports on a situation where the type annotations on 
> constructor parameters are incorrectly reported. Essentially, an 
> off-by-one error is the cause since the annotation information is 
> stored with respect to the number of parameters present in the source 
> and an additional parameter is present at runtime.
>
> An analogous situation exists for declaration annotations and 
> constructor parameters, declaration annotations being the traditional 
> flavor of annotations.
>
> Type annotations and declaration annotations are read using different 
> APIs so require separate fixes to detect the additional parameter and 
> make the necessary adjustments in the returned information.
>
> The regression tests cover both the type annotation reading API and 
> the two ways of reading declaration annotations on parameters, calling 
> getParameterAnnotations on the constructor or call getParameters on 
> the constructor and then calling getAnnotations on each parameter. The 
> getParameters API was added in JDK 8.
>
> Static member and non-static member classes are used as test cases, as 
> are constructors with and without generic type information.
>
> Thanks,
>
> -Joe
>
> [1] 
> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>


From peter.levart at gmail.com  Sat May 20 21:06:07 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 May 2017 23:06:07 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
Message-ID: <33c7880e-bf4d-5975-592b-9a564938ba10@gmail.com>

I see that local classes in static context don't have STATIC modifier. 
The same for anonymous classes. So there's no reliable information in 
the class file whether some local class is from the static context or not?

Regards, Peter

On 05/20/2017 08:00 PM, Peter Levart wrote:
> Hi Joe,
>
> So enum classes, anonymous classes and local classes don't have a 
> standard way of passing synthetic/implicit constructor parameters? Do 
> various compilers do it differently than javac?
>
> It's unfortunate but if # of parameter annotations arrays is less than 
> the # of parameters, Parameter.getAnnotations() may return wrong 
> annotations or throw IndexOutOfBoundException for enums, anonymous and 
> local classes. Can't we do anything for them? At least for code 
> compiled by javac?
>
> For example, javac compiles enum classes so that they always prefix 
> constructor source parameters with a pair of (String name, int 
> ordinal, ...) and so do anonymous enum subclasses provided by enum 
> constants (i.e. clazz.isAnonymousClass() && 
> clazz.getSuperclass().isEnum())
>
> Non-static local classes are compiled so that constructor source 
> parameters are prefixed with a single parameter (OuterClass 
> outerInstance, ...), while any captured variables follow source parameters
>
> Static local classes are compiled so that constructor source 
> parameters come 1st, followed by any captured variables.
>
> etc...
>
> Regards, Peter
>
>
> On 05/19/2017 11:31 PM, joe darcy wrote:
>> Hello,
>>
>> Please review the webrev to fix
>>
>>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong 
>> value
>> http://cr.openjdk.java.net/~darcy/8074977.3/
>>
>> To condense a complicated situation, there are cases where the number 
>> of parameters present for a constructor in source code and the number 
>> of parameters present for that constructor in the class file differ. 
>> One of those cases occurs for the constructor of a non-static member 
>> class [1] where there is a leading parameter to accept the outer this 
>> argument.
>>
>> Bug JDK-8074977 reports on a situation where the type annotations on 
>> constructor parameters are incorrectly reported. Essentially, an 
>> off-by-one error is the cause since the annotation information is 
>> stored with respect to the number of parameters present in the source 
>> and an additional parameter is present at runtime.
>>
>> An analogous situation exists for declaration annotations and 
>> constructor parameters, declaration annotations being the traditional 
>> flavor of annotations.
>>
>> Type annotations and declaration annotations are read using different 
>> APIs so require separate fixes to detect the additional parameter and 
>> make the necessary adjustments in the returned information.
>>
>> The regression tests cover both the type annotation reading API and 
>> the two ways of reading declaration annotations on parameters, 
>> calling getParameterAnnotations on the constructor or call 
>> getParameters on the constructor and then calling getAnnotations on 
>> each parameter. The getParameters API was added in JDK 8.
>>
>> Static member and non-static member classes are used as test cases, 
>> as are constructors with and without generic type information.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1] 
>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>>
>


From forax at univ-mlv.fr  Sat May 20 21:09:26 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 20 May 2017 23:09:26 +0200 (CEST)
Subject: JDK 9 RFR of JDK-8074977:
 Constructor.getAnnotatedParameterTypes returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
Message-ID: <1938852553.3765259.1495314566116.JavaMail.zimbra@u-pem.fr>

Hi Joe,
we had the same issue with ASM, we solve it without trying to detect every corner cases but by just comparing the number of parameter from the descriptor and the number of parameter (type?) annotations,
if there are less annotations, we add fake annotations at the starts of the array [1].

I don't remember the exact details but i'm pretty sure that at some point in the past ecj (the eclipse compiler) was generating more than one reference if you had an anonymous class inside an anonymous class.

ASM reports a special fake annotation "Ljava/lang/Synthetic;" so users can see that this is a synthetic parameter but i don't think it's a good idea to do that in the reflection API, ASM is more low level.

cheers,
R?mi 

[1] http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2FClassReader.java, in method readParameterAnnotations(). 

----- Mail original -----
> De: "Peter Levart" 
> ?: "joe darcy" , "core-libs-dev" 
> Envoy?: Samedi 20 Mai 2017 20:00:25
> Objet: Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value

> Hi Joe,
> 
> So enum classes, anonymous classes and local classes don't have a
> standard way of passing synthetic/implicit constructor parameters? Do
> various compilers do it differently than javac?
> 
> It's unfortunate but if # of parameter annotations arrays is less than
> the # of parameters, Parameter.getAnnotations() may return wrong
> annotations or throw IndexOutOfBoundException for enums, anonymous and
> local classes. Can't we do anything for them? At least for code compiled
> by javac?
> 
> For example, javac compiles enum classes so that they always prefix
> constructor source parameters with a pair of (String name, int ordinal,
> ...) and so do anonymous enum subclasses provided by enum constants
> (i.e. clazz.isAnonymousClass() && clazz.getSuperclass().isEnum())
> 
> Non-static local classes are compiled so that constructor source
> parameters are prefixed with a single parameter (OuterClass
> outerInstance, ...), while any captured variables follow source parameters
> 
> Static local classes are compiled so that constructor source parameters
> come 1st, followed by any captured variables.
> 
> etc...
> 
> Regards, Peter
> 
> 
> On 05/19/2017 11:31 PM, joe darcy wrote:
>> Hello,
>>
>> Please review the webrev to fix
>>
>>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong
>> value
>>     http://cr.openjdk.java.net/~darcy/8074977.3/
>>
>> To condense a complicated situation, there are cases where the number
>> of parameters present for a constructor in source code and the number
>> of parameters present for that constructor in the class file differ.
>> One of those cases occurs for the constructor of a non-static member
>> class [1] where there is a leading parameter to accept the outer this
>> argument.
>>
>> Bug JDK-8074977 reports on a situation where the type annotations on
>> constructor parameters are incorrectly reported. Essentially, an
>> off-by-one error is the cause since the annotation information is
>> stored with respect to the number of parameters present in the source
>> and an additional parameter is present at runtime.
>>
>> An analogous situation exists for declaration annotations and
>> constructor parameters, declaration annotations being the traditional
>> flavor of annotations.
>>
>> Type annotations and declaration annotations are read using different
>> APIs so require separate fixes to detect the additional parameter and
>> make the necessary adjustments in the returned information.
>>
>> The regression tests cover both the type annotation reading API and
>> the two ways of reading declaration annotations on parameters, calling
>> getParameterAnnotations on the constructor or call getParameters on
>> the constructor and then calling getAnnotations on each parameter. The
>> getParameters API was added in JDK 8.
>>
>> Static member and non-static member classes are used as test cases, as
>> are constructors with and without generic type information.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1]
>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes

From peter.levart at gmail.com  Sat May 20 21:30:58 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 May 2017 23:30:58 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: <1938852553.3765259.1495314566116.JavaMail.zimbra@u-pem.fr>
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
 <1938852553.3765259.1495314566116.JavaMail.zimbra@u-pem.fr>
Message-ID: 

Hi Remi

On 05/20/2017 11:09 PM, Remi Forax wrote:
> Hi Joe,
> we had the same issue with ASM, we solve it without trying to detect every corner cases but by just comparing the number of parameter from the descriptor and the number of parameter (type?) annotations,
> if there are less annotations, we add fake annotations at the starts of the array [1].
>
> I don't remember the exact details but i'm pretty sure that at some point in the past ecj (the eclipse compiler) was generating more than one reference if you had an anonymous class inside an anonymous class.
>
> ASM reports a special fake annotation "Ljava/lang/Synthetic;" so users can see that this is a synthetic parameter but i don't think it's a good idea to do that in the reflection API, ASM is more low level.
>
> cheers,
> R?mi
>
> [1] http://websvn.ow2.org/filedetails.php?repname=asm&path=%2Ftrunk%2Fasm%2Fsrc%2Forg%2Fobjectweb%2Fasm%2FClassReader.java, in method readParameterAnnotations().
         // ... This work-around supposes that the synthetic parameters 
are the first ones.
         int synthetics = Type.getArgumentTypes(context.desc).length - n;

Not always for local and anonymous classes. Captured values are appended 
to the parameter list. Source-level parameters are therefore between the 
outer instance and the captured values.

And if local or anonymous class is in the static context, there's no 
outer instance parameter, just captured values which are appended.

Here's what I was trying to do but then I found that local and anonymous 
classes never have STATIC modifier even if they are from static context:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8074977_ConstructorParameterAnnotations/webrev.01/

If there was a reliable way to determine whether a local or anonymous 
class is from static context or not, then this could work for javac 
generated code at least.

Regards, Peter

> ----- Mail original -----
>> De: "Peter Levart" 
>> ?: "joe darcy" , "core-libs-dev" 
>> Envoy?: Samedi 20 Mai 2017 20:00:25
>> Objet: Re: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
>> Hi Joe,
>>
>> So enum classes, anonymous classes and local classes don't have a
>> standard way of passing synthetic/implicit constructor parameters? Do
>> various compilers do it differently than javac?
>>
>> It's unfortunate but if # of parameter annotations arrays is less than
>> the # of parameters, Parameter.getAnnotations() may return wrong
>> annotations or throw IndexOutOfBoundException for enums, anonymous and
>> local classes. Can't we do anything for them? At least for code compiled
>> by javac?
>>
>> For example, javac compiles enum classes so that they always prefix
>> constructor source parameters with a pair of (String name, int ordinal,
>> ...) and so do anonymous enum subclasses provided by enum constants
>> (i.e. clazz.isAnonymousClass() && clazz.getSuperclass().isEnum())
>>
>> Non-static local classes are compiled so that constructor source
>> parameters are prefixed with a single parameter (OuterClass
>> outerInstance, ...), while any captured variables follow source parameters
>>
>> Static local classes are compiled so that constructor source parameters
>> come 1st, followed by any captured variables.
>>
>> etc...
>>
>> Regards, Peter
>>
>>
>> On 05/19/2017 11:31 PM, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the webrev to fix
>>>
>>>      JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong
>>> value
>>>      http://cr.openjdk.java.net/~darcy/8074977.3/
>>>
>>> To condense a complicated situation, there are cases where the number
>>> of parameters present for a constructor in source code and the number
>>> of parameters present for that constructor in the class file differ.
>>> One of those cases occurs for the constructor of a non-static member
>>> class [1] where there is a leading parameter to accept the outer this
>>> argument.
>>>
>>> Bug JDK-8074977 reports on a situation where the type annotations on
>>> constructor parameters are incorrectly reported. Essentially, an
>>> off-by-one error is the cause since the annotation information is
>>> stored with respect to the number of parameters present in the source
>>> and an additional parameter is present at runtime.
>>>
>>> An analogous situation exists for declaration annotations and
>>> constructor parameters, declaration annotations being the traditional
>>> flavor of annotations.
>>>
>>> Type annotations and declaration annotations are read using different
>>> APIs so require separate fixes to detect the additional parameter and
>>> make the necessary adjustments in the returned information.
>>>
>>> The regression tests cover both the type annotation reading API and
>>> the two ways of reading declaration annotations on parameters, calling
>>> getParameterAnnotations on the constructor or call getParameters on
>>> the constructor and then calling getAnnotations on each parameter. The
>>> getParameters API was added in JDK 8.
>>>
>>> Static member and non-static member classes are used as test cases, as
>>> are constructors with and without generic type information.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> [1]
>>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes


From joe.darcy at oracle.com  Sat May 20 21:38:29 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Sat, 20 May 2017 14:38:29 -0700
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
Message-ID: <5d5bdf2e-c384-fba9-ed5a-e450387418af@oracle.com>

Hi Peter,


On 5/20/2017 11:00 AM, Peter Levart wrote:
> Hi Joe,
>
> So enum classes, anonymous classes and local classes don't have a 
> standard way of passing synthetic/implicit constructor parameters?

Right; there is no standardized or mandated way for compilers to do 
that. Such details are intentionally outside of what the JLS specifies.

Since non-static member classes can be referred to and instances 
instantiated from outside of the enclosing class, there has to be a 
standardized linkage model in that case for separate compilation, etc. 
and that is covered in the JLS. This isn't the case for local and 
anonymous classes since there isn't a way to refer to such classes from 
outside of their immediate declaration context. The instances of such 
types can be returned of course and then it is possible for people to 
getClass().getConstructors()... their way into the issue.


> Do various compilers do it differently than javac?

IIRC, ecj does compile enum classes differently than javac.

>
> It's unfortunate but if # of parameter annotations arrays is less than 
> the # of parameters, Parameter.getAnnotations() may return wrong 
> annotations or throw IndexOutOfBoundException for enums, anonymous and 
> local classes. Can't we do anything for them? At least for code 
> compiled by javac?
>
> For example, javac compiles enum classes so that they always prefix 
> constructor source parameters with a pair of (String name, int 
> ordinal, ...) and so do anonymous enum subclasses provided by enum 
> constants (i.e. clazz.isAnonymousClass() && 
> clazz.getSuperclass().isEnum())
>
> Non-static local classes are compiled so that constructor source 
> parameters are prefixed with a single parameter (OuterClass 
> outerInstance, ...), while any captured variables follow source parameters

A wrinkle with local classes is that if they occur in a static context, 
such as a static initializer block, there is no leading outer instance 
parameter.

This is admittedly not a 100% solution to parameter mismatches and 
annotations; however, it is an improvement over the current state of 
affairs.

Ideally, the code for something like Parameters.getAnnotations could do 
something like look at the synthetic bit and pair up natural parameters 
with annotations if there was a mismatch in the number of parameters and 
annotations. Unfortunately, the Parameters.isSynthetic API wasn't 
introduced until JDK 8 and that information doesn't have to be available.

Cheers,

-Joe

>
> Static local classes are compiled so that constructor source 
> parameters come 1st, followed by any captured variables.
>
> etc...
>
> Regards, Peter
>
>
> On 05/19/2017 11:31 PM, joe darcy wrote:
>> Hello,
>>
>> Please review the webrev to fix
>>
>>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong 
>> value
>> http://cr.openjdk.java.net/~darcy/8074977.3/
>>
>> To condense a complicated situation, there are cases where the number 
>> of parameters present for a constructor in source code and the number 
>> of parameters present for that constructor in the class file differ. 
>> One of those cases occurs for the constructor of a non-static member 
>> class [1] where there is a leading parameter to accept the outer this 
>> argument.
>>
>> Bug JDK-8074977 reports on a situation where the type annotations on 
>> constructor parameters are incorrectly reported. Essentially, an 
>> off-by-one error is the cause since the annotation information is 
>> stored with respect to the number of parameters present in the source 
>> and an additional parameter is present at runtime.
>>
>> An analogous situation exists for declaration annotations and 
>> constructor parameters, declaration annotations being the traditional 
>> flavor of annotations.
>>
>> Type annotations and declaration annotations are read using different 
>> APIs so require separate fixes to detect the additional parameter and 
>> make the necessary adjustments in the returned information.
>>
>> The regression tests cover both the type annotation reading API and 
>> the two ways of reading declaration annotations on parameters, 
>> calling getParameterAnnotations on the constructor or call 
>> getParameters on the constructor and then calling getAnnotations on 
>> each parameter. The getParameters API was added in JDK 8.
>>
>> Static member and non-static member classes are used as test cases, 
>> as are constructors with and without generic type information.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1] 
>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>>
>


From peter.levart at gmail.com  Sat May 20 21:38:53 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 May 2017 23:38:53 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
 <1938852553.3765259.1495314566116.JavaMail.zimbra@u-pem.fr>
 
Message-ID: 



On 05/20/2017 11:30 PM, Peter Levart wrote:
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8074977_ConstructorParameterAnnotations/webrev.01/
>
> If there was a reliable way to determine whether a local or anonymous 
> class is from static context or not, then this could work for javac 
> generated code at least.
>

... it works for member classes and for enum classes and enum constant 
anonymous subclasses. Only local and anonymous classes are problematic...

Peter



From peter.levart at gmail.com  Sat May 20 21:48:23 2017
From: peter.levart at gmail.com (Peter Levart)
Date: Sat, 20 May 2017 23:48:23 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: <5d5bdf2e-c384-fba9-ed5a-e450387418af@oracle.com>
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
 <5d5bdf2e-c384-fba9-ed5a-e450387418af@oracle.com>
Message-ID: 

Hi Joe,

Thanks for explanation.

Regarding your patch. Take a look here:

http://cr.openjdk.java.net/~plevart/jdk9-dev/8074977_ConstructorParameterAnnotations/webrev.01/

I just want to point out that the logic could be centralized for 
classical and type annotations. What do you think?


Regards, Peter


On 05/20/2017 11:38 PM, joe darcy wrote:
> Hi Peter,
>
>
> On 5/20/2017 11:00 AM, Peter Levart wrote:
>> Hi Joe,
>>
>> So enum classes, anonymous classes and local classes don't have a 
>> standard way of passing synthetic/implicit constructor parameters?
>
> Right; there is no standardized or mandated way for compilers to do 
> that. Such details are intentionally outside of what the JLS specifies.
>
> Since non-static member classes can be referred to and instances 
> instantiated from outside of the enclosing class, there has to be a 
> standardized linkage model in that case for separate compilation, etc. 
> and that is covered in the JLS. This isn't the case for local and 
> anonymous classes since there isn't a way to refer to such classes 
> from outside of their immediate declaration context. The instances of 
> such types can be returned of course and then it is possible for 
> people to getClass().getConstructors()... their way into the issue.
>
>
>> Do various compilers do it differently than javac?
>
> IIRC, ecj does compile enum classes differently than javac.
>
>>
>> It's unfortunate but if # of parameter annotations arrays is less 
>> than the # of parameters, Parameter.getAnnotations() may return wrong 
>> annotations or throw IndexOutOfBoundException for enums, anonymous 
>> and local classes. Can't we do anything for them? At least for code 
>> compiled by javac?
>>
>> For example, javac compiles enum classes so that they always prefix 
>> constructor source parameters with a pair of (String name, int 
>> ordinal, ...) and so do anonymous enum subclasses provided by enum 
>> constants (i.e. clazz.isAnonymousClass() && 
>> clazz.getSuperclass().isEnum())
>>
>> Non-static local classes are compiled so that constructor source 
>> parameters are prefixed with a single parameter (OuterClass 
>> outerInstance, ...), while any captured variables follow source 
>> parameters
>
> A wrinkle with local classes is that if they occur in a static 
> context, such as a static initializer block, there is no leading outer 
> instance parameter.
>
> This is admittedly not a 100% solution to parameter mismatches and 
> annotations; however, it is an improvement over the current state of 
> affairs.
>
> Ideally, the code for something like Parameters.getAnnotations could 
> do something like look at the synthetic bit and pair up natural 
> parameters with annotations if there was a mismatch in the number of 
> parameters and annotations. Unfortunately, the Parameters.isSynthetic 
> API wasn't introduced until JDK 8 and that information doesn't have to 
> be available.
>
> Cheers,
>
> -Joe
>
>>
>> Static local classes are compiled so that constructor source 
>> parameters come 1st, followed by any captured variables.
>>
>> etc...
>>
>> Regards, Peter
>>
>>
>> On 05/19/2017 11:31 PM, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the webrev to fix
>>>
>>>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns 
>>> wrong value
>>> http://cr.openjdk.java.net/~darcy/8074977.3/
>>>
>>> To condense a complicated situation, there are cases where the 
>>> number of parameters present for a constructor in source code and 
>>> the number of parameters present for that constructor in the class 
>>> file differ. One of those cases occurs for the constructor of a 
>>> non-static member class [1] where there is a leading parameter to 
>>> accept the outer this argument.
>>>
>>> Bug JDK-8074977 reports on a situation where the type annotations on 
>>> constructor parameters are incorrectly reported. Essentially, an 
>>> off-by-one error is the cause since the annotation information is 
>>> stored with respect to the number of parameters present in the 
>>> source and an additional parameter is present at runtime.
>>>
>>> An analogous situation exists for declaration annotations and 
>>> constructor parameters, declaration annotations being the 
>>> traditional flavor of annotations.
>>>
>>> Type annotations and declaration annotations are read using 
>>> different APIs so require separate fixes to detect the additional 
>>> parameter and make the necessary adjustments in the returned 
>>> information.
>>>
>>> The regression tests cover both the type annotation reading API and 
>>> the two ways of reading declaration annotations on parameters, 
>>> calling getParameterAnnotations on the constructor or call 
>>> getParameters on the constructor and then calling getAnnotations on 
>>> each parameter. The getParameters API was added in JDK 8.
>>>
>>> Static member and non-static member classes are used as test cases, 
>>> as are constructors with and without generic type information.
>>>
>>> Thanks,
>>>
>>> -Joe
>>>
>>> [1] 
>>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>>>
>>
>


From joe.darcy at oracle.com  Sun May 21 00:23:28 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Sat, 20 May 2017 17:23:28 -0700
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
 <5d5bdf2e-c384-fba9-ed5a-e450387418af@oracle.com>
 
Message-ID: <23461b69-aaa9-f783-f770-f73e07ed7ed3@oracle.com>

Hi Peter,

Yours is a more ambitious attempt to more fully resolve this issue. It 
would likely nearly always work in practice, at least for 
javac-generated class files.

However, at this stage of JDK 9, I'd be more comfortable with something 
like the point fixes in my current patch, deferring a more complete 
solution to JDK 10. At that point, I think a two-stage fall back would 
be more complete: if the number of parameters differs, first try to see 
if java.lang.reflect.Parameter.{isSynthetic, isImplicit} information is 
available and if it is, use it accordingly. Otherwise, use the sort of 
case analysis present in the patch.

FWIW, on the javax.lang.model side of reflective APIs, in JDK 9 we added 
notions in the API to describe these sorts of differences in the 
javax.lang.model.util.Elements.Origin enum:

http://download.java.net/java/jdk9/docs/api/javax/lang/model/util/Elements.Origin.html

and the Elements.getOrigin methods which return that type.

Thanks,

-Joe


On 5/20/2017 2:48 PM, Peter Levart wrote:
> Hi Joe,
>
> Thanks for explanation.
>
> Regarding your patch. Take a look here:
>
> http://cr.openjdk.java.net/~plevart/jdk9-dev/8074977_ConstructorParameterAnnotations/webrev.01/
>
> I just want to point out that the logic could be centralized for 
> classical and type annotations. What do you think?
>
>
> Regards, Peter
>
>
> On 05/20/2017 11:38 PM, joe darcy wrote:
>> Hi Peter,
>>
>>
>> On 5/20/2017 11:00 AM, Peter Levart wrote:
>>> Hi Joe,
>>>
>>> So enum classes, anonymous classes and local classes don't have a 
>>> standard way of passing synthetic/implicit constructor parameters?
>>
>> Right; there is no standardized or mandated way for compilers to do 
>> that. Such details are intentionally outside of what the JLS specifies.
>>
>> Since non-static member classes can be referred to and instances 
>> instantiated from outside of the enclosing class, there has to be a 
>> standardized linkage model in that case for separate compilation, 
>> etc. and that is covered in the JLS. This isn't the case for local 
>> and anonymous classes since there isn't a way to refer to such 
>> classes from outside of their immediate declaration context. The 
>> instances of such types can be returned of course and then it is 
>> possible for people to getClass().getConstructors()... their way into 
>> the issue.
>>
>>
>>> Do various compilers do it differently than javac?
>>
>> IIRC, ecj does compile enum classes differently than javac.
>>
>>>
>>> It's unfortunate but if # of parameter annotations arrays is less 
>>> than the # of parameters, Parameter.getAnnotations() may return 
>>> wrong annotations or throw IndexOutOfBoundException for enums, 
>>> anonymous and local classes. Can't we do anything for them? At least 
>>> for code compiled by javac?
>>>
>>> For example, javac compiles enum classes so that they always prefix 
>>> constructor source parameters with a pair of (String name, int 
>>> ordinal, ...) and so do anonymous enum subclasses provided by enum 
>>> constants (i.e. clazz.isAnonymousClass() && 
>>> clazz.getSuperclass().isEnum())
>>>
>>> Non-static local classes are compiled so that constructor source 
>>> parameters are prefixed with a single parameter (OuterClass 
>>> outerInstance, ...), while any captured variables follow source 
>>> parameters
>>
>> A wrinkle with local classes is that if they occur in a static 
>> context, such as a static initializer block, there is no leading 
>> outer instance parameter.
>>
>> This is admittedly not a 100% solution to parameter mismatches and 
>> annotations; however, it is an improvement over the current state of 
>> affairs.
>>
>> Ideally, the code for something like Parameters.getAnnotations could 
>> do something like look at the synthetic bit and pair up natural 
>> parameters with annotations if there was a mismatch in the number of 
>> parameters and annotations. Unfortunately, the Parameters.isSynthetic 
>> API wasn't introduced until JDK 8 and that information doesn't have 
>> to be available.
>>
>> Cheers,
>>
>> -Joe
>>
>>>
>>> Static local classes are compiled so that constructor source 
>>> parameters come 1st, followed by any captured variables.
>>>
>>> etc...
>>>
>>> Regards, Peter
>>>
>>>
>>> On 05/19/2017 11:31 PM, joe darcy wrote:
>>>> Hello,
>>>>
>>>> Please review the webrev to fix
>>>>
>>>>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns 
>>>> wrong value
>>>> http://cr.openjdk.java.net/~darcy/8074977.3/
>>>>
>>>> To condense a complicated situation, there are cases where the 
>>>> number of parameters present for a constructor in source code and 
>>>> the number of parameters present for that constructor in the class 
>>>> file differ. One of those cases occurs for the constructor of a 
>>>> non-static member class [1] where there is a leading parameter to 
>>>> accept the outer this argument.
>>>>
>>>> Bug JDK-8074977 reports on a situation where the type annotations 
>>>> on constructor parameters are incorrectly reported. Essentially, an 
>>>> off-by-one error is the cause since the annotation information is 
>>>> stored with respect to the number of parameters present in the 
>>>> source and an additional parameter is present at runtime.
>>>>
>>>> An analogous situation exists for declaration annotations and 
>>>> constructor parameters, declaration annotations being the 
>>>> traditional flavor of annotations.
>>>>
>>>> Type annotations and declaration annotations are read using 
>>>> different APIs so require separate fixes to detect the additional 
>>>> parameter and make the necessary adjustments in the returned 
>>>> information.
>>>>
>>>> The regression tests cover both the type annotation reading API and 
>>>> the two ways of reading declaration annotations on parameters, 
>>>> calling getParameterAnnotations on the constructor or call 
>>>> getParameters on the constructor and then calling getAnnotations on 
>>>> each parameter. The getParameters API was added in JDK 8.
>>>>
>>>> Static member and non-static member classes are used as test cases, 
>>>> as are constructors with and without generic type information.
>>>>
>>>> Thanks,
>>>>
>>>> -Joe
>>>>
>>>> [1] 
>>>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>>>>
>>>
>>
>


From huaming.li at oracle.com  Mon May 22 04:26:41 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Mon, 22 May 2017 12:26:41 +0800
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
Message-ID: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8180732
webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/

Thank you
-Hamlin

From matthias.baesken at sap.com  Mon May 22 08:49:41 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Mon, 22 May 2017 08:49:41 +0000
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: <520c56a8-4379-e4b0-42ac-acde1939cc7b@oracle.com>
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
 <520c56a8-4379-e4b0-42ac-acde1939cc7b@oracle.com>
Message-ID: 

Hello Serguei,  the  com/sun/jdi  tests were executed ,  same number of  passed and errors in a patched and unpatched JDK .
We do not need a sponsor because  the change is in JDK not HS .

Best regards, Matthias


-----Original Message-----
From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com] 
Sent: Freitag, 19. Mai 2017 02:18
To: Baesken, Matthias ; Alan Bateman ; core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
Cc: Simonis, Volker 
Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent

Hi Matthias,

The fix looks good to me.
It must be tested at least with the JTreg com/sun/jdi tests.
Do you need a sponsor?

Thanks,
Serguei



On 5/16/17 03:21, Baesken, Matthias wrote:
>   Sure, I forward it to  serviceability-dev .
>
> -----Original Message-----
> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
> Sent: Dienstag, 16. Mai 2017 11:51
> To: Baesken, Matthias ; core-libs-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>
>
>
> On 16/05/2017 10:04, Baesken, Matthias wrote:
>> Hello, could you please review this small change :
>>
>> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>>
>> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>>
>> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>>
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180413
>>
>>
> Can you bring this to serviceability-dev as that is the mailing list
> where the JDWP agent is maintained?
>
> -Alan


From serguei.spitsyn at oracle.com  Mon May 22 09:40:09 2017
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Mon, 22 May 2017 02:40:09 -0700
Subject: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
In-Reply-To: 
References: 
 <37ac7b12-1edd-ce65-a20f-404bd3eba75e@oracle.com>
 <444e21a8d38c42338fa5c38093a32e9c@sap.com>
 <520c56a8-4379-e4b0-42ac-acde1939cc7b@oracle.com>
 
Message-ID: 

Hello Matthias,

It is great, you are able to push this fix!

Thanks,
Serguei



On 5/22/17 01:49, Baesken, Matthias wrote:
> Hello Serguei,  the  com/sun/jdi  tests were executed ,  same number of  passed and errors in a patched and unpatched JDK .
> We do not need a sponsor because  the change is in JDK not HS .
>
> Best regards, Matthias
>
>
> -----Original Message-----
> From: serguei.spitsyn at oracle.com [mailto:serguei.spitsyn at oracle.com]
> Sent: Freitag, 19. Mai 2017 02:18
> To: Baesken, Matthias ; Alan Bateman ; core-libs-dev at openjdk.java.net; serviceability-dev at openjdk.java.net
> Cc: Simonis, Volker 
> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>
> Hi Matthias,
>
> The fix looks good to me.
> It must be tested at least with the JTreg com/sun/jdi tests.
> Do you need a sponsor?
>
> Thanks,
> Serguei
>
>
>
> On 5/16/17 03:21, Baesken, Matthias wrote:
>>    Sure, I forward it to  serviceability-dev .
>>
>> -----Original Message-----
>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com]
>> Sent: Dienstag, 16. Mai 2017 11:51
>> To: Baesken, Matthias ; core-libs-dev at openjdk.java.net
>> Cc: Simonis, Volker 
>> Subject: Re: [XS] JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>>
>>
>>
>> On 16/05/2017 10:04, Baesken, Matthias wrote:
>>> Hello, could you please review this small change :
>>>
>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8180413/
>>>
>>> it fixes a number of places in   jdk.jdwp.agent   where in case of an error it is attempted to write to NULL .
>>>
>>> Bug :  JDK-8180413 : avoid accessing NULL in jdk.jdwp.agent
>>>
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8180413
>>>
>>>
>> Can you bring this to serviceability-dev as that is the mailing list
>> where the JDWP agent is maintained?
>>
>> -Alan


From mark.sheppard at oracle.com  Mon May 22 15:04:26 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Mon, 22 May 2017 16:04:26 +0100
Subject: RFR: 8175131: sun.rmi.transport.tcp.TCPChannel.createConnection
 close connection on timeout
In-Reply-To: <20170510202255.GG3159@vimes>
References: <20170510192501.GE3159@vimes>
 <61eb44e1-65dc-0306-d82f-229a928fa56b@Oracle.com>
 <20170510202255.GG3159@vimes>
Message-ID: <4ee53d2a-1e27-891e-f6d0-5c38cdc31172@oracle.com>

Hi Rob,
     updated change looks good and does the job (in jdk8 and jdk9) of 
eliminating the socket connection build up
regressions tests show no side effects.

noticed what appears to be a peculiarity in the test, in that the test's 
server object is exported on the same port as the
Registry! But that seems to be OK ... the end point mappings are set up 
fine and the end point listener
handles the incoming requests for RemoteObjectSample

regards
Mark

On 10/05/2017 21:22, Rob McKenna wrote:
> Good point, I was nervous that there may have been a reason for not
> closing the connection and completely overlooked the obvious.
>
> http://cr.openjdk.java.net/~robm/8175131/webrev.02/
>
> Thanks,
>
>      -Rob
>
> On 10/05/17 03:38, Roger Riggs wrote:
>> Hi Rob,
>>
>> If an exception is thrown in createConnection, it can't return the
>> connection that was created
>> and so it should close it.
>>
>> I would close the connection at line 298, before throwing the exception.
>>
>> Roger
>>
>> On 5/10/2017 3:25 PM, Rob McKenna wrote:
>>> Hi folks,
>>>
>>> Looking for a review of the following simple change:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8175131
>>> http://cr.openjdk.java.net/~robm/8175131/webrev.01/
>>>
>>> Note: I've deliberately limited the connection closure to the described
>>> case. If however you feel that it should be applied generally when an
>>> exception is thrown (in the if and / or else block) let me know!
>>>
>>>      -Rob
>>>


From martinrb at google.com  Mon May 22 19:44:22 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 May 2017 12:44:22 -0700
Subject: curious if there is a Local.java in the works for
 CompletableFutures like scala has
In-Reply-To: <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
Message-ID: 

There's not likely to be any support for local context anywhere in
java.util.concurrent, but it seems not too hard to roll your own support
with a custom executor to be used with CompletableFuture that kept track of
any local context.

On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo  wrote:

> General questions on concurrency in Java should be asked here:
>
>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>
> > On 18 May 2017, at 21:57, Dean Hiller  wrote:
> >
> > Way more detail here...
> >
> > http://stackoverflow.com/questions/37933713/does-
> completablefuture-have-a-corresponding-local-context
> >
> > So I was wondering if this was going to be added at some point to the jdk
> > as I could not figure out how to set something so it was still available
> on
> > the thread at a later time when traversing async thenCompose, thenAccept.
> >
> > thanks,
> > Dean
>
>

From brian.burkhalter at oracle.com  Mon May 22 20:22:29 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 May 2017 13:22:29 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
Message-ID: 

https://bugs.openjdk.java.net/browse/JDK-8180767
http://cr.openjdk.java.net/~bpb/8180767/webrev.00/

java.io.File#lastModified() returns zero if the file in question does not exist. If however the file does exist and by some fantastic improbability has a last-modified time equal to the epoch, then a caller literally following the specification verbiage would interpret the returned value of zero as signifying that the file does not exist. It would probably be ideal to throw a FileNotFoundException when the file does not exist, but instead here we propose to return unity (1) instead of zero when the last-modified time of the file equals the epoch.

Note that this webrev is with respect to the one for [1] which is currently pending CCC approval, and is shown in the webrev in the JDK 9 tree. As it contains code changes, it would however be pushed to JDK 10 after the patch for [1] has been pushed and eventually migrated into the JDK 10 repository.

Thanks,

Brian

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047787.html

From martinrb at google.com  Mon May 22 20:36:06 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 May 2017 13:36:06 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
Message-ID: 

I have seen such filesystems in the wild.  Imagine that a virtual
filesystem has to make up metadata for an object not actually stored, e.g.
a directory for a file system backed by a source code control system that
does not have directory artifacts.  Filesystem authors are likely to pick
the value 0 for timestamps, even though that is likely to cause trouble
(later than 2000 is much safer).

On Mon, May 22, 2017 at 1:22 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8180767
> http://cr.openjdk.java.net/~bpb/8180767/webrev.00/
>
> java.io.File#lastModified() returns zero if the file in question does not
> exist. If however the file does exist and by some fantastic improbability
> has a last-modified time equal to the epoch, then a caller literally
> following the specification verbiage would interpret the returned value of
> zero as signifying that the file does not exist. It would probably be ideal
> to throw a FileNotFoundException when the file does not exist, but instead
> here we propose to return unity (1) instead of zero when the last-modified
> time of the file equals the epoch.
>
> Note that this webrev is with respect to the one for [1] which is
> currently pending CCC approval, and is shown in the webrev in the JDK 9
> tree. As it contains code changes, it would however be pushed to JDK 10
> after the patch for [1] has been pushed and eventually migrated into the
> JDK 10 repository.
>
> Thanks,
>
> Brian
>
> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-
> May/047787.html

From brian.burkhalter at oracle.com  Mon May 22 20:38:04 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 May 2017 13:38:04 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
Message-ID: <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>

So are you suggesting that this would be a bad idea, an incompatible change as they would be looking for zero instead of unity?

On May 22, 2017, at 1:36 PM, Martin Buchholz  wrote:

> I have seen such filesystems in the wild.  Imagine that a virtual filesystem has to make up metadata for an object not actually stored, e.g. a directory for a file system backed by a source code control system that does not have directory artifacts.  Filesystem authors are likely to pick the value 0 for timestamps, even though that is likely to cause trouble (later than 2000 is much safer).

From mandy.chung at oracle.com  Mon May 22 20:41:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 22 May 2017 13:41:52 -0700
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
Message-ID: <2B3E85EE-C925-478B-9485-FE9FDBAE3317@oracle.com>


> On May 19, 2017, at 2:31 PM, joe darcy  wrote:
> 
> Hello,
> 
> Please review the webrev to fix
> 
>    JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
>    http://cr.openjdk.java.net/~darcy/8074977.3/

This fix looks okay to me.  Deferring a more complete solution to JDK 10 is a reasonable choice at this point of the release.

Mandy


From martinrb at google.com  Mon May 22 20:42:34 2017
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 22 May 2017 13:42:34 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
Message-ID: 

I have no opinion on how to address the problem - just pointing out that
the problem is real.

I might choose an even less likely value than 1 if I were to switch from 0.

(this is not a review!)

On Mon, May 22, 2017 at 1:38 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> So are you suggesting that this would be a bad idea, an incompatible
> change as they would be looking for zero instead of unity?
>
> On May 22, 2017, at 1:36 PM, Martin Buchholz  wrote:
>
> > I have seen such filesystems in the wild.  Imagine that a virtual
> filesystem has to make up metadata for an object not actually stored, e.g.
> a directory for a file system backed by a source code control system that
> does not have directory artifacts.  Filesystem authors are likely to pick
> the value 0 for timestamps, even though that is likely to cause trouble
> (later than 2000 is much safer).
>

From brian.burkhalter at oracle.com  Mon May 22 20:45:13 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 May 2017 13:45:13 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
Message-ID: <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>


On May 22, 2017, at 1:42 PM, Martin Buchholz  wrote:

> I have no opinion on how to address the problem - just pointing out that the problem is real.  
> 
> I might choose an even less likely value than 1 if I were to switch from 0.

Perhaps Long.MAX_VALUE.

> (this is not a review!)


Not so interpreted.

From pavel.rappo at oracle.com  Mon May 22 22:17:25 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Tue, 23 May 2017 01:17:25 +0300
Subject: [concurrency-interest] curious if there is a Local.java in the
 works for CompletableFutures like scala has
In-Reply-To: 
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
 
 
Message-ID: 

Heya Josh,

I only want this question to be discussed on ci rather on core-libs-dev :-) I'm not the OP.

> On 22 May 2017, at 23:01, Josh Humphries  wrote:
> 
> Pavel,
> It sounds like you want 

[...]

From igor.ignatyev at oracle.com  Mon May 22 22:49:22 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Mon, 22 May 2017 15:49:22 -0700
Subject: RFR(XS): 8180802 : move jdk.testlibrary.management.ThreadMXBeanTool
 to top level testlibrary
Message-ID: <987B0472-4322-4B46-A9CF-C0BE22D51D67@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180802/webrev.00/index.html
> 143 lines changed: 71 ins; 72 del; 0 mod; 
Hi all,

could you please review this patch which moves ThreadMXBeanTool from jdk testlibrary to the top level testlibrary?
please be aware that there are tests outside jdk repository which use this class. these tests will be updated accordingly.

webrev: http://cr.openjdk.java.net/~iignatyev//8180802/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180802

Thanks,
-- Igor

From stuart.marks at oracle.com  Mon May 22 22:52:45 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 22 May 2017 15:52:45 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
Message-ID: <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>

On 5/19/17 11:59 AM, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-6791812
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>       * @return  A long value representing the time the file was
>       *          last modified, measured in milliseconds since the epoch
>       *          (00:00:00 GMT, January 1, 1970), or 0L if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative in which case its absolute value indicates the
> +     *          number of milliseconds before the epoch
>       *
>       * @throws  SecurityException
>       *          If a security manager exists and its {@link

This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is 
Long.MIN_VALUE, which is still negative. A negative value for "milliseconds 
before the epoch" is confusing. It might be sufficient simply to say that 
negative values indicate a time prior to the epoch.

This is not outside the realm of possibility. For example, the Mac HFS+ file 
system represents time as seconds since January 1, 1904. It seems unlikely :-) 
that any Mac files were actually created between 1904 and 1970, but it is a 
possibility that somebody could have set a file's timestamp to a date in that range.

> The weird thing here is that if this method were invoked on a file last
> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
> file does not exist or whether its last-modified time is the epoch. It seems
> to me that if the file does not exist it would be better to throw a
> FileNotFoundException but that is not an issue for JDK 9 at this stage of
> game.

I'll comment on this on the subsequent thread.

s'marks



From brian.burkhalter at oracle.com  Mon May 22 22:55:58 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 May 2017 15:55:58 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
Message-ID: 

On May 22, 2017, at 3:52 PM, Stuart Marks  wrote:

>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -932,7 +932,9 @@
>>      * @return  A long value representing the time the file was
>>      *          last modified, measured in milliseconds since the epoch
>>      *          (00:00:00 GMT, January 1, 1970), or 0L if the
>> -     *          file does not exist or if an I/O error occurs
>> +     *          file does not exist or if an I/O error occurs; the value may
>> +     *          be negative in which case its absolute value indicates the
>> +     *          number of milliseconds before the epoch
>>      *
>>      * @throws  SecurityException
>>      *          If a security manager exists and its {@link
> 
> This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is Long.MIN_VALUE, which is still negative.

True.

> A negative value for "milliseconds before the epoch" is confusing. It might be sufficient simply to say that negative values indicate a time prior to the epoch.

Or it could say ?its mathematically absolute value? which would be accurate.

> This is not outside the realm of possibility. For example, the Mac HFS+ file system represents time as seconds since January 1, 1904. It seems unlikely :-) that any Mac files were actually created between 1904 and 1970, but it is a possibility that somebody could have set a file's timestamp to a date in that range.

Yes, I read about HFS Plus as part of investigating another time issue.

>> The weird thing here is that if this method were invoked on a file last
>> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
>> file does not exist or whether its last-modified time is the epoch. It seems
>> to me that if the file does not exist it would be better to throw a
>> FileNotFoundException but that is not an issue for JDK 9 at this stage of
>> game.
> 
> I'll comment on this on the subsequent thread.

Good!

Thanks,

Brian

From stuart.marks at oracle.com  Mon May 22 23:15:25 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 22 May 2017 16:15:25 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
Message-ID: 



On 5/22/17 1:45 PM, Brian Burkhalter wrote:
>
> On May 22, 2017, at 1:42 PM, Martin Buchholz  wrote:
>
>> I have no opinion on how to address the problem - just pointing out that the problem is real.
>>
>> I might choose an even less likely value than 1 if I were to switch from 0.
>
> Perhaps Long.MAX_VALUE.

I agree with Martin that this is a real problem.

I'm pretty sure I've seen files with a timestamp of zero. I can't remember the 
exact circumstances, but it was something like a tar file that was converted 
from a dump of some foreign filesystem where they either didn't bother to 
convert the timestamps, or that didn't have timestamps at all. Whoever wrote the 
converter had to choose some value to fill in; they chose zero. When tar 
extracts the files, it sets the modification time to the time value found in the 
archive. This resulted in a bunch of files with a modification date of the epoch.

Thus, I believe the files with a modification time of zero (the epoch) are 
rather more common than one might think.

Now this turns into a problem for the File.lastModified, as a return value of 0L 
can't distinguish between success on a file whose modified timestamp was the 
epoch, and file-not-found or another IOException. This is unfortunate, but I 
think we just have to live with it. Returning 1L instead of 0L seems like a bad 
idea, as the API is actually lying about the value it retrieved from the file 
system. I can imagine that this would lead to all sorts of subtle errors. For 
example, suppose somebody were to have written a "jtar" command that attempts to 
be a Java equivalent of the Unix "tar" command, and it uses File.lastModified. 
Using "tar" to extract an archive containing files with zero timestamps, then 
using "jtar" to create an archive from the extracted files, would result in an 
archive that differs from the original "tar" archive, and indeed one that 
differs from one produced by "jtar" on an earlier JDK release.

So yes, I'd say that returning 1L (or any other value) instead of 0L would be an 
incompatible change.

The specification for File.lastModified already has this note:

> Where it is required to distinguish an I/O exception from the case where 0L
> is returned, or where several attributes of the same file are required at the
> same time, or where the time of last access or the creation time are
> required, then the Files.readAttributes method may be used.

I think this is sufficient. People who care about this case will have to rewrite 
their code using Files.readAttributes instead of File.lastModified.

s'marks

From brian.burkhalter at oracle.com  Mon May 22 23:20:30 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Mon, 22 May 2017 16:20:30 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
Message-ID: <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>

On May 22, 2017, at 4:15 PM, Stuart Marks  wrote:

> So yes, I'd say that returning 1L (or any other value) instead of 0L would be an incompatible change.

I think the correct solution would be to throw a FNFE for a non-extant file but that is also incompatible.

> The specification for File.lastModified already has this note:
> 
>> Where it is required to distinguish an I/O exception from the case where 0L
>> is returned, or where several attributes of the same file are required at the
>> same time, or where the time of last access or the creation time are
>> required, then the Files.readAttributes method may be used.
> 
> I think this is sufficient. People who care about this case will have to rewrite their code using Files.readAttributes instead of File.lastModified.

On reflection, so to speak, I think I have to agree with you. I?ll leave the issue open for the time being but unless a compelling alternative solution arises should probably resolve it as ?Won?t Fix.?

Thanks for the careful commentary.

Brian

From Alan.Bateman at oracle.com  Tue May 23 10:02:28 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 23 May 2017 11:02:28 +0100
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
Message-ID: <1978135c-8675-a2dd-f1cf-dbeb01e27ec2@oracle.com>

On 23/05/2017 00:15, Stuart Marks wrote:

>
> I think this is sufficient. People who care about this case will have 
> to rewrite their code using Files.readAttributes instead of 
> File.lastModified.
or Files.getLastModifiedTime if only this timestamp is needed.

-Alan

From lance.andersen at oracle.com  Tue May 23 11:21:08 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 23 May 2017 07:21:08 -0400
Subject: RFR: 8180728: DatabaseMeta.getRowIdLifetime returns an enum but
 javadoc refers to int
Message-ID: 

Hi all,

This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0  for DatabaseMetadata.getRowIdLifetime which refers to an int being returned but in actuality an enum is returned.  The javadoc no aligns with the PDF JDBC spec.  

The CCC has been approved.

??????????????
$ hg diff
diff -r 490393b435bb src/java.sql/share/classes/java/sql/DatabaseMetaData.java
--- a/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Sun May 21 10:52:36 2017 +0200
+++ b/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Tue May 23 07:20:07 2017 -0400
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights reserved.
+ * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights reserved.
  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
  *
  * This code is free software; you can redistribute it and/or modify it
@@ -3199,22 +3199,10 @@
     //------------------------- JDBC 4.0 -----------------------------------
 
     /**
-     * Indicates whether or not this data source supports the SQL ROWID type,
-     * and if so  the lifetime for which a RowId object remains valid.
-     * 

-     * The returned int values have the following relationship:
-     * 
{@code
-     *     ROWID_UNSUPPORTED < ROWID_VALID_OTHER < ROWID_VALID_TRANSACTION
-     *         < ROWID_VALID_SESSION < ROWID_VALID_FOREVER
-     * }

-     * so conditional logic such as
-     * 
{@code
-     *     if (metadata.getRowIdLifetime() > DatabaseMetaData.ROWID_VALID_TRANSACTION)
-     * }

-     * can be used. Valid Forever means valid across all Sessions, and valid for
-     * a Session means valid across all its contained Transactions.
+     * Indicates whether this data source supports the SQL {@code  ROWID} type,
+     * and the lifetime for which a {@code  RowId} object remains valid.
      *
-     * @return the status indicating the lifetime of a RowId
+     * @return the status indicating the lifetime of a {@code  RowId}
      * @throws SQLException if a database access error occurs
      * @since 1.6
      */
??????????????
Best
Lance
 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From Roger.Riggs at Oracle.com  Tue May 23 13:56:14 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 09:56:14 -0400
Subject: RFR: 8180728: DatabaseMeta.getRowIdLifetime returns an enum but
 javadoc refers to int
In-Reply-To: 
References: 
Message-ID: <4d83cca9-2e68-39fe-9425-5fb50c35a04e@Oracle.com>

Hi Lance,

Should one of those @code's be @link so it is easy to get to the ROWID 
javadoc?

Otherwise, looks fine,

Roger


On 5/23/2017 7:21 AM, Lance Andersen wrote:
> Hi all,
>
> This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0  for DatabaseMetadata.getRowIdLifetime which refers to an int being returned but in actuality an enum is returned.  The javadoc no aligns with the PDF JDBC spec.
>
> The CCC has been approved.
>
> ??????????????
> $ hg diff
> diff -r 490393b435bb src/java.sql/share/classes/java/sql/DatabaseMetaData.java
> --- a/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Sun May 21 10:52:36 2017 +0200
> +++ b/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Tue May 23 07:20:07 2017 -0400
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights reserved.
> + * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights reserved.
>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>    *
>    * This code is free software; you can redistribute it and/or modify it
> @@ -3199,22 +3199,10 @@
>       //------------------------- JDBC 4.0 -----------------------------------
>   
>       /**
> -     * Indicates whether or not this data source supports the SQL ROWID type,
> -     * and if so  the lifetime for which a RowId object remains valid.
> -     * 

> -     * The returned int values have the following relationship:
> -     * 
{@code
> -     *     ROWID_UNSUPPORTED < ROWID_VALID_OTHER < ROWID_VALID_TRANSACTION
> -     *         < ROWID_VALID_SESSION < ROWID_VALID_FOREVER
> -     * }

> -     * so conditional logic such as
> -     * 
{@code
> -     *     if (metadata.getRowIdLifetime() > DatabaseMetaData.ROWID_VALID_TRANSACTION)
> -     * }

> -     * can be used. Valid Forever means valid across all Sessions, and valid for
> -     * a Session means valid across all its contained Transactions.
> +     * Indicates whether this data source supports the SQL {@code  ROWID} type,
> +     * and the lifetime for which a {@code  RowId} object remains valid.
>        *
> -     * @return the status indicating the lifetime of a RowId
> +     * @return the status indicating the lifetime of a {@code  RowId}
>        * @throws SQLException if a database access error occurs
>        * @since 1.6
>        */
> ??????????????
> Best
> Lance
>   
>    
>   Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
>
>
>


From Roger.Riggs at Oracle.com  Tue May 23 14:03:25 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 10:03:25 -0400
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: 
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
 
Message-ID: 

Hi Brian,

I don't think you need to mention the absolute value.

+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative indicating the number of milliseconds before the epoch

Roger



On 5/22/2017 6:55 PM, Brian Burkhalter wrote:
> On May 22, 2017, at 3:52 PM, Stuart Marks  wrote:
>
>>> --- a/src/java.base/share/classes/java/io/File.java
>>> +++ b/src/java.base/share/classes/java/io/File.java
>>> @@ -932,7 +932,9 @@
>>>       * @return  A long value representing the time the file was
>>>       *          last modified, measured in milliseconds since the epoch
>>>       *          (00:00:00 GMT, January 1, 1970), or 0L if the
>>> -     *          file does not exist or if an I/O error occurs
>>> +     *          file does not exist or if an I/O error occurs; the value may
>>> +     *          be negative in which case its absolute value indicates the
>>> +     *          number of milliseconds before the epoch
>>>       *
>>>       * @throws  SecurityException
>>>       *          If a security manager exists and its {@link
>> This is "absolutely" pedantic, but the absolute value of Long.MIN_VALUE is Long.MIN_VALUE, which is still negative.
> True.
>
>> A negative value for "milliseconds before the epoch" is confusing. It might be sufficient simply to say that negative values indicate a time prior to the epoch.
> Or it could say ?its mathematically absolute value? which would be accurate.
>
>> This is not outside the realm of possibility. For example, the Mac HFS+ file system represents time as seconds since January 1, 1904. It seems unlikely :-) that any Mac files were actually created between 1904 and 1970, but it is a possibility that somebody could have set a file's timestamp to a date in that range.
> Yes, I read about HFS Plus as part of investigating another time issue.
>
>>> The weird thing here is that if this method were invoked on a file last
>>> modified at 00:00:00 GMT, January 1, 1970, then we would not know whether the
>>> file does not exist or whether its last-modified time is the epoch. It seems
>>> to me that if the file does not exist it would be better to throw a
>>> FileNotFoundException but that is not an issue for JDK 9 at this stage of
>>> game.
>> I'll comment on this on the subsequent thread.
> Good!
>
> Thanks,
>
> Brian


From Roger.Riggs at Oracle.com  Tue May 23 14:07:49 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 10:07:49 -0400
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
Message-ID: 

+1

Roger

On 5/22/2017 7:20 PM, Brian Burkhalter wrote:
> On reflection, so to speak, I think I have to agree with you. I?ll leave the issue open for the time being but unless a compelling alternative solution arises should probably resolve it as ?Won?t Fix.?
>
> Thanks for the careful commentary.
>
> Brian


From brian.burkhalter at oracle.com  Tue May 23 15:03:17 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 08:03:17 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
Message-ID: <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>

Or perhaps per Alan?s comments below change the current wording

Where it is required to distinguish an I/O exception from the case where 0L is returned, or where several attributes of the same file are required at the same time, or where the time of last access or the creation time are required, then the Files.readAttributes method may be used.

to

Where it is required to distinguish an I/O exception from the case where 0L is returned, or where several attributes of the same file are required at the same time, or where the time of last access or the creation time are required, then the Files.readAttributes method may be used, or Files.getLastModifiedTime() if only this timestamp is needed.

?

I think it?s come down to either this just resolve it without change.

Brian

On May 23, 2017, at 7:07 AM, Roger Riggs  wrote:

> +1
> 
> Roger
> 
> On 5/22/2017 7:20 PM, Brian Burkhalter wrote:
>> On reflection, so to speak, I think I have to agree with you. I?ll leave the issue open for the time being but unless a compelling alternative solution arises should probably resolve it as ?Won?t Fix.?
>> 
>> Thanks for the careful commentary.
>> 
>> Brian
> 

On May 23, 2017, at 3:02 AM, Alan Bateman  wrote:

> On 23/05/2017 00:15, Stuart Marks wrote:
> 
>> 
>> I think this is sufficient. People who care about this case will have to rewrite their code using Files.readAttributes instead of File.lastModified.
> or Files.getLastModifiedTime if only this timestamp is needed.



From brian.burkhalter at oracle.com  Tue May 23 15:21:56 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 08:21:56 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: 
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
 
 
Message-ID: <3270129A-BB52-47EF-B4AB-81649DA53739@oracle.com>

Hi Roger,

So I guess this might be satisfy your and Stuart?s comments:

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -932,7 +932,9 @@
     * @return  A long value representing the time the file was
     *          last modified, measured in milliseconds since the epoch
     *          (00:00:00 GMT, January 1, 1970), or 0L if the
-     *          file does not exist or if an I/O error occurs
+     *          file does not exist or if an I/O error occurs; the value may
+     *          be negative indicating the number of milliseconds before the epoch

Thanks,

Brian

On May 23, 2017, at 7:03 AM, Roger Riggs  wrote:

> I don't think you need to mention the absolute value.
> 
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative indicating the number of milliseconds before the epoch


From huizhe.wang at oracle.com  Tue May 23 16:34:26 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 23 May 2017 09:34:26 -0700
Subject: RFR: 8180728: DatabaseMeta.getRowIdLifetime returns an enum but
 javadoc refers to int
In-Reply-To: <4d83cca9-2e68-39fe-9425-5fb50c35a04e@Oracle.com>
References: 
 <4d83cca9-2e68-39fe-9425-5fb50c35a04e@Oracle.com>
Message-ID: <051a11b3-efe2-df98-67f9-695bb4aef10c@oracle.com>

+1

-Joe

On 5/23/2017 6:56 AM, Roger Riggs wrote:
> Hi Lance,
>
> Should one of those @code's be @link so it is easy to get to the ROWID 
> javadoc?
>
> Otherwise, looks fine,
>
> Roger
>
>
> On 5/23/2017 7:21 AM, Lance Andersen wrote:
>> Hi all,
>>
>> This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0  
>> for DatabaseMetadata.getRowIdLifetime which refers to an int being 
>> returned but in actuality an enum is returned.  The javadoc no aligns 
>> with the PDF JDBC spec.
>>
>> The CCC has been approved.
>>
>> ??????????????
>> $ hg diff
>> diff -r 490393b435bb 
>> src/java.sql/share/classes/java/sql/DatabaseMetaData.java
>> --- a/src/java.sql/share/classes/java/sql/DatabaseMetaData.java Sun 
>> May 21 10:52:36 2017 +0200
>> +++ b/src/java.sql/share/classes/java/sql/DatabaseMetaData.java Tue 
>> May 23 07:20:07 2017 -0400
>> @@ -1,5 +1,5 @@
>>   /*
>> - * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All 
>> rights reserved.
>> + * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All 
>> rights reserved.
>>    * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>    *
>>    * This code is free software; you can redistribute it and/or 
>> modify it
>> @@ -3199,22 +3199,10 @@
>>       //------------------------- JDBC 4.0 
>> -----------------------------------
>>         /**
>> -     * Indicates whether or not this data source supports the SQL 
>> ROWID type,
>> -     * and if so  the lifetime for which a RowId object 
>> remains valid.
>> -     * 

>> -     * The returned int values have the following relationship:
>> -     * 
{@code
>> -     *     ROWID_UNSUPPORTED < ROWID_VALID_OTHER < 
>> ROWID_VALID_TRANSACTION
>> -     *         < ROWID_VALID_SESSION < ROWID_VALID_FOREVER
>> -     * }

>> -     * so conditional logic such as
>> -     * 
{@code
>> -     *     if (metadata.getRowIdLifetime() > 
>> DatabaseMetaData.ROWID_VALID_TRANSACTION)
>> -     * }

>> -     * can be used. Valid Forever means valid across all Sessions, 
>> and valid for
>> -     * a Session means valid across all its contained Transactions.
>> +     * Indicates whether this data source supports the SQL {@code  
>> ROWID} type,
>> +     * and the lifetime for which a {@code  RowId} object remains 
>> valid.
>>        *
>> -     * @return the status indicating the lifetime of a 
>> RowId
>> +     * @return the status indicating the lifetime of a {@code RowId}
>>        * @throws SQLException if a database access error occurs
>>        * @since 1.6
>>        */
>> ??????????????
>> Best
>> Lance
>> 
>>  
>> 
>> Lance 
>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com 
>>
>>
>>
>


From brent.christian at oracle.com  Tue May 23 16:53:26 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Tue, 23 May 2017 09:53:26 -0700
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
Message-ID: <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>

Hi, Hamlin

That looks pretty good.  A couple comments:

* If I'm not mistaken, main/othervm/policy=... is sufficient to enable 
the default security manager, and specifying "-Djava.security.manager" 
is unnecessary.

* Please add 8180732 to the @bug tag

You will also need approval from a JDK 10 Reviewer.

Thanks,
-Brent

On 5/21/17 9:26 PM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>
> Thank you
> -Hamlin

From huizhe.wang at oracle.com  Tue May 23 17:01:09 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 23 May 2017 10:01:09 -0700
Subject: RFR 8180349: Review JAXP Java SE 9 API javadocs
Message-ID: <6270fc97-1c61-ef7e-46eb-020167678b88@oracle.com>

Hi,

Please review an update to the JAXP Java SE 9 API javadocs.

JBS: https://bugs.openjdk.java.net/browse/JDK-8180349
webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/

There's a lot of format changes while converting to package-info.java, 
but only minor (wording) changes to the original documentation. All in 
all, including the new package descriptions, there's no material change 
to the APIs or description of them. Below are some details.

javax.xml
     New package description.

javax.xml.catalog
     Added a summary of the package.

javax.xml.datatype
     Added "Defines" at the beginning. Added @since.

javax.xml.namespace
     Added @since.

javax.xml.parsers
     Rephrased, added a short description of the plugability layer.

javax.xml.stream and javax.xml.stream.*
     New package description.

javax.xml.transform
     Added javax.xml.transform.stax to the description.

javax.xml.transform.dom
     Format only.

javax.xml.transform.sax
     Removed from the 1st paragraph the summary that's redundant to the 
next few paragraphs, which made it consistent with the .dom package.   
The last paragraph described an example that never existed. Rephrased 
the paragraph without mentioning an example.

javax.xml.transform.stax
     New

javax.xml.transform.stream
     The 1st statement is made consistent to that of .dom/sax/stax above

javax.xml.validation
     Format and minor wording changes. Under Support for additional 
schema langauges, I removed the words "as of JDK 1.5...".

javax.xml.xpath
     Format and minor wording changes.

org.w3c.dom
     Format only

org.w3c.dom.bootstrap .events .ls .traversal .views
     New package descriptions.

org.w3c.dom.range
     Removed the paragraphs copied from the DOM specification that 
states DOM is language-neutral and etc. since they have nothing to do 
with the Java package.

org.xml.sax
     minor wording changes. The starting sentence changed to start with 
"provides" to be consistent with the other packages. The last sentence 
"XMLReader implementations need not support them" is changed to 
"XMLReader implementations are not required to support them".

org.xml.sax.ext, .helpers
     Only the start, e.g. "Provides..."

Thanks,
Joe


From Roger.Riggs at Oracle.com  Tue May 23 17:05:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 13:05:52 -0400
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
 <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
Message-ID: <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>

Hi,

Security.java: 25-27: Style conventions call for " * " on every line in 
comment blocks.

On 5/23/2017 12:53 PM, Brent Christian wrote:
> Hi, Hamlin
>
> That looks pretty good.  A couple comments:
>
> * If I'm not mistaken, main/othervm/policy=... is sufficient to enable 
> the default security manager, and specifying "-Djava.security.manager" 
> is unnecessary.
>
> * Please add 8180732 to the @bug tag

I'm not sure this adds much because the bug report just is moving to 
test to the open repo.

>
> You will also need approval from a JDK 10 Reviewer.

Roger

>
> Thanks,
> -Brent
>
> On 5/21/17 9:26 PM, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
>> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>>
>> Thank you
>> -Hamlin


From lance.andersen at oracle.com  Tue May 23 17:10:27 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 23 May 2017 13:10:27 -0400
Subject: RFR: 8180728: DatabaseMeta.getRowIdLifetime returns an enum but
 javadoc refers to int
In-Reply-To: <4d83cca9-2e68-39fe-9425-5fb50c35a04e@Oracle.com>
References: 
 <4d83cca9-2e68-39fe-9425-5fb50c35a04e@Oracle.com>
Message-ID: <278599DF-A664-4819-93C9-F7B4A979AD80@oracle.com>

Hi Roger,
> On May 23, 2017, at 9:56 AM, Roger Riggs  wrote:
> 
> Hi Lance,
> 
> Should one of those @code's be @link so it is easy to get to the ROWID javadoc?

I could or add an @see.

I will tweak it before I push 

thank you.


> 
> Otherwise, looks fine,
> 
> Roger
> 
> 
> On 5/23/2017 7:21 AM, Lance Andersen wrote:
>> Hi all,
>> 
>> This RFR addresses a javadoc bug dating back to Java SE 6/JDBC 4.0  for DatabaseMetadata.getRowIdLifetime which refers to an int being returned but in actuality an enum is returned.  The javadoc no aligns with the PDF JDBC spec.
>> 
>> The CCC has been approved.
>> 
>> ??????????????
>> $ hg diff
>> diff -r 490393b435bb src/java.sql/share/classes/java/sql/DatabaseMetaData.java
>> --- a/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Sun May 21 10:52:36 2017 +0200
>> +++ b/src/java.sql/share/classes/java/sql/DatabaseMetaData.java	Tue May 23 07:20:07 2017 -0400
>> @@ -1,5 +1,5 @@
>>  /*
>> - * Copyright (c) 1996, 2015, Oracle and/or its affiliates. All rights reserved.
>> + * Copyright (c) 1996, 2017, Oracle and/or its affiliates. All rights reserved.
>>   * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>   *
>>   * This code is free software; you can redistribute it and/or modify it
>> @@ -3199,22 +3199,10 @@
>>      //------------------------- JDBC 4.0 -----------------------------------
>>        /**
>> -     * Indicates whether or not this data source supports the SQL ROWID type,
>> -     * and if so  the lifetime for which a RowId object remains valid.
>> -     * 

>> -     * The returned int values have the following relationship:
>> -     * 
{@code
>> -     *     ROWID_UNSUPPORTED < ROWID_VALID_OTHER < ROWID_VALID_TRANSACTION
>> -     *         < ROWID_VALID_SESSION < ROWID_VALID_FOREVER
>> -     * }

>> -     * so conditional logic such as
>> -     * 
{@code
>> -     *     if (metadata.getRowIdLifetime() > DatabaseMetaData.ROWID_VALID_TRANSACTION)
>> -     * }

>> -     * can be used. Valid Forever means valid across all Sessions, and valid for
>> -     * a Session means valid across all its contained Transactions.
>> +     * Indicates whether this data source supports the SQL {@code  ROWID} type,
>> +     * and the lifetime for which a {@code  RowId} object remains valid.
>>       *
>> -     * @return the status indicating the lifetime of a RowId
>> +     * @return the status indicating the lifetime of a {@code  RowId}
>>       * @throws SQLException if a database access error occurs
>>       * @since 1.6
>>       */
>> ??????????????
>> Best
>> Lance
>>  
>>   
>>  Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com 
>> 
>> 
>> 
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From brian.burkhalter at oracle.com  Tue May 23 19:41:57 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 12:41:57 -0700
Subject: JDK 9 RFC on test for 6212869: File.setLastModified(long) incorrect
 after calling TimeZone.setDefault()
Message-ID: 

For issue [1] I wrote a test [2] which subsumes the test in the issue report and ran it on the usual platforms via a regression job including the core java.io tests and I did not observe the reported failure. Therefore this issue can simply be resolved as ?Cannot Reproduce.? I am wondering however whether it would be worth adding the new test to the repository anyway, under a new, different issue ID, of course? In that case would there still be a ?@bug? tag in the test and if so which issue number would it have?

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-6212869
[2] http://cr.openjdk.java.net/~bpb/6212869/webrev.00/

From Roger.Riggs at Oracle.com  Tue May 23 20:02:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 16:02:28 -0400
Subject: JDK 9 RFC on test for 6212869: File.setLastModified(long)
 incorrect after calling TimeZone.setDefault()
In-Reply-To: 
References: 
Message-ID: 

Hi Brian,

The bug number does help trace the original/stimulus for the test;
you can push the new test as subtask.

line 36: I would probably add a comment with the readable time.
Its nice to know when that if someone had to debug the time on file.

And it's worth a couple of extra characters to add the units (ms) to the 
error at line 70.

Otherwise looks fine.

Roger



On 5/23/2017 3:41 PM, Brian Burkhalter wrote:
> For issue [1] I wrote a test [2] which subsumes the test in the issue report and ran it on the usual platforms via a regression job including the core java.io tests and I did not observe the reported failure. Therefore this issue can simply be resolved as ?Cannot Reproduce.? I am wondering however whether it would be worth adding the new test to the repository anyway, under a new, different issue ID, of course? In that case would there still be a ?@bug? tag in the test and if so which issue number would it have?
>
> Thanks,
>
> Brian
>
> [1] https://bugs.openjdk.java.net/browse/JDK-6212869
> [2] http://cr.openjdk.java.net/~bpb/6212869/webrev.00/


From stuart.marks at oracle.com  Tue May 23 20:23:50 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 23 May 2017 13:23:50 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <3270129A-BB52-47EF-B4AB-81649DA53739@oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
 
 
 <3270129A-BB52-47EF-B4AB-81649DA53739@oracle.com>
Message-ID: <4477f7d6-cbae-798e-ccbd-bb3ab7293655@oracle.com>

On 5/23/17 8:21 AM, Brian Burkhalter wrote:
> So I guess this might be satisfy your and Stuart?s comments:
>
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -932,7 +932,9 @@
>      * @return  A long value representing the time the file was
>      *          last modified, measured in milliseconds since the epoch
>      *          (00:00:00 GMT, January 1, 1970), or 0L if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs; the value may
> +     *          be negative indicating the number of milliseconds before the epoch

Yes, this looks great. Thanks.

s'marks


From stuart.marks at oracle.com  Tue May 23 20:34:50 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 23 May 2017 13:34:50 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
Message-ID: <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>



On 5/23/17 8:03 AM, Brian Burkhalter wrote:
> Or perhaps per Alan?s comments below change the current wording
>
> Where it is required to distinguish an I/O exception from the case where 0L is returned, or where several attributes of the same file are required at the same time, or where the time of last access or the creation time are required, then the Files.readAttributes method may be used.
>
> to
>
> Where it is required to distinguish an I/O exception from the case where 0L is returned, or where several attributes of the same file are required at the same time, or where the time of last access or the creation time are required, then the Files.readAttributes method may be used, or Files.getLastModifiedTime() if only this timestamp is needed.
>
> ?
>
> I think it?s come down to either this just resolve it without change.

Yes, this could be another non-normative change. You might even consider merging 
it with the other bug (JDK-6791812), and possibly even labeling it as @apiNote.

As for the wording itself, I think the sentiment is correct, but it's trying to 
pack a bit too much into a single sentence. Breaking it into two sentences would 
probably be helpful.

s'marks


From Roger.Riggs at Oracle.com  Tue May 23 20:38:27 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 23 May 2017 16:38:27 -0400
Subject: RFR 8180349: Review JAXP Java SE 9 API javadocs
In-Reply-To: <6270fc97-1c61-ef7e-46eb-020167678b88@oracle.com>
References: <6270fc97-1c61-ef7e-46eb-020167678b88@oracle.com>
Message-ID: 

Hi  Joe,

Looks good, a few minor editorial suggestions:

javax/transform/sax/package-info.java:
  - line 28:  I don't think the '-' belongs after SAX2 in the first 
sentence.

javax/transform/dom/package-info.java:
line 28:  ditto it is more readable without the '-'.

javax/stream/package-info.java:
line 33:  "easy pipelining".    -> "easy to pipeline" to
match the "to..., to..." structure of the sentence.

line 43: "may be located" -> "is located"

javax/validation/package-info.java:
line 68:  "is more preferable" -> "is preferred"

javax/xml/catalog/package-info.java:
line 34:  "JDK XML Processors" -> "XML Processors"

Thanks, Roger




On 5/23/2017 1:01 PM, huizhe wang wrote:
> Hi,
>
> Please review an update to the JAXP Java SE 9 API javadocs.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180349
> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/
>
> There's a lot of format changes while converting to package-info.java, 
> but only minor (wording) changes to the original documentation. All in 
> all, including the new package descriptions, there's no material 
> change to the APIs or description of them. Below are some details.
>
> javax.xml
>     New package description.
>
> javax.xml.catalog
>     Added a summary of the package.
>
> javax.xml.datatype
>     Added "Defines" at the beginning. Added @since.
>
> javax.xml.namespace
>     Added @since.
>
> javax.xml.parsers
>     Rephrased, added a short description of the plugability layer.
>
> javax.xml.stream and javax.xml.stream.*
>     New package description.
>
> javax.xml.transform
>     Added javax.xml.transform.stax to the description.
>
> javax.xml.transform.dom
>     Format only.
>
> javax.xml.transform.sax
>     Removed from the 1st paragraph the summary that's redundant to the 
> next few paragraphs, which made it consistent with the .dom package.   
> The last paragraph described an example that never existed. Rephrased 
> the paragraph without mentioning an example.
>
> javax.xml.transform.stax
>     New
>
> javax.xml.transform.stream
>     The 1st statement is made consistent to that of .dom/sax/stax above
>
> javax.xml.validation
>     Format and minor wording changes. Under Support for additional 
> schema langauges, I removed the words "as of JDK 1.5...".
>
> javax.xml.xpath
>     Format and minor wording changes.
>
> org.w3c.dom
>     Format only
>
> org.w3c.dom.bootstrap .events .ls .traversal .views
>     New package descriptions.
>
> org.w3c.dom.range
>     Removed the paragraphs copied from the DOM specification that 
> states DOM is language-neutral and etc. since they have nothing to do 
> with the Java package.
>
> org.xml.sax
>     minor wording changes. The starting sentence changed to start with 
> "provides" to be consistent with the other packages. The last sentence 
> "XMLReader implementations need not support them" is changed to 
> "XMLReader implementations are not required to support them".
>
> org.xml.sax.ext, .helpers
>     Only the start, e.g. "Provides..."
>
> Thanks,
> Joe
>


From brian.burkhalter at oracle.com  Tue May 23 21:08:39 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 14:08:39 -0700
Subject: JDK 9 RFC on test for 6212869: File.setLastModified(long)
 incorrect after calling TimeZone.setDefault()
In-Reply-To: 
References: 
 
Message-ID: <6B98BB44-ABA7-4904-8D06-F0D58D2B86C1@oracle.com>

Hi Roger,

On May 23, 2017, at 1:02 PM, Roger Riggs  wrote:

> The bug number does help trace the original/stimulus for the test;
> you can push the new test as subtask.

So the new test would have the sub-task issue ID in its @bug tag and the main issue would be resolved CNR?

> line 36: I would probably add a comment with the readable time.
> Its nice to know when that if someone had to debug the time on file.
> 
> And it's worth a couple of extra characters to add the units (ms) to the error at line 70.
> 
> Otherwise looks fine.

I will make those changes.

Thanks,

Brian

From brian.burkhalter at oracle.com  Tue May 23 21:27:48 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 14:27:48 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
Message-ID: 


On May 23, 2017, at 1:34 PM, Stuart Marks  wrote:

> Yes, this could be another non-normative change. You might even consider merging it with the other bug (JDK-6791812), and possibly even labeling it as @apiNote.
> 
> As for the wording itself, I think the sentiment is correct, but it's trying to pack a bit too much into a single sentence. Breaking it into two sentences would probably be helpful.

Does this seem better? It folds 8180767 into 6791812.

--- a/src/java.base/share/classes/java/io/File.java
+++ b/src/java.base/share/classes/java/io/File.java
@@ -928,11 +928,17 @@
      * the granularity of the value depends on the underlying
      * file system and may be larger.  For example, some
      * file systems use time stamps in units of seconds.
+     * Distinguishing an I/O exception from a zero return value may
+     * also be accomplished by using the
+     * {@link java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
+     * Files.getLastModifiedTime} method.
      *
      * @return  A long value representing the time the file was
      *          last modified, measured in milliseconds since the epoch
      *          (00:00:00 GMT, January 1, 1970), or 0L if the
-     *          file does not exist or if an I/O error occurs
+     *          file does not exist or if an I/O error occurs.  The value may
+     *          be negative indicating the number of milliseconds before the
+     *          epoch

I already verified that the generated javadoc is correct.

Thanks,

Brian

From lance.andersen at oracle.com  Tue May 23 22:05:24 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 23 May 2017 18:05:24 -0400
Subject: RFR 8180349: Review JAXP Java SE 9 API javadocs
In-Reply-To: 
References: <6270fc97-1c61-ef7e-46eb-020167678b88@oracle.com>
 
Message-ID: <13E3E4AF-0AFC-4E0D-A328-586801D5AB99@oracle.com>

Hi Joe,

Looks good overall and one comment below on top of Roger?s:
> On May 23, 2017, at 4:38 PM, Roger Riggs  wrote:
> 
> Hi  Joe,
> 
> Looks good, a few minor editorial suggestions:
> 
> javax/transform/sax/package-info.java:
> - line 28:  I don't think the '-' belongs after SAX2 in the first sentence.
> 
> javax/transform/dom/package-info.java:
> line 28:  ditto it is more readable without the '-'.
> 
> javax/stream/package-info.java:
> line 33:  "easy pipelining".    -> "easy to pipeline" to
> match the "to..., to..." structure of the sentence.
> 
> line 43: "may be located" -> "is located"
> 
> javax/validation/package-info.java:
> line 68:  "is more preferable" -> "is preferred"
> 
> javax/xml/catalog/package-info.java:
> line 34:  "JDK XML Processors" -> "XML Processors?

Is this trying to refer to the JAXP provided implementations?  if so, perhaps reword to try and make that clearer

> 
> Thanks, Roger
> 
> 
> 
> 
> On 5/23/2017 1:01 PM, huizhe wang wrote:
>> Hi,
>> 
>> Please review an update to the JAXP Java SE 9 API javadocs.
>> 
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180349
>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/
>> 
>> There's a lot of format changes while converting to package-info.java, but only minor (wording) changes to the original documentation. All in all, including the new package descriptions, there's no material change to the APIs or description of them. Below are some details.
>> 
>> javax.xml
>>    New package description.
>> 
>> javax.xml.catalog
>>    Added a summary of the package.
>> 
>> javax.xml.datatype
>>    Added "Defines" at the beginning. Added @since.
>> 
>> javax.xml.namespace
>>    Added @since.
>> 
>> javax.xml.parsers
>>    Rephrased, added a short description of the plugability layer.
>> 
>> javax.xml.stream and javax.xml.stream.*
>>    New package description.
>> 
>> javax.xml.transform
>>    Added javax.xml.transform.stax to the description.
>> 
>> javax.xml.transform.dom
>>    Format only.
>> 
>> javax.xml.transform.sax
>>    Removed from the 1st paragraph the summary that's redundant to the next few paragraphs, which made it consistent with the .dom package.   The last paragraph described an example that never existed. Rephrased the paragraph without mentioning an example.
>> 
>> javax.xml.transform.stax
>>    New
>> 
>> javax.xml.transform.stream
>>    The 1st statement is made consistent to that of .dom/sax/stax above
>> 
>> javax.xml.validation
>>    Format and minor wording changes. Under Support for additional schema langauges, I removed the words "as of JDK 1.5...".
>> 
>> javax.xml.xpath
>>    Format and minor wording changes.
>> 
>> org.w3c.dom
>>    Format only
>> 
>> org.w3c.dom.bootstrap .events .ls .traversal .views
>>    New package descriptions.
>> 
>> org.w3c.dom.range
>>    Removed the paragraphs copied from the DOM specification that states DOM is language-neutral and etc. since they have nothing to do with the Java package.
>> 
>> org.xml.sax
>>    minor wording changes. The starting sentence changed to start with "provides" to be consistent with the other packages. The last sentence "XMLReader implementations need not support them" is changed to "XMLReader implementations are not required to support them".
>> 
>> org.xml.sax.ext, .helpers
>>    Only the start, e.g. "Provides..."
>> 
>> Thanks,
>> Joe
>> 
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From brian.burkhalter at oracle.com  Tue May 23 22:55:07 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 15:55:07 -0700
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
Message-ID: 

RFR thread re-directed from RFC thread [1].

Create a sub-task [2] of [3] to create a test for the problem described in the main issue. The webrev [4] is with respect to the fix for the sub-task [2]. The ?@bug? tag in [2] has the issue ID of [3] which itself will be manually resolved as ?Cannot Reproduce? once Hg Updates has resolved [2] pursuant to the push.

Thanks,

Brian

[1] RFC thread - http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047833.html
[2] Sub-task - https://bugs.openjdk.java.net/browse/JDK-8180885
[3] Main-issue https://bugs.openjdk.java.net/browse/JDK-6212869
[4] Patch - http://cr.openjdk.java.net/~bpb/8180885/webrev.00/

From brian.burkhalter at oracle.com  Tue May 23 22:56:07 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 23 May 2017 15:56:07 -0700
Subject: JDK 9 RFC on test for 6212869: File.setLastModified(long)
 incorrect after calling TimeZone.setDefault()
In-Reply-To: <6B98BB44-ABA7-4904-8D06-F0D58D2B86C1@oracle.com>
References: 
 
 <6B98BB44-ABA7-4904-8D06-F0D58D2B86C1@oracle.com>
Message-ID: <98D5FE7E-E8C8-49C5-BCA6-DB9ED42A18C1@oracle.com>

This discussion has now transitioned to an RFR [1]

Thanks,

Brian

[1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047841.html

On May 23, 2017, at 2:08 PM, Brian Burkhalter  wrote:

> Hi Roger,
> 
> On May 23, 2017, at 1:02 PM, Roger Riggs  wrote:
> 
>> The bug number does help trace the original/stimulus for the test;
>> you can push the new test as subtask.
> 
> So the new test would have the sub-task issue ID in its @bug tag and the main issue would be resolved CNR?
> 
>> line 36: I would probably add a comment with the readable time.
>> Its nice to know when that if someone had to debug the time on file.
>> 
>> And it's worth a couple of extra characters to add the units (ms) to the error at line 70.
>> 
>> Otherwise looks fine.
> 
> I will make those changes.
> 
> Thanks,
> 
> Brian


From huizhe.wang at oracle.com  Tue May 23 23:27:21 2017
From: huizhe.wang at oracle.com (huizhe wang)
Date: Tue, 23 May 2017 16:27:21 -0700
Subject: RFR 8180349: Review JAXP Java SE 9 API javadocs
In-Reply-To: <13E3E4AF-0AFC-4E0D-A328-586801D5AB99@oracle.com>
References: <6270fc97-1c61-ef7e-46eb-020167678b88@oracle.com>
 
 <13E3E4AF-0AFC-4E0D-A328-586801D5AB99@oracle.com>
Message-ID: <44beba12-3f62-5487-cf1f-cc00d60db2ca@oracle.com>



On 5/23/2017 3:05 PM, Lance Andersen wrote:
> Hi Joe,
>
> Looks good overall and one comment below on top of Roger?s:
>> On May 23, 2017, at 4:38 PM, Roger Riggs  wrote:
>>
>> Hi  Joe,
>>
>> Looks good, a few minor editorial suggestions:
>>
>> javax/transform/sax/package-info.java:
>> - line 28:  I don't think the '-' belongs after SAX2 in the first sentence.
>>
>> javax/transform/dom/package-info.java:
>> line 28:  ditto it is more readable without the '-'.
>>
>> javax/stream/package-info.java:
>> line 33:  "easy pipelining".    -> "easy to pipeline" to
>> match the "to..., to..." structure of the sentence.
>>
>> line 43: "may be located" -> "is located"
>>
>> javax/validation/package-info.java:
>> line 68:  "is more preferable" -> "is preferred"
>>
>> javax/xml/catalog/package-info.java:
>> line 34:  "JDK XML Processors" -> "XML Processors?
> Is this trying to refer to the JAXP provided implementations?  if so, perhaps reword to try and make that clearer

Yes. It's probably not appropriate for the API docs to mention "JDK", so 
I've removed it as Roger commented. I think we are fine since we cover 
the topic in details with sample code in the developer guide.

Here's updated webrevs:
http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev01/

Thanks,
Joe

>
>> Thanks, Roger
>>
>>
>>
>>
>> On 5/23/2017 1:01 PM, huizhe wang wrote:
>>> Hi,
>>>
>>> Please review an update to the JAXP Java SE 9 API javadocs.
>>>
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180349
>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8180349/webrev/
>>>
>>> There's a lot of format changes while converting to package-info.java, but only minor (wording) changes to the original documentation. All in all, including the new package descriptions, there's no material change to the APIs or description of them. Below are some details.
>>>
>>> javax.xml
>>>     New package description.
>>>
>>> javax.xml.catalog
>>>     Added a summary of the package.
>>>
>>> javax.xml.datatype
>>>     Added "Defines" at the beginning. Added @since.
>>>
>>> javax.xml.namespace
>>>     Added @since.
>>>
>>> javax.xml.parsers
>>>     Rephrased, added a short description of the plugability layer.
>>>
>>> javax.xml.stream and javax.xml.stream.*
>>>     New package description.
>>>
>>> javax.xml.transform
>>>     Added javax.xml.transform.stax to the description.
>>>
>>> javax.xml.transform.dom
>>>     Format only.
>>>
>>> javax.xml.transform.sax
>>>     Removed from the 1st paragraph the summary that's redundant to the next few paragraphs, which made it consistent with the .dom package.   The last paragraph described an example that never existed. Rephrased the paragraph without mentioning an example.
>>>
>>> javax.xml.transform.stax
>>>     New
>>>
>>> javax.xml.transform.stream
>>>     The 1st statement is made consistent to that of .dom/sax/stax above
>>>
>>> javax.xml.validation
>>>     Format and minor wording changes. Under Support for additional schema langauges, I removed the words "as of JDK 1.5...".
>>>
>>> javax.xml.xpath
>>>     Format and minor wording changes.
>>>
>>> org.w3c.dom
>>>     Format only
>>>
>>> org.w3c.dom.bootstrap .events .ls .traversal .views
>>>     New package descriptions.
>>>
>>> org.w3c.dom.range
>>>     Removed the paragraphs copied from the DOM specification that states DOM is language-neutral and etc. since they have nothing to do with the Java package.
>>>
>>> org.xml.sax
>>>     minor wording changes. The starting sentence changed to start with "provides" to be consistent with the other packages. The last sentence "XMLReader implementations need not support them" is changed to "XMLReader implementations are not required to support them".
>>>
>>> org.xml.sax.ext, .helpers
>>>     Only the start, e.g. "Provides..."
>>>
>>> Thanks,
>>> Joe
>>>
>   
>    
>   Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com 
>
>
>


From igor.ignatyev at oracle.com  Wed May 24 05:17:16 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 23 May 2017 22:17:16 -0700
Subject: RFR(XS) : 8180895 :
 java/security/AccessController/DoPrivAccompliceTest.java has to be improved
Message-ID: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html
> 81 lines changed: 37 ins; 23 del; 21 mod; 

Hi all,

could you please review the fix which improves and refactors DoPrivAccompliceTest.java test?
the test had several issues:
 - it did not fail if the java spawned by JavaToolUtils::runJava exists w/ non-zero exit code
 - negative test case was not covered, i.e. the test did not check that if privileges are not granted to the right jar-file an exception is thrown
 - the test created files inside test.classes, which might interfere w/ other tests
 - the test uses JavaToolUtils testlibrary class to create a jar, start a jvm, which duplicates functionality of the common testlibrary and will be removed by 8180898[1]

webrev: http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180895
testing: affected tests

[1] https://bugs.openjdk.java.net/browse/JDK-8180898

Thanks,
-- Igor

From felix.yang at oracle.com  Wed May 24 07:16:55 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Wed, 24 May 2017 15:16:55 +0800
Subject: RFR 8087307/9, new tests for ServiceLoader updates for module
In-Reply-To: <52e0929c-6b65-7fd0-f06c-bc55112c100b@oracle.com>
References: 
 
 <52e0929c-6b65-7fd0-f06c-bc55112c100b@oracle.com>
Message-ID: <04182a67-1ecd-e859-d7c4-20d119049a40@oracle.com>

Hi all,

     updated tests according with comments. Also comments inline.

New webrev: http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.01/

Thanks,

Felix

On 2017/5/19 13:57, Hamlin Li wrote:
> Hi Felix,
>
> I have some comments as below:
>
>
> 1. Possible test gaps for Locating Order
>         1.1 providers in named module have high priority than 
> providers in unnamed
>         1.2 ServiceLoader.load?(ModuleLayer layer, Class service) 
> is not tested
This is a set of additional tests.  The above scenarios have been 
covered in existing j.u.ServiceLoader/modules/Basic.java

-Felix
> 2. Possible test gap for automatic module, it is not tested
>
Add a basic test for providers in automatic module. It leverages 
existing scripts implementations in other tests.

> 3. Could you remove unnecessary module dependency on java.scripting, 
> replace it with a customized module or java.base? it will make your 
> tests run under as many as conditions.
Good catch,thanks
-Felix
>
> 4. For [a|b]filesystem
>     could you use URLStreamHandlerProvider rather than 
> FileSystemProvider, it will make your test files(FileSystemForInstr, 
> AFileSystem, BFileSystem) more simple.
This is intended to leverage JDK built-in providers (jar, jrt) in 
Platform and Bootstrap classloaders. There is no explicit implementation 
for URLStreamHandlerProvider.
-Felix
>
> 5. MisUsesTest.java and missuse
>     missuses: miss => mis? (missuses => mis.uses)
>     Possible test gap: add similar use case for unnamed module?
A good question, but I think it is not necessary. The test is to cover 
missing "uses" in module descriptor with a service 
(URLStreamHandlerProvider) having no explicit implementation. It 
implicitly indicates that the "can use" check not-related with how it is 
implemented.

-Felix
>
> 6. OrderingWithInstrTest.java
>     Could you use jtreg tag "driver RedefineModuleAgent" rather than 
> "@run main/othervm OrderingWithInstrTest" to trigger the preparation 
> of test? and move createAgentJar() and main() into 
> RedefineModuleAgent.java.
Fixed, thanks.
-Felix
>
> 7. ReloadTest.java
>     The test success depends on execution order of tests, so need to 
> add priority=N to every @Test method, or separate tests into 2 
> classes, one for negative, one for normal tests.
The tests looks for me not depend on order. They only depend on setup 
method which is annotated with BeforeClass.
>
> 8. Some additional minor comments:
>     8.1 split module name with ".", for e.g. multiprovides => 
> multi.provides
I may keep the naming to be identical with existing ServiceLoader module 
tests.
>     8.2 wrap long lines, and revert unnecessary wrapping too, in 
> several files.
>     8.3 correct indent, e.g. in PermissionTest.java
>     8.4 Is default constructor "public ProviderX() { }" necessary in 
> multi.ProviderX ?
Resolved above, thanks

> 8.5 rename Service to OrderedService?
I may keep to be identical with existing ServiceLoader module tests.
-Felix
>
> Thank you
>
> -Hamlin
>
>
> On 2017/5/19 9:38, Felix Yang wrote:
>> Ping:)
>>
>> -Felix
>>> On 16 May 2017, at 4:59 PM, Felix Yang  wrote:
>>>
>>> Hi there,
>>>
>>>     please review the new tests added for ServiceLoader updates for 
>>> module system.
>>>
>>> Test bug:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8087307
>>>
>>> Webrev:
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8087307/webrev.00/
>>>
>>> Related product Changes:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8132026
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8047814
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>>
>


From daniel.fuchs at oracle.com  Wed May 24 08:39:36 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 May 2017 09:39:36 +0100
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
In-Reply-To: 
References: 
Message-ID: 

Hi Brian,

Because this test appears to change the time zone I think it
should run in its own VM. Unless there's a global othervm property
in TEST.properties that apply to all tests in this hierarchy?

best regards,

-- daniel

On 23/05/2017 23:55, Brian Burkhalter wrote:
> RFR thread re-directed from RFC thread [1].
>
> Create a sub-task [2] of [3] to create a test for the problem described in the main issue. The webrev [4] is with respect to the fix for the sub-task [2]. The ?@bug? tag in [2] has the issue ID of [3] which itself will be manually resolved as ?Cannot Reproduce? once Hg Updates has resolved [2] pursuant to the push.
>
> Thanks,
>
> Brian
>
> [1] RFC thread - http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047833.html
> [2] Sub-task - https://bugs.openjdk.java.net/browse/JDK-8180885
> [3] Main-issue https://bugs.openjdk.java.net/browse/JDK-6212869
> [4] Patch - http://cr.openjdk.java.net/~bpb/8180885/webrev.00/
>


From forax at univ-mlv.fr  Wed May 24 09:02:12 2017
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 May 2017 11:02:12 +0200 (CEST)
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
Message-ID: <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>

As a meta-comment, we should deprecate java.io.File (with no for removal),
java.nio.file.Path is a nice replacement so java.io.File should be used only for dealing with legacy code. 

regards,
R?mi

----- Mail original -----
> De: "Brian Burkhalter" 
> ?: "Stuart Marks" 
> Cc: core-libs-dev at openjdk.java.net
> Envoy?: Mardi 23 Mai 2017 23:27:48
> Objet: Re: JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

> On May 23, 2017, at 1:34 PM, Stuart Marks  wrote:
> 
>> Yes, this could be another non-normative change. You might even consider merging
>> it with the other bug (JDK-6791812), and possibly even labeling it as @apiNote.
>> 
>> As for the wording itself, I think the sentiment is correct, but it's trying to
>> pack a bit too much into a single sentence. Breaking it into two sentences
>> would probably be helpful.
> 
> Does this seem better? It folds 8180767 into 6791812.
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -928,11 +928,17 @@
>      * the granularity of the value depends on the underlying
>      * file system and may be larger.  For example, some
>      * file systems use time stamps in units of seconds.
> +     * Distinguishing an I/O exception from a zero return value may
> +     * also be accomplished by using the
> +     * {@link java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
> +     * Files.getLastModifiedTime} method.
>      *
>      * @return  A long value representing the time the file was
>      *          last modified, measured in milliseconds since the epoch
>      *          (00:00:00 GMT, January 1, 1970), or 0L if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs.  The value may
> +     *          be negative indicating the number of milliseconds before the
> +     *          epoch
> 
> I already verified that the generated javadoc is correct.
> 
> Thanks,
> 
> Brian

From huaming.li at oracle.com  Wed May 24 09:09:25 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 24 May 2017 17:09:25 +0800
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell tests
 to java
Message-ID: 

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8166142

webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/


Thank you

-Hamlin


From daniel.fuchs at oracle.com  Wed May 24 09:14:54 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 24 May 2017 10:14:54 +0100
Subject: 9 (test only) RFR: 8180279: java/net/httpclient/whitebox/Driver.java
 failed due to timeout
Message-ID: <26ac399a-98fb-b120-15ec-32e4d7375074@oracle.com>

Hi,

Please find below a test-only fix for:

8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
https://bugs.openjdk.java.net/browse/JDK-8180279

The failing testcase is RawChannelTest.

The test appears to be failing because of a flaw in the test logic which
allowed for a race condition between the client and the (fake) server.

http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/

What can be seen from the traces is that when the test fails,
the client is writing bytes to the server and the server is
writing bytes to the client but the client never wakes up to read
the bytes. It can also be seen that the client has found some bytes
in the 'initialByteBuffer' of the RawChannel.

What happens here is that the initialRawBuffer has read all
the bytes that were available in the channel - and the server
is waiting for the client to stall before writing more bytes.
But the code that will unblock the server is never executed,
because it is triggered by a selector read event, and the
channel is already dry so the event is never fired.

I reworked the tests a bit, adding two new CountDownLatches to
ensure that 1. the client will always find initial bytes in the
channel's initialByteBuffer (the intermittent condition that made
the test fail) and 2. the server will wait for the client to
signal that it has got the initial bytes, and write an additional
chunk of bytes that will trigger the selector read (which will
in turn ensure that the client will unblock the server later on).

best regards,

-- daniel

From huaming.li at oracle.com  Wed May 24 09:18:11 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 24 May 2017 17:18:11 +0800
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
 <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
 <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>
Message-ID: 

Hi Roger, Brent,

Thank you for reviewing, please check new webrev at : 
http://cr.openjdk.java.net/~mli/8180732/webrev.01/

Thank you

-Hamlin

On 2017/5/24 1:05, Roger Riggs wrote:
> Hi,
>
> Security.java: 25-27: Style conventions call for " * " on every line 
> in comment blocks.
>
> On 5/23/2017 12:53 PM, Brent Christian wrote:
>> Hi, Hamlin
>>
>> That looks pretty good.  A couple comments:
>>
>> * If I'm not mistaken, main/othervm/policy=... is sufficient to 
>> enable the default security manager, and specifying 
>> "-Djava.security.manager" is unnecessary.
>>
>> * Please add 8180732 to the @bug tag
>
> I'm not sure this adds much because the bug report just is moving to 
> test to the open repo.
>
>>
>> You will also need approval from a JDK 10 Reviewer.
>
> Roger
>
>>
>> Thanks,
>> -Brent
>>
>> On 5/21/17 9:26 PM, Hamlin Li wrote:
>>> Would you please review the below patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
>>> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>>>
>>> Thank you
>>> -Hamlin
>


From huaming.li at oracle.com  Wed May 24 09:30:02 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 24 May 2017 17:30:02 +0800
Subject: 9 doc-api-only RFR of JDK-8180807: java.io.Serializable class-level
 readObject description error
Message-ID: 

Would you please review the below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8180807

webrev: http://cr.openjdk.java.net/~mli/8180807/webrev.00/


Thank you

-Hamlin


From amy.lu at oracle.com  Wed May 24 10:22:51 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 24 May 2017 18:22:51 +0800
Subject: JDK 10 RFR of JDK-8173905: Test
 tools/jar/multiRelease/RuntimeTest.java fails under JDK 10
Message-ID: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>

After the version update to "10" in JDK 10 ( JDK-8029942 ), test 
tools/jar/multiRelease/RuntimeTest.java starts failing because the 
release version is hardcoded, not only in the test itself, but also in 
test data files for the jar that tested on.

I've updated the test to generate those data files on the fly based on 
the template and $version, and the hardcoding of release version also be 
replaced by the value based on Runtime.version().major(). In this way, 
test don't need to be updated again for JDK 11.

Compared the newly generated "data" files with the old "data", no diff 
(except the version).

bug: https://bugs.openjdk.java.net/browse/JDK-8173905
webrev: http://cr.openjdk.java.net/~amlu/8173905/webrev.00/

Tested on all platforms.

Thanks,
Amy

From claes.redestad at oracle.com  Wed May 24 11:29:48 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Wed, 24 May 2017 13:29:48 +0200
Subject: JDK 10 RFR of JDK-8173905: Test
 tools/jar/multiRelease/RuntimeTest.java fails under JDK 10
In-Reply-To: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
References: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
Message-ID: <1ef804e8-b04d-49cd-b4ab-63048e1aef0e@oracle.com>

Hi Amy,

On 05/24/2017 12:22 PM, Amy Lu wrote:
> After the version update to "10" in JDK 10 ( JDK-8029942 ), test 
> tools/jar/multiRelease/RuntimeTest.java starts failing because the 
> release version is hardcoded, not only in the test itself, but also in 
> test data files for the jar that tested on.
>
> I've updated the test to generate those data files on the fly based on 
> the template and $version, and the hardcoding of release version also 
> be replaced by the value based on Runtime.version().major(). In this 
> way, test don't need to be updated again for JDK 11.
>
> Compared the newly generated "data" files with the old "data", no diff 
> (except the version).
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8173905
> webrev: http://cr.openjdk.java.net/~amlu/8173905/webrev.00/

looks good to me!

(I prefer the more space:ious style around array initializers in the 
pre-existing code, though)

/Claes

>
> Tested on all platforms.
>
> Thanks,
> Amy


From chris.hegarty at oracle.com  Wed May 24 11:53:34 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 24 May 2017 12:53:34 +0100
Subject: 9 doc-api-only RFR of JDK-8180807: java.io.Serializable
 class-level readObject description error
In-Reply-To: 
References: 
Message-ID: <71B998A4-16C1-45B5-B90F-A78844FA33A9@oracle.com>


> On 24 May 2017, at 10:30, Hamlin Li  wrote:
> 
> Would you please review the below patch?
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8180807
> 
> webrev: http://cr.openjdk.java.net/~mli/8180807/webrev.00/

The updated wording, lifted from ObjectInputStream, seems reasonable.

This seems like a day-one cut?n?paste error. I don?t think that it changes the
specification in a normative way, so a CSR should not strictly be necessary.

-Chris. 

From brian.burkhalter at oracle.com  Wed May 24 14:15:10 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 24 May 2017 07:15:10 -0700
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
In-Reply-To: 
References: 
 
Message-ID: 

Hi Daniel,

That is a good point. I?ll run it through a regression test job with /othervm and see what happens.

Thanks,

Brian

On May 24, 2017, at 1:39 AM, Daniel Fuchs  wrote:

> Because this test appears to change the time zone I think it
> should run in its own VM. Unless there's a global othervm property
> in TEST.properties that apply to all tests in this hierarchy?


From brian.burkhalter at oracle.com  Wed May 24 15:08:04 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 24 May 2017 08:08:04 -0700
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
In-Reply-To: 
References: 
 
 
Message-ID: <31C073E6-BBE2-4B89-A278-45043867C66F@oracle.com>

Hi Daniel,

Regression test job succeeded for java.io on all platforms using @run main/othervm.

Thanks,

Brian

On May 24, 2017, at 7:15 AM, Brian Burkhalter  wrote:

> That is a good point. I?ll run it through a regression test job with /othervm and see what happens.


From brent.christian at oracle.com  Wed May 24 15:59:52 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 24 May 2017 08:59:52 -0700
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: 
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
 <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
 <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>
 
Message-ID: 

Looks fine to me, Hamlin.

Thanks,
-Brent

On 5/24/17 2:18 AM, Hamlin Li wrote:
> Hi Roger, Brent,
>
> Thank you for reviewing, please check new webrev at :
> http://cr.openjdk.java.net/~mli/8180732/webrev.01/
>
> Thank you
>
> -Hamlin
>
> On 2017/5/24 1:05, Roger Riggs wrote:
>> Hi,
>>
>> Security.java: 25-27: Style conventions call for " * " on every line
>> in comment blocks.
>>
>> On 5/23/2017 12:53 PM, Brent Christian wrote:
>>> Hi, Hamlin
>>>
>>> That looks pretty good.  A couple comments:
>>>
>>> * If I'm not mistaken, main/othervm/policy=... is sufficient to
>>> enable the default security manager, and specifying
>>> "-Djava.security.manager" is unnecessary.
>>>
>>> * Please add 8180732 to the @bug tag
>>
>> I'm not sure this adds much because the bug report just is moving to
>> test to the open repo.
>>
>>>
>>> You will also need approval from a JDK 10 Reviewer.
>>
>> Roger
>>
>>>
>>> Thanks,
>>> -Brent
>>>
>>> On 5/21/17 9:26 PM, Hamlin Li wrote:
>>>> Would you please review the below patch?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
>>>> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>>>>
>>>> Thank you
>>>> -Hamlin
>>
>

From paul.sandoz at oracle.com  Wed May 24 16:38:50 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 24 May 2017 09:38:50 -0700
Subject: JDK 10 RFR of JDK-8173905: Test
 tools/jar/multiRelease/RuntimeTest.java fails under JDK 10
In-Reply-To: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
References: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
Message-ID: <752377E3-DB19-4AC5-BD20-DF5A559E1A6D@oracle.com>

Hi Amy,

Looks good,

A minor suggestion i would rename the template files to be the   + ?.template?. Then you don?t need the map ?templateSourceMap?, and it becomes clearer what files the templates are associated with. Also i would try and retain the same directory structure as well e.g. recursively traversing a directory transforming any file whose name ends with template into a concrete file in versioned area of the same relative path.

Paul.

> On 24 May 2017, at 03:22, Amy Lu  wrote:
> 
> After the version update to "10" in JDK 10 ( JDK-8029942 ), test tools/jar/multiRelease/RuntimeTest.java starts failing because the release version is hardcoded, not only in the test itself, but also in test data files for the jar that tested on.
> 
> I've updated the test to generate those data files on the fly based on the template and $version, and the hardcoding of release version also be replaced by the value based on Runtime.version().major(). In this way, test don't need to be updated again for JDK 11.
> 
> Compared the newly generated "data" files with the old "data", no diff (except the version).
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8173905
> webrev: http://cr.openjdk.java.net/~amlu/8173905/webrev.00/
> 
> Tested on all platforms.
> 
> Thanks,
> Amy


From Roger.Riggs at Oracle.com  Wed May 24 17:06:43 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 24 May 2017 13:06:43 -0400
Subject: 9 doc-api-only RFR of JDK-8180807: java.io.Serializable
 class-level readObject description error
In-Reply-To: <71B998A4-16C1-45B5-B90F-A78844FA33A9@oracle.com>
References: 
 <71B998A4-16C1-45B5-B90F-A78844FA33A9@oracle.com>
Message-ID: <01078cf7-1376-7c9a-6281-3db95e8df9e0@Oracle.com>

+1

On 5/24/2017 7:53 AM, Chris Hegarty wrote:
>> On 24 May 2017, at 10:30, Hamlin Li  wrote:
>>
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8180807
>>
>> webrev: http://cr.openjdk.java.net/~mli/8180807/webrev.00/
> The updated wording, lifted from ObjectInputStream, seems reasonable.
>
> This seems like a day-one cut?n?paste error. I don?t think that it changes the
> specification in a normative way, so a CSR should not strictly be necessary.
>
> -Chris.


From Roger.Riggs at Oracle.com  Wed May 24 17:24:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 24 May 2017 13:24:30 -0400
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
In-Reply-To: <31C073E6-BBE2-4B89-A278-45043867C66F@oracle.com>
References: 
 
 
 <31C073E6-BBE2-4B89-A278-45043867C66F@oracle.com>
Message-ID: <31443d9b-c93f-1f95-4fab-662780177b4c@Oracle.com>

+1

Though the webrev does not show the @run main/othervm.

Roger


On 5/24/2017 11:08 AM, Brian Burkhalter wrote:
> Hi Daniel,
>
> Regression test job succeeded for java.io on all platforms using @run main/othervm.
>
> Thanks,
>
> Brian
>
> On May 24, 2017, at 7:15 AM, Brian Burkhalter  wrote:
>
>> That is a good point. I?ll run it through a regression test job with /othervm and see what happens.


From rob.mckenna at oracle.com  Wed May 24 17:33:10 2017
From: rob.mckenna at oracle.com (Rob McKenna)
Date: Wed, 24 May 2017 18:33:10 +0100
Subject: RFR:     8180949
Message-ID: <20170524173310.GC4024@vimes>

Hi folks,

Looking for a review for this fix which repairs a push containing an
older revision of the approved change:

http://cr.openjdk.java.net/~robm/8180949/webrev.01/

    -Rob


From Roger.Riggs at Oracle.com  Wed May 24 17:39:07 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 24 May 2017 13:39:07 -0400
Subject: RFR: 8180949
In-Reply-To: <20170524173310.GC4024@vimes>
References: <20170524173310.GC4024@vimes>
Message-ID: 

Hi Rob,

Looks fine.

Roger


On 5/24/2017 1:33 PM, Rob McKenna wrote:
> Hi folks,
>
> Looking for a review for this fix which repairs a push containing an
> older revision of the approved change:
>
> http://cr.openjdk.java.net/~robm/8180949/webrev.01/
>
>      -Rob
>


From brian.burkhalter at oracle.com  Wed May 24 17:41:01 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 24 May 2017 10:41:01 -0700
Subject: JDK 9 test-only RFR of 8180885: Create test to detect if
 TimeZone.setDefault affects File.setLastModifiedTime
In-Reply-To: <31443d9b-c93f-1f95-4fab-662780177b4c@Oracle.com>
References: 
 
 
 <31C073E6-BBE2-4B89-A278-45043867C66F@oracle.com>
 <31443d9b-c93f-1f95-4fab-662780177b4c@Oracle.com>
Message-ID: <9DAE5F3F-3470-406A-AD69-BB243B8D3739@oracle.com>

This one does:

http://cr.openjdk.java.net/~bpb/8180885/webrev.01/

I?ll consider this reviewed unless told otherwise.

Thanks,

Brian

On May 24, 2017, at 10:24 AM, Roger Riggs  wrote:

> +1
> 
> Though the webrev does not show the @run main/othervm.
> 
> Roger
> 
> 
> On 5/24/2017 11:08 AM, Brian Burkhalter wrote:
>> Hi Daniel,
>> 
>> Regression test job succeeded for java.io on all platforms using @run main/othervm.
>> 
>> Thanks,
>> 
>> Brian
>> 
>> On May 24, 2017, at 7:15 AM, Brian Burkhalter  wrote:
>> 
>>> That is a good point. I?ll run it through a regression test job with /othervm and see what happens.
> 


From viktor.klang at gmail.com  Mon May 22 19:58:37 2017
From: viktor.klang at gmail.com (Viktor Klang)
Date: Mon, 22 May 2017 21:58:37 +0200
Subject: [concurrency-interest] curious if there is a Local.java in the
 works for CompletableFutures like scala has
In-Reply-To: 
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
 
Message-ID: 

Ah, this question comes up once in a while, the biggest questions in my
mind are:
1) It's easy to lose context when intermediate libraries/Executors get
involved, how does the developer detect and fix it?
2) It's unclear what fan-in behaviors like zip, merge etc mean in terms of
what the local values should be?
3) It's unclear what fan-out behaviors like split, route, broadcast mean in
terms of what the local values should be?

On Mon, May 22, 2017 at 9:44 PM, Martin Buchholz 
wrote:

> There's not likely to be any support for local context anywhere in
> java.util.concurrent, but it seems not too hard to roll your own support
> with a custom executor to be used with CompletableFuture that kept track of
> any local context.
>
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo 
> wrote:
>
>> General questions on concurrency in Java should be asked here:
>>
>>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> > On 18 May 2017, at 21:57, Dean Hiller  wrote:
>> >
>> > Way more detail here...
>> >
>> > http://stackoverflow.com/questions/37933713/does-completable
>> future-have-a-corresponding-local-context
>> >
>> > So I was wondering if this was going to be added at some point to the
>> jdk
>> > as I could not figure out how to set something so it was still
>> available on
>> > the thread at a later time when traversing async thenCompose,
>> thenAccept.
>> >
>> > thanks,
>> > Dean
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>


-- 
Cheers,
?

From jhump at bluegosling.com  Mon May 22 20:01:41 2017
From: jhump at bluegosling.com (Josh Humphries)
Date: Mon, 22 May 2017 16:01:41 -0400
Subject: [concurrency-interest] curious if there is a Local.java in the
 works for CompletableFutures like scala has
In-Reply-To: 
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
 
Message-ID: 

Pavel,
It sounds like you want something like this

and this
,
and specify the former as the Executor parameter to the CompletionStage
chaining methods. Java 9 adds new overridable methods to CompletableFuture
so that you could sub-class it and override defaultExecutor(), so the
context is always correctly propagated for your sub-classed kind of future.

----
*Josh Humphries*
jhump at bluegosling.com

On Mon, May 22, 2017 at 3:44 PM, Martin Buchholz 
wrote:

> There's not likely to be any support for local context anywhere in
> java.util.concurrent, but it seems not too hard to roll your own support
> with a custom executor to be used with CompletableFuture that kept track of
> any local context.
>
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo 
> wrote:
>
>> General questions on concurrency in Java should be asked here:
>>
>>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> > On 18 May 2017, at 21:57, Dean Hiller  wrote:
>> >
>> > Way more detail here...
>> >
>> > http://stackoverflow.com/questions/37933713/does-completable
>> future-have-a-corresponding-local-context
>> >
>> > So I was wondering if this was going to be added at some point to the
>> jdk
>> > as I could not figure out how to set something so it was still
>> available on
>> > the thread at a later time when traversing async thenCompose,
>> thenAccept.
>> >
>> > thanks,
>> > Dean
>>
>>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>

From oleksandr.otenko at gmail.com  Tue May 23 09:12:39 2017
From: oleksandr.otenko at gmail.com (Alex Otenko)
Date: Tue, 23 May 2017 10:12:39 +0100
Subject: [concurrency-interest] curious if there is a Local.java in the
 works for CompletableFutures like scala has
In-Reply-To: 
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
 
Message-ID: 

Why would someone want to rely on state they cannot control?

Is the idea to subvert some API that does not provide a way to pass state? This is strange especially in the context of Scala, where you can easily form tuples.

Alex

> On 22 May 2017, at 20:44, Martin Buchholz  wrote:
> 
> There's not likely to be any support for local context anywhere in java.util.concurrent, but it seems not too hard to roll your own support with a custom executor to be used with CompletableFuture that kept track of any local context.
> 
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo > wrote:
> General questions on concurrency in Java should be asked here:
> 
>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest 
> 
> > On 18 May 2017, at 21:57, Dean Hiller > wrote:
> >
> > Way more detail here...
> >
> > http://stackoverflow.com/questions/37933713/does-completablefuture-have-a-corresponding-local-context 
> >
> > So I was wondering if this was going to be added at some point to the jdk
> > as I could not figure out how to set something so it was still available on
> > the thread at a later time when traversing async thenCompose, thenAccept.
> >
> > thanks,
> > Dean
> 
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest


From dhiller at twitter.com  Tue May 23 16:20:10 2017
From: dhiller at twitter.com (Dean Hiller)
Date: Tue, 23 May 2017 10:20:10 -0600
Subject: [concurrency-interest] curious if there is a Local.java in the
 works for CompletableFutures like scala has
In-Reply-To: 
References: 
 <45779887-D9E2-463B-948A-458BB6F02CDA@oracle.com>
 
 
Message-ID: 

All, this post is all about 3rd party code that I do not control so
therefore the solutions above do not work as those libraries may predate my
library.  more specifically.....

Martin,
   If I roll my own slf4j MDC only works in my code and stops working in
3rd party code!  because the 3rd party code does not transfer the context.

Viktor,
  You hit the head on the nail with "It's easy to lose context when
intermediate libraries/Executors".  This is solved on twitter futures until
we hit libraries not using twitter futures because no matter the executor,
the future transfers the context for us the way it was written.

   "It's unclear what fan-in behaviors like zip, merge etc mean in terms of
what the local values should be?"
This is a very good question.  I wonder what twitter futures do here.  I
would be ok with dropping the context in this case or combining it.  I do
not really care yet here since I have not run into it but it is a very good
question and would need a lot of thought

Josh,
   I cannot expect all 3rd party libraries that are brought in will be
using ContextPropagatingExecutor so that solution breaks down as Viktor
eludes to.

Alex,
   tuples do not solve the issue.  in fact twitter futures have a
Local.scala file that does solve the issue.  The main issue is 3rd party
code and having the context continue into "unknown code" using
CompletableFuture.  I cannot control that code BUT want every log.info in
that code to use and log the request id.  it is awesome at twitter as I can
just follow that request id in the logs.  If CompletableFuture had such a
context, I could transfer this info into it and into the 3rd party java
libraries.

I am writing a webserver for fun based on CompletableFutures and therefore
cannot control the controllers as the app developer writes that and the
request id stops getting logged on the request path which is mostly
.thenApply and .thenCompose.  even if the Controllers do you my future,
they will bring in libraries NOT using my future :(

thanks
Dean





On Tue, May 23, 2017 at 3:12 AM, Alex Otenko 
wrote:

> Why would someone want to rely on state they cannot control?
>
> Is the idea to subvert some API that does not provide a way to pass state?
> This is strange especially in the context of Scala, where you can easily
> form tuples.
>
> Alex
>
> On 22 May 2017, at 20:44, Martin Buchholz  wrote:
>
> There's not likely to be any support for local context anywhere in
> java.util.concurrent, but it seems not too hard to roll your own support
> with a custom executor to be used with CompletableFuture that kept track of
> any local context.
>
> On Fri, May 19, 2017 at 1:16 PM, Pavel Rappo 
> wrote:
>
>> General questions on concurrency in Java should be asked here:
>>
>>    http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
>>
>> > On 18 May 2017, at 21:57, Dean Hiller  wrote:
>> >
>> > Way more detail here...
>> >
>> > http://stackoverflow.com/questions/37933713/does-completable
>> future-have-a-corresponding-local-context
>> >
>> > So I was wondering if this was going to be added at some point to the
>> jdk
>> > as I could not figure out how to set something so it was still
>> available on
>> > the thread at a later time when traversing async thenCompose,
>> thenAccept.
>> >
>> > thanks,
>> > Dean
>>
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
>
>

From paul.sandoz at oracle.com  Wed May 24 18:41:43 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 24 May 2017 11:41:43 -0700
Subject: RFR(S) : 8180724: move ModuleInfoMaker to the top level
 testlibrary
In-Reply-To: 
References: 
Message-ID: <8B28DAF3-57DD-4734-9648-7DE90ECBE5D4@oracle.com>

+1
Paul.

> On 19 May 2017, at 16:29, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
>> 295 lines changed: 139 ins; 140 del; 16 mod;
> 
> Hi all,
> 
> could you please review this small fix which moves ModuleInfoMaker class from jdk testlibrary to the top level testlibrary? since ModuleInfoMaker depends on CompilerUtil and thus on jdk.compiler module, it has been placed to jdk.test.lib.compiler package to avoid unneeded module dependency in tests. HashesTest has been updated to use ModuleInfoMaker::compile instead of using CompilerUtils::compile directly.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180724
> testing: affected tests (jdk/test/tools/launcher)
> 
> Thanks,
> -- Igor


From paul.sandoz at oracle.com  Wed May 24 18:42:31 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 24 May 2017 11:42:31 -0700
Subject: RFR(XS): 8180802 : move
 jdk.testlibrary.management.ThreadMXBeanTool to top level testlibrary
In-Reply-To: <987B0472-4322-4B46-A9CF-C0BE22D51D67@oracle.com>
References: <987B0472-4322-4B46-A9CF-C0BE22D51D67@oracle.com>
Message-ID: <6C0208EA-A2F2-4E0A-B62E-C0BA79AC11F1@oracle.com>

+1

Paul.

> On 22 May 2017, at 15:49, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180802/webrev.00/index.html
>> 143 lines changed: 71 ins; 72 del; 0 mod;
> Hi all,
> 
> could you please review this patch which moves ThreadMXBeanTool from jdk testlibrary to the top level testlibrary?
> please be aware that there are tests outside jdk repository which use this class. these tests will be updated accordingly.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180802/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180802
> 
> Thanks,
> -- Igor


From Roger.Riggs at Oracle.com  Wed May 24 18:53:29 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 24 May 2017 14:53:29 -0400
Subject: Please indicate target repo in review requests
In-Reply-To: <6C0208EA-A2F2-4E0A-B62E-C0BA79AC11F1@oracle.com>
References: <987B0472-4322-4B46-A9CF-C0BE22D51D67@oracle.com>
 <6C0208EA-A2F2-4E0A-B62E-C0BA79AC11F1@oracle.com>
Message-ID: 

I supposed reviews for JDK 9 are the exception now but it would be 
convenient if the subject line included some indication of the JDK 10 
target.

Thanks, Roger

From john.r.rose at oracle.com  Wed May 24 20:11:42 2017
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 24 May 2017 13:11:42 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>
References: 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
 <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>
Message-ID: <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>

On May 24, 2017, at 2:02 AM, Remi Forax  wrote:
> 
> As a meta-comment, we should deprecate java.io.File (with no for removal),
> java.nio.file.Path is a nice replacement so java.io.File should be used only for dealing with legacy code. 

This seems right to me.  As a casual user of core-libs I would be
less likely to use File in new code, and take a second to look for the
better replacement, if it were in fact solidly deprecated.

Could someone file a bug/rfe to follow this up?  Debate about the ultimate
worthiness of File could then be attached to the bug.

? John


From Alan.Bateman at oracle.com  Wed May 24 20:45:02 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 24 May 2017 21:45:02 +0100
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>
References: 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
 <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>
 <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>
Message-ID: 

On 24/05/2017 21:11, John Rose wrote:

> :
> This seems right to me.  As a casual user of core-libs I would be
> less likely to use File in new code, and take a second to look for the
> better replacement, if it were in fact solidly deprecated.
>
> Could someone file a bug/rfe to follow this up?  Debate about the ultimate
> worthiness of File could then be attached to the bug.
There was deliberate decision back a few years back not to deprecate 
File. At the time then the bar to add @Deprecated was very high and an 
API needed to be very toxic. Looking at now then several methods could 
be candidates to deprecate as they are inherently broken, deprecating 
the entire class might be too much. One other thing that was tried out 
at the time was to replace the implementation of java.io.File and 
friends to use the new code. This had the benefit of fixing dozens of 
issues (esp. on Windows) in one flick of the wrist. Sadly, subtle 
benefit changes to fix issues are also compatibility issues when dealing 
with an old API. So we chickened out from going there too.

-Alan


From igor.ignatyev at oracle.com  Wed May 24 21:18:11 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 24 May 2017 14:18:11 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the
 top level test library
In-Reply-To: 
References: 
 <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
 
Message-ID: <6F741C05-DFC8-47DF-89D5-6DD4EB53970C@oracle.com>

Hi Paul,

do you have other comments on this or can I consider it as reviewed?

Thanks,
-- Igor
> On May 18, 2017, at 10:36 AM, Igor Ignatyev  wrote:
> 
> Paul,
> 
> doh, too many review requests in parallel, thank you for providing the correct links.
> 
> yes, you are right j/l/m/ThreadMXBean/Locks test does not depend on jdk testlibrary anymore, I have cleaned it up and retested:
> 
>>   * @author  Mandy Chung
>>   * @author  Jaroslav Bachorik
>>   *
>> - * @library /lib/testlibrary /test/lib
>> + * @library /test/lib
>>   *
>> - * @build jdk.testlibrary.*
>>   * @run main/othervm Locks
>>   */
>>  import java.lang.management.*;
> 
> Thanks,
> -- Igor
> 
>> On May 17, 2017, at 5:13 PM, Paul Sandoz > wrote:
>> 
>> 
>> It?s this one :-)
>> 
>>   https://bugs.openjdk.java.net/browse/JDK-8180399 
>>   http://cr.openjdk.java.net/~iignatyev/8180399/webrev.00/ 
>> 
>> Does the Locks test need to depend on stuff in /lib/testlibrary ?
>> 
>> Paul.
>> 
>>> On 16 May 2017, at 21:21, Igor Ignatyev > wrote:
>>> 
>>> http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html 
>>>> 186 lines changed: 87 ins; 90 del; 9 mod; 
>>> 
>>> Hi all,
>>> 
>>> could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library?
>>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>>> 
>>> webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html 
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180397 
>>> testing: affected tests
>>> 
>>> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327 
>>> 
>>> Thanks,
>>> -- Igor
>>> 
>>> 
>> 
> 


From mandy.chung at oracle.com  Wed May 24 21:19:06 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 May 2017 14:19:06 -0700
Subject: RFR(S) : 8180724: move ModuleInfoMaker to the top level
 testlibrary
In-Reply-To: 
References: 
Message-ID: <1C3BAF15-6BFA-4A6C-8C07-D455206B2569@oracle.com>


> On May 19, 2017, at 4:29 PM, Igor Ignatyev  wrote:
> 
> could you please review this small fix which moves ModuleInfoMaker class from jdk testlibrary to the top level testlibrary? since ModuleInfoMaker depends on CompilerUtil and thus on jdk.compiler module, it has been placed to jdk.test.lib.compiler package to avoid unneeded module dependency in tests. HashesTest has been updated to use ModuleInfoMaker::compile instead of using CompilerUtils::compile directly.
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180724
> testing: affected tests (jdk/test/tools/launcher)

jdk/test/tools/jmod/hashes/HashesTest.java
  Nit: can you keep line 307-309, 386-387 unchanged?

Otherwise, looks fine.
Mandy


From mandy.chung at oracle.com  Wed May 24 21:25:53 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 24 May 2017 14:25:53 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the
 top level test library
In-Reply-To: <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
References: 
 <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
Message-ID: <021747AE-3B39-4F05-AA0D-BD7945130FAE@oracle.com>

I suggest to rename it to jdk.test.lib.LockFreeLogger.  It does not use java.util.logging and it could be in the same package as the other utility.

Mandy

> On May 17, 2017, at 5:13 PM, Paul Sandoz  wrote:
> 
> 
> It?s this one :-)
> 
>  https://bugs.openjdk.java.net/browse/JDK-8180399 
>  http://cr.openjdk.java.net/~iignatyev/8180399/webrev.00/ 
> 
> Does the Locks test need to depend on stuff in /lib/testlibrary ?
> 
> Paul.
> 
>> On 16 May 2017, at 21:21, Igor Ignatyev  wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180399/webrev.00/index.html
>>> 186 lines changed: 87 ins; 90 del; 9 mod;
>> 
>> Hi all,
>> 
>> could you please review this small patch which moves LockFreeLogManager class from jdk test library to the top level test library?
>> this fix is a part of ongoing effort on merging and cleaning up our test libraries[1].
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180397/webrev.00/index.html
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8180397
>> testing: affected tests
>> 
>> [1]  https://bugs.openjdk.java.net/browse/JDK-8075327
>> 
>> Thanks,
>> -- Igor
>> 
>> 
> 


From paul.sandoz at oracle.com  Wed May 24 22:02:08 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Wed, 24 May 2017 15:02:08 -0700
Subject: RFR(S) : 8180399 : move jdk.testlibrary.LockFreeLogManager to the
 top level test library
In-Reply-To: <6F741C05-DFC8-47DF-89D5-6DD4EB53970C@oracle.com>
References: 
 <17FE9311-B10C-426B-ACB5-FD52892282A1@oracle.com>
 
 <6F741C05-DFC8-47DF-89D5-6DD4EB53970C@oracle.com>
Message-ID: <753BC65A-85F3-427F-92B1-5E393942ABC3@oracle.com>


> On 24 May 2017, at 14:18, Igor Ignatyev  wrote:
> 
> Hi Paul,
> 
> do you have other comments on this or can I consider it as reviewed?
> 

The only further comment i have is i like Mandy?s recent suggestion.

Paul.

From igor.ignatyev at oracle.com  Wed May 24 22:08:32 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 24 May 2017 15:08:32 -0700
Subject: RFR(S) : 8180724: move ModuleInfoMaker to the top level
 testlibrary
In-Reply-To: <1C3BAF15-6BFA-4A6C-8C07-D455206B2569@oracle.com>
References: 
 <1C3BAF15-6BFA-4A6C-8C07-D455206B2569@oracle.com>
Message-ID: <8AEC691E-CE57-41EB-A62F-AA31135DEA21@oracle.com>

sure, if you prefer that style more, I'll undo these changes before pushing.
thanks for review.

-- Igor

> On May 24, 2017, at 2:19 PM, Mandy Chung  wrote:
> 
> 
>> On May 19, 2017, at 4:29 PM, Igor Ignatyev  wrote:
>> 
>> could you please review this small fix which moves ModuleInfoMaker class from jdk testlibrary to the top level testlibrary? since ModuleInfoMaker depends on CompilerUtil and thus on jdk.compiler module, it has been placed to jdk.test.lib.compiler package to avoid unneeded module dependency in tests. HashesTest has been updated to use ModuleInfoMaker::compile instead of using CompilerUtils::compile directly.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180724/webrev.00/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8180724
>> testing: affected tests (jdk/test/tools/launcher)
> 
> jdk/test/tools/jmod/hashes/HashesTest.java
>  Nit: can you keep line 307-309, 386-387 unchanged?
> 
> Otherwise, looks fine.
> Mandy
> 


From huaming.li at oracle.com  Thu May 25 02:02:17 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 25 May 2017 10:02:17 +0800
Subject: 9 doc-api-only RFR of JDK-8180807: java.io.Serializable
 class-level readObject description error
In-Reply-To: <01078cf7-1376-7c9a-6281-3db95e8df9e0@Oracle.com>
References: 
 <71B998A4-16C1-45B5-B90F-A78844FA33A9@oracle.com>
 <01078cf7-1376-7c9a-6281-3db95e8df9e0@Oracle.com>
Message-ID: <2a6ece5c-b3d1-f299-1dd3-39792cd52ee8@oracle.com>

Got it, will push the change soon.

Thank you

-Hamlin


On 2017/5/25 1:06, Roger Riggs wrote:
> +1
>
> On 5/24/2017 7:53 AM, Chris Hegarty wrote:
>>> On 24 May 2017, at 10:30, Hamlin Li  wrote:
>>>
>>> Would you please review the below patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180807
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8180807/webrev.00/
>> The updated wording, lifted from ObjectInputStream, seems reasonable.
>>
>> This seems like a day-one cut?n?paste error. I don?t think that it 
>> changes the
>> specification in a normative way, so a CSR should not strictly be 
>> necessary.
>>
>> -Chris.
>


From huaming.li at oracle.com  Thu May 25 02:23:50 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 25 May 2017 10:23:50 +0800
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: 
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
 <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
 <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>
 
 
Message-ID: <449800b5-f64d-dd57-4c9e-171b059cae27@oracle.com>

Thank you for review Brent.

I still need a official reviewer to review the change.

Thank you

-Hamlin


On 2017/5/24 23:59, Brent Christian wrote:
> Looks fine to me, Hamlin.
>
> Thanks,
> -Brent
>
> On 5/24/17 2:18 AM, Hamlin Li wrote:
>> Hi Roger, Brent,
>>
>> Thank you for reviewing, please check new webrev at :
>> http://cr.openjdk.java.net/~mli/8180732/webrev.01/
>>
>> Thank you
>>
>> -Hamlin
>>
>> On 2017/5/24 1:05, Roger Riggs wrote:
>>> Hi,
>>>
>>> Security.java: 25-27: Style conventions call for " * " on every line
>>> in comment blocks.
>>>
>>> On 5/23/2017 12:53 PM, Brent Christian wrote:
>>>> Hi, Hamlin
>>>>
>>>> That looks pretty good.  A couple comments:
>>>>
>>>> * If I'm not mistaken, main/othervm/policy=... is sufficient to
>>>> enable the default security manager, and specifying
>>>> "-Djava.security.manager" is unnecessary.
>>>>
>>>> * Please add 8180732 to the @bug tag
>>>
>>> I'm not sure this adds much because the bug report just is moving to
>>> test to the open repo.
>>>
>>>>
>>>> You will also need approval from a JDK 10 Reviewer.
>>>
>>> Roger
>>>
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> On 5/21/17 9:26 PM, Hamlin Li wrote:
>>>>> Would you please review the below patch?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
>>>>> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>
>>


From pavel.rappo at oracle.com  Thu May 25 07:53:17 2017
From: pavel.rappo at oracle.com (Pavel Rappo)
Date: Thu, 25 May 2017 10:53:17 +0300
Subject: 9 (test only) RFR: 8180279:
 java/net/httpclient/whitebox/Driver.java failed due to timeout
In-Reply-To: <26ac399a-98fb-b120-15ec-32e4d7375074@oracle.com>
References: <26ac399a-98fb-b120-15ec-32e4d7375074@oracle.com>
Message-ID: 

Daniel, thanks for taking care of this! Looks good.

> On 24 May 2017, at 12:14, Daniel Fuchs  wrote:
> 
> Hi,
> 
> Please find below a test-only fix for:
> 
> 8180279: java/net/httpclient/whitebox/Driver.java failed due to timeout
> https://bugs.openjdk.java.net/browse/JDK-8180279
> 
> The failing testcase is RawChannelTest.
> 
> The test appears to be failing because of a flaw in the test logic which
> allowed for a race condition between the client and the (fake) server.
> 
> http://cr.openjdk.java.net/~dfuchs/webrev_8180279/webrev.00/
> 
> What can be seen from the traces is that when the test fails,
> the client is writing bytes to the server and the server is
> writing bytes to the client but the client never wakes up to read
> the bytes. It can also be seen that the client has found some bytes
> in the 'initialByteBuffer' of the RawChannel.
> 
> What happens here is that the initialRawBuffer has read all
> the bytes that were available in the channel - and the server
> is waiting for the client to stall before writing more bytes.
> But the code that will unblock the server is never executed,
> because it is triggered by a selector read event, and the
> channel is already dry so the event is never fired.
> 
> I reworked the tests a bit, adding two new CountDownLatches to
> ensure that 1. the client will always find initial bytes in the
> channel's initialByteBuffer (the intermittent condition that made
> the test fail) and 2. the server will wait for the client to
> signal that it has got the initial bytes, and write an additional
> chunk of bytes that will trigger the selector read (which will
> in turn ensure that the client will unblock the server later on).
> 
> best regards,
> 
> -- daniel


From felix.yang at oracle.com  Thu May 25 08:08:31 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Thu, 25 May 2017 16:08:31 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
Message-ID: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>

Hi there,

    please review following patch to convert all shell cases under 
java/net to plain java codes.

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8166139


Thanks,

Felix


From huaming.li at oracle.com  Thu May 25 09:19:02 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Thu, 25 May 2017 17:19:02 +0800
Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in
 java.base & java.datatransfer module
Message-ID: 

Would you please review below patch?

bug: https://bugs.openjdk.java.net/browse/JDK-8181082

webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/


Thank you

-Hamlin


From amy.lu at oracle.com  Thu May 25 09:24:33 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Thu, 25 May 2017 17:24:33 +0800
Subject: JDK 10 RFR of JDK-8173905: Test
 tools/jar/multiRelease/RuntimeTest.java fails under JDK 10
In-Reply-To: <752377E3-DB19-4AC5-BD20-DF5A559E1A6D@oracle.com>
References: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
 <752377E3-DB19-4AC5-BD20-DF5A559E1A6D@oracle.com>
Message-ID: 

Thank you Paul and Claes!

I updated the webrev, renamed the template files and updated 
createJarSourceFiles method. Now templateSourceMap is not needed. Also 
updated the style around array initializers.

http://cr.openjdk.java.net/~amlu/8173905/webrev.01
(For your ref: 
http://cr.openjdk.java.net/~amlu/8173905/RuntimeTest.webrev.00_webrev.01.diff)

Thanks,
Amy


On 5/25/17 12:38 AM, Paul Sandoz wrote:
> Hi Amy,
>
> Looks good,
>
> A minor suggestion i would rename the template files to be the   + ?.template?. Then you don?t need the map ?templateSourceMap?, and it becomes clearer what files the templates are associated with. Also i would try and retain the same directory structure as well e.g. recursively traversing a directory transforming any file whose name ends with template into a concrete file in versioned area of the same relative path.
>
> Paul.
>
>> On 24 May 2017, at 03:22, Amy Lu  wrote:
>>
>> After the version update to "10" in JDK 10 ( JDK-8029942 ), test tools/jar/multiRelease/RuntimeTest.java starts failing because the release version is hardcoded, not only in the test itself, but also in test data files for the jar that tested on.
>>
>> I've updated the test to generate those data files on the fly based on the template and $version, and the hardcoding of release version also be replaced by the value based on Runtime.version().major(). In this way, test don't need to be updated again for JDK 11.
>>
>> Compared the newly generated "data" files with the old "data", no diff (except the version).
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8173905
>> webrev: http://cr.openjdk.java.net/~amlu/8173905/webrev.00/
>>
>> Tested on all platforms.
>>
>> Thanks,
>> Amy


From Roger.Riggs at Oracle.com  Thu May 25 15:31:14 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 11:31:14 -0400
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
Message-ID: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>

Please review an update to the RMI Registry built-in serial filter 
implementation limit on the depth
of a instance that can be bound in the registry.  The initial depth 
limit was 5 and it was too limiting
for some existing applications.  It limit is updated to depth = 20 and 
should be more than adequate.

Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html

Issue:
    https://bugs.openjdk.java.net/browse/JDK-8180582

Thanks, Roger

From brian.burkhalter at oracle.com  Thu May 25 15:32:07 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 25 May 2017 08:32:07 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
Message-ID: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>

This is a continuation / merge of two previous RFRs:

6791812: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047787.html
8180767: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047809.html

An updated patch which folds the second change into the first is here:

http://cr.openjdk.java.net/~bpb/6791812/webrev.00/

If this is approved I will update the corresponding CCC request and after eventually pushing the patch will resolve 8180767 as a duplicate.

Thanks,

Brian

From brian.burkhalter at oracle.com  Thu May 25 15:32:51 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 25 May 2017 08:32:51 -0700
Subject: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible
 File.lastModified() and setLastModified() for negative time
In-Reply-To: <4477f7d6-cbae-798e-ccbd-bb3ab7293655@oracle.com>
References: <0E2305BC-FB99-4099-9562-EABAB4A8786E@oracle.com>
 <0a5fc6d1-e05b-2aaf-4bb3-2679a9d5e22a@oracle.com>
 
 
 <3270129A-BB52-47EF-B4AB-81649DA53739@oracle.com>
 <4477f7d6-cbae-798e-ccbd-bb3ab7293655@oracle.com>
Message-ID: <4D82E780-9318-4ED5-ABC0-910B789258CE@oracle.com>

This thread is now moved here:

http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047885.html

Thanks,

Brian

On May 23, 2017, at 1:23 PM, Stuart Marks  wrote:

> On 5/23/17 8:21 AM, Brian Burkhalter wrote:
>> So I guess this might be satisfy your and Stuart?s comments:
>> 
>> --- a/src/java.base/share/classes/java/io/File.java
>> +++ b/src/java.base/share/classes/java/io/File.java
>> @@ -932,7 +932,9 @@
>>     * @return  A long value representing the time the file was
>>     *          last modified, measured in milliseconds since the epoch
>>     *          (00:00:00 GMT, January 1, 1970), or 0L if the
>> -     *          file does not exist or if an I/O error occurs
>> +     *          file does not exist or if an I/O error occurs; the value may
>> +     *          be negative indicating the number of milliseconds before the epoch
> 
> Yes, this looks great. Thanks.
> 
> s'marks
> 


From brian.burkhalter at oracle.com  Thu May 25 15:34:47 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 25 May 2017 08:34:47 -0700
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <057035AE-57F7-4C57-A9EA-94FD8F866A29@oracle.com>
 
 <21220E7C-D6AB-4680-AF5C-7CDF46A3FD94@oracle.com>
 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
Message-ID: <6E49E553-8F8A-439B-843F-3070FE204CF0@oracle.com>

This thread is now moved here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047885.html

Thanks,

Brian

On May 23, 2017, at 2:27 PM, Brian Burkhalter  wrote:

> 
> On May 23, 2017, at 1:34 PM, Stuart Marks  wrote:
> 
>> Yes, this could be another non-normative change. You might even consider merging it with the other bug (JDK-6791812), and possibly even labeling it as @apiNote.
>> 
>> As for the wording itself, I think the sentiment is correct, but it's trying to pack a bit too much into a single sentence. Breaking it into two sentences would probably be helpful.
> 
> Does this seem better? It folds 8180767 into 6791812.
> 
> --- a/src/java.base/share/classes/java/io/File.java
> +++ b/src/java.base/share/classes/java/io/File.java
> @@ -928,11 +928,17 @@
>      * the granularity of the value depends on the underlying
>      * file system and may be larger.  For example, some
>      * file systems use time stamps in units of seconds.
> +     * Distinguishing an I/O exception from a zero return value may
> +     * also be accomplished by using the
> +     * {@link java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
> +     * Files.getLastModifiedTime} method.
>      *
>      * @return  A long value representing the time the file was
>      *          last modified, measured in milliseconds since the epoch
>      *          (00:00:00 GMT, January 1, 1970), or 0L if the
> -     *          file does not exist or if an I/O error occurs
> +     *          file does not exist or if an I/O error occurs.  The value may
> +     *          be negative indicating the number of milliseconds before the
> +     *          epoch
> 
> I already verified that the generated javadoc is correct.
> 
> Thanks,
> 
> Brian


From forax at univ-mlv.fr  Thu May 25 16:18:58 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 25 May 2017 18:18:58 +0200 (CEST)
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>
References: 
 <42AE6D5F-BD3A-4159-AAB2-939AB5088507@oracle.com>
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
 <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>
 <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>
Message-ID: <527680992.2616455.1495729138294.JavaMail.zimbra@u-pem.fr>

I've created JDK-8181098 [1] and assign it to Alan. 

R?mi 

[1] https://bugs.openjdk.java.net/browse/JDK-8181098 

> De: "John Rose" 
> ?: "R?mi Forax" 
> Cc: "Brian Burkhalter" ,
> core-libs-dev at openjdk.java.net
> Envoy?: Mercredi 24 Mai 2017 22:11:42
> Objet: Re: JDK 10 RFR of 8180767: A return value of zero from
> java.io.File#lastModified() is ambiguous

> On May 24, 2017, at 2:02 AM, Remi Forax < forax at univ-mlv.fr > wrote:

>> As a meta-comment, we should deprecate java.io.File (with no for removal),
>> java.nio.file.Path is a nice replacement so java.io.File should be used only for
>> dealing with legacy code.

> This seems right to me. As a casual user of core-libs I would be
> less likely to use File in new code, and take a second to look for the
> better replacement, if it were in fact solidly deprecated.

> Could someone file a bug/rfe to follow this up? Debate about the ultimate
> worthiness of File could then be attached to the bug.

> ? John

From forax at univ-mlv.fr  Thu May 25 16:34:30 2017
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Thu, 25 May 2017 18:34:30 +0200 (CEST)
Subject: JDK 10 RFR of 8180767: A return value of zero from
 java.io.File#lastModified() is ambiguous
In-Reply-To: 
References: 
 
 <7014156B-AB14-4076-A0F4-1EB3BA675189@oracle.com>
 <542de81e-cfd3-0f20-661a-d12ae2efe858@oracle.com>
 
 <515142668.1925404.1495616532655.JavaMail.zimbra@u-pem.fr>
 <1E107D34-3B1F-48C4-89A3-22C6BB856C64@oracle.com>
 
Message-ID: <780705170.2617257.1495730070235.JavaMail.zimbra@u-pem.fr>

Alan,

----- Mail original -----
> De: "Alan Bateman" 
> ?: "John Rose" , "R?mi Forax" 
> Cc: core-libs-dev at openjdk.java.net
> Envoy?: Mercredi 24 Mai 2017 22:45:02
> Objet: Re: JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

> On 24/05/2017 21:11, John Rose wrote:
> 
>> :
>> This seems right to me.  As a casual user of core-libs I would be
>> less likely to use File in new code, and take a second to look for the
>> better replacement, if it were in fact solidly deprecated.
>>
>> Could someone file a bug/rfe to follow this up?  Debate about the ultimate
>> worthiness of File could then be attached to the bug.
> There was deliberate decision back a few years back not to deprecate
> File. At the time then the bar to add @Deprecated was very high and an
> API needed to be very toxic.

java.io.File is toxic too, the way it deals with the file name encoding is something i would like to think as a thing of the past.

Also Path is not only a replacement for java.io.File, it is also more modern., you have the fact that by default, the API uses UTF8 as default file encoding, that the API is able to produce Streams, etc. so it mixes better with modern code.

The other problem is that because it's not deprecated, people still using java.io.File in new code and while there is an interropt between Path and File, the burden goes to the developer that uses Path instead of the one that use File because Path is a more general abstraction than File so the conversion from Path to File can fail.

> Looking at now then several methods could
> be candidates to deprecate as they are inherently broken, deprecating
> the entire class might be too much. 

We are at the starts of 10, if things goes wrong, we can backtrack to your solution.

> One other thing that was tried out
> at the time was to replace the implementation of java.io.File and
> friends to use the new code. This had the benefit of fixing dozens of
> issues (esp. on Windows) in one flick of the wrist. Sadly, subtle
> benefit changes to fix issues are also compatibility issues when dealing
> with an old API. So we chickened out from going there too.
> 
> -Alan

R?mi

From Roger.Riggs at Oracle.com  Thu May 25 18:54:33 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 14:54:33 -0400
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: 
References: 
Message-ID: <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>

Hi Hamlin,

For imports they should import specific classes, wildcards are not used.

maskSyntheticModifier/Test.java
consTest/Test.java
deserializeButton/Test.java

  test/java/io/Serializable/packageAccess/Driver.java: the name "Driver" 
is not descriptive and should be.

Each Driver.java should have a different and functional/descriptive name.

Better yet, there should be a single program that creates jar files 
using command line arguments
that can be invoked depending on the test.

There is a mix of Driver's copying files vs the test program copying; 
can that be made more uniform.

Test.java files should have descriptive/functional names. (Even if the 
duplicating the directory)

Regards, Roger


On 5/24/2017 5:09 AM, Hamlin Li wrote:
> Would you please review the below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>
> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>
>
> Thank you
>
> -Hamlin
>


From Roger.Riggs at Oracle.com  Thu May 25 18:58:01 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 14:58:01 -0400
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
Message-ID: <6221686d-a955-8726-0f9c-845c5ff19b81@Oracle.com>

Looks good,

Thanks, Roger


On 5/25/2017 11:32 AM, Brian Burkhalter wrote:
> This is a continuation / merge of two previous RFRs:
>
> 6791812: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047787.html
> 8180767: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047809.html
>
> An updated patch which folds the second change into the first is here:
>
> http://cr.openjdk.java.net/~bpb/6791812/webrev.00/
>
> If this is approved I will update the corresponding CCC request and after eventually pushing the patch will resolve 8180767 as a duplicate.
>
> Thanks,
>
> Brian


From Roger.Riggs at Oracle.com  Thu May 25 19:24:10 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 15:24:10 -0400
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
Message-ID: <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>

Hi Felix,

closetest/CloseTest:

32: Please put the @modules directives together (and not repeat)

44: do not use wildcard imports  (reconfigure your IDE if necessary to 
avoid accidents).

63: setup() is invoked twice...  remove 1 or explain why 2 calls

69, 78,90,91,... :  space in method call is not proper style

sealing/CheckSealed.java:
  - Why is @test block removed?
     Should be converted to @run main CheckSealed

Regards, Roger



On 5/25/2017 4:08 AM, Felix Yang wrote:
> Hi there,
>
>    please review following patch to convert all shell cases under 
> java/net to plain java codes.
>
> Webrev:
>
>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>
> Bug:
>
>     https://bugs.openjdk.java.net/browse/JDK-8166139
>
>
> Thanks,
>
> Felix
>


From Roger.Riggs at Oracle.com  Thu May 25 19:25:04 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Thu, 25 May 2017 15:25:04 -0400
Subject: jdk10 RFR of JDK-8180732: add test to check temp file permission
In-Reply-To: 
References: <19c56248-8f81-457a-17ad-dffd7cb7b121@oracle.com>
 <38090abe-1b4d-8b7f-0009-7d7cda88a0a9@oracle.com>
 <38181367-69ab-7967-6a37-3b70eeebb11a@Oracle.com>
 
 
Message-ID: 

+1, Reviewed

On 5/24/2017 11:59 AM, Brent Christian wrote:
> Looks fine to me, Hamlin.
>
> Thanks,
> -Brent
>
> On 5/24/17 2:18 AM, Hamlin Li wrote:
>> Hi Roger, Brent,
>>
>> Thank you for reviewing, please check new webrev at :
>> http://cr.openjdk.java.net/~mli/8180732/webrev.01/
>>
>> Thank you
>>
>> -Hamlin
>>
>> On 2017/5/24 1:05, Roger Riggs wrote:
>>> Hi,
>>>
>>> Security.java: 25-27: Style conventions call for " * " on every line
>>> in comment blocks.
>>>
>>> On 5/23/2017 12:53 PM, Brent Christian wrote:
>>>> Hi, Hamlin
>>>>
>>>> That looks pretty good.  A couple comments:
>>>>
>>>> * If I'm not mistaken, main/othervm/policy=... is sufficient to
>>>> enable the default security manager, and specifying
>>>> "-Djava.security.manager" is unnecessary.
>>>>
>>>> * Please add 8180732 to the @bug tag
>>>
>>> I'm not sure this adds much because the bug report just is moving to
>>> test to the open repo.
>>>
>>>>
>>>> You will also need approval from a JDK 10 Reviewer.
>>>
>>> Roger
>>>
>>>>
>>>> Thanks,
>>>> -Brent
>>>>
>>>> On 5/21/17 9:26 PM, Hamlin Li wrote:
>>>>> Would you please review the below patch?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8180732
>>>>> webrev: http://cr.openjdk.java.net/~mli/8180732/webrev.00/
>>>>>
>>>>> Thank you
>>>>> -Hamlin
>>>
>>


From kumar.x.srinivasan at oracle.com  Thu May 25 19:48:11 2017
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 25 May 2017 12:48:11 -0700
Subject: RFR: JDK10 JDK-8180286: Remove the launchers data model flags
 -d32/-d64
Message-ID: <592734FB.3050804@oracle.com>

Hello,

Please review the removal of the launcher options -d32/-d64 from the
launcher's help, the implementations were removed with JDK-8169646,
but the help part was overlooked.

JBS: https://bugs.openjdk.java.net/browse/JDK-8180286
webrev: http://cr.openjdk.java.net/~ksrini/8180286/webrev.00/

Thanks
Kumar


From paul.sandoz at oracle.com  Thu May 25 22:04:03 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Thu, 25 May 2017 15:04:03 -0700
Subject: JDK 10 RFR of JDK-8173905: Test
 tools/jar/multiRelease/RuntimeTest.java fails under JDK 10
In-Reply-To: 
References: <9af8384f-388c-3510-244f-50efc4a7b95e@oracle.com>
 <752377E3-DB19-4AC5-BD20-DF5A559E1A6D@oracle.com>
 
Message-ID: <33B75110-1221-4F6A-AB77-78A837DBFB95@oracle.com>


> On 25 May 2017, at 02:24, Amy Lu  wrote:
> 
> Thank you Paul and Claes!
> 
> I updated the webrev, renamed the template files and updated createJarSourceFiles method. Now templateSourceMap is not needed. Also updated the style around array initializers.
> 
> http://cr.openjdk.java.net/~amlu/8173905/webrev.01
> (For your ref: http://cr.openjdk.java.net/~amlu/8173905/RuntimeTest.webrev.00_webrev.01.diff)
> 

Nice, +1

Paul.

From stuart.marks at oracle.com  Thu May 25 22:37:00 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 25 May 2017 15:37:00 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
Message-ID: <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>



On 5/25/17 8:32 AM, Brian Burkhalter wrote:
> This is a continuation / merge of two previous RFRs:
>
> 6791812: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047787.html
> 8180767: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047809.html
>
> An updated patch which folds the second change into the first is here:
>
> http://cr.openjdk.java.net/~bpb/6791812/webrev.00/
>
> If this is approved I will update the corresponding CCC request and after eventually pushing the patch will resolve 8180767 as a duplicate.

The test in the @return paragraph is fine.

The new text at the end of the @apiNote is ok...

  931      * Distinguishing an I/O exception from a zero return value may
  932      * also be accomplished by using the
  933      * {@link java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
  934      * Files.getLastModifiedTime} method.

but it's redundant with the text in the paragraph that precedes the @apiNote. 
This covers the same issue, but it suggests a different alternative:

  919      * 
 Where it is required to distinguish an I/O exception from the case
  920      * where {@code 0L} is returned, or where several attributes of the
  921      * same file are required at the same time, or where the time of last
  922      * access or the creation time are required, then the {@link
  923      * java.nio.file.Files#readAttributes(Path,Class,LinkOption[])
  924      * Files.readAttributes} method may be used.

None of this is wrong, but it's weird to have two paragraphs that address the 
same issue in different ways, one within an @apiNote and the other not.

I'd suggest merging all of this into the @apiNote. Some rewording is probably 
necessary. There are too many different circumstances and alternatives to cover 
in a single sentence. But maybe this is trying to cover too much. It might 
simplify things if it simply mentions the problem and points people elsewhere:

     @apiNote
     This method returns {@code 0L} in cases where an I/O exception occurs or
     where the actual modification time is {@code 0L}. To distinguish these
     cases, consider calling {@link
     java.nio.file.Files#readAttributes(Path,Class,LinkOption[])
     Files.readAttributes} or {@link
     java.nio.file.Files#getLastModifiedTime(Path,LinkOption[])
     Files.readAttributes} instead.

The "granularity" sentences currently in the @apiNote can remain, but probably 
in a separate paragraph in the @apiNote.

**

The problem with fixing up javadoc in one place is that it becomes inconsistent 
with other places.

For example, File.length() has similar "Where it is required to distinguish..." 
wording. This should also be made into an @apiNote and also reworded to be in 
alignment with whatever text is used in File.lastModified().

Also, File.createNewFile(), File.delete(), and File.deleteOnExit() have words to 
the effect of "Note: ..." or "Note that..." which indicate API notes, but which 
aren't tagged with @apiNote. The @apiNote tag should probably be added to those 
as well.

These can be handled separately if you like. Unless you're really ambitious, in 
which case you can fix them all in a single changeset. Up to you.

s'marks

From brian.burkhalter at oracle.com  Fri May 26 00:43:05 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 25 May 2017 17:43:05 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
Message-ID: <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>


On May 25, 2017, at 3:37 PM, Stuart Marks  wrote:

> The test in the @return paragraph is fine.

I think you intended ?text.?

> The new text at the end of the @apiNote is ok...
> 
> [?]
> 
> The "granularity" sentences currently in the @apiNote can remain, but probably in a separate paragraph in the @apiNote.

I agree with the foregoing. I?ll take another pass over it tomorrow.

> The problem with fixing up javadoc in one place is that it becomes inconsistent with other places.
> 
> For example, File.length() has similar "Where it is required to distinguish..." wording. This should also be made into an @apiNote and also reworded to be in alignment with whatever text is used in File.lastModified().
> 
> Also, File.createNewFile(), File.delete(), and File.deleteOnExit() have words to the effect of "Note: ..." or "Note that..." which indicate API notes, but which aren't tagged with @apiNote. The @apiNote tag should probably be added to those as well.
> 
> These can be handled separately if you like. Unless you're really ambitious, in which case you can fix them all in a single changeset. Up to you.

I was only looking at this one particular thing and not reviewing the verbiage of the entire class. I would prefer to note the problems and file a separate issue to deal with them.

Thanks,

Brian

From igor.ignatyev at oracle.com  Fri May 26 01:28:40 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Thu, 25 May 2017 18:28:40 -0700
Subject: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to
 jdk/test/java/lang/invoke directory
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
> 41 lines changed: 5 ins; 4 del; 32 mod; 

Hi all,

jsr292 testlibrary is used only by java/lang/invoke tests, so there is no reason to have this library in common testlibrary, this changeset moves jsr292 testlibrary classes from jdk/test/lib/testlibrary to jdk/test/java/lang/invoke/common, so they will be closed to the tests which use them.

webrev: http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180890
testing: java/lang/invoke

Thanks,
-- Igor


From david.holmes at oracle.com  Fri May 26 02:23:20 2017
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 May 2017 12:23:20 +1000
Subject: RFR: JDK10 JDK-8180286: Remove the launchers data model flags
 -d32/-d64
In-Reply-To: <592734FB.3050804@oracle.com>
References: <592734FB.3050804@oracle.com>
Message-ID: 

Looks good.

We should probably start including links to the CSR issue in the RFR 
when it exists. :)

Thanks,
David

On 26/05/2017 5:48 AM, Kumar Srinivasan wrote:
> Hello,
> 
> Please review the removal of the launcher options -d32/-d64 from the
> launcher's help, the implementations were removed with JDK-8169646,
> but the help part was overlooked.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180286
> webrev: http://cr.openjdk.java.net/~ksrini/8180286/webrev.00/
> 
> Thanks
> Kumar
> 

From amy.lu at oracle.com  Fri May 26 02:42:07 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 26 May 2017 10:42:07 +0800
Subject: JDK 10 RFR of JDK-8181126: Refactor shell test
 java/nio/Buffer/LimitDirectMemory.sh to java
Message-ID: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>

java/nio/Buffer/LimitDirectMemory.sh

Please review this patch to refactor the shell test to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8181126
webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/

Thanks,
Amy

From mandy.chung at oracle.com  Fri May 26 02:49:24 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 25 May 2017 19:49:24 -0700
Subject: RFR: JDK10 JDK-8180286: Remove the launchers data model flags
 -d32/-d64
In-Reply-To: <592734FB.3050804@oracle.com>
References: <592734FB.3050804@oracle.com>
Message-ID: <64158C26-ED38-42D6-BC6F-0FCB64B4C908@oracle.com>

+1

Mandy

> On May 25, 2017, at 12:48 PM, Kumar Srinivasan  wrote:
> 
> Hello,
> 
> Please review the removal of the launcher options -d32/-d64 from the
> launcher's help, the implementations were removed with JDK-8169646,
> but the help part was overlooked.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180286
> webrev: http://cr.openjdk.java.net/~ksrini/8180286/webrev.00/
> 
> Thanks
> Kumar
> 


From felix.yang at oracle.com  Fri May 26 03:14:32 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 26 May 2017 11:14:32 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
Message-ID: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>

Hi Roger,

     please review the updated webrev:

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/

Thanks,
Felix
On 2017/5/26 3:24, Roger Riggs wrote:
> Hi Felix,
>
> closetest/CloseTest:
>
> 32: Please put the @modules directives together (and not repeat)
Fixed
-Felix
>
> 44: do not use wildcard imports  (reconfigure your IDE if necessary to 
> avoid accidents).
Fixed and also organized imports in other test files
-Felix
>
> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
Fixed
-Felix
>
> 69, 78,90,91,... :  space in method call is not proper style
Fixed and also formatted other history codes. Just format only without 
logic change.
Not restricted to this test. I only formatted history codes "nearby", to 
avoid hiding real logic changes in the patch.

-Felix
>
> sealing/CheckSealed.java:
>  - Why is @test block removed?
>     Should be converted to @run main CheckSealed
There was a checksealed.sh. I replaced it with CheckSealedTest.java and 
declared @test there.
http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html

BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
removed. That is because corresponding prerequisite was removed even in 
JDK 8.

-Felix
>
> Regards, Roger
>
>
>
> On 5/25/2017 4:08 AM, Felix Yang wrote:
>> Hi there,
>>
>>    please review following patch to convert all shell cases under 
>> java/net to plain java codes.
>>
>> Webrev:
>>
>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>
>> Bug:
>>
>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>
>>
>> Thanks,
>>
>> Felix
>>
>


From amy.lu at oracle.com  Fri May 26 03:43:10 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Fri, 26 May 2017 11:43:10 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
Message-ID: 

Hi, Felix

I noticed that CompilerUtils from jdk/test/lib/testlibrary is still used 
in tests. It?s better to use the version [1] from top level.

(Not a reviewer.)

Thanks,
Amy

[1] 
http://hg.openjdk.java.net/jdk10/jdk10/file/tip/test/lib/jdk/test/lib/compiler/CompilerUtils.java

On 5/26/17 11:14 AM, Felix Yang wrote:
> Hi Roger,
>
>     please review the updated webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>
> Thanks,
> Felix
> On 2017/5/26 3:24, Roger Riggs wrote:
>> Hi Felix,
>>
>> closetest/CloseTest:
>>
>> 32: Please put the @modules directives together (and not repeat)
> Fixed
> -Felix
>>
>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>> to avoid accidents).
> Fixed and also organized imports in other test files
> -Felix
>>
>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
> Fixed
> -Felix
>>
>> 69, 78,90,91,... :  space in method call is not proper style
> Fixed and also formatted other history codes. Just format only without 
> logic change.
> Not restricted to this test. I only formatted history codes "nearby", 
> to avoid hiding real logic changes in the patch.
>
> -Felix
>>
>> sealing/CheckSealed.java:
>>  - Why is @test block removed?
>>     Should be converted to @run main CheckSealed
> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
> and declared @test there.
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>
>
> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
> removed. That is because corresponding prerequisite was removed even 
> in JDK 8.
>
> -Felix
>>
>> Regards, Roger
>>
>>
>>
>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>> Hi there,
>>>
>>>    please review following patch to convert all shell cases under 
>>> java/net to plain java codes.
>>>
>>> Webrev:
>>>
>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>
>>> Bug:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>
>


From huaming.li at oracle.com  Fri May 26 04:26:15 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Fri, 26 May 2017 12:26:15 +0800
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
References: 
 <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
Message-ID: <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>

Hi Roger,

Thank you for detailed review. Fixed as you suggested, new webrev: 
http://cr.openjdk.java.net/~mli/8166142/webrev.01/

Thank you

-Hamlin


On 2017/5/26 2:54, Roger Riggs wrote:
> Hi Hamlin,
>
> For imports they should import specific classes, wildcards are not used.
>
> maskSyntheticModifier/Test.java
> consTest/Test.java
> deserializeButton/Test.java
>
>  test/java/io/Serializable/packageAccess/Driver.java: the name 
> "Driver" is not descriptive and should be.
>
> Each Driver.java should have a different and functional/descriptive name.
>
> Better yet, there should be a single program that creates jar files 
> using command line arguments
> that can be invoked depending on the test.
>
> There is a mix of Driver's copying files vs the test program copying; 
> can that be made more uniform.
>
> Test.java files should have descriptive/functional names. (Even if the 
> duplicating the directory)
>
> Regards, Roger
>
>
> On 5/24/2017 5:09 AM, Hamlin Li wrote:
>> Would you please review the below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>>
>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>
>


From felix.yang at oracle.com  Fri May 26 04:46:40 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Fri, 26 May 2017 12:46:40 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: 
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 
Message-ID: <0f5ec587-1654-7f35-f88b-a7dd99ffe571@oracle.com>

Hi Amy,

     it is intended, because in my changes CompilerUtils is usually used 
together with JarUtils, which has not been moved yet. It is a bit 
confusing to add two lib directories, and even there are files with the 
same name. So it may be clearer to refactor lib usage unified in 
JDK-8075327  or 
clean-ups tasks with single purpose.

Thanks,

Felix

On 2017/5/26 11:43, Amy Lu wrote:
> Hi, Felix
>
> I noticed that CompilerUtils from jdk/test/lib/testlibrary is still 
> used in tests. It?s better to use the version [1] from top level.
>
> (Not a reviewer.)
>
> Thanks,
> Amy
>
> [1] 
> http://hg.openjdk.java.net/jdk10/jdk10/file/tip/test/lib/jdk/test/lib/compiler/CompilerUtils.java
>
> On 5/26/17 11:14 AM, Felix Yang wrote:
>> Hi Roger,
>>
>>     please review the updated webrev:
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>
>> Thanks,
>> Felix
>> On 2017/5/26 3:24, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> closetest/CloseTest:
>>>
>>> 32: Please put the @modules directives together (and not repeat)
>> Fixed
>> -Felix
>>>
>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>>> to avoid accidents).
>> Fixed and also organized imports in other test files
>> -Felix
>>>
>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>> Fixed
>> -Felix
>>>
>>> 69, 78,90,91,... :  space in method call is not proper style
>> Fixed and also formatted other history codes. Just format only 
>> without logic change.
>> Not restricted to this test. I only formatted history codes "nearby", 
>> to avoid hiding real logic changes in the patch.
>>
>> -Felix
>>>
>>> sealing/CheckSealed.java:
>>>  - Why is @test block removed?
>>>     Should be converted to @run main CheckSealed
>> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
>> and declared @test there.
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>
>>
>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
>> removed. That is because corresponding prerequisite was removed even 
>> in JDK 8.
>>
>> -Felix
>>>
>>> Regards, Roger
>>>
>>>
>>>
>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>> Hi there,
>>>>
>>>>    please review following patch to convert all shell cases under 
>>>> java/net to plain java codes.
>>>>
>>>> Webrev:
>>>>
>>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>
>>>> Bug:
>>>>
>>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Felix
>>>>
>>>
>>
>


From Alan.Bateman at oracle.com  Fri May 26 06:07:22 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 May 2017 07:07:22 +0100
Subject: RFR: JDK10 JDK-8180286: Remove the launchers data model flags
 -d32/-d64
In-Reply-To: <592734FB.3050804@oracle.com>
References: <592734FB.3050804@oracle.com>
Message-ID: 

On 25/05/2017 20:48, Kumar Srinivasan wrote:

> Hello,
>
> Please review the removal of the launcher options -d32/-d64 from the
> launcher's help, the implementations were removed with JDK-8169646,
> but the help part was overlooked.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8180286
> webrev: http://cr.openjdk.java.net/~ksrini/8180286/webrev.00/
Looks good.

-Alan.

From tenghuanhe at gmail.com  Fri May 26 14:21:48 2017
From: tenghuanhe at gmail.com (Tenghuan He)
Date: Fri, 26 May 2017 22:21:48 +0800
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o)
 implementation efficiency
Message-ID: 

Hi, all

I found that the equalsimplementation of
java.util.concurrent.ConcurrentSkipListSet in JDK as follows:

public boolean equals(Object o) {
    // Override AbstractSet version to avoid calling size()
    if (o == this)
        return true;
    if (!(o instanceof Set))
        return false;
    Collection c = (Collection) o;
    try {
        return containsAll(c) && c.containsAll(this);
    } catch (ClassCastException unused) {
        return false;
    } catch (NullPointerException unused) {
        return false;
    }}


Since ConcurrentSkipListSet extends NavigableSet which extends SortedSet,
the following equalsimplementation seems more reasonable for a compare
object which also extends SortedSet.

public boolean myEquals(Object o) {
        // Override AbstractSet version to avoid calling size()
        if (o == this)
            return true;
        if (!(o instanceof Set))
            return false;
        if (o instanceof SortedSet) {
            Iterator iter1 = ((SortedSet) o).iterator();
            Iterator iter2 = iterator();

            while (iter1.hasNext() && iter2.hasNext()) {
                if (!iter1.next().equals(iter2.next())) {
                    return false;
                }
            }
            return !(iter1.hasNext() || iter1.hasNext());
        }
        Collection c = (Collection) o;
        try {
            return containsAll(c) && c.containsAll(this);
        } catch (ClassCastException unused) {
            return false;
        } catch (NullPointerException unused) {
            return false;
        }
    }

A simple test has shown the performance improvement

public class Test {
    public static void main(String[] args) {
        ConcurrentSkipListSet set1 = new
ConcurrentSkipListSet();
        ConcurrentSkipListSet set2 = new
ConcurrentSkipListSet();

        for (int i = 0; i < 10000000; i++) {
            set1.add(i);
            set2.add(i);
        }

        long ts = System.currentTimeMillis();
        System.out.println(set1.equals(set2));
        System.out.println(System.currentTimeMillis() - ts);

        ts = System.currentTimeMillis();
        System.out.println(myset1.myEquals(myset2));
        System.out.println(System.currentTimeMillis() - ts);
    }}

Output result

true2713true589


Any ideas? (Related question on SO:
https://stackoverflow.com/questions/44198103/jdk-java-util-concurrent-concurrentskiplistset-equalsobject-o-implementation-e

Thanks & Best Regards

Tenghuan He

From Roger.Riggs at Oracle.com  Fri May 26 14:29:30 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 26 May 2017 10:29:30 -0400
Subject: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to
 jdk/test/java/lang/invoke directory
In-Reply-To: 
References: 
Message-ID: <164a7bea-4858-c6fd-5e84-eb4470ce7a68@Oracle.com>

Hi Igor,

It would be nice if all of the @library source lines were the same (not 
mixed in the order).

Since this is a cleanup task, I might be inclined to make the order of 
imports consistent
within those tests but that goes beyond the simple goal of the issue.

+1

Roger


On 5/25/2017 9:28 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
>> 41 lines changed: 5 ins; 4 del; 32 mod;
> Hi all,
>
> jsr292 testlibrary is used only by java/lang/invoke tests, so there is no reason to have this library in common testlibrary, this changeset moves jsr292 testlibrary classes from jdk/test/lib/testlibrary to jdk/test/java/lang/invoke/common, so they will be closed to the tests which use them.
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180890
> testing: java/lang/invoke
>
> Thanks,
> -- Igor
>


From matthias.baesken at sap.com  Fri May 26 14:43:10 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Fri, 26 May 2017 14:43:10 +0000
Subject: [XS]  RFR : JDK-8181145 : add platforms to test
 java/nio/ByteOrder/NativeOrder.java    (test change)
Message-ID: 

Please review this small test change .
It adds a number of platforms to the existing test  jdk10  jtreg test  java/nio/ByteOrder/NativeOrder.java  .

Especially the porting platforms ppc64/ppc64le/s390x are added .


Webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8181145/


bug :

https://bugs.openjdk.java.net/browse/JDK-8181145


Thanks, Matthias



From martinrb at google.com  Fri May 26 15:55:00 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 26 May 2017 08:55:00 -0700
Subject: [XS] RFR : JDK-8181145 : add platforms to test
 java/nio/ByteOrder/NativeOrder.java (test change)
In-Reply-To: 
References: 
Message-ID: 

Looks good to me!

On Fri, May 26, 2017 at 7:43 AM, Baesken, Matthias  wrote:

> Please review this small test change .
> It adds a number of platforms to the existing test  jdk10  jtreg test
> java/nio/ByteOrder/NativeOrder.java  .
>
> Especially the porting platforms ppc64/ppc64le/s390x are added .
>
>
> Webrev :
>
> http://cr.openjdk.java.net/~mbaesken/webrevs/8181145/
>
>
> bug :
>
> https://bugs.openjdk.java.net/browse/JDK-8181145
>
>
> Thanks, Matthias
>
>
>

From brian.burkhalter at oracle.com  Fri May 26 16:17:51 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 26 May 2017 09:17:51 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
 <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>
Message-ID: 

Here?s one more attempt:

http://cr.openjdk.java.net/~bpb/6791812/webrev.01/
http://cr.openjdk.java.net/~bpb/6791812/File.html

Similar verbal de-obfuscation of other methods may be handled under other yet-to-be-file issues.

Thanks,

Brian

From martinrb at google.com  Fri May 26 16:45:18 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 26 May 2017 09:45:18 -0700
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o)
 implementation efficiency
In-Reply-To: 
References: 
Message-ID: 

Thanks for the suggestion!
I filed https://bugs.openjdk.java.net/browse/JDK-8181146

On Fri, May 26, 2017 at 7:21 AM, Tenghuan He  wrote:

> Hi, all
>
> I found that the equalsimplementation of
> java.util.concurrent.ConcurrentSkipListSet in JDK as follows:
>
> public boolean equals(Object o) {
>     // Override AbstractSet version to avoid calling size()
>     if (o == this)
>         return true;
>     if (!(o instanceof Set))
>         return false;
>     Collection c = (Collection) o;
>     try {
>         return containsAll(c) && c.containsAll(this);
>     } catch (ClassCastException unused) {
>         return false;
>     } catch (NullPointerException unused) {
>         return false;
>     }}
>
>
> Since ConcurrentSkipListSet extends NavigableSet which extends SortedSet,
> the following equalsimplementation seems more reasonable for a compare
> object which also extends SortedSet.
>
> public boolean myEquals(Object o) {
>         // Override AbstractSet version to avoid calling size()
>         if (o == this)
>             return true;
>         if (!(o instanceof Set))
>             return false;
>         if (o instanceof SortedSet) {
>             Iterator iter1 = ((SortedSet) o).iterator();
>             Iterator iter2 = iterator();
>
>             while (iter1.hasNext() && iter2.hasNext()) {
>                 if (!iter1.next().equals(iter2.next())) {
>                     return false;
>                 }
>             }
>             return !(iter1.hasNext() || iter1.hasNext());
>         }
>         Collection c = (Collection) o;
>         try {
>             return containsAll(c) && c.containsAll(this);
>         } catch (ClassCastException unused) {
>             return false;
>         } catch (NullPointerException unused) {
>             return false;
>         }
>     }
>
> A simple test has shown the performance improvement
>
> public class Test {
>     public static void main(String[] args) {
>         ConcurrentSkipListSet set1 = new
> ConcurrentSkipListSet();
>         ConcurrentSkipListSet set2 = new
> ConcurrentSkipListSet();
>
>         for (int i = 0; i < 10000000; i++) {
>             set1.add(i);
>             set2.add(i);
>         }
>
>         long ts = System.currentTimeMillis();
>         System.out.println(set1.equals(set2));
>         System.out.println(System.currentTimeMillis() - ts);
>
>         ts = System.currentTimeMillis();
>         System.out.println(myset1.myEquals(myset2));
>         System.out.println(System.currentTimeMillis() - ts);
>     }}
>
> Output result
>
> true2713true589
>
>
> Any ideas? (Related question on SO:
> https://stackoverflow.com/questions/44198103/jdk-java-util-concurrent-
> concurrentskiplistset-equalsobject-o-implementation-e
>
> Thanks & Best Regards
>
> Tenghuan He
>

From jason_mehrens at hotmail.com  Fri May 26 16:51:26 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 26 May 2017 16:51:26 +0000
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o)
 implementation efficiency
In-Reply-To: 
References: 
Message-ID: 

Tenghuan He,

You are correct if 'this' is a SortedMap/Set and 'o' is a SortedMap/Set then both interfaces list a clause in the top level documentation of:
"This order is reflected when iterating over the sorted map's collection views" and "The set's iterator will traverse the set in ascending element order."

So it should be safe to do an ordered  'list' type element comparison if and only if you have determined that both sets/maps use the same ordering.
In your example code you are missing the check to make sure the comparators are both null or equal.

Seems like a worthwhile RFE.  In general, though I tend to think of use cases for ConcurrentSkipListSet as "wildly mutating" which means you never call Set equals
or equals fails pretty early due to the mutation.

Jason  

________________________________________
From: core-libs-dev  on behalf of Tenghuan He 
Sent: Friday, May 26, 2017 9:21 AM
To: core-libs-dev at openjdk.java.net
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o) implementation efficiency

Hi, all

I found that the equalsimplementation of
java.util.concurrent.ConcurrentSkipListSet in JDK as follows:

public boolean equals(Object o) {
    // Override AbstractSet version to avoid calling size()
    if (o == this)
        return true;
    if (!(o instanceof Set))
        return false;
    Collection c = (Collection) o;
    try {
        return containsAll(c) && c.containsAll(this);
    } catch (ClassCastException unused) {
        return false;
    } catch (NullPointerException unused) {
        return false;
    }}


Since ConcurrentSkipListSet extends NavigableSet which extends SortedSet,
the following equalsimplementation seems more reasonable for a compare
object which also extends SortedSet.

public boolean myEquals(Object o) {
        // Override AbstractSet version to avoid calling size()
        if (o == this)
            return true;
        if (!(o instanceof Set))
            return false;
        if (o instanceof SortedSet) {
            Iterator iter1 = ((SortedSet) o).iterator();
            Iterator iter2 = iterator();

            while (iter1.hasNext() && iter2.hasNext()) {
                if (!iter1.next().equals(iter2.next())) {
                    return false;
                }
            }
            return !(iter1.hasNext() || iter1.hasNext());
        }
        Collection c = (Collection) o;
        try {
            return containsAll(c) && c.containsAll(this);
        } catch (ClassCastException unused) {
            return false;
        } catch (NullPointerException unused) {
            return false;
        }
    }

A simple test has shown the performance improvement

public class Test {
    public static void main(String[] args) {
        ConcurrentSkipListSet set1 = new
ConcurrentSkipListSet();
        ConcurrentSkipListSet set2 = new
ConcurrentSkipListSet();

        for (int i = 0; i < 10000000; i++) {
            set1.add(i);
            set2.add(i);
        }

        long ts = System.currentTimeMillis();
        System.out.println(set1.equals(set2));
        System.out.println(System.currentTimeMillis() - ts);

        ts = System.currentTimeMillis();
        System.out.println(myset1.myEquals(myset2));
        System.out.println(System.currentTimeMillis() - ts);
    }}

Output result

true2713true589


Any ideas? (Related question on SO:
https://stackoverflow.com/questions/44198103/jdk-java-util-concurrent-concurrentskiplistset-equalsobject-o-implementation-e

Thanks & Best Regards

Tenghuan He

From jason_mehrens at hotmail.com  Fri May 26 17:02:07 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 26 May 2017 17:02:07 +0000
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: 
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
 <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>,
 
Message-ID: 

Brian,

Is there a dangling '}' after Files.readAttributes or missing '{@link '?

Jason

________________________________________
From: core-libs-dev  on behalf of Brian Burkhalter 
Sent: Friday, May 26, 2017 11:17 AM
To: Stuart Marks
Cc: core-libs-dev
Subject: Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

Here?s one more attempt:

http://cr.openjdk.java.net/~bpb/6791812/webrev.01/
http://cr.openjdk.java.net/~bpb/6791812/File.html

Similar verbal de-obfuscation of other methods may be handled under other yet-to-be-file issues.

Thanks,

Brian

From mandy.chung at oracle.com  Fri May 26 17:29:09 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 May 2017 10:29:09 -0700
Subject: Request Review: JDK-8181148: Update the jdeps tool to list exported
 packages instead of just internal APIs
Message-ID: <249CFE06-4CDC-4894-A66B-2BE9CEF42C36@oracle.com>

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181148/webrev.00/

This updates an existing tool to take an option to list exported 
packages.  This tool is not run during the build but instead used to
generate a resource file checked in in the source.  It?s relevant
to the build tools in build.tools.jigsaw package and so this tool 
is moved to jdk repo that makes it easier to find.

Mandy



From igor.ignatyev at oracle.com  Fri May 26 17:39:31 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 26 May 2017 10:39:31 -0700
Subject: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to
 jdk/test/java/lang/invoke directory
In-Reply-To: 
References: 
Message-ID: <8C7FAAC2-5784-41E4-9E6B-02E124465BA9@oracle.com>

Hi Roger,

I'm fine w/ doing more clean up.

I have normalized @library and reorganized imports in the all touched files. could you please take a look at new webrev: http://cr.openjdk.java.net/~iignatyev/8180890/webrev.01/index.html 
for you convenience, here is the diff b/w 00 and 01 webrevs: http://cr.openjdk.java.net/~iignatyev/8180890/webrev.00-01/index.html 

Thanks,
-- Igor

> Roger Riggs Fri May 26 14:29:30 UTC 2017:
> Hi Igor,
> 
> It would be nice if all of the @library source lines were the same (not 
> mixed in the order).
> 
> Since this is a cleanup task, I might be inclined to make the order of 
> imports consistent
> within those tests but that goes beyond the simple goal of the issue.
> 
> +1
> 
> Roger
>> On May 25, 2017, at 6:28 PM, Igor Ignatyev  wrote:
>> 
>> http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
>>> 41 lines changed: 5 ins; 4 del; 32 mod; 
>> 
>> Hi all,
>> 
>> jsr292 testlibrary is used only by java/lang/invoke tests, so there is no reason to have this library in common testlibrary, this changeset moves jsr292 testlibrary classes from jdk/test/lib/testlibrary to jdk/test/java/lang/invoke/common, so they will be closed to the tests which use them.
>> 
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8180890
>> testing: java/lang/invoke
>> 
>> Thanks,
>> -- Igor
>> 

From brian.burkhalter at oracle.com  Fri May 26 17:45:35 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 26 May 2017 10:45:35 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: 
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
 <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>,
 
 
Message-ID: 

Jason,

No, there is not. If there is any special formatting I almost always actually build the javadoc and test the links, etc., and these work as intended.

Thanks,

Brian

On May 26, 2017, at 10:02 AM, Jason Mehrens  wrote:

> Brian,
> 
> Is there a dangling '}' after Files.readAttributes or missing '{@link '?
> 
> Jason
> 
> ________________________________________
> From: core-libs-dev  on behalf of Brian Burkhalter 
> Sent: Friday, May 26, 2017 11:17 AM
> To: Stuart Marks
> Cc: core-libs-dev
> Subject: Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time
> 
> Here?s one more attempt:
> 
> http://cr.openjdk.java.net/~bpb/6791812/webrev.01/
> http://cr.openjdk.java.net/~bpb/6791812/File.html
> 
> Similar verbal de-obfuscation of other methods may be handled under other yet-to-be-file issues.
> 
> Thanks,
> 
> Brian


From claes.redestad at oracle.com  Fri May 26 17:58:15 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 May 2017 19:58:15 +0200
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path for
 UTF-8
Message-ID: 

Hi,

various JNI methods in the JDK converts from java Strings to native
encoding using JNI_GetStringPlatformChars, which has long standing
optimizations for dealing with various default charsets.

However, UTF-8 is missing, which is a shame since we have optimized
utilities for converting from a String to UTF-8-encoded char* (since
this is the native encoding used by HotSpot internally).

Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8181147

Allocation rate can drop significantly in microbenchmarks, e.g., -60%
in a trivial micro doing new File(path).isHidden() (along with a 30%
throughput win), while the rate of native allocation with is net neutral.

(I think the code for FAST_646_US could be removed, since Solaris 8
support was dropped in JDK 8, but that's a separate RFE...)

Thanks!

/Claes

From shade at redhat.com  Fri May 26 18:07:17 2017
From: shade at redhat.com (Aleksey Shipilev)
Date: Fri, 26 May 2017 20:07:17 +0200
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path
 for UTF-8
In-Reply-To: 
References: 
Message-ID: <18a3a7a3-039e-f862-27d9-f00098315d5a@redhat.com>

On 05/26/2017 07:58 PM, Claes Redestad wrote:
> However, UTF-8 is missing, which is a shame since we have optimized
> utilities for converting from a String to UTF-8-encoded char* (since
> this is the native encoding used by HotSpot internally).
> 
> Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/

This looks okay to me, except:

*) Don't you miss "result[len] = 0;" at the end of getStringUTF8()?

-Aleksey


From dl at cs.oswego.edu  Fri May 26 18:11:31 2017
From: dl at cs.oswego.edu (Doug Lea)
Date: Fri, 26 May 2017 14:11:31 -0400
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o)
 implementation efficiency
In-Reply-To: 
References: 
 
Message-ID: <4e6bc22c-a106-2d9e-57ef-93b16d6df0e7@cs.oswego.edu>

On 05/26/2017 12:51 PM, Jason Mehrens wrote:

> So it should be safe to do an ordered  'list' type element comparison
> if and only if you have determined that both sets/maps use the same
> ordering. In your example code you are missing the check to make sure
> the comparators are both null or equal.

Yes; this check must be added.

> 
> Seems like a worthwhile RFE.  In general, though I tend to think of
> use cases for ConcurrentSkipListSet as "wildly mutating" which means
> you never call Set equals or equals fails pretty early due to the
> mutation.
> 

However, this technique might apply more usefully to TreeSet.

-Doug


From martinrb at google.com  Fri May 26 18:12:51 2017
From: martinrb at google.com (Martin Buchholz)
Date: Fri, 26 May 2017 11:12:51 -0700
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path
 for UTF-8
In-Reply-To: 
References: 
Message-ID: 

I think you've fallen into the trap of confusing UTF-8 and Modified UTF-8.

The prevailing pattern seems to be to write an entirely new UTF-8
implementation for any performance problem involving UTF-8 :-(  e.g. in
StringCoding.

On Fri, May 26, 2017 at 10:58 AM, Claes Redestad 
wrote:

> Hi,
>
> various JNI methods in the JDK converts from java Strings to native
> encoding using JNI_GetStringPlatformChars, which has long standing
> optimizations for dealing with various default charsets.
>
> However, UTF-8 is missing, which is a shame since we have optimized
> utilities for converting from a String to UTF-8-encoded char* (since
> this is the native encoding used by HotSpot internally).
>
> Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181147
>
> Allocation rate can drop significantly in microbenchmarks, e.g., -60%
> in a trivial micro doing new File(path).isHidden() (along with a 30%
> throughput win), while the rate of native allocation with is net neutral.
>
> (I think the code for FAST_646_US could be removed, since Solaris 8
> support was dropped in JDK 8, but that's a separate RFE...)
>
> Thanks!
>
> /Claes
>

From claes.redestad at oracle.com  Fri May 26 18:16:17 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 May 2017 20:16:17 +0200
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path
 for UTF-8
In-Reply-To: <18a3a7a3-039e-f862-27d9-f00098315d5a@redhat.com>
References: 
 <18a3a7a3-039e-f862-27d9-f00098315d5a@redhat.com>
Message-ID: <5d288949-eca2-1255-8444-31af60659930@oracle.com>


On 2017-05-26 20:07, Aleksey Shipilev wrote:
> On 05/26/2017 07:58 PM, Claes Redestad wrote:
>> However, UTF-8 is missing, which is a shame since we have optimized
>> utilities for converting from a String to UTF-8-encoded char* (since
>> this is the native encoding used by HotSpot internally).
>>
>> Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
> This looks okay to me, except:
>
> *) Don't you miss "result[len] = 0;" at the end of getStringUTF8()?

I think we're covered:

GetStringUTFRegion meanders into UNICODE::as_utf8 in
vm/utilities/utf8.cpp, which does the equivalent of setting
result[len] = 0 by means of doing  *p = '\0'; after the loop.

Thanks!

/Claes

>
> -Aleksey
>


From mandy.chung at oracle.com  Fri May 26 18:17:40 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 May 2017 11:17:40 -0700
Subject: Request Review JDK-8180574:
 tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in
 upgradeHashedModule() and patchHashedModule() intermittently
Message-ID: 

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/

The test fails intermittently that the hash of new_m1.jar might be the 
same value as m1.jar that is hashed in m2.  Unfortunately I haven?t 
managed to reproduce the test failure with my instrumented test to
confirm.  I propose to change the test to upgrade a different version
of m1 rather than the same content and observe if this test would
fail again.

Mandy

From xueming.shen at oracle.com  Fri May 26 18:32:40 2017
From: xueming.shen at oracle.com (Xueming Shen)
Date: Fri, 26 May 2017 11:32:40 -0700
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path
 for UTF-8
In-Reply-To: 
References: 
Message-ID: <592874C8.6080705@oracle.com>

Isn't UNICODE::as_utf8  the version of modified-utf8?

-sherman

On 5/26/17, 10:58 AM, Claes Redestad wrote:
> Hi,
>
> various JNI methods in the JDK converts from java Strings to native
> encoding using JNI_GetStringPlatformChars, which has long standing
> optimizations for dealing with various default charsets.
>
> However, UTF-8 is missing, which is a shame since we have optimized
> utilities for converting from a String to UTF-8-encoded char* (since
> this is the native encoding used by HotSpot internally).
>
> Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181147
>
> Allocation rate can drop significantly in microbenchmarks, e.g., -60%
> in a trivial micro doing new File(path).isHidden() (along with a 30%
> throughput win), while the rate of native allocation with is net neutral.
>
> (I think the code for FAST_646_US could be removed, since Solaris 8
> support was dropped in JDK 8, but that's a separate RFE...)
>
> Thanks!
>
> /Claes


From claes.redestad at oracle.com  Fri May 26 18:33:42 2017
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 26 May 2017 20:33:42 +0200
Subject: RFR: 8181147: JNI_GetStringPlatformChars should have a fast path
 for UTF-8
In-Reply-To: 
References: 
 
Message-ID: 

Indeed I did...

Oh well, another day...

/Claes

On 2017-05-26 20:12, Martin Buchholz wrote:
> I think you've fallen into the trap of confusing UTF-8 and Modified 
> UTF-8.
>
> The prevailing pattern seems to be to write an entirely new UTF-8 
> implementation for any performance problem involving UTF-8 :-(  e.g. 
> in StringCoding.
>
> On Fri, May 26, 2017 at 10:58 AM, Claes Redestad 
> > wrote:
>
>     Hi,
>
>     various JNI methods in the JDK converts from java Strings to native
>     encoding using JNI_GetStringPlatformChars, which has long standing
>     optimizations for dealing with various default charsets.
>
>     However, UTF-8 is missing, which is a shame since we have optimized
>     utilities for converting from a String to UTF-8-encoded char* (since
>     this is the native encoding used by HotSpot internally).
>
>     Webrev: http://cr.openjdk.java.net/~redestad/8181147/jdk.00/
>     
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8181147
>     
>
>     Allocation rate can drop significantly in microbenchmarks, e.g., -60%
>     in a trivial micro doing new File(path).isHidden() (along with a 30%
>     throughput win), while the rate of native allocation with is net
>     neutral.
>
>     (I think the code for FAST_646_US could be removed, since Solaris 8
>     support was dropped in JDK 8, but that's a separate RFE...)
>
>     Thanks!
>
>     /Claes
>
>


From jason_mehrens at hotmail.com  Fri May 26 18:50:54 2017
From: jason_mehrens at hotmail.com (Jason Mehrens)
Date: Fri, 26 May 2017 18:50:54 +0000
Subject: JDK java.util.concurrent.ConcurrentSkipListSet.equals(Object o)
 implementation efficiency
In-Reply-To: <4e6bc22c-a106-2d9e-57ef-93b16d6df0e7@cs.oswego.edu>
References: 
 ,
 <4e6bc22c-a106-2d9e-57ef-93b16d6df0e7@cs.oswego.edu>
Message-ID: 

Hi Doug,

>However, this technique might apply more usefully to TreeSet.

True.  The more I think about it, it is probably applicable to CSLS under the context where it is concurrently added to and then reaches some idle state (shutdown) and then performs the equality test.  It could be port it to CSLM and set views too.

Jason

From Roger.Riggs at Oracle.com  Fri May 26 19:30:28 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 26 May 2017 15:30:28 -0400
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>
References: 
 <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
 <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>
Message-ID: <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com>

Hi Hamlin,

SubclassTest.java:37: typo" excepiton" -> exception


SubclassDataLossTest.java:
103/104:  Adding the class loader close() calls isn't very effective 
since if there is an exception they are not
closed and the creation in a static initializer is mismatched with 
main() code.

It would be cleaner to open in main() using try-with-resources and close 
them in a finally clause.
And pass the loaders to the test function.
But for simplicity, perhaps just leave out the new calls to ldr1/2.close.

(There is something odd about the webrev links, the nagivation links 
don't work as expected. but that's transient)

Thanks, Roger



On 5/26/2017 12:26 AM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for detailed review. Fixed as you suggested, new webrev: 
> http://cr.openjdk.java.net/~mli/8166142/webrev.01/
>
> Thank you
>
> -Hamlin
>
>
> On 2017/5/26 2:54, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> For imports they should import specific classes, wildcards are not used.
>>
>> maskSyntheticModifier/Test.java
>> consTest/Test.java
>> deserializeButton/Test.java
>>
>>  test/java/io/Serializable/packageAccess/Driver.java: the name 
>> "Driver" is not descriptive and should be.
>>
>> Each Driver.java should have a different and functional/descriptive 
>> name.
>>
>> Better yet, there should be a single program that creates jar files 
>> using command line arguments
>> that can be invoked depending on the test.
>>
>> There is a mix of Driver's copying files vs the test program copying; 
>> can that be made more uniform.
>>
>> Test.java files should have descriptive/functional names. (Even if 
>> the duplicating the directory)
>>
>> Regards, Roger
>>
>>
>> On 5/24/2017 5:09 AM, Hamlin Li wrote:
>>> Would you please review the below patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>>>
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>
>


From stuart.marks at oracle.com  Fri May 26 19:34:14 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Fri, 26 May 2017 12:34:14 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: 
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
 <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>
 
Message-ID: <52c8a5c2-69a0-e307-9331-0a7a6d32e972@oracle.com>

On 5/26/17 9:17 AM, Brian Burkhalter wrote:
> Here?s one more attempt:
>
>   * http://cr.openjdk.java.net/~bpb/6791812/webrev.01/
>   * http://cr.openjdk.java.net/~bpb/6791812/File.html
>
> Similar verbal de-obfuscation of other methods may be handled under other
> yet-to-be-file issues.

OK, this looks good. Handling the other stuff separately is fine.

s'marks

From brian.burkhalter at oracle.com  Fri May 26 19:42:42 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 26 May 2017 12:42:42 -0700
Subject: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec)
 Incompatible File.lastModified() and setLastModified() for negative time
In-Reply-To: <52c8a5c2-69a0-e307-9331-0a7a6d32e972@oracle.com>
References: <1222A5BE-59C0-4CB4-A791-A15F41F16FE6@oracle.com>
 <602a8b4b-6702-2129-1a6d-3ff9ff657f45@oracle.com>
 <800C37DD-924A-4D37-92F8-55FC2731999A@oracle.com>
 
 <52c8a5c2-69a0-e307-9331-0a7a6d32e972@oracle.com>
Message-ID: <619011BF-6061-4537-BDC4-ADC0E60BD08F@oracle.com>


On May 26, 2017, at 12:34 PM, Stuart Marks  wrote:

> On 5/26/17 9:17 AM, Brian Burkhalter wrote:
>> Here?s one more attempt:
>> 
>>  * http://cr.openjdk.java.net/~bpb/6791812/webrev.01/
>>  * http://cr.openjdk.java.net/~bpb/6791812/File.html
>> 
>> Similar verbal de-obfuscation of other methods may be handled under other
>> yet-to-be-file issues.
> 
> OK, this looks good. Handling the other stuff separately is fine.

Great!

Thanks,

Brian

From Roger.Riggs at Oracle.com  Fri May 26 19:50:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 26 May 2017 15:50:46 -0400
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
Message-ID: <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>

Hi Felix,

fyi, there is a new version of webrev.ksh that provides convenient next 
and previous links.
http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh


CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not 
make sense.

Ditto: closetest/GetResourceAsStream.java

URLConnection/6212146/Test.java:47 typo: ULR -> URL

Regards, Roger


On 5/25/2017 11:14 PM, Felix Yang wrote:
> Hi Roger,
>
>     please review the updated webrev:
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>
> Thanks,
> Felix
> On 2017/5/26 3:24, Roger Riggs wrote:
>> Hi Felix,
>>
>> closetest/CloseTest:
>>
>> 32: Please put the @modules directives together (and not repeat)
> Fixed
> -Felix
>>
>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>> to avoid accidents).
> Fixed and also organized imports in other test files
> -Felix
>>
>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
> Fixed
> -Felix
>>
>> 69, 78,90,91,... :  space in method call is not proper style
> Fixed and also formatted other history codes. Just format only without 
> logic change.
> Not restricted to this test. I only formatted history codes "nearby", 
> to avoid hiding real logic changes in the patch.
>
> -Felix
>>
>> sealing/CheckSealed.java:
>>  - Why is @test block removed?
>>     Should be converted to @run main CheckSealed
> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
> and declared @test there.
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>
>
> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
> removed. That is because corresponding prerequisite was removed even 
> in JDK 8.
Perhaps then add a comment to CheckSealed.java indicating it is compiled 
and executed by CheckSealedTest.java.

Roger

>
> -Felix
>>
>> Regards, Roger
>>
>>
>>
>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>> Hi there,
>>>
>>>    please review following patch to convert all shell cases under 
>>> java/net to plain java codes.
>>>
>>> Webrev:
>>>
>>>     http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>
>>> Bug:
>>>
>>>     https://bugs.openjdk.java.net/browse/JDK-8166139
>>>
>>>
>>> Thanks,
>>>
>>> Felix
>>>
>>
>


From brent.christian at oracle.com  Fri May 26 20:14:58 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 26 May 2017 13:14:58 -0700
Subject: Request Review JDK-8180574:
 tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in
 upgradeHashedModule() and patchHashedModule() intermittently
In-Reply-To: 
References: 
Message-ID: 

Hi, Mandy

Should "@key intermittent" be added, or is this pretty likely to resolve 
the problem ?

Thanks,
-Brent

On 5/26/17 11:17 AM, Mandy Chung wrote:
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/
>
> The test fails intermittently that the hash of new_m1.jar might be the
> same value as m1.jar that is hashed in m2.  Unfortunately I haven?t
> managed to reproduce the test failure with my instrumented test to
> confirm.  I propose to change the test to upgrade a different version
> of m1 rather than the same content and observe if this test would
> fail again.
>
> Mandy
>

From Roger.Riggs at Oracle.com  Fri May 26 20:29:25 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Fri, 26 May 2017 16:29:25 -0400
Subject: RFR(XS) : 8180890: move c.o.testlibrary.jsr292 classes to
 jdk/test/java/lang/invoke directory
In-Reply-To: <8C7FAAC2-5784-41E4-9E6B-02E124465BA9@oracle.com>
References: 
 <8C7FAAC2-5784-41E4-9E6B-02E124465BA9@oracle.com>
Message-ID: 

Hi Igor,

Looks good.

Can you wrap the too long  lines in:

    LFGarbageCollectedTest.java
    LFCaching/LambdaFormTestCase.java
    MethodHandlesTest.java
    PermuteArgsTest.java

no need for another review.

Thanks, Roger


On 5/26/2017 1:39 PM, Igor Ignatyev wrote:
> Hi Roger,
>
> I'm fine w/ doing more clean up.
>
> I have normalized @library and reorganized imports in the all touched 
> files. could you please take a look at new webrev: 
> http://cr.openjdk.java.net/~iignatyev/8180890/webrev.01/index.html 
> 
> for you convenience, here is the diff b/w 00 and 01 webrevs: 
> http://cr.openjdk.java.net/~iignatyev/8180890/webrev.00-01/index.html 
> 
>
> Thanks,
> -- Igor
>
>> *Roger Riggs */Fri May 26 14:29:30 UTC 2017:/
>> Hi Igor,
>>
>> It would be nice if all of the @library source lines were the same (not
>> mixed in the order).
>>
>> Since this is a cleanup task, I might be inclined to make the order of
>> imports consistent
>> within those tests but that goes beyond the simple goal of the issue.
>>
>> +1
>>
>> Roger
>>> On May 25, 2017, at 6:28 PM, Igor Ignatyev >> > wrote:
>>>
>>> http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html 
>>> 
>>>> 41 lines changed: 5 ins; 4 del; 32 mod;
>>>
>>> Hi all,
>>>
>>> jsr292 testlibrary is used only by java/lang/invoke tests, so there 
>>> is no reason to have this library in common testlibrary, this 
>>> changeset moves jsr292 testlibrary classes from 
>>> jdk/test/lib/testlibrary to jdk/test/java/lang/invoke/common, so 
>>> they will be closed to the tests which use them.
>>>
>>> webrev: 
>>> http://cr.openjdk.java.net/~iignatyev//8180890/webrev.00/index.html
>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8180890
>>> testing: java/lang/invoke
>>>
>>> Thanks,
>>> -- Igor
>>>


From Alan.Bateman at oracle.com  Fri May 26 20:55:10 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 26 May 2017 21:55:10 +0100
Subject: Request Review JDK-8180574:
 tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in
 upgradeHashedModule() and patchHashedModule() intermittently
In-Reply-To: 
References: 
Message-ID: <52b52e42-5ab1-d768-455b-d77edf4702ea@oracle.com>

On 26/05/2017 19:17, Mandy Chung wrote:

> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/
>
> The test fails intermittently that the hash of new_m1.jar might be the
> same value as m1.jar that is hashed in m2.  Unfortunately I haven?t
> managed to reproduce the test failure with my instrumented test to
> confirm.  I propose to change the test to upgrade a different version
> of m1 rather than the same content and observe if this test would
> fail again.
>
Changing the test to use a different version of m1 make sense, the 
changes look okay to me.

-Alan

From mandy.chung at oracle.com  Fri May 26 21:23:52 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 26 May 2017 14:23:52 -0700
Subject: Request Review JDK-8180574:
 tools/launcher/modules/patch/systemmodules/PatchSystemModules.java failed in
 upgradeHashedModule() and patchHashedModule() intermittently
In-Reply-To: 
References: 
 
Message-ID: <11277BF7-BCE6-4E09-853D-5A99DC5E3657@oracle.com>

The test is not supposed to be intermittent.  I like it to be fixed properly.

Mandy

> On May 26, 2017, at 1:14 PM, Brent Christian  wrote:
> 
> Hi, Mandy
> 
> Should "@key intermittent" be added, or is this pretty likely to resolve the problem ?
> 
> Thanks,
> -Brent
> 
> On 5/26/17 11:17 AM, Mandy Chung wrote:
>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8180574/webrev.00/
>> 
>> The test fails intermittently that the hash of new_m1.jar might be the
>> same value as m1.jar that is hashed in m2.  Unfortunately I haven?t
>> managed to reproduce the test failure with my instrumented test to
>> confirm.  I propose to change the test to upgrade a different version
>> of m1 rather than the same content and observe if this test would
>> fail again.
>> 
>> Mandy
>> 


From artem.smotrakov at oracle.com  Fri May 26 22:19:39 2017
From: artem.smotrakov at oracle.com (Artem Smotrakov)
Date: Fri, 26 May 2017 15:19:39 -0700
Subject: RFR(XS) : 8180895 :
 java/security/AccessController/DoPrivAccompliceTest.java has to be improved
In-Reply-To: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com>
References: <807D35FC-39D4-40BD-A7D0-A5D2FA7B39EB@oracle.com>
Message-ID: <63dff5ef-9e7c-1c4d-11ba-caa21308f792@oracle.com>

@summary doesn't seem to be correct, the test uses user.name system 
property.

Otherwise, looks good for me.

Artem


On 05/23/2017 10:17 PM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html
>> 81 lines changed: 37 ins; 23 del; 21 mod;
> Hi all,
>
> could you please review the fix which improves and refactors DoPrivAccompliceTest.java test?
> the test had several issues:
>   - it did not fail if the java spawned by JavaToolUtils::runJava exists w/ non-zero exit code
>   - negative test case was not covered, i.e. the test did not check that if privileges are not granted to the right jar-file an exception is thrown
>   - the test created files inside test.classes, which might interfere w/ other tests
>   - the test uses JavaToolUtils testlibrary class to create a jar, start a jvm, which duplicates functionality of the common testlibrary and will be removed by 8180898[1]
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8180895/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180895
> testing: affected tests
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8180898
>
> Thanks,
> -- Igor


From brent.christian at oracle.com  Sat May 27 00:29:59 2017
From: brent.christian at oracle.com (Brent Christian)
Date: Fri, 26 May 2017 17:29:59 -0700
Subject: JDK 10 RFR of JDK-8181126: Refactor shell test
 java/nio/Buffer/LimitDirectMemory.sh to java
In-Reply-To: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
References: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
Message-ID: 

That all looks fine to me, Amy.

(You'll also need a JDK 10 Reviewer).

Thanks,
-Brent

On 5/25/17 7:42 PM, Amy Lu wrote:
> java/nio/Buffer/LimitDirectMemory.sh
>
> Please review this patch to refactor the shell test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8181126
> webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/
>
> Thanks,
> Amy

From huaming.li at oracle.com  Sat May 27 01:14:02 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Sat, 27 May 2017 09:14:02 +0800
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com>
References: 
 <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
 <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>
 <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com>
Message-ID: <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com>

Hi Roger,

Thank you for catching it, new webrev: 
http://cr.openjdk.java.net/~mli/8166142/webrev.02/

Thank you

-Hamlin


On 2017/5/27 3:30, Roger Riggs wrote:
> Hi Hamlin,
>
> SubclassTest.java:37: typo" excepiton" -> exception
>
>
> SubclassDataLossTest.java:
> 103/104:  Adding the class loader close() calls isn't very effective 
> since if there is an exception they are not
> closed and the creation in a static initializer is mismatched with 
> main() code.
>
> It would be cleaner to open in main() using try-with-resources and 
> close them in a finally clause.
> And pass the loaders to the test function.
> But for simplicity, perhaps just leave out the new calls to ldr1/2.close.
>
> (There is something odd about the webrev links, the nagivation links 
> don't work as expected. but that's transient)
>
> Thanks, Roger
>
>
>
> On 5/26/2017 12:26 AM, Hamlin Li wrote:
>> Hi Roger,
>>
>> Thank you for detailed review. Fixed as you suggested, new webrev: 
>> http://cr.openjdk.java.net/~mli/8166142/webrev.01/
>>
>> Thank you
>>
>> -Hamlin
>>
>>
>> On 2017/5/26 2:54, Roger Riggs wrote:
>>> Hi Hamlin,
>>>
>>> For imports they should import specific classes, wildcards are not 
>>> used.
>>>
>>> maskSyntheticModifier/Test.java
>>> consTest/Test.java
>>> deserializeButton/Test.java
>>>
>>>  test/java/io/Serializable/packageAccess/Driver.java: the name 
>>> "Driver" is not descriptive and should be.
>>>
>>> Each Driver.java should have a different and functional/descriptive 
>>> name.
>>>
>>> Better yet, there should be a single program that creates jar files 
>>> using command line arguments
>>> that can be invoked depending on the test.
>>>
>>> There is a mix of Driver's copying files vs the test program 
>>> copying; can that be made more uniform.
>>>
>>> Test.java files should have descriptive/functional names. (Even if 
>>> the duplicating the directory)
>>>
>>> Regards, Roger
>>>
>>>
>>> On 5/24/2017 5:09 AM, Hamlin Li wrote:
>>>> Would you please review the below patch?
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>>>>
>>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>>>>
>>>>
>>>> Thank you
>>>>
>>>> -Hamlin
>>>>
>>>
>>
>


From felix.yang at oracle.com  Sat May 27 01:15:16 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Sat, 27 May 2017 09:15:16 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
Message-ID: <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>

Hi Roger,

     thanks for the comments. Please see the new webrev

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/

-Felix
On 2017/5/27 3:50, Roger Riggs wrote:
> Hi Felix,
>
> fyi, there is a new version of webrev.ksh that provides convenient 
> next and previous links.
> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>
>
> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not 
> make sense.
>
> Ditto: closetest/GetResourceAsStream.java
Removed such check, since the test depends on several system 
properties("test.src", "user.dir"). It is not expected to run outside jtreg.

-Felix
>
> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>
> Regards, Roger
>
>
> On 5/25/2017 11:14 PM, Felix Yang wrote:
>> Hi Roger,
>>
>>     please review the updated webrev:
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>
>> Thanks,
>> Felix
>> On 2017/5/26 3:24, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> closetest/CloseTest:
>>>
>>> 32: Please put the @modules directives together (and not repeat)
>> Fixed
>> -Felix
>>>
>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary 
>>> to avoid accidents).
>> Fixed and also organized imports in other test files
>> -Felix
>>>
>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>> Fixed
>> -Felix
>>>
>>> 69, 78,90,91,... :  space in method call is not proper style
>> Fixed and also formatted other history codes. Just format only 
>> without logic change.
>> Not restricted to this test. I only formatted history codes "nearby", 
>> to avoid hiding real logic changes in the patch.
>>
>> -Felix
>>>
>>> sealing/CheckSealed.java:
>>>  - Why is @test block removed?
>>>     Should be converted to @run main CheckSealed
>> There was a checksealed.sh. I replaced it with CheckSealedTest.java 
>> and declared @test there.
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>
>>
>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were 
>> removed. That is because corresponding prerequisite was removed even 
>> in JDK 8.
> Perhaps then add a comment to CheckSealed.java indicating it is 
> compiled and executed by CheckSealedTest.java.
>
> Roger
>
>>
>> -Felix
>>>
>>> Regards, Roger
>>>
>>>
>>>
>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>> Hi there,
>>>>
>>>>    please review following patch to convert all shell cases under 
>>>> java/net to plain java codes.
>>>>
>>>> Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>
>>>> Bug:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Felix
>>>>
>>>
>>
>


From huaming.li at oracle.com  Sat May 27 01:14:57 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Sat, 27 May 2017 09:14:57 +0800
Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in
 java.base & java.datatransfer module
In-Reply-To: 
References: 
Message-ID: <735f89a2-8c5b-a08c-dc6f-5cd14ad1629a@oracle.com>

Is someone available to review the change?

Thank you

-Hamlin


On 2017/5/25 17:19, Hamlin Li wrote:
> Would you please review below patch?
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8181082
>
> webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
>
>
> Thank you
>
> -Hamlin
>


From sergey.bylokhov at oracle.com  Sat May 27 01:23:01 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 26 May 2017 18:23:01 -0700 (PDT)
Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in
 java.base & java.datatransfer module
Message-ID: <3a40d9e5-f04e-4058-ac93-91c7b1715e7d@default>


The changes in datatransfer module looks fine. But how did you check when these classes were added?

----- huaming.li at oracle.com wrote:

> Is someone available to review the change?
> 
> Thank you
> 
> -Hamlin
> 
> 
> On 2017/5/25 17:19, Hamlin Li wrote:
> > Would you please review below patch?
> >
> > bug: https://bugs.openjdk.java.net/browse/JDK-8181082
> >
> > webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
> >
> >
> > Thank you
> >
> > -Hamlin
> >

From igor.ignatyev at oracle.com  Sat May 27 06:06:16 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 26 May 2017 23:06:16 -0700
Subject: RFR(S) : 8180887: move FileUtils to top level testlibrary
Message-ID: <58DE5A70-1F0E-4BE2-A578-EDA449A8A1FC@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180887/webrev.00/index.html
> 567 lines changed: 231 ins; 252 del; 84 mod;

Hi all,

could you please review this changeset which moves FileUtils class from the jdk testlibrary to the top level testlibary?

webrev: http://cr.openjdk.java.net/~iignatyev/8180887/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180887
testing: :tier[1-3]

Thanks,
-- Igor 

From Alan.Bateman at oracle.com  Sat May 27 06:17:48 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 May 2017 07:17:48 +0100
Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in
 java.base & java.datatransfer module
In-Reply-To: <735f89a2-8c5b-a08c-dc6f-5cd14ad1629a@oracle.com>
References: 
 <735f89a2-8c5b-a08c-dc6f-5cd14ad1629a@oracle.com>
Message-ID: <212618e5-6a12-42ab-bda6-0013d2816a79@oracle.com>



On 27/05/2017 02:14, Hamlin Li wrote:
> Is someone available to review the change?
>
I skimmed through it,  crossing checking several against the  docs for 
JDK 1.0, JDK 1.1, and JDK 1.2. I didn't spot any mistakes but I agree 
with Sergey, it would be good to know if this was done by creating the 
lists from the binaries rather than manual.

-Alan

>
>
> On 2017/5/25 17:19, Hamlin Li wrote:
>> Would you please review below patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8181082
>>
>> webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
>>
>>
>> Thank you
>>
>> -Hamlin
>>
>


From igor.ignatyev at oracle.com  Sat May 27 06:30:14 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Fri, 26 May 2017 23:30:14 -0700
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html
> 308 lines changed: 110 ins; 40 del; 158 mod


Hi all,

this changeset introduces jdk.test.lib.RandomFactory in the top level testlibrary and updates all but java/time/ tests to use it instead of jdk.testlibrary.RandomFactory from the jdk testlibrary. due to CODETOOLS-7901987[1], java/time/ tests can't use the top level testlibrary, so jdk.testlibrary.RandomFactory hasn't been removed, however it has been marked as deprecated and will be removed by JDK-8181118[2] as soon as there is promoted jtreg w/ CODETOOLS-7901987 fixed.

webrev: http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180805
testing: :tier[1-3]

[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901987
[2] https://bugs.openjdk.java.net/browse/JDK-8181118

Thanks,
-- Igor

From joel.borggren.franck at gmail.com  Sat May 27 08:48:26 2017
From: joel.borggren.franck at gmail.com (=?UTF-8?Q?Joel_Borggr=C3=A9n=2DFranck?=)
Date: Sat, 27 May 2017 10:48:26 +0200
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
Message-ID: 

Hi Joe,

Looks Good.

Nit: TypeAnnotationParser.java

"126         // If a constructor has a mandated outer this, that parameter
 127         // has no annotations and the annotations to parameter mapping
 128         // should be offset by 1."

>From memory this comment is a bit misleading since the outer this
might actually have a receiver type annotation. The outcome seem
correct though.

cheers
/Joel

On Fri, May 19, 2017 at 11:31 PM, joe darcy  wrote:
> Hello,
>
> Please review the webrev to fix
>
>     JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
>     http://cr.openjdk.java.net/~darcy/8074977.3/
>
> To condense a complicated situation, there are cases where the number of
> parameters present for a constructor in source code and the number of
> parameters present for that constructor in the class file differ. One of
> those cases occurs for the constructor of a non-static member class [1]
> where there is a leading parameter to accept the outer this argument.
>
> Bug JDK-8074977 reports on a situation where the type annotations on
> constructor parameters are incorrectly reported. Essentially, an off-by-one
> error is the cause since the annotation information is stored with respect
> to the number of parameters present in the source and an additional
> parameter is present at runtime.
>
> An analogous situation exists for declaration annotations and constructor
> parameters, declaration annotations being the traditional flavor of
> annotations.
>
> Type annotations and declaration annotations are read using different APIs
> so require separate fixes to detect the additional parameter and make the
> necessary adjustments in the returned information.
>
> The regression tests cover both the type annotation reading API and the two
> ways of reading declaration annotations on parameters, calling
> getParameterAnnotations on the constructor or call getParameters on the
> constructor and then calling getAnnotations on each parameter. The
> getParameters API was added in JDK 8.
>
> Static member and non-static member classes are used as test cases, as are
> constructors with and without generic type information.
>
> Thanks,
>
> -Joe
>
> [1]
> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>

From joe.darcy at oracle.com  Sat May 27 17:43:31 2017
From: joe.darcy at oracle.com (joe darcy)
Date: Sat, 27 May 2017 10:43:31 -0700
Subject: JDK 9 RFR of JDK-8074977: Constructor.getAnnotatedParameterTypes
 returns wrong value
In-Reply-To: 
References: <9674be25-0874-0d27-4ca8-85cffb26dece@oracle.com>
 
Message-ID: 

Hi Joel,

Thanks for the comments. I'll include an update/correction as part of 
the follow-up work in JDK 10.

Cheers,

-Joe


On 5/27/2017 1:48 AM, Joel Borggr?n-Franck wrote:
> Hi Joe,
>
> Looks Good.
>
> Nit: TypeAnnotationParser.java
>
> "126         // If a constructor has a mandated outer this, that parameter
>   127         // has no annotations and the annotations to parameter mapping
>   128         // should be offset by 1."
>
>  From memory this comment is a bit misleading since the outer this
> might actually have a receiver type annotation. The outcome seem
> correct though.
>
> cheers
> /Joel
>
> On Fri, May 19, 2017 at 11:31 PM, joe darcy  wrote:
>> Hello,
>>
>> Please review the webrev to fix
>>
>>      JDK-8074977: Constructor.getAnnotatedParameterTypes returns wrong value
>>      http://cr.openjdk.java.net/~darcy/8074977.3/
>>
>> To condense a complicated situation, there are cases where the number of
>> parameters present for a constructor in source code and the number of
>> parameters present for that constructor in the class file differ. One of
>> those cases occurs for the constructor of a non-static member class [1]
>> where there is a leading parameter to accept the outer this argument.
>>
>> Bug JDK-8074977 reports on a situation where the type annotations on
>> constructor parameters are incorrectly reported. Essentially, an off-by-one
>> error is the cause since the annotation information is stored with respect
>> to the number of parameters present in the source and an additional
>> parameter is present at runtime.
>>
>> An analogous situation exists for declaration annotations and constructor
>> parameters, declaration annotations being the traditional flavor of
>> annotations.
>>
>> Type annotations and declaration annotations are read using different APIs
>> so require separate fixes to detect the additional parameter and make the
>> necessary adjustments in the returned information.
>>
>> The regression tests cover both the type annotation reading API and the two
>> ways of reading declaration annotations on parameters, calling
>> getParameterAnnotations on the constructor or call getParameters on the
>> constructor and then calling getAnnotations on each parameter. The
>> getParameters API was added in JDK 8.
>>
>> Static member and non-static member classes are used as test cases, as are
>> constructors with and without generic type information.
>>
>> Thanks,
>>
>> -Joe
>>
>> [1]
>> https://blogs.oracle.com/darcy/nested,-inner,-member,-and-top-level-classes
>>


From chris.hegarty at oracle.com  Mon May 29 10:19:00 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 29 May 2017 11:19:00 +0100
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
Message-ID: 

Felix,

Thanks for taking this one. A few comments:


1) test/java/net/URLConnection/6212146/TestDriver.java
    Please check indentation around L81:

   80         Files.copy(testJar,
              ___________targetDir.resolve(ARCHIVE_NAME),
   81         ___________StandardCopyOption.REPLACE_EXISTING);


    Also, and more importantly, the ulimit that was executed in the shell
    is supposed to affect the potential file descriptor usage of the
    following java process. I believe that is not captured correctly
    in the TestDriver.java, since there is no parent/child relationship
    between the processes, no?


2) test/java/net/URLClassLoader/getresourceasstream/policy

    Please add a copyright/header.

3) getresourceasstream/TestDriver.java, CheckSealedTest.java, CloseTest.java

    If you statically import StandardCopyOption.REPLACE_EXISTING in a
    few places it may lead to a few shorter lines.

4) Why has the test for 5077773 simply been removed?

-Chris.


On 27/05/17 02:15, Felix Yang wrote:
> Hi Roger,
>
>     thanks for the comments. Please see the new webrev
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>
> -Felix
> On 2017/5/27 3:50, Roger Riggs wrote:
>> Hi Felix,
>>
>> fyi, there is a new version of webrev.ksh that provides convenient
>> next and previous links.
>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>>
>>
>>
>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>> make sense.
>>
>> Ditto: closetest/GetResourceAsStream.java
> Removed such check, since the test depends on several system
> properties("test.src", "user.dir"). It is not expected to run outside
> jtreg.
>
> -Felix
>>
>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>
>> Regards, Roger
>>
>>
>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>> Hi Roger,
>>>
>>>     please review the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>
>>> Thanks,
>>> Felix
>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>> Hi Felix,
>>>>
>>>> closetest/CloseTest:
>>>>
>>>> 32: Please put the @modules directives together (and not repeat)
>>> Fixed
>>> -Felix
>>>>
>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>> to avoid accidents).
>>> Fixed and also organized imports in other test files
>>> -Felix
>>>>
>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>> Fixed
>>> -Felix
>>>>
>>>> 69, 78,90,91,... :  space in method call is not proper style
>>> Fixed and also formatted other history codes. Just format only
>>> without logic change.
>>> Not restricted to this test. I only formatted history codes "nearby",
>>> to avoid hiding real logic changes in the patch.
>>>
>>> -Felix
>>>>
>>>> sealing/CheckSealed.java:
>>>>  - Why is @test block removed?
>>>>     Should be converted to @run main CheckSealed
>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>> and declared @test there.
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html
>>>
>>>
>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>> removed. That is because corresponding prerequisite was removed even
>>> in JDK 8.
>> Perhaps then add a comment to CheckSealed.java indicating it is
>> compiled and executed by CheckSealedTest.java.
>>
>> Roger
>>
>>>
>>> -Felix
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>>
>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>> Hi there,
>>>>>
>>>>>    please review following patch to convert all shell cases under
>>>>> java/net to plain java codes.
>>>>>
>>>>> Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>
>>>>> Bug:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Felix
>>>>>
>>>>
>>>
>>
>

From felix.yang at oracle.com  Mon May 29 15:17:20 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Mon, 29 May 2017 23:17:20 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: 
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 
Message-ID: 

Hi Chris,

     please review the updated webrev below. Comments inline.

http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/

-Felix
On 2017/5/29 18:19, Chris Hegarty wrote:
> Felix,
>
> Thanks for taking this one. A few comments:
>
>
> 1) test/java/net/URLConnection/6212146/TestDriver.java
>    Please check indentation around L81:
>
>   80         Files.copy(testJar,
>              ___________targetDir.resolve(ARCHIVE_NAME),
>   81         ___________StandardCopyOption.REPLACE_EXISTING);
>
>    Also, and more importantly, the ulimit that was executed in the shell
>    is supposed to affect the potential file descriptor usage of the
>    following java process. I believe that is not captured correctly
>    in the TestDriver.java, since there is no parent/child relationship
>    between the processes, no?
Fixed, thanks
Felix
>
>
> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>
>    Please add a copyright/header.
>
Checked existing test policy files, all of them have no 
copyright/header. So I hesitated to add here. Please confirm.

-Felix
> 3) getresourceasstream/TestDriver.java, CheckSealedTest.java, 
> CloseTest.java
>
>    If you statically import StandardCopyOption.REPLACE_EXISTING in a
>    few places it may lead to a few shorter lines.
Changed, thanks
Felix
>
> 4) Why has the test for 5077773 simply been removed?
As priorly commented, the test is probably not necessary.
Because it actually quits immediately after prerequisite checking for 
"javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it 
is to cover endorsed scenarios, while endorsed mechanism has been 
removed in JDK 9.

-Felix
>
> -Chris.
>
>
> On 27/05/17 02:15, Felix Yang wrote:
>> Hi Roger,
>>
>>     thanks for the comments. Please see the new webrev
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>
>> -Felix
>> On 2017/5/27 3:50, Roger Riggs wrote:
>>> Hi Felix,
>>>
>>> fyi, there is a new version of webrev.ksh that provides convenient
>>> next and previous links.
>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh 
>>>
>>>
>>>
>>>
>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>>> make sense.
>>>
>>> Ditto: closetest/GetResourceAsStream.java
>> Removed such check, since the test depends on several system
>> properties("test.src", "user.dir"). It is not expected to run outside
>> jtreg.
>>
>> -Felix
>>>
>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>
>>> Regards, Roger
>>>
>>>
>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>> Hi Roger,
>>>>
>>>>     please review the updated webrev:
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>
>>>> Thanks,
>>>> Felix
>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>> Hi Felix,
>>>>>
>>>>> closetest/CloseTest:
>>>>>
>>>>> 32: Please put the @modules directives together (and not repeat)
>>>> Fixed
>>>> -Felix
>>>>>
>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>> to avoid accidents).
>>>> Fixed and also organized imports in other test files
>>>> -Felix
>>>>>
>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>> Fixed
>>>> -Felix
>>>>>
>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>> Fixed and also formatted other history codes. Just format only
>>>> without logic change.
>>>> Not restricted to this test. I only formatted history codes "nearby",
>>>> to avoid hiding real logic changes in the patch.
>>>>
>>>> -Felix
>>>>>
>>>>> sealing/CheckSealed.java:
>>>>>  - Why is @test block removed?
>>>>>     Should be converted to @run main CheckSealed
>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>> and declared @test there.
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>>>
>>>>
>>>>
>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>> removed. That is because corresponding prerequisite was removed even
>>>> in JDK 8.
>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>> compiled and executed by CheckSealedTest.java.
>>>
>>> Roger
>>>
>>>>
>>>> -Felix
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>>
>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>> Hi there,
>>>>>>
>>>>>>    please review following patch to convert all shell cases under
>>>>>> java/net to plain java codes.
>>>>>>
>>>>>> Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>
>>>>>> Bug:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Felix
>>>>>>
>>>>>
>>>>
>>>
>>


From chris.hegarty at oracle.com  Tue May 30 09:44:05 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 30 May 2017 10:44:05 +0100
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: 
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 
 
Message-ID: <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>

On 29/05/17 16:17, Felix Yang wrote:
> Hi Chris,
>
>     please review the updated webrev below. Comments inline.
>
> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/

Thanks Felix.

> ..
>> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>>
>>    Please add a copyright/header.
>>
> Checked existing test policy files, all of them have no
> copyright/header. So I hesitated to add here. Please confirm.

The code is not consistent, but please do add the copyright
header here ( we'll fix the other files at a later time ).

>> ...
>> 4) Why has the test for 5077773 simply been removed?
> As priorly commented, the test is probably not necessary.
> Because it actually quits immediately after prerequisite checking for
> "javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it
> is to cover endorsed scenarios, while endorsed mechanism has been
> removed in JDK 9.

Ok, sorry for not seeing the previous reply.

I am finished reviewing this. No need for an updated webrev, for
the license header.

-Chris.

> -Felix
>>
>> -Chris.
>>
>>
>> On 27/05/17 02:15, Felix Yang wrote:
>>> Hi Roger,
>>>
>>>     thanks for the comments. Please see the new webrev
>>>
>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>>
>>> -Felix
>>> On 2017/5/27 3:50, Roger Riggs wrote:
>>>> Hi Felix,
>>>>
>>>> fyi, there is a new version of webrev.ksh that provides convenient
>>>> next and previous links.
>>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh
>>>>
>>>>
>>>>
>>>>
>>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does not
>>>> make sense.
>>>>
>>>> Ditto: closetest/GetResourceAsStream.java
>>> Removed such check, since the test depends on several system
>>> properties("test.src", "user.dir"). It is not expected to run outside
>>> jtreg.
>>>
>>> -Felix
>>>>
>>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>>> Hi Roger,
>>>>>
>>>>>     please review the updated webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>>
>>>>> Thanks,
>>>>> Felix
>>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>>> Hi Felix,
>>>>>>
>>>>>> closetest/CloseTest:
>>>>>>
>>>>>> 32: Please put the @modules directives together (and not repeat)
>>>>> Fixed
>>>>> -Felix
>>>>>>
>>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>>> to avoid accidents).
>>>>> Fixed and also organized imports in other test files
>>>>> -Felix
>>>>>>
>>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>>> Fixed
>>>>> -Felix
>>>>>>
>>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>>> Fixed and also formatted other history codes. Just format only
>>>>> without logic change.
>>>>> Not restricted to this test. I only formatted history codes "nearby",
>>>>> to avoid hiding real logic changes in the patch.
>>>>>
>>>>> -Felix
>>>>>>
>>>>>> sealing/CheckSealed.java:
>>>>>>  - Why is @test block removed?
>>>>>>     Should be converted to @run main CheckSealed
>>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>>> and declared @test there.
>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html
>>>>>
>>>>>
>>>>>
>>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>>> removed. That is because corresponding prerequisite was removed even
>>>>> in JDK 8.
>>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>>> compiled and executed by CheckSealedTest.java.
>>>>
>>>> Roger
>>>>
>>>>>
>>>>> -Felix
>>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>>> Hi there,
>>>>>>>
>>>>>>>    please review following patch to convert all shell cases under
>>>>>>> java/net to plain java codes.
>>>>>>>
>>>>>>> Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>>
>>>>>>> Bug:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Felix
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>

From thomas.stuefe at gmail.com  Tue May 30 09:46:41 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 30 May 2017 11:46:41 +0200
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
Message-ID: 

Hi all,

may I have please a review for this tiny change:

Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.00/webrev/

This reverts 8177809 for AIX because it leads to build errors on older AIX
systems. We want to retain the ability to build on older AIX releases.

Thanks, Thomas

From felix.yang at oracle.com  Tue May 30 14:58:55 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Tue, 30 May 2017 22:58:55 +0800
Subject: RFR 8166139/10, Refactor java/net shell cases to java
In-Reply-To: <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>
References: <1136b4fe-0733-ae7a-aae2-135fa49f6035@oracle.com>
 <91acc262-36ca-100f-78a3-1a68ab2b2303@Oracle.com>
 <1b9f4d07-af31-deda-8cf7-3c0ea02f351f@oracle.com>
 <1d7598b4-ede0-e8c8-150e-7d7d1f51e07e@Oracle.com>
 <6e97d724-44ca-87c9-41ea-414fb6add822@oracle.com>
 
 
 <3a722373-2f5a-2ec1-46da-615b80e7aeba@oracle.com>
Message-ID: 

Hi Chris,

    pushed, thank you very much!

-Felix
On 2017/5/30 17:44, Chris Hegarty wrote:
> On 29/05/17 16:17, Felix Yang wrote:
>> Hi Chris,
>>
>>     please review the updated webrev below. Comments inline.
>>
>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.03/
>
> Thanks Felix.
>
>> ..
>>> 2) test/java/net/URLClassLoader/getresourceasstream/policy
>>>
>>>    Please add a copyright/header.
>>>
>> Checked existing test policy files, all of them have no
>> copyright/header. So I hesitated to add here. Please confirm.
>
> The code is not consistent, but please do add the copyright
> header here ( we'll fix the other files at a later time ).
Added.
>
>>> ...
>>> 4) Why has the test for 5077773 simply been removed?
>> As priorly commented, the test is probably not necessary.
>> Because it actually quits immediately after prerequisite checking for
>> "javax/swing/text/rtf/charsets/mac.txt". According with JDK-5077773, it
>> is to cover endorsed scenarios, while endorsed mechanism has been
>> removed in JDK 9.
>
> Ok, sorry for not seeing the previous reply.
>
> I am finished reviewing this. No need for an updated webrev, for
> the license header.
>
> -Chris.
>
>> -Felix
>>>
>>> -Chris.
>>>
>>>
>>> On 27/05/17 02:15, Felix Yang wrote:
>>>> Hi Roger,
>>>>
>>>>     thanks for the comments. Please see the new webrev
>>>>
>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.02/
>>>>
>>>> -Felix
>>>> On 2017/5/27 3:50, Roger Riggs wrote:
>>>>> Hi Felix,
>>>>>
>>>>> fyi, there is a new version of webrev.ksh that provides convenient
>>>>> next and previous links.
>>>>> http://hg.openjdk.java.net/code-tools/webrev/raw-file/d26c194772db/webrev.ksh 
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> CloseTest.java: 66; checking WORK_DIR *after* calling setup() does 
>>>>> not
>>>>> make sense.
>>>>>
>>>>> Ditto: closetest/GetResourceAsStream.java
>>>> Removed such check, since the test depends on several system
>>>> properties("test.src", "user.dir"). It is not expected to run outside
>>>> jtreg.
>>>>
>>>> -Felix
>>>>>
>>>>> URLConnection/6212146/Test.java:47 typo: ULR -> URL
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>> On 5/25/2017 11:14 PM, Felix Yang wrote:
>>>>>> Hi Roger,
>>>>>>
>>>>>>     please review the updated webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/
>>>>>>
>>>>>> Thanks,
>>>>>> Felix
>>>>>> On 2017/5/26 3:24, Roger Riggs wrote:
>>>>>>> Hi Felix,
>>>>>>>
>>>>>>> closetest/CloseTest:
>>>>>>>
>>>>>>> 32: Please put the @modules directives together (and not repeat)
>>>>>> Fixed
>>>>>> -Felix
>>>>>>>
>>>>>>> 44: do not use wildcard imports  (reconfigure your IDE if necessary
>>>>>>> to avoid accidents).
>>>>>> Fixed and also organized imports in other test files
>>>>>> -Felix
>>>>>>>
>>>>>>> 63: setup() is invoked twice...  remove 1 or explain why 2 calls
>>>>>> Fixed
>>>>>> -Felix
>>>>>>>
>>>>>>> 69, 78,90,91,... :  space in method call is not proper style
>>>>>> Fixed and also formatted other history codes. Just format only
>>>>>> without logic change.
>>>>>> Not restricted to this test. I only formatted history codes 
>>>>>> "nearby",
>>>>>> to avoid hiding real logic changes in the patch.
>>>>>>
>>>>>> -Felix
>>>>>>>
>>>>>>> sealing/CheckSealed.java:
>>>>>>>  - Why is @test block removed?
>>>>>>>     Should be converted to @run main CheckSealed
>>>>>> There was a checksealed.sh. I replaced it with CheckSealedTest.java
>>>>>> and declared @test there.
>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.01/test/java/net/URLClassLoader/sealing/CheckSealedTest.java.html 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> BTW, you may noticed test/java/net/URLClassLoader/B5077773.* were
>>>>>> removed. That is because corresponding prerequisite was removed even
>>>>>> in JDK 8.
>>>>> Perhaps then add a comment to CheckSealed.java indicating it is
>>>>> compiled and executed by CheckSealedTest.java.
>>>>>
>>>>> Roger
>>>>>
>>>>>>
>>>>>> -Felix
>>>>>>>
>>>>>>> Regards, Roger
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 5/25/2017 4:08 AM, Felix Yang wrote:
>>>>>>>> Hi there,
>>>>>>>>
>>>>>>>>    please review following patch to convert all shell cases under
>>>>>>>> java/net to plain java codes.
>>>>>>>>
>>>>>>>> Webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~xiaofeya/8166139/webrev.00/
>>>>>>>>
>>>>>>>> Bug:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8166139
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Felix
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>


From brian.burkhalter at oracle.com  Tue May 30 16:36:48 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 30 May 2017 09:36:48 -0700
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: 
References: 
Message-ID: 

Hi Igor,

On May 26, 2017, at 11:30 PM, Igor Ignatyev  wrote:

> this changeset introduces jdk.test.lib.RandomFactory in the top level testlibrary and updates all but java/time/ tests to use it instead of jdk.testlibrary.RandomFactory from the jdk testlibrary.

Code changes look OK provided all tests still run properly. I have not been following the test package refactoring however so no comment on that.

> due to CODETOOLS-7901987[1], java/time/ tests can't use the top level testlibrary, so jdk.testlibrary.RandomFactory hasn't been removed, however it has been marked as deprecated and will be removed by JDK-8181118[2] as soon as there is promoted jtreg w/ CODETOOLS-7901987 fixed.

Should this be using ?@Deprecated(since=?9?, forRemoval=true)? or something like that?

Thanks,

Brian

From martin.doerr at sap.com  Mon May 29 09:46:30 2017
From: martin.doerr at sap.com (Doerr, Martin)
Date: Mon, 29 May 2017 09:46:30 +0000
Subject: [XS] RFR : JDK-8181145 : add platforms to test
 java/nio/ByteOrder/NativeOrder.java (test change)
In-Reply-To: 
References: 
 
Message-ID: <3994b8f747104a84b7906c6ce58ec43f@sap.com>

Hi,

thanks for providing the webrev and for reviewing.
I?ve pushed it.

Best regards,
Martin


From: Martin Buchholz [mailto:martinrb at google.com]
Sent: Freitag, 26. Mai 2017 17:55
To: Baesken, Matthias 
Cc: core-libs-dev at openjdk.java.net; Simonis, Volker ; Schmidt, Lutz ; Doerr, Martin 
Subject: Re: [XS] RFR : JDK-8181145 : add platforms to test java/nio/ByteOrder/NativeOrder.java (test change)

Looks good to me!

On Fri, May 26, 2017 at 7:43 AM, Baesken, Matthias > wrote:
Please review this small test change .
It adds a number of platforms to the existing test  jdk10  jtreg test  java/nio/ByteOrder/NativeOrder.java  .

Especially the porting platforms ppc64/ppc64le/s390x are added .


Webrev :

http://cr.openjdk.java.net/~mbaesken/webrevs/8181145/


bug :

https://bugs.openjdk.java.net/browse/JDK-8181145


Thanks, Matthias



From daniel.fuchs at oracle.com  Tue May 30 18:00:29 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Tue, 30 May 2017 19:00:29 +0100
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
In-Reply-To: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
Message-ID: 

Hi Roger,

Looks good! Just one nit with the test:

  194             registry.unbind(name);
  195             Assert.fail("Registry filter should have rejected 
depth: " + depthOverride + 1);

Technically, the test will also pass if bind() succeed but
unbind() fails - for some unforeseen reason.

best regards,

-- daniel

On 25/05/17 16:31, Roger Riggs wrote:
> Please review an update to the RMI Registry built-in serial filter 
> implementation limit on the depth
> of a instance that can be bound in the registry.  The initial depth 
> limit was 5 and it was too limiting
> for some existing applications.  It limit is updated to depth = 20 and 
> should be more than adequate.
> 
> Webrev:
> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
> 
> Issue:
>     https://bugs.openjdk.java.net/browse/JDK-8180582
> 
> Thanks, Roger


From Roger.Riggs at Oracle.com  Tue May 30 18:12:59 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 30 May 2017 14:12:59 -0400
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: 
References: 
 
Message-ID: 

Hi Igor,

Looks fine.

Though I am puzzled why the changeset in the webrev is empty.
http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/jdk10.patch

Thanks, Roger

On 5/30/2017 12:36 PM, Brian Burkhalter wrote:
> Hi Igor,
>
> On May 26, 2017, at 11:30 PM, Igor Ignatyev  wrote:
>
>> this changeset introduces jdk.test.lib.RandomFactory in the top level testlibrary and updates all but java/time/ tests to use it instead of jdk.testlibrary.RandomFactory from the jdk testlibrary.
> Code changes look OK provided all tests still run properly. I have not been following the test package refactoring however so no comment on that.
>
>> due to CODETOOLS-7901987[1], java/time/ tests can't use the top level testlibrary, so jdk.testlibrary.RandomFactory hasn't been removed, however it has been marked as deprecated and will be removed by JDK-8181118[2] as soon as there is promoted jtreg w/ CODETOOLS-7901987 fixed.
> Should this be using ?@Deprecated(since=?9?, forRemoval=true)? or something like that?
>
> Thanks,
>
> Brian


From Roger.Riggs at Oracle.com  Tue May 30 18:26:52 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 30 May 2017 14:26:52 -0400
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
In-Reply-To: 
References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
 
Message-ID: <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com>

Hi Daniel,

Fixed, there is no need for the unbind since the registry is not reused 
and it might
cause a spurious success.

(Also corrected the exception error message @ 151 and 153).

Webrev updated in place.
http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/jdk10.patch

Thanks, Roger


On 5/30/2017 2:00 PM, Daniel Fuchs wrote:
> Hi Roger,
>
> Looks good! Just one nit with the test:
>
>  194             registry.unbind(name);
>  195             Assert.fail("Registry filter should have rejected 
> depth: " + depthOverride + 1);
>
> Technically, the test will also pass if bind() succeed but
> unbind() fails - for some unforeseen reason.
>
> best regards,
>
> -- daniel
>
> On 25/05/17 16:31, Roger Riggs wrote:
>> Please review an update to the RMI Registry built-in serial filter 
>> implementation limit on the depth
>> of a instance that can be bound in the registry.  The initial depth 
>> limit was 5 and it was too limiting
>> for some existing applications.  It limit is updated to depth = 20 
>> and should be more than adequate.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
>>
>> Issue:
>>     https://bugs.openjdk.java.net/browse/JDK-8180582
>>
>> Thanks, Roger
>


From paul.sandoz at oracle.com  Tue May 30 19:47:07 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 May 2017 12:47:07 -0700
Subject: RFR(S) : 8180887: move FileUtils to top level testlibrary
In-Reply-To: <58DE5A70-1F0E-4BE2-A578-EDA449A8A1FC@oracle.com>
References: <58DE5A70-1F0E-4BE2-A578-EDA449A8A1FC@oracle.com>
Message-ID: <0A715898-174F-4F6D-9115-12F72D04CF9E@oracle.com>

+1

Paul.

> On 26 May 2017, at 23:06, Igor Ignatyev  wrote:
> 
> http://cr.openjdk.java.net/~iignatyev//8180887/webrev.00/index.html
>> 567 lines changed: 231 ins; 252 del; 84 mod;
> 
> Hi all,
> 
> could you please review this changeset which moves FileUtils class from the jdk testlibrary to the top level testlibary?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev/8180887/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180887
> testing: :tier[1-3]
> 
> Thanks,
> -- Igor


From paul.sandoz at oracle.com  Tue May 30 19:51:20 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 May 2017 12:51:20 -0700
Subject: Request Review: JDK-8181148: Update the jdeps tool to list
 exported packages instead of just internal APIs
In-Reply-To: <249CFE06-4CDC-4894-A66B-2BE9CEF42C36@oracle.com>
References: <249CFE06-4CDC-4894-A66B-2BE9CEF42C36@oracle.com>
Message-ID: <251F47E8-B98D-4E10-BED1-63B77E3675D3@oracle.com>

+1

Paul.

> On 26 May 2017, at 10:29, Mandy Chung  wrote:
> 
> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8181148/webrev.00/
> 
> This updates an existing tool to take an option to list exported
> packages.  This tool is not run during the build but instead used to
> generate a resource file checked in in the source.  It?s relevant
> to the build tools in build.tools.jigsaw package and so this tool
> is moved to jdk repo that makes it easier to find.
> 
> Mandy
> 
> 


From paul.sandoz at oracle.com  Tue May 30 19:54:19 2017
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 May 2017 12:54:19 -0700
Subject: JDK 10 RFR of JDK-8181126: Refactor shell test
 java/nio/Buffer/LimitDirectMemory.sh to java
In-Reply-To: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
References: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
Message-ID: <71EA9FDB-E8FA-410A-A812-BCC17233ABD3@oracle.com>

+1

Paul.

> On 25 May 2017, at 19:42, Amy Lu  wrote:
> 
> java/nio/Buffer/LimitDirectMemory.sh
> 
> Please review this patch to refactor the shell test to java.
> 
> bug: https://bugs.openjdk.java.net/browse/JDK-8181126
> webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/
> 
> Thanks,
> Amy


From Roger.Riggs at Oracle.com  Tue May 30 21:11:44 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 30 May 2017 17:11:44 -0400
Subject: JDK 10 RFR of JDK-8181126: Refactor shell test
 java/nio/Buffer/LimitDirectMemory.sh to java
In-Reply-To: 
References: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
 
Message-ID: 

Hi Amy,

LimitDirectMemory.java: 61  - Can you add a usage message to the 
exception identifying the arguments.
  It is good practice to provide a message so when reading a failing 
log, you don't have to go back to the source and stack trace.

LimitDirectMemoryNegativeTest.java:

45:  Add a usage message to the exception like:  "missing size argument"
  it will help someone who later tries to run it from the command line

51 - the test should check that the error message includes the
   offending argument;  append the arg[0] to ERR.

         .shouldContain(ERR*+ arg[0]*)

Looks fine, no need for another review.

Thanks, Roger


On 5/26/2017 8:29 PM, Brent Christian wrote:
> That all looks fine to me, Amy.
>
> (You'll also need a JDK 10 Reviewer).
>
> Thanks,
> -Brent
>
> On 5/25/17 7:42 PM, Amy Lu wrote:
>> java/nio/Buffer/LimitDirectMemory.sh
>>
>> Please review this patch to refactor the shell test to java.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8181126
>> webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/
>>
>> Thanks,
>> Amy


From jonathan.gibbons at oracle.com  Tue May 30 22:02:49 2017
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 30 May 2017 15:02:49 -0700
Subject: RFR: 8181290 Invalid HTML 5 in core-libs docs
Message-ID: <592DEC09.3090105@oracle.com>

Please review a small set of fixes for HTML 5 compliance which slipped 
through the previous rounds of updates.

JBS: https://bugs.openjdk.java.net/browse/JDK-8181290

Webrev:
     http://cr.openjdk.java.net/~jjg/8181290/corba.webrev.00/
     http://cr.openjdk.java.net/~jjg/8181290/jdk.webrev.00/

-- Jon


From mandy.chung at oracle.com  Tue May 30 22:24:22 2017
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 30 May 2017 15:24:22 -0700
Subject: RFR: 8181290 Invalid HTML 5 in core-libs docs
In-Reply-To: <592DEC09.3090105@oracle.com>
References: <592DEC09.3090105@oracle.com>
Message-ID: 


> On May 30, 2017, at 3:02 PM, Jonathan Gibbons  wrote:
> 
> Please review a small set of fixes for HTML 5 compliance which slipped through the previous rounds of updates.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181290
> 
> Webrev:
>    http://cr.openjdk.java.net/~jjg/8181290/corba.webrev.00/
>    http://cr.openjdk.java.net/~jjg/8181290/jdk.webrev.00/


+1

Mandy

From lance.andersen at oracle.com  Tue May 30 22:41:58 2017
From: lance.andersen at oracle.com (Lance Andersen)
Date: Tue, 30 May 2017 18:41:58 -0400
Subject: RFR: 8181290 Invalid HTML 5 in core-libs docs
In-Reply-To: <592DEC09.3090105@oracle.com>
References: <592DEC09.3090105@oracle.com>
Message-ID: <2F0A8485-4F20-47B2-A1C6-6DC93A3B1136@oracle.com>

looks fine Jon


> On May 30, 2017, at 6:02 PM, Jonathan Gibbons  wrote:
> 
> Please review a small set of fixes for HTML 5 compliance which slipped through the previous rounds of updates.
> 
> JBS: https://bugs.openjdk.java.net/browse/JDK-8181290
> 
> Webrev:
>    http://cr.openjdk.java.net/~jjg/8181290/corba.webrev.00/
>    http://cr.openjdk.java.net/~jjg/8181290/jdk.webrev.00/
> 
> -- Jon
> 

 
  
 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com 




From daniel.fuchs at oracle.com  Tue May 30 23:04:05 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 31 May 2017 00:04:05 +0100
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
In-Reply-To: <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com>
References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
 
 <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com>
Message-ID: 

Hi Roger,

On 30/05/17 19:26, Roger Riggs wrote:
> Hi Daniel,
> 
> Fixed, there is no need for the unbind since the registry is not reused 
> and it might
> cause a spurious success.
> 
> (Also corrected the exception error message @ 151 and 153).
> 
> Webrev updated in place.
> http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/jdk10.patch

I assume you meant
http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
which is what I reviewed ;-)

Looks good!

-- danel

> 
> Thanks, Roger
> 
> 
> On 5/30/2017 2:00 PM, Daniel Fuchs wrote:
>> Hi Roger,
>>
>> Looks good! Just one nit with the test:
>>
>>  194             registry.unbind(name);
>>  195             Assert.fail("Registry filter should have rejected 
>> depth: " + depthOverride + 1);
>>
>> Technically, the test will also pass if bind() succeed but
>> unbind() fails - for some unforeseen reason.
>>
>> best regards,
>>
>> -- daniel
>>
>> On 25/05/17 16:31, Roger Riggs wrote:
>>> Please review an update to the RMI Registry built-in serial filter 
>>> implementation limit on the depth
>>> of a instance that can be bound in the registry.  The initial depth 
>>> limit was 5 and it was too limiting
>>> for some existing applications.  It limit is updated to depth = 20 
>>> and should be more than adequate.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
>>>
>>> Issue:
>>> https://bugs.openjdk.java.net/browse/JDK-8180582
>>>
>>> Thanks, Roger
>>
> 


From huaming.li at oracle.com  Tue May 30 23:34:19 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 31 May 2017 07:34:19 +0800
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com>
References: 
 <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
 <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>
 <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com>
 <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com>
Message-ID: 

Ping.

Thank you

-Hamlin


On 2017/5/27 9:14, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for catching it, new webrev: 
> http://cr.openjdk.java.net/~mli/8166142/webrev.02/
>
> Thank you
>
> -Hamlin
>
>
> On 2017/5/27 3:30, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> SubclassTest.java:37: typo" excepiton" -> exception
>>
>>
>> SubclassDataLossTest.java:
>> 103/104:  Adding the class loader close() calls isn't very effective 
>> since if there is an exception they are not
>> closed and the creation in a static initializer is mismatched with 
>> main() code.
>>
>> It would be cleaner to open in main() using try-with-resources and 
>> close them in a finally clause.
>> And pass the loaders to the test function.
>> But for simplicity, perhaps just leave out the new calls to 
>> ldr1/2.close.
>>
>> (There is something odd about the webrev links, the nagivation links 
>> don't work as expected. but that's transient)
>>
>> Thanks, Roger
>>
>>
>>
>> On 5/26/2017 12:26 AM, Hamlin Li wrote:
>>> Hi Roger,
>>>
>>> Thank you for detailed review. Fixed as you suggested, new webrev: 
>>> http://cr.openjdk.java.net/~mli/8166142/webrev.01/
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>>
>>> On 2017/5/26 2:54, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> For imports they should import specific classes, wildcards are not 
>>>> used.
>>>>
>>>> maskSyntheticModifier/Test.java
>>>> consTest/Test.java
>>>> deserializeButton/Test.java
>>>>
>>>>  test/java/io/Serializable/packageAccess/Driver.java: the name 
>>>> "Driver" is not descriptive and should be.
>>>>
>>>> Each Driver.java should have a different and functional/descriptive 
>>>> name.
>>>>
>>>> Better yet, there should be a single program that creates jar files 
>>>> using command line arguments
>>>> that can be invoked depending on the test.
>>>>
>>>> There is a mix of Driver's copying files vs the test program 
>>>> copying; can that be made more uniform.
>>>>
>>>> Test.java files should have descriptive/functional names. (Even if 
>>>> the duplicating the directory)
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 5/24/2017 5:09 AM, Hamlin Li wrote:
>>>>> Would you please review the below patch?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> -Hamlin
>>>>>
>>>>
>>>
>>
>


From huaming.li at oracle.com  Wed May 31 00:13:45 2017
From: huaming.li at oracle.com (Hamlin Li)
Date: Wed, 31 May 2017 08:13:45 +0800
Subject: (doc-only) 9 RFR of JDK-8181082: class-level since tag issues in
 java.base & java.datatransfer module
In-Reply-To: <212618e5-6a12-42ab-bda6-0013d2816a79@oracle.com>
References: 
 <735f89a2-8c5b-a08c-dc6f-5cd14ad1629a@oracle.com>
 <212618e5-6a12-42ab-bda6-0013d2816a79@oracle.com>
Message-ID: 

Hi Alan, Sergey,

Sorry for delayed reply, I have been on vacation for last few days.

I do have a tool (still under development, it's based on javadoc doclet) 
to scan versions (currently from 1.7 to 9) of jdk source, find since tag 
issues, and give suggested since tag versions if feasible. But for older 
versions of jdk source code, for example 1.6 or older versions, the tool 
has trouble with them, so for classes added in older versions, the tool 
can only detect the issues, but can not give the suggested since tag 
versions, the changes in this webrev is generated manually. As for older 
versions, we only need to fix issues once, so I think it's worth to do 
the necessary manual check and fix.

Thank you

-Hamlin


On 2017/5/27 14:17, Alan Bateman wrote:
>
>
> On 27/05/2017 02:14, Hamlin Li wrote:
>> Is someone available to review the change?
>>
> I skimmed through it,  crossing checking several against the  docs for 
> JDK 1.0, JDK 1.1, and JDK 1.2. I didn't spot any mistakes but I agree 
> with Sergey, it would be good to know if this was done by creating the 
> lists from the binaries rather than manual.
>
> -Alan
>
>>
>>
>> On 2017/5/25 17:19, Hamlin Li wrote:
>>> Would you please review below patch?
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8181082
>>>
>>> webrev: http://cr.openjdk.java.net/~mli/8181082/webrev.00/
>>>
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>
>


From igor.ignatyev at oracle.com  Wed May 31 00:40:21 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 30 May 2017 17:40:21 -0700
Subject: RFR(S) : 8180888: move jdk.testlibrary.JarUtils to the top level
 testlibrary
Message-ID: 

http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
> 354 lines changed: 148 ins; 149 del; 57 mod;

Hi all,

could you please review this changeset which moves JarUtils to the top level testlibrary?

webrev: http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180888
testing: :tier[1-3]

Thanks,
-- Igor

From weijun.wang at oracle.com  Wed May 31 00:54:43 2017
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 31 May 2017 08:54:43 +0800
Subject: RFR(S) : 8180888: move jdk.testlibrary.JarUtils to the top level
 testlibrary
In-Reply-To: 
References: 
Message-ID: 

Hi Igor

Your change looks fine.

BTW, the 
http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/jdk10.patch 
link is empty. Anything wrong with your version of webrev?

Thanks
Max

On 05/31/2017 08:40 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
>> 354 lines changed: 148 ins; 149 del; 57 mod;
> 
> Hi all,
> 
> could you please review this changeset which moves JarUtils to the top level testlibrary?
> 
> webrev: http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180888
> testing: :tier[1-3]
> 
> Thanks,
> -- Igor
> 

From igor.ignatyev at oracle.com  Wed May 31 03:31:04 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Tue, 30 May 2017 20:31:04 -0700
Subject: RFR(S) : 8180888: move jdk.testlibrary.JarUtils to the top level
 testlibrary
In-Reply-To: 
References: 
 
Message-ID: <1C69ECB1-7A1F-4354-8AD7-49EBCF8C7208@oracle.com>

Hi Max,

thank you for the review.

it seems webrev fails to create a patch file when -f option is used.

-- Igor

> On May 30, 2017, at 5:54 PM, Weijun Wang  wrote:
> 
> Hi Igor
> 
> Your change looks fine.
> 
> BTW, the http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/jdk10.patch link is empty. Anything wrong with your version of webrev?
> 
> Thanks
> Max
> 
> On 05/31/2017 08:40 AM, Igor Ignatyev wrote:
>> http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
>>> 354 lines changed: 148 ins; 149 del; 57 mod;
>> Hi all,
>> could you please review this changeset which moves JarUtils to the top level testlibrary?
>> webrev: http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
>> jbs: https://bugs.openjdk.java.net/browse/JDK-8180888
>> testing: :tier[1-3]
>> Thanks,
>> -- Igor


From amy.lu at oracle.com  Wed May 31 03:57:27 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 May 2017 11:57:27 +0800
Subject: JDK 10 RFR of JDK-8181301: Refactor shell test
 AsynchronousChannelGroup/run_any_task.sh to java
Message-ID: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com>

java/nio/channels/AsynchronousChannelGroup/run_any_task.sh

Please review this patch to refactor the shell test to java.

bug: https://bugs.openjdk.java.net/browse/JDK-8181301
webrev: http://cr.openjdk.java.net/~amlu/8181301/webrev.00/

Thanks,
Amy

From vyom.tewari at oracle.com  Wed May 31 04:13:23 2017
From: vyom.tewari at oracle.com (Vyom Tewari)
Date: Wed, 31 May 2017 09:43:23 +0530
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
In-Reply-To: 
References: 
Message-ID: <489a79d1-d484-e5ae-e33d-7b32ec307a64@oracle.com>

Hi Thomas,

Change looks good to me, but i am not official reviewer.

Thanks,

Vyom


On Tuesday 30 May 2017 03:16 PM, Thomas St?fe wrote:
> Hi all,
>
> may I have please a review for this tiny change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.00/webrev/
>
> This reverts 8177809 for AIX because it leads to build errors on older AIX
> systems. We want to retain the ability to build on older AIX releases.
>
> Thanks, Thomas


From thomas.stuefe at gmail.com  Wed May 31 05:46:10 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 31 May 2017 07:46:10 +0200
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
In-Reply-To: <489a79d1-d484-e5ae-e33d-7b32ec307a64@oracle.com>
References: 
 <489a79d1-d484-e5ae-e33d-7b32ec307a64@oracle.com>
Message-ID: 

Thank you Vyom!

On Wed, May 31, 2017 at 6:13 AM, Vyom Tewari  wrote:

> Hi Thomas,
>
> Change looks good to me, but i am not official reviewer.
>
> Thanks,
>
> Vyom
>
>
>
> On Tuesday 30 May 2017 03:16 PM, Thomas St?fe wrote:
>
>> Hi all,
>>
>> may I have please a review for this tiny change:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
>> webrev:
>> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-
>> breaks-AIX-builds/webrev.00/webrev/
>>
>> This reverts 8177809 for AIX because it leads to build errors on older AIX
>> systems. We want to retain the ability to build on older AIX releases.
>>
>> Thanks, Thomas
>>
>
>

From Alan.Bateman at oracle.com  Wed May 31 07:23:10 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 08:23:10 +0100
Subject: RFR(S) : 8180888: move jdk.testlibrary.JarUtils to the top level
 testlibrary
In-Reply-To: 
References: 
Message-ID: <8e29ef7c-91f0-0c9c-6ea6-113cc9aba0e9@oracle.com>

On 31/05/2017 01:40, Igor Ignatyev wrote:

> http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
>> 354 lines changed: 148 ins; 149 del; 57 mod;
> Hi all,
>
> could you please review this changeset which moves JarUtils to the top level testlibrary?
>
> webrev: http://cr.openjdk.java.net/~iignatyev//8180888/webrev.00/index.html
> jbs: https://bugs.openjdk.java.net/browse/JDK-8180888
> testing: :tier[1-3]
>
>
This is "old" JarUtils that is mostly used by the security libs tests. 
We have a "new" JarUtils that we have been using in newer tests - are 
you planning to move that too?

-Alan

From Alan.Bateman at oracle.com  Wed May 31 07:27:20 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 08:27:20 +0100
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: 
References: 
Message-ID: 

On 27/05/2017 07:30, Igor Ignatyev wrote:

> http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html
>> 308 lines changed: 110 ins; 40 del; 158 mod
>
One general comment about all these moves is that I see that many tests 
are being changed to no longer explicitly compile the test 
infrastructure, instead I think it means the tests will rely on implicit 
complication of the infrastructure classes - is that intended? We've had 
a lot a issues in the past with agent VMs + concurrency with implicit 
complication. Have you seen any issues with these changes?

-Alan

From Alan.Bateman at oracle.com  Wed May 31 08:01:09 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 09:01:09 +0100
Subject: JDK 10 RFR of JDK-8181301: Refactor shell test
 AsynchronousChannelGroup/run_any_task.sh to java
In-Reply-To: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com>
References: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com>
Message-ID: <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com>

On 31/05/2017 04:57, Amy Lu wrote:

> java/nio/channels/AsynchronousChannelGroup/run_any_task.sh
>
> Please review this patch to refactor the shell test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8181301
> webrev: http://cr.openjdk.java.net/~amlu/8181301/webrev.00/
This looks okay to me although I think I would put the test description 
before the imports in AsExecutor so you don't have to skip over those to 
see how the test is run. A minor nit is that the JAR file can be 
"privileged.jar" rather than "Privileged.jar".

-Alan

From felix.yang at oracle.com  Wed May 31 08:05:17 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Wed, 31 May 2017 16:05:17 +0800
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: 
References: 
 
Message-ID: <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com>

Hi Alan

     even with explicit compilation, I also observed failures. I'm 
curious what is the best practice here. IMO, there could be a potential 
jtreg bug.

See:

https://bugs.openjdk.java.net/browse/JDK-8181299

https://bugs.openjdk.java.net/browse/JDK-8181300

Thanks,
Felix
On 2017/5/31 15:27, Alan Bateman wrote:
> On 27/05/2017 07:30, Igor Ignatyev wrote:
>
>> http://cr.openjdk.java.net/~iignatyev//8180805/webrev.00/index.html
>>> 308 lines changed: 110 ins; 40 del; 158 mod
>>
> One general comment about all these moves is that I see that many 
> tests are being changed to no longer explicitly compile the test 
> infrastructure, instead I think it means the tests will rely on 
> implicit complication of the infrastructure classes - is that 
> intended? We've had a lot a issues in the past with agent VMs + 
> concurrency with implicit complication. Have you seen any issues with 
> these changes?
>
> -Alan


From Alan.Bateman at oracle.com  Wed May 31 08:07:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 09:07:30 +0100
Subject: JDK 10 RFR of JDK-8181126: Refactor shell test
 java/nio/Buffer/LimitDirectMemory.sh to java
In-Reply-To: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
References: <2c1c726a-bbc4-21ae-82dc-13433eb351c9@oracle.com>
Message-ID: 

On 26/05/2017 03:42, Amy Lu wrote:

> java/nio/Buffer/LimitDirectMemory.sh
>
> Please review this patch to refactor the shell test to java.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8181126
> webrev: http://cr.openjdk.java.net/~amlu/8181126/webrev.00/
This looks okay to me.

-Alan

From amy.lu at oracle.com  Wed May 31 08:10:45 2017
From: amy.lu at oracle.com (Amy Lu)
Date: Wed, 31 May 2017 16:10:45 +0800
Subject: JDK 10 RFR of JDK-8181301: Refactor shell test
 AsynchronousChannelGroup/run_any_task.sh to java
In-Reply-To: <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com>
References: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com>
 <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com>
Message-ID: 

On 5/31/17 4:01 PM, Alan Bateman wrote:
> On 31/05/2017 04:57, Amy Lu wrote:
>
>> java/nio/channels/AsynchronousChannelGroup/run_any_task.sh
>>
>> Please review this patch to refactor the shell test to java.
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8181301
>> webrev: http://cr.openjdk.java.net/~amlu/8181301/webrev.00/
> This looks okay to me although I think I would put the test 
> description before the imports in AsExecutor so you don't have to skip 
> over those to see how the test is run. A minor nit is that the JAR 
> file can be "privileged.jar" rather than "Privileged.jar".
>
> -Alan
Thank you Alan!

Webrev updated according to the suggestions:
http://cr.openjdk.java.net/~amlu/8181301/webrev.01

Thanks,
Amy


From Alan.Bateman at oracle.com  Wed May 31 08:38:30 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 09:38:30 +0100
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com>
References: 
 
 <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com>
Message-ID: <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com>

On 31/05/2017 09:05, Felix Yang wrote:

> Hi Alan
>
>     even with explicit compilation, I also observed failures. I'm 
> curious what is the best practice here. IMO, there could be a 
> potential jtreg bug.
One of the tests listed in JDK-8181299 is 
java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the test 
description has:

@build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test

but the test fails intermittently with:

java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
at jdk.test.lib.process.OutputAnalyzer.(OutputAnalyzer.java:47)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
at jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
at TestDriver.main(TestDriver.java:61)

I assume changing the @build to jdk.test.lib.process.* will fix this, 
assuming all the classes needed for ProcessTools are in this package.

As to why it's intermittent then I think it's a side effect of test 
library classes being compiled by one test and then re-used by a test 
that runs sometime later in the same VM. Combine that with implicit 
compilation, varied @build usages, and concurrently should explain why 
it's intermittent. I see you've cc'ed Jon Gibbons and he is the best 
person to comment on this. Now seems a good time to get to the bottom of 
these issues, esp. with Igor changing lots of tests to drop the explicit 
compilation of test library classes.

-Alan

From Alan.Bateman at oracle.com  Wed May 31 08:39:17 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 09:39:17 +0100
Subject: JDK 10 RFR of JDK-8181301: Refactor shell test
 AsynchronousChannelGroup/run_any_task.sh to java
In-Reply-To: 
References: <1890eba3-8030-3ca6-ef5a-3e381c977eac@oracle.com>
 <99f549ea-c64c-6994-48e2-e17c078274a8@oracle.com>
 
Message-ID: 

On 31/05/2017 09:10, Amy Lu wrote:

> Thank you Alan!
>
> Webrev updated according to the suggestions:
> http://cr.openjdk.java.net/~amlu/8181301/webrev.01
>
Looks good.

From volker.simonis at gmail.com  Wed May 31 08:49:27 2017
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 31 May 2017 10:49:27 +0200
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
In-Reply-To: 
References: 
Message-ID: 

Hi Thomas,

as far as I can see, AIX supports both, the st_[a,c,m]time members in
the stat64 structure for seconds and the corresponding
st_[a,c,m]time_n members for nanosecond resolution since at least 5.3.
Can you please use both - there's no reason to discriminate AIX here
:)

Also, can you please change the code such that we have:

#ifdef MACOSX
...
#else
#ifdef AIX
...
#else
...
#endif
#endif

I don't really like using "ifndef XXX" for everything else except XXX.

Thnank you and best regards,
Volker


On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe  wrote:
> Hi all,
>
> may I have please a review for this tiny change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.00/webrev/
>
> This reverts 8177809 for AIX because it leads to build errors on older AIX
> systems. We want to retain the ability to build on older AIX releases.
>
> Thanks, Thomas

From felix.yang at oracle.com  Wed May 31 09:42:04 2017
From: felix.yang at oracle.com (Felix Yang)
Date: Wed, 31 May 2017 17:42:04 +0800
Subject: RFR 8181299/10, Several jdk tests fail with
 java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
Message-ID: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com>

Hi there,

     please review the patch to various jdk tests to explicitly 
compiling test libraries and the lib's dependencies. Though it could be 
a jtreg issue (I think so), it is necessary to get the tests running 
firstly.

Bug:

     https://bugs.openjdk.java.net/browse/JDK-8181299

Webrev:

     http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/

Thanks,

Felix


From daniel.fuchs at oracle.com  Wed May 31 10:15:40 2017
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Wed, 31 May 2017 03:15:40 -0700 (PDT)
Subject: RFR 8181299/10, Several jdk tests fail with
 java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
In-Reply-To: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com>
References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com>
Message-ID: <8697e5ea-aa1d-e1ef-9074-fa5c37ff237c@oracle.com>

Hi Felix,

Looks good to me. Did you try to run each test in isolation
(removing JT* between 2 runs) to check that they compile
all they need?

If you haven't committed yet then I guess a little
   for f in $(hg st . -nma) ; do \
       rm -r JT* ; \
       jtreg -verbose:summary -jdk .... $f ; \
   done
might do the trick ;-)

best regards,

-- daniel

On 31/05/2017 10:42, Felix Yang wrote:
> Hi there,
> 
>      please review the patch to various jdk tests to explicitly 
> compiling test libraries and the lib's dependencies. Though it could be 
> a jtreg issue (I think so), it is necessary to get the tests running 
> firstly.
> 
> Bug:
> 
>      https://bugs.openjdk.java.net/browse/JDK-8181299
> 
> Webrev:
> 
>      http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/
> 
> Thanks,
> 
> Felix
> 


From chris.hegarty at oracle.com  Wed May 31 10:20:18 2017
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Wed, 31 May 2017 11:20:18 +0100
Subject: RFR 8181299/10,
 Several jdk tests fail with java.lang.NoClassDefFoundError:
 jdk/test/lib/process/StreamPumper
In-Reply-To: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com>
References: <6aed9ea5-3bf9-5c51-8c87-bab37fc835f1@oracle.com>
Message-ID: 


> On 31 May 2017, at 10:42, Felix Yang  wrote:
> 
> Hi there,
> 
>    please review the patch to various jdk tests to explicitly compiling test libraries and the lib's dependencies. Though it could be a jtreg issue (I think so), it is necessary to get the tests running firstly.
> 
> Bug:
> 
>    https://bugs.openjdk.java.net/browse/JDK-8181299
> 
> Webrev:
> 
>    http://cr.openjdk.java.net/~xiaofeya/8181299/webrev.00/

This may be ok to get the tests running again, but explicit build targets
would be better. The contents, and module dependencies, from classes
in the test library are subject to change, so building all classes may 
require more modules than in the @modules tags in the test.

I agree with Daniel, each test should be run separately in a clean
environment, to verify that it can build the necessary dependencies.
This may be a straight forward way to identify explicit build dependencies
and avoid the wildcards.

-Chris.


From dalibor.topic at oracle.com  Wed May 31 10:22:51 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 May 2017 12:22:51 +0200
Subject: Proposal:
 javax.naming.spi.NamingManager.clearInitialContextFactoryBuilder()
In-Reply-To: 
References: 
 
 
 <7ecfcdef-af59-7760-d3b8-99de47b1e2bf@oracle.com>
 
Message-ID: <837dd4df-4ac9-1199-6474-00630fb3f81d@oracle.com>



On 18.05.2017 00:20, Andrew Guibert wrote:

> Hi Alan, I've checked within IBM and it appears we do not have any OpenJDK
> committers.  Still trying to chase down if we have anyone in IBM who can
> drive this commit.  Do you know of anyone?
>

Hi Andrew,

you can find a list of JDK 10 Committers at 
http://openjdk.java.net/census#jdk10 . You can cross reference it with 
the list at http://db.openjdk.java.net/people to lookup their 
organizations, if any.

cheers,
dalibor topic

-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

From roman.grigoriadi at oracle.com  Wed May 31 12:06:39 2017
From: roman.grigoriadi at oracle.com (Roman Grigoriadi)
Date: Wed, 31 May 2017 14:06:39 +0200
Subject: RFR: 8176508 Update JAX-WS RI integration to latest version
In-Reply-To: 
References: <77c72add-d5fa-fd3d-9ed9-c344bdf18bbc@oracle.com>
 
 <91DA679C-871F-4967-96CE-903FC0D55B8B@oracle.com>
 
Message-ID: <31F269AE-A4AE-47A0-B86A-A926561D75C3@oracle.com>

Hi,

New webrev can be found here:
http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/02/ 

Previous review comments have been addressed.

New changes since last webrev upload:

Few ?opens xxx to java.xml.bind? in the module-info of java.xml.ws with descriptions of files in java.xml.ws, which calls JAXBContext#newInstance. 

JAXB-API:
 - JAXBContext.java - deprecated implementation discovery with jaxb.properties resource. 
 - ContextFinder when called with String contextPath now tries to resolve jaxb.properties with Class#getResource if ClassLoader#getResource fails due to insufficient openness of jaxb.properties resource package.
 - better JAXBException message when package of jaxb classes is not open to java.xml.bind

JAXB-RI:
 - fixed escaping newlines when using bundled jaxws transport.

SAAJ-RI
 - fixed TCK test failures

JAXWS-RI
 - fixed parsing wsdl in secure mode

We have one JCK runtime test failure, which should be probably fixed in tests, I have created issue for it: https://bugs.openjdk.java.net/browse/JCK-7308397 

Please review.

Thanks,
Roman

> On 8 May 2017, at 22:38, Lance Andersen  wrote:
> 
> Hi Roman,
> 
> I made a pass through the webrev and have the following feedback:
> 
> 
> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/StaxLazySourceBridge.java and several files  - which follow in the webrev, have formatting issues with the newly added @override and existing @overrides and should probably be cleaned up
> 
> src/java.xml.ws/share/classes/com/sun/xml/internal/messaging/saaj/soap/impl/BodyElementImpl.java - can 960 -962 be deleted
> 
> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/util/version.properties - The copyright was reverted.  Also what happens to the svn info in this file with the move to github?
> 
> src/java.xml.ws/share/classes/javax/xml/soap/package-info.java -  I would use ™ for TM
> 
> src/java.xml.ws/share/classes/javax/xml/ws/Service.java - See comments starting at 230 seem off
> 
> src/java.xml.ws/share/classes/javax/xml/ws/WebServiceRef.java -  I would make the comments starting at 139 be consistent with the other comments 
> 
> src/jdk.xml.bind/share/classes/com/sun/tools/internal/jxc/*.properties - the copyright date was reverted
> 
> src/jdk.xml.bind/share/classes/module-info.java  should already be updated in the workspace
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/processor/ProcessorException.java - The copyright should be updated to 2017
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/util/WSDLParseException.java -  the copyright was reverted
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ParseException.java - the copyright was reverted 
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/wsdl/framework/ValidationException.java - the copyright was reverted
> 
> src/jdk.xml.ws/share/classes/module-info.java - this was already updated in the workspace
> 
> src/java.xml.bind/share/classes/javax/xml/bind/ModuleUtil.java - the copyright should only be 2017
> 
> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/policy/sourcemodel/attach/ContextClassloaderLocalMessages.java. - the copyright should only be 2017
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/NewmessagesMessages.java - the copyright should only be 2017
> 
> src/jdk.xml.ws/share/classes/com/sun/tools/internal/ws/resources/newmessages.properties - this is in the workspace already
> 
> 
> 
>> On May 3, 2017, at 12:49 PM, Roman Grigoriadi > wrote:
>> 
>> Hi,
>> 
>> you can find new web rev here:
>> http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/01/  >
>> 
>> Previous review comments are addressed. 
>> 
>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project.
>> 
>> 
>> Version as in our Maven project is 2.3.0-SNAPSHOT for JAX-WS at the time we are syncing. Subcomponents (SAAJ, JAXB mainly) are promoted, for example 
>> in jdk/jaxws/src/jdk.xml.bind/share/classes/com/sun/tools/internal/xjc/MessageBundle.properties
>> There is:
>> # for JDK integration - include version in source zip
>> jaxb.jdk.version=2.3.0-b170412.1723
>> 
>> We can add another version.properties file with versions of all JAX-* components. We may also change version from 2.3.0-SNAPSHOT to something unique like 2.3.0-bXXXXXX.XXXX before sync and put it to maven promoted repo.
>> 
>> Roman
>> 
>> 
>>> On 12 Mar 2017, at 16:14, Alan Bateman > wrote:
>>> 
>>> 
>>> 
>>> On 12/03/2017 14:39, Roman Grigoriadi wrote:
>>>> Hi,
>>>> 
>>>> Please review standalone JAXB/JAXWS changes, synced to jdk/jaxws repo.
>>>> 
>>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8176508 
>>>> Webrev: http://cr.openjdk.java.net/~aefimov/jaxws-integrations/8176508/00/ 
>>>> 
>>> I skimmed the changes and have a few comments (I'm sure Lance or someone else will do a more detailed review).
>>> 
>>> In JAXBContext then "must be open to the java.xml.bind module" should be "must be open to at least the java.xml.bind module" so as to cover the case that the package is opened unconditionally or to java.xml.bind and other modules. In addition, include "at least" makes it consistent with other wording that we have agreed for other areas.
>>> 
>>> In MailcapCommandMap then the following doesn't seem right for the class description:
>>> 
>>> 59  * (Where java.home is the value of the "java.home" System property
>>> 60  * and conf is the directory named "conf" if it exists,
>>> 61  * otherwise the directory named "lib"; the "conf" directory was
>>> 62  * introduced in JDK 1.9.)
>>> 
>>> It might be simpler to just have javadoc specify that it attepts to locate the `mailcap` file in the Java run-time image and then add an @implNote with the details as to where it looks for specific runtime releases.
>>> 
>>> I see the new source file ModuleUtil is using java.util.StringTokenizer. It's use in new code has been discouraged for many years and maybe this could start out using String.split rather than the legacy class.
>>> 
>>> The change to version.properties reminds me to ask if there is anything in the jaxws repo to indicate the version of the JAX-* components? It's often difficult to determine what bits are in the JDK vs. the upstream project.
>>> 
>>> -Alan
>> 
> 
>  
>   
>  Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering 
> 1 Network Drive 
> Burlington, MA 01803
> Lance.Andersen at oracle.com 

From Roger.Riggs at Oracle.com  Wed May 31 14:02:24 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 10:02:24 -0400
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
In-Reply-To: 
References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
 
 <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com>
 
Message-ID: <39f12457-65a8-36c9-cb32-babb74fa9c08@Oracle.com>

Thanks Daniel for the review and corrected link.

On 5/30/2017 7:04 PM, Daniel Fuchs wrote:
> Hi Roger,
>
> On 30/05/17 19:26, Roger Riggs wrote:
>> Hi Daniel,
>>
>> Fixed, there is no need for the unbind since the registry is not 
>> reused and it might
>> cause a spurious success.
>>
>> (Also corrected the exception error message @ 151 and 153).
>>
>> Webrev updated in place.
>> ...
>
> I assume you meant
> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
> which is what I reviewed ;-)
>
> Looks good!
>
> -- danel
>
>>
>> Thanks, Roger
>>
>>
>> On 5/30/2017 2:00 PM, Daniel Fuchs wrote:
>>> Hi Roger,
>>>
>>> Looks good! Just one nit with the test:
>>>
>>>  194             registry.unbind(name);
>>>  195             Assert.fail("Registry filter should have rejected 
>>> depth: " + depthOverride + 1);
>>>
>>> Technically, the test will also pass if bind() succeed but
>>> unbind() fails - for some unforeseen reason.
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>> On 25/05/17 16:31, Roger Riggs wrote:
>>>> Please review an update to the RMI Registry built-in serial filter 
>>>> implementation limit on the depth
>>>> of a instance that can be bound in the registry.  The initial depth 
>>>> limit was 5 and it was too limiting
>>>> for some existing applications.  It limit is updated to depth = 20 
>>>> and should be more than adequate.
>>>>
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
>>>>
>>>> Issue:
>>>> https://bugs.openjdk.java.net/browse/JDK-8180582
>>>>
>>>> Thanks, Roger
>>>
>>
>


From igor.ignatyev at oracle.com  Wed May 31 14:18:54 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 31 May 2017 07:18:54 -0700
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com>
References: 
 
 <3b801b3a-1778-0085-7e0b-a3c92713d053@oracle.com>
 <70aec07f-7357-4986-fb0d-4bc6a7dbbf86@oracle.com>
Message-ID: <758AC3CF-CB25-49C2-81D0-9C8D2AD9447A@oracle.com>

Hi Alan,

we believe it's a jtreg bug. we have seen similar intermittent failures in hotspot testing[1], Ioi(cc'ed) did a really great job analyzing the root cause[2], in to words jtreg puts a part of testlibrary to one path and another part to a different path. [3] is his suggested fix for jtreg.

-- Igor 

[1] https://bugs.openjdk.java.net/browse/CODETOOLS-7901986
[2] https://bugs.openjdk.java.net/secure/attachment/70197/jtreg_random_class_not_found.txt
[3] http://cr.openjdk.java.net/~iklam/jtreg/7901986_split_library/
  
> On May 31, 2017, at 1:38 AM, Alan Bateman  wrote:
> 
> On 31/05/2017 09:05, Felix Yang wrote:
> 
>> Hi Alan
>> 
>>    even with explicit compilation, I also observed failures. I'm curious what is the best practice here. IMO, there could be a potential jtreg bug.
> One of the tests listed in JDK-8181299 is java/net/URLConnection/6212146/TestDriver.java. In jdk10/jdk10 the test description has:
> 
> @build jdk.test.lib.JDKToolFinder jdk.test.lib.process.ProcessTools Test
> 
> but the test fails intermittently with:
> 
> java.lang.NoClassDefFoundError: jdk/test/lib/process/StreamPumper
> at jdk.test.lib.process.ProcessTools.getOutput(ProcessTools.java:85)
> at jdk.test.lib.process.OutputAnalyzer.(OutputAnalyzer.java:47)
> at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:397)
> at jdk.test.lib.process.ProcessTools.executeProcess(ProcessTools.java:425)
> at jdk.test.lib.process.ProcessTools.executeCommand(ProcessTools.java:475)
> at TestDriver.main(TestDriver.java:61)
> 
> I assume changing the @build to jdk.test.lib.process.* will fix this, assuming all the classes needed for ProcessTools are in this package.
> 
> As to why it's intermittent then I think it's a side effect of test library classes being compiled by one test and then re-used by a test that runs sometime later in the same VM. Combine that with implicit compilation, varied @build usages, and concurrently should explain why it's intermittent. I see you've cc'ed Jon Gibbons and he is the best person to comment on this. Now seems a good time to get to the bottom of these issues, esp. with Igor changing lots of tests to drop the explicit compilation of test library classes.
> 
> -Alan


From igor.ignatyev at oracle.com  Wed May 31 14:23:19 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 31 May 2017 07:23:19 -0700
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: 
References: 
 
Message-ID: <386A2BA8-2114-4584-AC35-D06D0736B2B1@oracle.com>

Hi Brian,

thank you for your review.

regarding '@Deprecated(since=?9?, forRemoval=true)', since the only users of testlibrary classes are our own tests and we do not need to inform anyone or wait for a new release to remove them, I don't think it makes much sense to have such attributes.

PS sorry, by some reason the email unnoticeably stuck in my outbox, and I have already pushed the patch. if you have any further comments, I will address them by a separate fix.

Thanks,
-- Igor

> On May 30, 2017, at 9:36 AM, Brian Burkhalter  wrote:
> 
> Hi Igor,
> 
> On May 26, 2017, at 11:30 PM, Igor Ignatyev > wrote:
> 
>> this changeset introduces jdk.test.lib.RandomFactory in the top level testlibrary and updates all but java/time/ tests to use it instead of jdk.testlibrary.RandomFactory from the jdk testlibrary.
> 
> Code changes look OK provided all tests still run properly. I have not been following the test package refactoring however so no comment on that.
> 
>> due to CODETOOLS-7901987[1], java/time/ tests can't use the top level testlibrary, so jdk.testlibrary.RandomFactory hasn't been removed, however it has been marked as deprecated and will be removed by JDK-8181118[2] as soon as there is promoted jtreg w/ CODETOOLS-7901987 fixed.
> 
> Should this be using ?@Deprecated(since=?9?, forRemoval=true)? or something like that?
> 
> Thanks,
> 
> Brian


From Roger.Riggs at Oracle.com  Wed May 31 14:34:46 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 10:34:46 -0400
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
Message-ID: 

Please review javadoc markup change to update to html5 acceptable to 
doclint.
The table formatting is updated to html5 markup.

The Docs build is updated to require doclint html5.

Webrev:
   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/

Issue:
https://bugs.openjdk.java.net/browse/JDK-8181156 html5 doclint issues in 
java.base javadoc

Thanks, Roger

From Alan.Bateman at oracle.com  Wed May 31 14:43:20 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 15:43:20 +0100
Subject: RFR 9: (doclint) 8181156 html5 doclint issues in java.base javadoc
In-Reply-To: 
References: <2a7c09be-7537-431b-9d8f-03c883aca15a@Oracle.com>
 
Message-ID: <00be0bd8-baed-2859-a32a-fd6376f8db62@oracle.com>

On 31/05/2017 15:34, Roger Riggs wrote:

> Please review javadoc markup change to update to html5 acceptable to 
> doclint.
> The table formatting is updated to html5 markup.
>
> The Docs build is updated to require doclint html5.
>
> Webrev:
>   jdk: http://cr.openjdk.java.net/~rriggs/webrev-base-html5-8181156/
>   build: http://cr.openjdk.java.net/~rriggs/webrev-top-html5-8181156/
Some of the lines are way too long now and will means lots of horizontal 
scrolling when looking at diffs in the future. Can these be cleaned up 
before these changes are pushed?

-Alan

From brian.burkhalter at oracle.com  Wed May 31 14:50:21 2017
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 31 May 2017 07:50:21 -0700
Subject: RFR(S) : 8180805 : move RandomFactory to the top level testlibrary
In-Reply-To: <386A2BA8-2114-4584-AC35-D06D0736B2B1@oracle.com>
References: 
 
 <386A2BA8-2114-4584-AC35-D06D0736B2B1@oracle.com>
Message-ID: 

Hi Igor,

On May 31, 2017, at 7:23 AM, Igor Ignatyev  wrote:

> thank you for your review.

You?re welcome.

> regarding '@Deprecated(since=?9?, forRemoval=true)', since the only users of testlibrary classes are our own tests and we do not need to inform anyone or wait for a new release to remove them, I don't think it makes much sense to have such attributes.

I think it?s fine: I was just pointing out a possibility.

> PS sorry, by some reason the email unnoticeably stuck in my outbox, and I have already pushed the patch. if you have any further comments, I will address them by a separate fix.

No, it?s good.

Thanks,

Brian

From matthias.baesken at sap.com  Wed May 31 15:11:25 2017
From: matthias.baesken at sap.com (Baesken, Matthias)
Date: Wed, 31 May 2017 15:11:25 +0000
Subject: jdk9 vs. jdk8 :  TimeZone  getDisplayName(Locale.GERMAN)   for TZ=MET
Message-ID: 


I wonder why the display names for timezone MET changed ( I observed this on Linux and Solaris) when I compare
jdk8 to jdk9 .

The test is very small, it just outputs for Locale.GERMAN  the display name.
With jdk8 we get a translated german timezone name, but not with jdk9  (this is a bit strange because  the jdk9 rsource file
src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java
still contains the translation).

Is this intentional  or a bug ?

Best regards, Matthias



TimeZoneTest.java
------------------------
import java.util.TimeZone;
import java.util.Locale;

public class TimeZoneTest {

    public static void main(String[] args)
    {
        TimeZone tz = TimeZone.getDefault();
        // now test for german
        String dng = tz.getDisplayName(Locale.GERMAN);
        System.out.println("timezone display name for Locale.GERMAN " + dng);
    }
}
------------------------

for environment variable TZ=MET  (export TZ=MET) we get :
../output-jdk8/images/j2sdk-image/bin/java  TimeZoneTest
timezone display name for Locale.GERMAN Zentraleurop?ische Zeit

../output-jdk9/images/jdk/bin/java  TimeZoneTest
timezone display name for Locale.GERMAN Middle Europe Time

From dalibor.topic at oracle.com  Wed May 31 15:18:36 2017
From: dalibor.topic at oracle.com (dalibor topic)
Date: Wed, 31 May 2017 17:18:36 +0200
Subject: jdk9 vs. jdk8 : TimeZone getDisplayName(Locale.GERMAN) for TZ=MET
In-Reply-To: 
References: 
Message-ID: 

On 31.05.2017 17:11, Baesken, Matthias wrote:
>
> I wonder why the display names for timezone MET changed ( I observed this on Linux and Solaris) when I compare
> jdk8 to jdk9 .
>
> The test is very small, it just outputs for Locale.GERMAN  the display name.
> With jdk8 we get a translated german timezone name, but not with jdk9  (this is a bit strange because  the jdk9 rsource file
> src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java
> still contains the translation).
>
> Is this intentional  or a bug ?

Hi Matthias,

it might be a side effect of http://openjdk.java.net/jeps/252 .

cheers,
dalibor topic

> Best regards, Matthias
>
>
>
> TimeZoneTest.java
> ------------------------
> import java.util.TimeZone;
> import java.util.Locale;
>
> public class TimeZoneTest {
>
>     public static void main(String[] args)
>     {
>         TimeZone tz = TimeZone.getDefault();
>         // now test for german
>         String dng = tz.getDisplayName(Locale.GERMAN);
>         System.out.println("timezone display name for Locale.GERMAN " + dng);
>     }
> }
> ------------------------
>
> for environment variable TZ=MET  (export TZ=MET) we get :
> ../output-jdk8/images/j2sdk-image/bin/java  TimeZoneTest
> timezone display name for Locale.GERMAN Zentraleurop?ische Zeit
>
> ../output-jdk9/images/jdk/bin/java  TimeZoneTest
> timezone display name for Locale.GERMAN Middle Europe Time
>

-- 
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

From igor.ignatyev at oracle.com  Wed May 31 15:19:01 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 31 May 2017 08:19:01 -0700 (PDT)
Subject: RFR(XXS) : 8181307: tests added/changed by 8166139 should be updated
 to use the latest testlibrary
Message-ID: <0224D58A-DC7E-4A30-BDCD-D3A0D82A660D@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8181307/webrev.00/index.html
> 2 lines changed: 1 ins; 0 del; 1 mod;

Hi all,

misfortunately, 8180887[1] was created and tested before 8166139[2] has been integrated. then the fixes met in jdk10/jdk10, java/net/URLClassLoader/closetest/CloseTest.java started to fail due to 'Error. can't find jdk.testlibrary.FileUtils in test directory or libraries'. the test should be updated to use /test/lib library and not to build removed jdk.testlibrary.FileUtils. 

jbs: https://bugs.openjdk.java.net/browse/JDK-8181307
webrev: http://cr.openjdk.java.net/~iignatyev//8181307/webrev.00/index.html
testing: java/net tests


[1] https://bugs.openjdk.java.net/browse/JDK-8180887
[2] https://bugs.openjdk.java.net/browse/JDK-8166139

Thanks.
-- Igor

From Roger.Riggs at Oracle.com  Wed May 31 15:26:32 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 11:26:32 -0400
Subject: RFR(XXS) : 8181307: tests added/changed by 8166139 should be
 updated to use the latest testlibrary
In-Reply-To: <0224D58A-DC7E-4A30-BDCD-D3A0D82A660D@oracle.com>
References: <0224D58A-DC7E-4A30-BDCD-D3A0D82A660D@oracle.com>
Message-ID: 

+1, looks good.

Roger

On 5/31/2017 11:19 AM, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8181307/webrev.00/index.html
>> 2 lines changed: 1 ins; 0 del; 1 mod;
> Hi all,
>
> misfortunately, 8180887[1] was created and tested before 8166139[2] has been integrated. then the fixes met in jdk10/jdk10, java/net/URLClassLoader/closetest/CloseTest.java started to fail due to 'Error. can't find jdk.testlibrary.FileUtils in test directory or libraries'. the test should be updated to use /test/lib library and not to build removed jdk.testlibrary.FileUtils.
>
> jbs: https://bugs.openjdk.java.net/browse/JDK-8181307
> webrev: http://cr.openjdk.java.net/~iignatyev//8181307/webrev.00/index.html
> testing: java/net tests
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8180887
> [2] https://bugs.openjdk.java.net/browse/JDK-8166139
>
> Thanks.
> -- Igor


From thomas.stuefe at gmail.com  Wed May 31 15:29:40 2017
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 31 May 2017 17:29:40 +0200
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
In-Reply-To: 
References: 
 
Message-ID: 

Hi Volker,

Good suggestions! I completely overlooked the ..._n members in stat64
struct. It seems it is even documented:
https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm

new webrev:
http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/

..Thomas

On Wed, May 31, 2017 at 10:49 AM, Volker Simonis 
wrote:

> Hi Thomas,
>
> as far as I can see, AIX supports both, the st_[a,c,m]time members in
> the stat64 structure for seconds and the corresponding
> st_[a,c,m]time_n members for nanosecond resolution since at least 5.3.
> Can you please use both - there's no reason to discriminate AIX here
> :)
>
> Also, can you please change the code such that we have:
>
> #ifdef MACOSX
> ...
> #else
> #ifdef AIX
> ...
> #else
> ...
> #endif
> #endif
>
> I don't really like using "ifndef XXX" for everything else except XXX.
>
> Thnank you and best regards,
> Volker
>
>
> On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe 
> wrote:
> > Hi all,
> >
> > may I have please a review for this tiny change:
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
> > webrev:
> > http://cr.openjdk.java.net/~stuefe/webrevs/8181207-
> 8177809-breaks-AIX-builds/webrev.00/webrev/
> >
> > This reverts 8177809 for AIX because it leads to build errors on older
> AIX
> > systems. We want to retain the ability to build on older AIX releases.
> >
> > Thanks, Thomas
>

From mark.sheppard at oracle.com  Wed May 31 16:43:12 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 31 May 2017 17:43:12 +0100
Subject: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API docs to
 unilinks for guides
Message-ID: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com>

Hi,
    please oblige and review the following changes
http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/

which address the issue raised in
https://bugs.openjdk.java.net/browse/JDK-8176784

this results in changes to  href in the corba javadoc, such that the
relative links to technote/guides html pages have been
replaces with the @extLink annotation. This will result in a
URL query link being created to replace the technote links, when
the javadoc is generated.

regards
Mark

From Roger.Riggs at Oracle.com  Wed May 31 16:47:36 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 12:47:36 -0400
Subject: (10) RFR of JDK-8166142: Refactor java.io.serialization shell
 tests to java
In-Reply-To: <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com>
References: 
 <4c8cde26-21db-76e7-06cc-2afeae601bb4@Oracle.com>
 <658eff8e-77ff-89a0-6fc0-030ff75c6319@oracle.com>
 <6c685ce1-0e2a-1d6e-460c-babe2a2b754a@Oracle.com>
 <04f27f13-36b9-23fe-c6e6-56d521cbc919@oracle.com>
Message-ID: 

Hi Hamlin,

RenamePackageTest.java:
   - 48,61:  rename "sutup" -> "setup"

81-83/93/95:  use  SHARE.resolve(xxx).toString to compute the paths.

ClassPathTest.java:
42: add a space before "{"

56:  Generally, exception messages should not end in "."; they are phrases
so they could be printed with context.
In this specific case it is not important, just a pattern to follow 
consistently.

Thanks, Roger

On 5/26/2017 9:14 PM, Hamlin Li wrote:
> Hi Roger,
>
> Thank you for catching it, new webrev: 
> http://cr.openjdk.java.net/~mli/8166142/webrev.02/
>
> Thank you
>
> -Hamlin
>
>
> On 2017/5/27 3:30, Roger Riggs wrote:
>> Hi Hamlin,
>>
>> SubclassTest.java:37: typo" excepiton" -> exception
>>
>>
>> SubclassDataLossTest.java:
>> 103/104:  Adding the class loader close() calls isn't very effective 
>> since if there is an exception they are not
>> closed and the creation in a static initializer is mismatched with 
>> main() code.
>>
>> It would be cleaner to open in main() using try-with-resources and 
>> close them in a finally clause.
>> And pass the loaders to the test function.
>> But for simplicity, perhaps just leave out the new calls to 
>> ldr1/2.close.
>>
>> (There is something odd about the webrev links, the nagivation links 
>> don't work as expected. but that's transient)
>>
>> Thanks, Roger
>>
>>
>>
>> On 5/26/2017 12:26 AM, Hamlin Li wrote:
>>> Hi Roger,
>>>
>>> Thank you for detailed review. Fixed as you suggested, new webrev: 
>>> http://cr.openjdk.java.net/~mli/8166142/webrev.01/
>>>
>>> Thank you
>>>
>>> -Hamlin
>>>
>>>
>>> On 2017/5/26 2:54, Roger Riggs wrote:
>>>> Hi Hamlin,
>>>>
>>>> For imports they should import specific classes, wildcards are not 
>>>> used.
>>>>
>>>> maskSyntheticModifier/Test.java
>>>> consTest/Test.java
>>>> deserializeButton/Test.java
>>>>
>>>>  test/java/io/Serializable/packageAccess/Driver.java: the name 
>>>> "Driver" is not descriptive and should be.
>>>>
>>>> Each Driver.java should have a different and functional/descriptive 
>>>> name.
>>>>
>>>> Better yet, there should be a single program that creates jar files 
>>>> using command line arguments
>>>> that can be invoked depending on the test.
>>>>
>>>> There is a mix of Driver's copying files vs the test program 
>>>> copying; can that be made more uniform.
>>>>
>>>> Test.java files should have descriptive/functional names. (Even if 
>>>> the duplicating the directory)
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 5/24/2017 5:09 AM, Hamlin Li wrote:
>>>>> Would you please review the below patch?
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8166142
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~mli/8166142/webrev.00/
>>>>>
>>>>>
>>>>> Thank you
>>>>>
>>>>> -Hamlin
>>>>>
>>>>
>>>
>>
>


From Roger.Riggs at Oracle.com  Wed May 31 17:11:34 2017
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Wed, 31 May 2017 13:11:34 -0400
Subject: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API
 docs to unilinks for guides
In-Reply-To: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com>
References: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com>
Message-ID: 

Hi Mark,

org/omg/CORBA/package.html:  for consistency should

{@extLink jidlexception Java IDL exceptions }

be the same as others:

{@extLink jidlexception documentation on Java IDL exceptions}

I'm not sure if the   is really needed.  I'd remove it if not 
necessary.

Otherwise looks fine.

Roger



On 5/31/2017 12:43 PM, Mark Sheppard wrote:
> Hi,
>    please oblige and review the following changes
> http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/
>
> which address the issue raised in
> https://bugs.openjdk.java.net/browse/JDK-8176784
>
> this results in changes to  href in the corba javadoc, such that the
> relative links to technote/guides html pages have been
> replaces with the @extLink annotation. This will result in a
> URL query link being created to replace the technote links, when
> the javadoc is generated.
>
> regards
> Mark


From mark.sheppard at oracle.com  Wed May 31 17:50:26 2017
From: mark.sheppard at oracle.com (Mark Sheppard)
Date: Wed, 31 May 2017 18:50:26 +0100
Subject: RFR: JDK-8176784 - Amend HREF to technote/guides in CORBA API
 docs to unilinks for guides
In-Reply-To: 
References: <0f827c59-8b9a-9351-bd74-35b93a4e51cb@oracle.com>
 
Message-ID: <7c10abe3-03f1-adf0-5d36-20c8604762d8@oracle.com>

thanks Roger ...
  i'll make it consistent and add the   tag in this instance and 
check for others
occurrences, also.

I used the same anchor text for the translation to @extLink

regards
Mark

On 31/05/2017 18:11, Roger Riggs wrote:
> Hi Mark,
>
> org/omg/CORBA/package.html:  for consistency should
>
> {@extLink jidlexception Java IDL exceptions }
>
> be the same as others:
>
> {@extLink jidlexception documentation on Java IDL exceptions}
>
> I'm not sure if the   is really needed.  I'd remove it if not 
> necessary.
>
> Otherwise looks fine.
>
> Roger
>
>
>
> On 5/31/2017 12:43 PM, Mark Sheppard wrote:
>> Hi,
>>    please oblige and review the following changes
>> http://cr.openjdk.java.net/~msheppar/8176784-IV/webrev.02/
>>
>> which address the issue raised in
>> https://bugs.openjdk.java.net/browse/JDK-8176784
>>
>> this results in changes to  href in the corba javadoc, such that the
>> relative links to technote/guides html pages have been
>> replaces with the @extLink annotation. This will result in a
>> URL query link being created to replace the technote links, when
>> the javadoc is generated.
>>
>> regards
>> Mark
>


From igor.ignatyev at oracle.com  Wed May 31 18:04:36 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 31 May 2017 11:04:36 -0700
Subject: RFR(S) : 8180898: remove JavaToolUtils testlibrary class
Message-ID: <827CADA9-6EF9-4CBD-8538-FE5322EA130B@oracle.com>

http://cr.openjdk.java.net/~iignatyev//8180898/webrev.00/index.html
> 209 lines changed: 0 ins; 209 del; 0 mod; 0

Hi all,

8180895[1] has updated the sole user of JavaToolUtils class to use other testlibrary classes, JavaToolUtils itself does not provide any unique methods, so it should be removed.

webrev: http://cr.openjdk.java.net/~iignatyev//8180898/webrev.00/index.html
jbs: https://bugs.openjdk.java.net/browse/JDK-8180898
testing: grep -rl JavaToolUtils ./jdk/test

[1] https://bugs.openjdk.java.net/browse/JDK-8180898

Thanks,
-- Igor


From Alan.Bateman at oracle.com  Wed May 31 20:07:18 2017
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 May 2017 21:07:18 +0100
Subject: RFR(S) : 8180898: remove JavaToolUtils testlibrary class
In-Reply-To: <827CADA9-6EF9-4CBD-8538-FE5322EA130B@oracle.com>
References: <827CADA9-6EF9-4CBD-8538-FE5322EA130B@oracle.com>
Message-ID: <9c27fd64-9ec8-6e1d-b546-27abf43156d4@oracle.com>



On 31/05/2017 19:04, Igor Ignatyev wrote:
> http://cr.openjdk.java.net/~iignatyev//8180898/webrev.00/index.html
>
Looks okay to me.

From christoph.langer at sap.com  Wed May 31 21:41:14 2017
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 31 May 2017 21:41:14 +0000
Subject: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds
In-Reply-To: 
References: 
 
 
Message-ID: <05c5fe05f8cb4c8b831255600a0eb2e9@sap.com>

Hi Thomas,

looks good.

Some suggestions about formatting:

a) you could code write your code like this:

#if defined(_AIX)
?
#elif defined(MACOSX)
?
#else
?
#endif

That way the coding has 3 clear sections and you don?t have to do an #ifdef block in another #ifdef.

b)  Line 234, 235 (AIX block), rather write:
             rv   = (jlong)sb.st_mtime * 1000;
             rv += (jlong)sb.st_mtime_n / 1000000;
Then it looks aligned with the MACOSX and the default section.

Best regards
Christoph



From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Thomas St?fe
Sent: Mittwoch, 31. Mai 2017 17:30
To: Volker Simonis 
Cc: ppc-aix-port-dev at openjdk.java.net; Java Core Libs 
Subject: Re: JDK10: RFR(xxs): 8181207: 8177809 breaks AIX 5.3, 6.1 builds

Hi Volker,

Good suggestions! I completely overlooked the ..._n members in stat64 struct. It seems it is even documented: https://www.ibm.com/support/knowledgecenter/ssw_aix_72/com.ibm.aix.files/stat.h.htm

new webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.01/webrev/

..Thomas

On Wed, May 31, 2017 at 10:49 AM, Volker Simonis > wrote:
Hi Thomas,

as far as I can see, AIX supports both, the st_[a,c,m]time members in
the stat64 structure for seconds and the corresponding
st_[a,c,m]time_n members for nanosecond resolution since at least 5.3.
Can you please use both - there's no reason to discriminate AIX here
:)

Also, can you please change the code such that we have:

#ifdef MACOSX
...
#else
#ifdef AIX
...
#else
...
#endif
#endif

I don't really like using "ifndef XXX" for everything else except XXX.

Thnank you and best regards,
Volker


On Tue, May 30, 2017 at 11:46 AM, Thomas St?fe > wrote:
> Hi all,
>
> may I have please a review for this tiny change:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8181207
> webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8181207-8177809-breaks-AIX-builds/webrev.00/webrev/
>
> This reverts 8177809 for AIX because it leads to build errors on older AIX
> systems. We want to retain the ability to build on older AIX releases.
>
> Thanks, Thomas


From naoto.sato at oracle.com  Wed May 31 21:53:54 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 31 May 2017 14:53:54 -0700
Subject: jdk9 vs. jdk8 : TimeZone getDisplayName(Locale.GERMAN) for TZ=MET
In-Reply-To: 
References: 
 
Message-ID: 

Hi Matthias, Dalibor,

Yes, the result you are seeing is due to the default locale provider 
change to CLDR. CLDR does not provide localized display names for those 
abbreviated three letter time zones. In such a case, English name from 
the COMPAT provider (i.e., the same locale data from JDK8. The resource 
bundle file you are seeing below belongs to this provider) is 
supplemented. To see the same behavior with JDK8, you can set the 
"java.locale.providers" system property to "COMPAT" so that it will use 
the COMPAT locale provider as the default.

HTH,
Naoto

On 5/31/17 8:18 AM, dalibor topic wrote:
> On 31.05.2017 17:11, Baesken, Matthias wrote:
>>
>> I wonder why the display names for timezone MET changed ( I observed 
>> this on Linux and Solaris) when I compare
>> jdk8 to jdk9 .
>>
>> The test is very small, it just outputs for Locale.GERMAN  the display 
>> name.
>> With jdk8 we get a translated german timezone name, but not with jdk9  
>> (this is a bit strange because  the jdk9 rsource file
>> src/jdk.localedata/share/classes/sun/util/resources/ext/TimeZoneNames_de.java 
>>
>> still contains the translation).
>>
>> Is this intentional  or a bug ?
> 
> Hi Matthias,
> 
> it might be a side effect of http://openjdk.java.net/jeps/252 .
> 
> cheers,
> dalibor topic
> 
>> Best regards, Matthias
>>
>>
>>
>> TimeZoneTest.java
>> ------------------------
>> import java.util.TimeZone;
>> import java.util.Locale;
>>
>> public class TimeZoneTest {
>>
>>     public static void main(String[] args)
>>     {
>>         TimeZone tz = TimeZone.getDefault();
>>         // now test for german
>>         String dng = tz.getDisplayName(Locale.GERMAN);
>>         System.out.println("timezone display name for Locale.GERMAN " 
>> + dng);
>>     }
>> }
>> ------------------------
>>
>> for environment variable TZ=MET  (export TZ=MET) we get :
>> ../output-jdk8/images/j2sdk-image/bin/java  TimeZoneTest
>> timezone display name for Locale.GERMAN Zentraleurop?ische Zeit
>>
>> ../output-jdk9/images/jdk/bin/java  TimeZoneTest
>> timezone display name for Locale.GERMAN Middle Europe Time
>>
> 

From igor.ignatyev at oracle.com  Wed May 31 21:57:33 2017
From: igor.ignatyev at oracle.com (Igor Ignatyev)
Date: Wed, 31 May 2017 14:57:33 -0700
Subject: RFR(S) : 8180386: remove jdk.testlibrary.TimeLimitedRunner
In-Reply-To: 
References: <0022AF62-2D30-4850-A5BC-D48085648396@oracle.com>
 
 <8E330394-02DF-4CC5-B822-C9226F9AAB9A@oracle.com>
 
 
Message-ID: <7D58B500-AE31-4A65-B148-DE12CF9742AA@oracle.com>

Hi Mandy,

8180793[1], which moved j.t.l.wrappers.* to j.t.lib package, has been propagated to jdk10/jdk10. I have updated the patch accordingly -- http://cr.openjdk.java.net/~iignatyev//8180386/webrev.01/index.html 
could you please take a look?

[1] https://bugs.openjdk.java.net/browse/JDK-8180793

Thanks,
-- Igor

> On May 18, 2017, at 2:49 PM, Igor Ignatyev  wrote:
> 
>> 
>> On May 18, 2017, at 2:41 PM, Mandy Chung  wrote:
>> 
>> 
>>> On May 18, 2017, at 2:37 PM, Igor Ignatyev  wrote:
>>> 
>>> 
>>>> On May 18, 2017, at 2:34 PM, Mandy Chung  wrote:
>>>> This comment is not related to the change.  The package name `jdk.test.lib.wrappers` is odd. TimeLimitedRunner and InfiniteLoop classes could simply be in the jdk.test.lib package or jdk.test.lib.util package.
>>>> 
>>>> Mandy
>>>> 
>>> 
>>> agree, I'll file an RFE to find a better package for TimeLimitedRunner and InfiniteLoop classes.
>> 
>> Why not doing the rename with this patch?
> 
> there are hotspot tests which use jdk.test.lib.wrappers.TimeLimitedRunner and InfiniteLoop, so it will require changes in hotspot repo. I'd prefer to have removing classes from jdk testlibrary and renaming classes in top level testlibrary as separate patches for clarity purposes. 
> 
> -- Igor


From stuart.marks at oracle.com  Wed May 31 23:09:31 2017
From: stuart.marks at oracle.com (Stuart Marks)
Date: Wed, 31 May 2017 16:09:31 -0700
Subject: RFR 9+-: 8180582: The bind to rmiregistry is rejected by
 registryFilter even though registryFilter is set
In-Reply-To: <39f12457-65a8-36c9-cb32-babb74fa9c08@Oracle.com>
References: <64bc8ce2-4eaf-0300-13e2-1102cd765f8d@Oracle.com>
 
 <996d590e-4d08-df0b-d20d-b65610ba472d@Oracle.com>
 
 <39f12457-65a8-36c9-cb32-babb74fa9c08@Oracle.com>
Message-ID: <6dc73b18-1bee-23a6-11c0-e80b5463a21f@oracle.com>

Hi Roger,

RegistryImpl change looks fine. I have a quibble on the regex used in the test.

  162         Matcher m = Pattern
  163                 .compile(".*maxdepth=(\\d*)")
  164                 .matcher(Objects.requireNonNullElse(registryFilter, ""));
  165         int depthOverride = m.find() ? Integer.parseInt(m.group(1)) : 
REGISTRY_MAX_DEPTH;

Since Matcher.find() is called, the pattern can be found anywhere in the input 
string, so the leading ".*" is unnecessary. I'd suggest replacing it with "\\b" 
to match a word boundary immediately preceding "maxdepth". Also, "\\d*" will 
match zero characters, which could cause the subsequent parseInt() to fail.

These issues aren't of immediate concern, as the test works as it stands. They 
may make the test a bit harder to maintain, though.

But I think the main concern is that if the regex were modified by future 
maintenance, it might not match, which would cause the test to test 
REGISTRY_MAX_DEPTH redundantly instead of the depth the filter is attempting to 
specify. This problem wouldn't be completely silent, but it'd be easy to miss. 
You'd have to inspect the log pretty carefully to see what's going on. So maybe 
it would be good to have something like a command-line argument that specifies 
the expected value of maxdepth. Yes, this is redundant, but it's a useful 
cross-check, I think.

There are several identical lines of code starting at line 184. Maybe these 
could be extracted into a common method.

These are all cleanup issues, so it's up to you how much additional work you 
want to put into this before it gets into 9.

s'marks



On 5/31/17 7:02 AM, Roger Riggs wrote:
> Thanks Daniel for the review and corrected link.
>
> On 5/30/2017 7:04 PM, Daniel Fuchs wrote:
>> Hi Roger,
>>
>> On 30/05/17 19:26, Roger Riggs wrote:
>>> Hi Daniel,
>>>
>>> Fixed, there is no need for the unbind since the registry is not reused and
>>> it might
>>> cause a spurious success.
>>>
>>> (Also corrected the exception error message @ 151 and 153).
>>>
>>> Webrev updated in place.
>>> ...
>>
>> I assume you meant
>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
>> which is what I reviewed ;-)
>>
>> Looks good!
>>
>> -- danel
>>
>>>
>>> Thanks, Roger
>>>
>>>
>>> On 5/30/2017 2:00 PM, Daniel Fuchs wrote:
>>>> Hi Roger,
>>>>
>>>> Looks good! Just one nit with the test:
>>>>
>>>>  194             registry.unbind(name);
>>>>  195             Assert.fail("Registry filter should have rejected depth: "
>>>> + depthOverride + 1);
>>>>
>>>> Technically, the test will also pass if bind() succeed but
>>>> unbind() fails - for some unforeseen reason.
>>>>
>>>> best regards,
>>>>
>>>> -- daniel
>>>>
>>>> On 25/05/17 16:31, Roger Riggs wrote:
>>>>> Please review an update to the RMI Registry built-in serial filter
>>>>> implementation limit on the depth
>>>>> of a instance that can be bound in the registry.  The initial depth limit
>>>>> was 5 and it was too limiting
>>>>> for some existing applications.  It limit is updated to depth = 20 and
>>>>> should be more than adequate.
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~rriggs/webrev-depth-max-8180582/index.html
>>>>>
>>>>> Issue:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8180582
>>>>>
>>>>> Thanks, Roger
>>>>
>>>
>>
>


description