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

Hello! The javadoc for Long.parseLong() mistakenly mentions {@code int} while it should have been {@code long}. Would you please help review a trivial fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8216413 WEBREV: http://cr.openjdk.java.net/~igerasim/8216413/00/webrev/ Thanks in advan

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"

Hi Rob, Thanks for fixing this issue, please use hostname.isEmpty(), instead of "".equal(hostname). I have a question to you, why we are converting null to empty string("") in LdapDnsProvider ?. If you see the java doc it tells that domainname can be null /** * Construct an LdapDnsProvi

Re: [12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class

Looks good to me. On 1/8/19 11:16 PM, Naoto Sato wrote: Hello, Please review the change for the following issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 The proposed changeset is located at: http://cr.openjdk.java.net/~nao

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

Thanks Phillipp, I had already updated the test to account for both scenarios. I will push out the webrev tomorrow Best Lance > On Jan 8, 2019, at 7:17 PM, Philipp Kunz wrote: > > Manifest.read throws an exception with the jar file name passed to the > constructor the manifest was construct

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

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 construction with read and will be used by subsequent

Re: RFR (XS) 8210788 : Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero

Hi Ivan, Both the CSR and the code review look fine. Thanks, Roger On 01/08/2019 01:16 PM, Ivan Gerasimov wrote: Hello! It is a minor javadoc editing to cover the case thread.join(0, 0). Currently, the documentation may give a wrong impression that such a call will not block execution of th

Feature suggestion: Add support to Base64.Encoder and Base64.Decoder to wrap Writer / Reader

Java 8 added Base64 with its nested classes Encoder and Decoder. These both have methods to wrap an OutputStream / InputStream respectively. However, base64 is text; the alphabets exist out of ASCII characters only. This is (somewhat) acknowledged by the presence of the encodeToString(byte[]) a

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Usually when we add defaults to Collection interfaces, we provide efficient implementations for the several dozen primary JDK implementations. On 1/8/2019 11:16 AM, some-java-user-99206970363698485...@vodafonemail.de wrote: Would this method then be useful enough if the default implementation

RFR (XS) 8210788 : Javadoc for Thread.join(long, int) should specify that it waits forever when both arguments are zero

Hello! It is a minor javadoc editing to cover the case thread.join(0, 0). Currently, the documentation may give a wrong impression that such a call will not block execution of the current thread at all. Would you please help review the fix and CSR? BUGURL: https://bugs.openjdk.java.net/browse

Re: [PATCH] for error message not containing file name of jar with bad manifest

In this case, the caller is passing in the filename through the public JarFile API so as long as it is not modified it should be ok. The concerns I raised previously are situations where the caller did not pass in the file or the JDK converts a relative path to an absolute path, which could rev

Re: [12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class

Hi Naoto, Looks fine. Roger On 01/08/2019 12:46 PM, Naoto Sato wrote: Hello, Please review the change for the following issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 The proposed changeset is located at: http://cr.openj

[12] RFR: 8216176: Clarify the singleton description in j.t.c.JapaneseEra class

Hello, Please review the change for the following issue: Issue: https://bugs.openjdk.java.net/browse/JDK-8216176 CSR: https://bugs.openjdk.java.net/browse/JDK-8216177 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216176/webrev.00/ This is a simple one line change th

[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"

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 gets passed to StartTlsResponseImpl.verify. Unfortunately StartTlsResponseImpl.verify only expects null values. Since null and the empty String ar

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

Hi Andrew, See [1]/[2] for the background of the fix. I would say jdk11 behavior is correct and expected :-) anyway, it's a  behavior change, so probably will not be easily to go back into jdk8. Regards, Sherman [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-June/006957

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Would this method then be useful enough if the default implementation is that inefficient (in case you only want to get a nullable value)? > Brian Goetz hat am 8. Januar 2019 um 16:57 > geschrieben: > > > Here's a default implementation that returns the actual key: > >    default Optional>

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Here's a default implementation that returns the actual key:    default Optional> getEntry(K key) {    for (Map.Entry e : entrySet) {    if (Objects.equals(key, e.getKey())    return Optional.of(e);    }    return Optional.empty();    } On 1/8/2019 10:50 AM, some

Re: Feature suggestion: Provide efficient way for nullable value lookup in Map

Yes it is now possible to implement the methods `getKey(Object key)` and `getEntry(Object key)` requested by JDK-6552529 as default methods, however both would have to include that "The default implementation returns the provided key. Overriding implementations may return the actual key used b

Re: [PATCH] for error message not containing file name of jar with bad manifest

Hi, Even though this is a bug fix, the security concerns about putting the full pathnames of files in exceptions should be considered.  I would be fine with putting only the filename (no path) in the message. If a typo is in scope:  line 89 "occured" -> "occurred". Thanks, Roger On 01/08/2

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

Thanks Roger, I hadn't seen those existing bugs, so following that trail I get to: https://bugs.openjdk.java.net/browse/JDK-8189343 JDK-8189343: Change of behavior of java.util.regex.Pattern between JDK 8 and JDK 9 Which was resolved as "Not an issue", as the related fix to 6609854 you refer to

Re: [PATCH] for error message not containing file name of jar with bad manifest

Hi Philipp, I created JDK-8216362 and will look to address later today or tomorrow Best Lance > On Jan 8, 2019, at 1:24 AM, Philipp Kunz wrote: > > Hi Lance, > > I also see fit for a new bug. But I cannot create it now because I cannot log > in to Jira and don't know how else to create one an

Re: RFR: 8215995: Add specialized toArray methods to immutable collections

On 2019-01-08 03:44, Stuart Marks wrote: This is one of Stuart's designs Trying to blame it all on me, aren't you? :-) Yes: you are being too nice! :-) Overall the changes look good. Thanks! I can't really speak to how to improve the loops in certain circumstances (the "tricky circul

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

Technically, another option would be to have Java standardize a meaning, and I take it you're not mentioning that because of the performance implications? On Tue, Jan 8, 2019 at 2:37 AM John Rose wrote: > As I think you expect, isSubstitutible(x,y) will mean that x and y are > equivalent > for a

RE: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Alan, Volker, thanks for bringing up these discussion points. I agree that we shall carefully revisit that. First of all, I'd like to point out that PosixFileAttributeView::readAttributes won't ever throw UOE with the proposed changes to zipfs. It should always return an object of type Posi