Re: RFR 8179292: a number of launcher tests fail when run with --limit-modules due to CNFE: javax.tools.ToolProvider

+1 Kumar On 7/25/2017 6:30 PM, Andrey Nazarov wrote: Thank you! On 25 Jul 2017, at 18:20, Mandy Chung wrote: On Jul 25, 2017, at 6:18 PM, Andrey Nazarov mailto:andrey.x.naza...@oracle.com>> wrote: Updated by this line. http://cr.openjdk.java.net/~anazarov/JDK-8179292/webrev.02/webrev/

Re: RFR: JDK-8183579: refactor and cleanup launcher help messages

> On Jul 20, 2017, at 11:53 AM, Kumar Srinivasan > wrote: > > Hi, > > Please review refactoring and clean up of the java launcher's help/usage > messages. > > The highlights of the changes are as follows: > > 1. Helper.java: is renamed from LauncherHelper.java, simpler name, >containing

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

A double negative (!Files.notExists) somewhat unusual coding and will perplex people reading it. They might even switch it back to Files.exists as a style cleanup, so I recommend adding a comment explaining why you’re using it. Thanks, Paul On 7/25/17, 5:08 PM, "core-libs-dev on behalf of Andr

RFR: JDK-8185359: Unnecessary in module doc comment

Continuing the ongoing docs cleanup, please review this fix to remove a superfluous in the docs for the java.scripting module. No webrev; just one line deleted, as shown here: $ hg diff -R jdk diff -r d93f2fd542b7 src/java.scripting/share/classes/module-info.java --- a/src/java.scripting/share

Re: RFR: JDK-8185359: Unnecessary in module doc comment

+1 > On Jul 26, 2017, at 2:57 PM, Jonathan Gibbons > wrote: > > Continuing the ongoing docs cleanup, please review this fix to remove a > superfluous > in the docs for the java.scripting module. > > No webrev; just one line deleted, as shown here: > > $ hg diff -R jdk > diff -r d93f2fd542b7

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

> On 26 Jul 2017, at 18:03, Hohensee, Paul wrote: > > A double negative (!Files.notExists) somewhat unusual coding and will perplex > people reading it. They might even switch it back to Files.exists as a style > cleanup, so I recommend adding a comment explaining why you’re using it. As the

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

> On 26 Jul 2017, at 12:31, Chris Hegarty wrote: > > >> On 26 Jul 2017, at 18:03, Hohensee, Paul wrote: >> >> A double negative (!Files.notExists) somewhat unusual coding and will >> perplex people reading it. They might even switch it back to Files.exists as >> a style cleanup, so I recomm

Re: RFR: JDK-8185359: Unnecessary in module doc comment

+1 Mandy > On Jul 26, 2017, at 11:57 AM, Jonathan Gibbons > wrote: > > Continuing the ongoing docs cleanup, please review this fix to remove a > superfluous > in the docs for the java.scripting module. > > No webrev; just one line deleted, as shown here: > > $ hg diff -R jdk > diff -r d93f

Re: RFR 8184961: jdk.test.lib.util.FileUtils.deleteFileWithRetry0 should wait for absence of a file

Hi, Please review this simple documentation patch diff -r a133a7d1007b test/lib/jdk/test/lib/util/FileUtils.java --- a/test/lib/jdk/test/lib/util/FileUtils.java Tue Jul 25 17:04:46 2017 -0700 +++ b/test/lib/jdk/test/lib/util/FileUtils.java Wed Jul 26 13:20:44 2017 -0700 @@ -98,6 +98,7 @@

JEP 306: Restore Always-Strict Floating-Point Semantics

New JEP Candidate: http://openjdk.java.net/jeps/306 - Mark

RFR: JDK-8185365 Tidy up leftover dead code after JDK-8136570

1. JDK-8185365 Tidy up leftover dead code after JDK-8136570 http://cr.openjdk.java.net/~martin/webrevs/openjdk10/post-8136570-tidy/

[10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0

Hello, This change fixes a regression in JDK 9 by allowing the java.util and zipfs zip implementations to read archives where the modified day or month is 0. bug: https://bugs.openjdk.java.net/browse/JDK-8184940 webrev: http://cr.openjdk.java.net/~cushon/8184940/webrev.00/ Thanks, Liam

Re: [10] RFR: 8184940: JDK 9 rejects zip files where the modified day or month is 0

Looks good. This should go into jdk10 and later into a jdk9 update. (Will an Oracle engineer volunteer?) I wonder where the "8" in the "Friday the 30th" date comes from. Could your California time zone be leaking into the test? The DOS timestamp is interpreted as local time while Instant.pars