Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

On 22/03/2018 12:52 PM, Andrei Nazarov wrote: On Mar 21, 2018 19:13, David Holmes wrote: Hi Andrei, On 22/03/2018 11:12 AM, Andrey Nazarov wrote: > Hi, > > Please review fix in launcher tests. > > Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/

RFR 8198882: Add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/

Please review the changes to add 10 JNDI tests to com/sun/jndi/dns/AttributeTests/, thanks bug: https://bugs.openjdk.java.net/browse/JDK-8198882 webrev: http://cr.openjdk.java.net/~xyin/8198882/webrev.00/

Re: RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

Hi Andrei, On 22/03/2018 11:12 AM, Andrey Nazarov wrote: Hi, Please review fix in launcher tests. Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196750?filter=-1 test/jdk/tools/launcher/ToolsOpts.java I don't understand how th

RFR: 8196750 [Testbug] tools/launcher tests need to tolerate unrelated warnings

Hi, Please review fix in launcher tests. Review: http://cr.openjdk.java.net/~anazarov/JDK-8196750/webrev/ Bug: https://bugs.openjdk.java.net/browse/JDK-8196750?filter=-1 —Thanks, Andrei

Re: [11] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Hi Claes, I'm finally finally getting back to this. I reviewed the current state of the patch located here: http://cr.openjdk.java.net/~redestad/8193128/open.06/ I think this is mostly fine as it is. There are some things about it that could be adjusted, but none of them stand in the way

Re: Reactive Streams utility API

Hi all, We've created a reference implementation. It's been done in such a way that implementation of new features (stages) is quite straight forward, there is an abstraction that does the hard work of handling concurrency, the reactive streams spec conformance, and managing demand and buffering,

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Hmmm... it's a hard problem because we intentionally have invalid html in our private javadoc, since it's designed primarily for human readers, e.g. error: malformed HTML [javadoc] * Precondition and postcondition: 0 <= i < modulus. jsr166 has: [javadoc] 86 errors [javadoc] 780 warnin

Re: RFR (JDK11/doc-only) 8199176: Accessibility issues in java.base docs

They look ok. They actually go better with the package name when they are just 1 level down instead of 2, that is, rather than for the titles when the package name is . If we don't want the strong emphasis on the titles, we could lower the package name generated by javadoc to instead of . Th

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 3/21/18 1:59 PM, Jonathan Gibbons wrote: On 03/21/2018 01:39 PM, mandy chung wrote: On 3/21/18 10:26 AM, David Lloyd wrote: I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, defineClass and then click on "binary name"; it's actually using the sources, rather than gener

Re: RFR (JDK11/doc-only) 8199176: Accessibility issues in java.base docs

On 3/21/18 2:28 PM, Alan Bateman wrote: On 21/03/2018 19:08, Joe Wang wrote: : *Item 3*: Heading leavels should only increase by one     This is due to the javadoc tool generates a header with an addition of headings, in this particular case, . The fix for this particular case is to replace

Re: RFR (JDK11/doc-only) 8199176: Accessibility issues in java.base docs

On 21/03/2018 19:08, Joe Wang wrote: : *Item 3*: Heading leavels should only increase by one     This is due to the javadoc tool generates a header with an addition of headings, in this particular case, . The fix for this particular case is to replace the s with . I assume this has the effect

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 3/21/18 2:18 PM, Martin Buchholz wrote: On Wed, Mar 21, 2018 at 1:59 PM, Jonathan Gibbons mailto:jonathan.gibb...@oracle.com>> wrote: I think that maybe we should establish a convention such that user-defined anchors can never conflict with javadoc-generated anchors. Using

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On Mar 21, 2018, at 2:21 PM, Stuart Marks wrote: >>> Such a refactoring would be prohibited by an @implSpec. >> Why then not an @implNote instead of an @apiNote? > The statement that was proposed: > This method is equivalent to write(b, 0, b.length). > is a statement about the semantics of writeB

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On 3/21/18 1:27 PM, Brian Burkhalter wrote: On Mar 21, 2018, at 1:23 PM, Stuart Marks > wrote: Perhaps instead the verbiage just needs to be changed to, e.g., “The implementation in this class simply invokes {@link #write(byte[],int,int) write(b, 0, b.length)}.”

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 1:59 PM, Jonathan Gibbons < jonathan.gibb...@oracle.com> wrote: > > I think that maybe we should establish a convention such that user-defined > anchors can never conflict with javadoc-generated anchors. Using an > embedded "-" (as in this proposal) in user-defined anchors

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 2:03 PM, David Lloyd wrote: > On Wed, Mar 21, 2018 at 3:39 PM, mandy chung > wrote: > > On 3/21/18 10:26 AM, David Lloyd wrote: > > > > I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, > > defineClass and then click on "binary name"; it's actually using

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 3:39 PM, mandy chung wrote: > On 3/21/18 10:26 AM, David Lloyd wrote: > > I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, > defineClass and then click on "binary name"; it's actually using the > sources, rather than generated JavaDoc. > > > I don't object

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 03/21/2018 01:39 PM, mandy chung wrote: On 3/21/18 10:26 AM, David Lloyd wrote: I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, defineClass and then click on "binary name"; it's actually using the sources, rather than generated JavaDoc. I don't object to do this renam

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 3/21/18 10:26 AM, David Lloyd wrote: I see it with IntelliJ IDEA when I pop up "quick JavaDoc" on, say, defineClass and then click on "binary name"; it's actually using the sources, rather than generated JavaDoc. I don't object to do this renaming as I favor this more explicit id.  Howeve

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On Mar 21, 2018, at 1:23 PM, Stuart Marks wrote: >> Perhaps instead the verbiage just needs to be changed to, e.g., >> >> “The implementation in this class simply invokes {@link >> #write(byte[],int,int) write(b, 0, b.length)}.” > I don't think you want to specify this detail about the impleme

Re: RFR of 8180451: ByteArrayInputStream should override readAllBytes, readNBytes, and transferTo

Sorry. This looks OK to me (non-reviewer) now. On Wed, Mar 21, 2018 at 1:01 PM, Brian Burkhalter wrote: > This is still in need of final approval, assuming it is OK. > > Thanks, > > Brian > > On Mar 14, 2018, at 10:50 AM, Brian Burkhalter > wrote: > > On Mar 14, 2018, at 9:27 AM, David Lloyd w

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On 3/21/18 1:01 PM, Brian Burkhalter wrote: On Mar 21, 2018, at 12:34 PM, Stuart Marks > wrote: Having this as an @implSpec sounds as if the implementation of this method in BAOS is *required* to call write(b, 0, b.length). It happens to do that in the current w

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On Mar 21, 2018, at 12:34 PM, Stuart Marks wrote: > Having this as an @implSpec sounds as if the implementation of this method in > BAOS is *required* to call write(b, 0, b.length). It happens to do that in > the current webrev, but this is not a requirement on the implementation. (At > least

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On 3/21/18 11:27 AM, Brian Burkhalter wrote: --- a/src/java.base/share/classes/java/io/ByteArrayOutputStream.java +++ b/src/java.base/share/classes/java/io/ByteArrayOutputStream.java @@ -158,15 +158,16 @@ count += len; } /** * Writes the complete contents of the

Re: RFR (JDK11/doc-only) 8199176: Accessibility issues in java.base docs

looks fine Joe > On Mar 21, 2018, at 3:08 PM, Joe Wang wrote: > > Hi, > > Please an accessibility fix for several package-info files. > > The report contained 4 items. Among them, 1 and 2 are issues in the javadoc > tool, and 3 could use an improvement in the tool or documentation. For > ref

RFR (JDK11/doc-only) 8199176: Accessibility issues in java.base docs

Hi, Please an accessibility fix for several package-info files. The report contained 4 items. Among them, 1 and 2 are issues in the javadoc tool, and 3 could use an improvement in the tool or documentation. For reference, please see the linked issues in JBS [1]. For the current issue, we're

Re: RFR 8198997: Cache normalized/resolved user.dir property

On Mar 21, 2018, at 11:36 AM, Alan Bateman wrote: > That looks right. I assume there's no test for this as it's never been > supported to change user.dir on the command line. I don’t think a test is called for. Thanks, Brian

Re: RFR 8198997: Cache normalized/resolved user.dir property

On 21/03/2018 18:12, Brian Burkhalter wrote: That was unclear, at least to me: --- a/src/java.base/windows/classes/java/io/WinNTFileSystem.java +++ b/src/java.base/windows/classes/java/io/WinNTFileSystem.java @@ -48,11 +48,11 @@   public WinNTFileSystem() {       Properties props = GetPropertyA

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

The diff: --- a/src/java.base/share/classes/java/io/ByteArrayOutputStream.java +++ b/src/java.base/share/classes/java/io/ByteArrayOutputStream.java @@ -158,15 +158,16 @@ count += len; } /** * Writes the complete contents of the specified byte array * to this {@code

Re: RFR 8198997: Cache normalized/resolved user.dir property

On Mar 21, 2018, at 11:08 AM, Alan Bateman wrote: > On 21/03/2018 18:02, Brian Burkhalter wrote: >> Ping … > I think we're waiting for a new version that will normalize the value of > user.dir in the WinNTFileSystem constructor. That was unclear, at least to me: --- a/src/java.base/windows/cla

Re: RFR 8198997: Cache normalized/resolved user.dir property

On 21/03/2018 18:02, Brian Burkhalter wrote: Ping … I think we're waiting for a new version that will normalize the value of user.dir in the WinNTFileSystem constructor. -Alan

Re: RFR 8198997: Cache normalized/resolved user.dir property

Ping … On Mar 13, 2018, at 12:33 PM, Brian Burkhalter wrote: > On Mar 13, 2018, at 12:24 PM, Alan Bateman wrote: > >> As relative paths are command then it might be simpler to just change the >> static initializer > > Static initializer or constructor? > >> to initialize userDir to normali

Re: RFR of 8180451: ByteArrayInputStream should override readAllBytes, readNBytes, and transferTo

This is still in need of final approval, assuming it is OK. Thanks, Brian On Mar 14, 2018, at 10:50 AM, Brian Burkhalter wrote: > On Mar 14, 2018, at 9:27 AM, David Lloyd wrote: > >> @@ -196,14 +194,32 @@ >> return len; >> } >> >> +public synchronized byte[] readAllBytes()

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 12:04 PM, mandy chung wrote: > > > On 3/21/18 8:58 AM, David Lloyd wrote: > > Since adding a field called "name" to java.lang.ClassLoader, the > "name" anchor which previously referred to the section entitled > "binary names" has been broken. > > The attached doc-only patch

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 3/21/18 8:58 AM, David Lloyd wrote: Since adding a field called "name" to java.lang.ClassLoader, the "name" anchor which previously referred to the section entitled "binary names" has been broken. The attached doc-only patch changes the name of the anchor to "binary-name". It applies with

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

Hi Roger, I’ll change before pushing. Thanks, Brian On Mar 21, 2018, at 9:58 AM, Roger Riggs wrote: > An @impSpec for that is fine with me.

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

Hi Brian, An @impSpec for that is fine with me. Roger On 3/21/2018 12:48 PM, Brian Burkhalter wrote: On Mar 16, 2018, at 8:04 AM, Brian Burkhalter mailto:brian.burkhal...@oracle.com>> wrote: On Mar 16, 2018, at 7:59 AM, Roger Riggs > wrote: ByteArrayOutpu

Re: RFR 8180410: ByteArrayOutputStream should not throw IOExceptions

On Mar 16, 2018, at 8:04 AM, Brian Burkhalter wrote: > On Mar 16, 2018, at 7:59 AM, Roger Riggs wrote: > >> ByteArrayOutputStream: 166: Add spaces after "," in the code. > > Done: webrev.01 updated in place. > >> Write: >> Thanks for converting to TestNG. >> There are probably some more

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On 21/03/2018 16:10, Martin Buchholz wrote: : I'm confused by the subject. There is no such bug 9053056: Anchor name conflict in ClassLoader JavaDoc I've just moved it to the jdk project where it is JDK-8199947. -Alan

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Ah, so the submitted bug ID doesn't match the final bug ID. Excellent. On Wed, Mar 21, 2018 at 11:24 AM, Martin Buchholz wrote: > Found it. > https://bugs.openjdk.java.net/browse/JDK-8199947 > -- - DML

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Found it. https://bugs.openjdk.java.net/browse/JDK-8199947

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

On Wed, Mar 21, 2018 at 11:10 AM, Martin Buchholz wrote: > Hi David. > > I'll take this one. Thanks. > - * Returns a {@code Package} of the given name that > + * Returns a {@code Package} of the given href="#binary-name">name that > > Do Packages (I should really learn about Packages)

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Hi David. I'll take this one. - * Returns a {@code Package} of the given name that + * Returns a {@code Package} of the given name that Do Packages (I should really learn about Packages) actually have binary names? I'm confused by the subject. There is no such bug 9053056: Anchor nam

Re: [11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

I discovered there are a couple of references outside of ClassLoader as well. Here's the updated patch... On Wed, Mar 21, 2018 at 10:58 AM, David Lloyd wrote: > Since adding a field called "name" to java.lang.ClassLoader, the > "name" anchor which previously referred to the section entitled > "b

[11] [PATCH] 9053056: Anchor name conflict in ClassLoader JavaDoc

Since adding a field called "name" to java.lang.ClassLoader, the "name" anchor which previously referred to the section entitled "binary names" has been broken. The attached doc-only patch changes the name of the anchor to "binary-name". It applies with "patch -p1". -- - DML diff --git a/src/ja

Re: Raw String Literal Library Support

One more change set. trimIndent -> stripIndent trimMarkers -> stripMarkers > On Mar 20, 2018, at 10:35 AM, Jim Laskey wrote: > > Summary. > > A. Line support. > > - Supporting a mix of line terminators `\n|\r\n|\r` is already a well > established pattern in language parsers, in the JDK (ex