Re: Need sponsor to fix Javadoc warnings

Vipin, I saw that Max had already reviewed that incremental patch. That's good. I couldn't resist fixing a couple of typos in the already affected jdk.internal.icu (International Components for Unicode) package. Once this has been cleared by experts in that area, we are good to go. Here's the c

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

Hi Alan, Thanks for your feedback. I've updated the fix with your comments and you can find them in the new webrev below. WRT the release note JDK-8237530 , that's a good point. I will look into removing it. webrev: http://cr.openjdk.java.n

Re: RFR[8237890]: 'DatagramPacket::getSocketAddress doesn't specify what happens if address or port are not set'

> On 15 Apr 2020, at 16:40, Patrick Concannon > wrote: > > ... > > webrev: http://cr.openjdk.java.net/~pconcannon/8237890/webrevs/webrev.01/ > I added myself as reviewer on the CSR. The changes mainly look good. Can you please add, or amend an existing, test for the newly specified defaul

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Daniel, > On 14 Apr 2020, at 16:37, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > 8238270: java.net HTTP/2 client does not decrease stream count > when receives 204 response > https://bugs.openjdk.java.net/browse/JDK-8238270 > > webrev: > http://cr.openjdk.java.net/

Re: Need sponsor to fix Javadoc warnings

Vipin, After a private exchange with Naoto Sato, who is fluent in that area, I decided to leave out all the changes to the jdk.internal.icu package from the changeset. The reason is quite simple. A significant portion of code in jdk.internal.icu comes from an upstream project, ICU4J. Making OpenJ

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

On 15/04/2020 17:40, Chris Hegarty wrote: The new test is good, but has an unnecessary reference to AbstractThrowingSubscribers.TestExecutor. Good catch. I'll send a new webrev after I have received further feedback. (or in a couple of days if none are forthcoming :-) ) -- daniel

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Hi Chris, On 15/04/2020 17:40, Chris Hegarty wrote: It is allowable for a HEADERS frame to carry an END_STREAM, but not an END_HEADERS. If this happens, then CONTINUATION frames must follow, the last of which will carry END_HEADERS. That probably explains why the END_STREAM handling is done the

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

> On 15 Apr 2020, at 18:17, Daniel Fuchs wrote: > > Hi Chris, > > On 15/04/2020 17:40, Chris Hegarty wrote: >> It is allowable for a HEADERS frame to carry an END_STREAM, >> but not an END_HEADERS. If this happens, then CONTINUATION >> frames must follow, the last of which will carry END_HEADER

Re: Need sponsor to fix Javadoc warnings

Hi Pavel, > On Apr 9, 2020, at 2:45 AM, Pavel Rappo wrote: > > If your new patch addresses a similar type of problem, please send it in > reply to this email, > so that I could merge it with the existing patch. Let's try to minimize > process overhead if possible. > This is additional patch:

Re: Need sponsor to fix Javadoc warnings

Thanks Pavel, I will keep this in mind for future patches. > On Apr 15, 2020, at 10:22 PM, Pavel Rappo wrote: > > Vipin, > > After a private exchange with Naoto Sato, who is fluent in that area, I > decided > to leave out all the changes to the jdk.internal.icu package from the > changeset. >

Re: 8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

Argh! On 15/04/2020 19:46, Chris Hegarty wrote: From section 6.2 - HEADERS: END_STREAM (0x1): When set, bit 0 indicates that the header block (Section 4.3 ) is the last that the endpoint will send for the identified stream.

Re: RFR[8241072]: 'Reimplement Legacy DatagramSocket API'

Hi Alan, Thanks for your further comments. I've refactored DatagramSocket as you suggested, and returned DatagramSocketAdaptor to the correct formatting. I also removed the incorrect @bug tag from SetGetSendBufferSize and /othervm from the other test updates.I've included these changes in the