[12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)

Hello. Could you review the fix ? And please push this to jdk12 if possible. Bug:https://bugs.openjdk.java.net/browse/JDK-8211841 Change: http://cr.openjdk.java.net/~itakiguchi/8211841/webrev.00/ I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd.

Re: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format

Hi Joe! From what I see, the discussion was about possibility to only accept input strings with precisely sized parts, i.e. that matches "\p{XDigit}{8}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{4}- \p{XDigit}{12}". And I'm proposing to only reject input with too large individual parts, i.e.

Re: RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format

Hi Ivan, How does this bug relate to the recent discussion of "JDK-8165199: UUID.fromString(str) compliance checking?": http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-December/057470.html Cheers, -Joe On 1/9/2019 3:23 PM, Ivan Gerasimov wrote: Hello! String representation of UU

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

> On Jan 9, 2019, at 6:34 PM, Philipp Kunz wrote: > > > Better late than too late: Would it be an option to catch the exception in > JarFile.getManifestFromReference and throw another one with the name and the > caught exception as a cause? Because this is the only code that calls that > part

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

Better late than too late: Would it be an option to catch the exception in JarFile.getManifestFromReference and throw another one with the name and the caught exception as a cause? Because this is the only code that calls that particular constructor that I know of. JarVerifier could be a candidat

RFR 8216407 : java.util.UUID.fromString accepts input that does not match expected format

Hello! String representation of UUID should conform to RFC4122 , i.e. each its part has to be of the fixed size. Unfortunately, the UUID.fromString() method does not keep up to this requirement: - First, it permits the leading zeroes of any part to be om

Re: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

On Jan 9, 2019, at 2:04 PM, John Rose wrote: > > you might consider using > a little combinatorial code to generate bad and good class > names P.S. To motivate this suggestion a bit more: I found no problem with your manually-written test vectors of bad and good names, but I also found it diffi

Re: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

Nice work. A couple of small points: A qualified class name is one that has a package prefix. So it is surprising that verifyUnqualifiedClassName allows a package prefix. Maybe it needs a different name. The testing looks adequate, but you might consider using a little combinatorial code to gen

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

+1 On 01/09/2019 03:46 PM, Sean Mullan wrote: Looks good. --Sean On 1/9/19 3:42 PM, Lance Andersen wrote: Here is the webrev for the changes: http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html Best Lance On Jan 9, 2019, at 12:13 PM, Sean Mullan >

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

Looks good. --Sean On 1/9/19 3:42 PM, Lance Andersen wrote: Here is the webrev for the changes: http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html Best Lance On Jan 9, 2019, at 12:13 PM, Sean Mullan > wrote: On 1/8/19 7:17 PM, Philipp Kunz wrote:

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

Here is the webrev for the changes: http://cr.openjdk.java.net/~lancea/8216362/webrev.00/index.html Best Lance > On Jan 9, 2019, at 12:13 PM, Sean Mullan wrote: > > On 1/8/19 7:17 PM, Philipp Kunz wrote: >> Manifest.read throws

Re: RFR: JDK-8215510: j.l.c.ClassDesc is accepting descriptors not allowed by the spec

+1 from me. On 1/7/2019 1:17 PM, Vicente Romero wrote: I have updated the webrev after additional feedback from the TCK tester please check last version at [1] Thanks, Vicente [1] http://cr.openjdk.java.net/~vromero/8215510/webrev.01 On 1/3/19 12:21 PM, Vicente Romero wrote: Please review t

[PATCH] JDK-8216140: Correct UnicodeDecoder U+FFFE handling

Hello, I’ve crossed this bug on the past and I would like to fix it. You will find the patch with the fix attached to this message. I have few questions around this subject. 1.Where should the test be placed? It is not clear to me which is the standard approach. I’ve spent about 1h searching

Re: [RFR] 8216362: Incorrect jar file error message when there is an invalid manifest

On 1/8/19 7:17 PM, Philipp Kunz wrote: Manifest.read throws an exception with the jar file name passed to the constructor the manifest was constructed with and not passed to the call to the read that throws the exception because the jarFilename variable is not reset after successful constructio

Re: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"

The behavior looks similar to the underlying TLS implementation. Looks good to me. Thanks, Xuelei On 1/8/2019 9:03 AM, Rob McKenna wrote: Hi folks, I'd like to fix this test failure caused by 8160768. The problem is that the LdapDnsProviderResult sets the hostname to the empty String and ge

Re: [RFR] 8214440: ldap over a TLS connection negotiate failed with "javax.net.ssl.SSLPeerUnverifiedException: hostname of the server '' does not match the hostname in the server's certificate"

The parameter can be null, but if you look at the spec for getDomainName it details the behaviour when the result is created with a null value. I would rather avoid changing the spec at this point so I plan to stick with this approach. (I'll switch the "".equals for isEmpty - thanks for that)

Re: JDK-8215626 : Correct [^..&&..] intersection negation behaviour JDK8 vs JDK11 ??

Thanks Sherman, Yes I agree. Cheers Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd Phone internal: 245913, external: 01962 815913 internet email: andrew_m_leon...@uk.ibm.com From: Xueming Shen To: core-libs-dev@openjdk.java.net Date: 08/01/2019 16:

Re: RFR - JDK-8215489 Remove String::align

Looks good. -Sundar On 09/01/19, 8:56 PM, Jim Laskey wrote: Please review the removal of String::align from JDK12. Thank you. — Jim webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html JBS: https://bugs.open

RFR - JDK-8215489 Remove String::align

Please review the removal of String::align from JDK12. Thank you. — Jim webrev: http://cr.openjdk.java.net/~jlaskey/8215489/webrev/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8215489

Re: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long}

Thank you Christoph! Pushed. On 1/9/19 5:47 AM, Langer, Christoph wrote: Hi Ivan, looks good 😊 Best regards Christoph -Original Message- From: core-libs-dev On Behalf Of Ivan Gerasimov Sent: Mittwoch, 9. Januar 2019 08:19 To: core-libs-dev@openjdk.java.net Subject: RFR (XS) 821641

RE: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless string contains parsable {@code int}; should be {@code long}

Hi Ivan, looks good 😊 Best regards Christoph > -Original Message- > From: core-libs-dev On Behalf > Of Ivan Gerasimov > Sent: Mittwoch, 9. Januar 2019 08:19 > To: core-libs-dev@openjdk.java.net > Subject: RFR (XS) 8216413 : Long.parseLong() is specified to throw unless > string contains

Re: JDK-8210280 - Unnecessary reallocation when invoking HashMap.putAll()

ping On 1/3/19 9:31 PM, Michal Vala wrote: Hi Martin, can we please finish this review? On 12/19/18 6:32 PM, Michal Vala wrote: On 12/19/18 4:15 PM, Martin Buchholz wrote: On Wed, Dec 19, 2018 at 6:59 AM Roger Riggs wrote: Hi Martin, It is also useful and conventional to print the seed

Re: Feature suggestion: Add static equals methods to Float and Double

Le 08/01/2019 à 19:55, Hans Boehm a écrit : > The IEEE standard does say that for quiet NaNs, the value (or one of them) > "should" be preserved by most operations on the quiet NaN. I have not heard > of implementations violating this for anything other than the "quiet" bit. > Thus I don't immediat