Re: RFR: 8140723: Remove source code conditionalized on JAVASE_EMBEDDED

Can I please get someone from AWT to approve this. Thanks, David On 14/07/2016 2:25 PM, David Holmes wrote: The bug report for this is confidential but quite simply all of the little tweaks and knobs we added to the open build and source files to support the Java SE Embedded product no longer n

Re: JDK 9 RFR of JDK-8161500: Use getTypeName and StringJoiner in core reflection toString methods

Looks OK, although I find: StringJoiner sj = StringJoiner(delimiter, before, after); ... sb.append(sj.toString()); to be a messier read than: sb.append(before); StringJoiner sj = new StringJoiner(delimiter); ... sb.append(sj.toString()) .append(after); Any of these are ever used in a perform

JDK 9 RFR of JDK-8161500: Use getTypeName and StringJoiner in core reflection toString methods

Hello, Please review this straightforward cleanup of some of the core reflection implementation classes: JDK-8161500: Use getTypeName and StringJoiner in core reflection toString methods http://cr.openjdk.java.net/~darcy/8161500.1/ All java/lang/Class and java/lang/reflect regressio

Re: RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

Hi, this looks good to me, and it makes sense to me that upgrading to Java 9 and using this API on a Multi-release JAR doesn't suddenly filter out entries. /Claes On 2016-07-15 23:17, Steve Drach wrote: Hi, Please review this change to JarFile that reverts JarFile::stream and JarFile::entrie

RFR: 8157524 Revert JarFile methods "entries" and "stream" to Java 8 behavior

Hi, Please review this change to JarFile that reverts JarFile::stream and JarFile::entries to JDK 8 behavior. The code is identical to that in JDK 8 except line 504 in JarEntryIterator that now uses a different constructor to create a JarFileEntry. I also added some implementation notes expla

Re: [doc-only] JDK 9 RFR of 8161455: Missing word in API documentation

On 15/07/2016 20:29, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161455 Patch: [1] This looks fine. -Alan

Re: [doc-only] JDK 9 RFR of 8161455: Missing word in API documentation

+1 On 7/15/2016 3:29 PM, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161455 Patch: [1] Thanks, Brian [1] diff --- a/src/java.base/share/classes/java/nio/file/Files.java +++ b/src/java.base/share/classes/java/nio/file/Files.ja

[doc-only] JDK 9 RFR of 8161455: Missing word in API documentation

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161455 Patch: [1] Thanks, Brian [1] diff --- a/src/java.base/share/classes/java/nio/file/Files.java +++ b/src/java.base/share/classes/java/nio/file/Files.java @@ -3290,8 +3290,8 @@ * a size of {@code 0}

Re: JDK 9 RFR of 8161413: Math.fma javadoc doesn't have @since 9 [doc-only]

+1 On 7/15/2016 3:17 PM, Brian Burkhalter wrote: Please review @ your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161413 Patch: [1] Thanks, Brian [1] diff --- a/src/java.base/share/classes/java/lang/Math.java +++ b/src/java.base/share/classes/java/lang/Math.java @@ -1613

JDK 9 RFR of 8161413: Math.fma javadoc doesn't have @since 9 [doc-only]

Please review @ your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8161413 Patch: [1] Thanks, Brian [1] diff --- a/src/java.base/share/classes/java/lang/Math.java +++ b/src/java.base/share/classes/java/lang/Math.java @@ -1613,6 +1613,8 @@ * @return (a × b + c) * co

Re: RFR 8054213: Class name repeated in output of Type.toString()

Thank you, Joe! Sure, I'll change alignment in the test. Thanks, Svetlana On 15.07.2016 8:56, joe darcy wrote: Hi Svetlana, Looks okay. I approve pushing the fix with the following change to the test: have the expected output align with the given output. The webrev shows 63

Re: Create java.util.stream.Stream from Iterator / Enumeration

> On 14 Jul 2016, at 17:55, Patrick Reinhart wrote: > > Hi Paul, > > On 2016-07-13 10:28, Paul Sandoz wrote: > >> I see some comments already by Stuart and Alan, and concur with Alan >> about working closely with jigsaw-dev. >> Focusing on the public methods is good and then it will come down