Re: RFR (s): 8217412 deprecate rmic for removal

Looks good. -Sundar On 31/05/19, 6:40 AM, Stuart Marks wrote: Hi all, Please review this patch and CSR request for upgrading the deprecation status of the rmic to from ordinary to terminal (i.e., conceptually set forRemoval=true, though there are no actual annotations involved here).

Re: RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs

+1 Mandy On 5/30/19 6:07 PM, Jonathan Gibbons wrote: Please review a simple docs fix for jdk.zipfs module-info.java. The ranks of the headings are updated to close up the gaps, and a couple of superfluous are removed. Webrev link below, but the patch is small enough to read inline if you

RFR [XS/docs] JDK-8225094: Fix minor HTML issues in jdk.zipfs

Please review a simple docs fix for jdk.zipfs module-info.java. The ranks of the headings are updated to close up the gaps, and a couple of superfluous are removed. Webrev link below, but the patch is small enough to read inline if you want. -- Jon JBS:

RFR (s): 8217412 deprecate rmic for removal

Hi all, Please review this patch and CSR request for upgrading the deprecation status of the rmic to from ordinary to terminal (i.e., conceptually set forRemoval=true, though there are no actual annotations involved here). There are no code changes, just documentation changes and changes to

Re: RFR: docs/accessibility: JDK-8220251: fix headings in java.management

looks ok Jon > On May 30, 2019, at 7:53 PM, Jonathan Gibbons > wrote: > > Please review a conceptually simple fix to adjust the rank of the headings in > the following files in 4 management-related modules: > > src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html >

RFR: docs/accessibility: JDK-8220251: fix headings in java.management

Please review a conceptually simple fix to adjust the rank of the headings in the following files in 4 management-related modules: src/java.management.rmi/share/classes/javax/management/remote/rmi/package.html src/java.management/share/classes/java/lang/management/LockInfo.java

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

Thank you for elaborating. The new version looks good. -Brent On 5/30/19 1:29 PM, Lance Andersen wrote: Hi Brent, On May 30, 2019, at 4:02 PM, Brent Christian mailto:brent.christ...@oracle.com>> wrote: Hi, Lance Thank you for the review. This change is to collect more information in

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

> On May 30, 2019, at 3:58 PM, Roger Riggs wrote: > > Hi Kim, > > To ensure you see some messages in the case of timeouts, it would be > useful to call System.out.flush() after printing the message in logProcess(). Good idea; added. full: http://cr.openjdk.java.net/~kbarrett/8219149/open.01/

Re: RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module

+1 > On May 30, 2019, at 4:32 PM, Jonathan Gibbons > wrote: > > Please review a one line change to fix a 404 link in > javax/annotation/processing/Filer.java > With this fix, DocCheck finds no errors in the java.compiler module. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 > >

Re: RFR: [XS, doc] JDK-8225077: fix references to broken link in java.compiler module

+1 Thanks Jon, -Joe On 5/30/2019 1:32 PM, Jonathan Gibbons wrote: Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java With this fix, DocCheck finds no errors in the java.compiler module. JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 -- Jon

RFR: [XS,doc] JDK-8225077: fix references to broken link in java.compiler module

Please review a one line change to fix a 404 link in javax/annotation/processing/Filer.java With this fix, DocCheck finds no errors in the java.compiler module. JBS: https://bugs.openjdk.java.net/browse/JDK-8225077 -- Jon Patch inline: $ hg diff -R open diff -r a0d4e61acb6b

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

Hi Brent, > On May 30, 2019, at 4:02 PM, Brent Christian > wrote: > > Hi, Lance Thank you for the review. > > This change is to collect more information in case this happens again, yes? This changes reduces the use of ProcessBuilder resulting in much improved test runs similar to what I

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

> On May 30, 2019, at 12:42 AM, David Holmes wrote: > > Adding back hotspot-dev. I don't think Kim saw this. I did see it, though nearly missed, and not spotted until late evening. Thanks for making sure… > > David > > On 30/05/2019 4:04 am, Roger Riggs wrote: >> Hi Kim, >> In the normal

Re: RFR 8212807: tools/jar/multiRelease/Basic.java times out

Hi, Lance This change is to collect more information in case this happens again, yes? Looks pretty good - just a couple comments: test/jdk/tools/jar/multiRelease/Basic.java 536 jar("ufm", jarfile, manifest.toString(), Is there a reason not to convert this to call jarTool() ? --

Re: RFR: 8219149: ProcessTools.ProcessBuilder should print timing info for subprocesses

Hi Kim, To ensure you see some messages in the case of timeouts, it would be useful to call System.out.flush() after printing the message in logProcess(). I'm ok with the timestamps, as is, though the Duration might be useful in some cases. +1, Roger On 05/30/2019 12:42 AM, David Holmes

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

If you are calling System.gc() for correctness (e.g. in a test), it is probably because some sort of finalization is being triggered. And that happens in some Java thread (e.g. Reference Handler) that System.gc() has no control over. So in practice, users need to call System.gc() and then wait

Re: RFR: 8224974: Implement JEP 352

On 5/30/19 9:08 AM, Andrew Dinn wrote: HI Vladimir, Thank you for reviewing the patch. On 29/05/2019 20:49, Vladimir Kozlov wrote: I tried to test these changes and build failed on all systems except Linux because: workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

On 5/30/19 6:48 PM, Roger Riggs wrote: > There are several ways to monitor the progress/"completion" of gc, > including visible affects on WeakReference, etc., Runtime.availableMemory, > etc. > Without the ("or ever"), the case can be made that eventually some kind of > completion > should

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

Hi Peter, There are several ways to monitor the progress/"completion" of gc, including visible affects on WeakReference, etc., Runtime.availableMemory, etc. Without the ("or ever"), the case can be made that eventually some kind of completion should be/must be visible directly or indirectly.

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

Hi Mandy, Yes, the method returns and something may have happened. But "or even" is a essential element, because there can be no guarantee that any reclamation will ever happen, whether or not the method returns. For example, EpilsonGC. Thanks, Roger On 05/30/2019 12:11 PM, Mandy Chung wrote:

RFR 8212807: tools/jar/multiRelease/Basic.java times out

Hi all, The following fix addresses an issue with an occasional timeout for tools/jar/multiRelease/Basic.java. The webrev can be found at: http://cr.openjdk.java.net/~lancea/8212807/webrev.00/index.html Best, Lance

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

On 5/30/19 8:55 AM, Peter Levart wrote: Yes Roger, this sounds better to me. Maybe even easier: "There is no guarantee that this effort will recycle any particular number of unused objects, reclaim any particular amount of space, or complete before the method returns (or ever)." +1 and

Re: RFR: 8224974: Implement JEP 352

HI Vladimir, Thank you for reviewing the patch. On 29/05/2019 20:49, Vladimir Kozlov wrote: > I tried to test these changes and build failed on all systems except > Linux because: > > workspace/open/src/hotspot/share/prims/unsafe.cpp:446:3: error: use of > undeclared identifier

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

Yes Roger, this sounds better to me. Maybe even easier: "There is no guarantee that this effort will recycle any particular number of unused objects, reclaim any particular amount of space, or complete before the method returns (or ever)." So, hypothetically, the effort triggered by

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

Hi, A release note would be a good idea to explain the change in behavior of SMART mode, I added label "release-note=yes" Regards, Roger On 05/30/2019 09:50 AM, Roger Riggs wrote: Hi, The behavior is within the spec and seems more just like a bug in the implementation. Also, an exception

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

Thanks, Roger. On 5/30/19 6:55 AM, Roger Riggs wrote: Hi Naoto, This looks ok. Typically, it is not necessary to check the exception message text. I just wanted to make sure that the thrown DateTimeParseException is none other than the exception that is expected. There seems no other way

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

Hi, Though I see your point about gc() eventually returns, the spec typically does not guarantee than any method eventually returns.  That's more a quality of service attribute. The sentence refers to the effort to reclaim space, not the method call. Would it clarify the case to add a

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

Hi Naoto, This looks ok. Typically, it is not necessary to check the exception message text. Thanks, Roger On 05/29/2019 05:21 PM, Lance Andersen wrote: Hi Naoto, This is OK. Could you please add an @summary as it is missing so that we are consistent with other tests. No need to spin a

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

Hi, The behavior is within the spec and seems more just like a bug in the implementation. Also, an exception was thrown but it was for the wrong reason. $.02, Roger On 05/29/2019 06:55 PM, naoto.s...@oracle.com wrote: Hi Joe, Right, I will file a corresponding CSR. Naoto On 5/29/19 3:51

jpackage EA Build Question Followup

Hi, I had sent in a question in January about the jpackage (see below link and email). Due to issues with our email filtering service I did not see the response and wandered upon it last night. So apologies in advance for such a long time between messages, I am now a subscriber and hopefully

Re: RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong

On 30/05/2019 11:55, Sundararajan Athijegannathan wrote: Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8224946 Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/ Earlier attempt for the fix of the same bug resulted in test failures and so the fix was reverted. The

RFR 8224946: jrtfs URI to Path and Path to URI conversions are wrong

Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8224946 Webrev: https://cr.openjdk.java.net/~sundar/8224946/webrev.00/ Earlier attempt for the fix of the same bug resulted in test failures and so the fix was reverted. The current webrev has the same fix - but fixes 2 jlink tests

Re: RFR 8220238 : Enhancing j.l.Runtime/System::gc specification with an explicit 'no guarantee' statement

>> Any other comments on: >> "* Runs the garbage collector in the Java Virtual Machine. >> * >> * Calling this method suggests that the Java Virtual Machine >> * expend effort toward recycling unused objects in order to >> * make the memory they currently occupy available for reuse >> * by the

Re: [13] RFR: 8223773: DateTimeFormatter Fails to throw an Exception on Invalid CLOCK_HOUR_OF_AMPM and HOUR_OF_AMPM

+1 On Wed, 29 May 2019, 22:13 , wrote: > Hi, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8223773 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8223773/webrev.00/ > > Checking the range of HourOfAmPm with the