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

Hi, Roger Thanks a lot for your review and comments, inline and update new webrev as below, please have a review http://cr.openjdk.java.net/~xyin/8198882/webrev.03/ > On 24 Jul 2018, at 1:05 AM, Roger Riggs wrote: > > Hi Chris, > > Sorr

Re: 8143850: retrofit ArrayDeque to implement List

(As usual, I don't have enough time to devote to this at the moment) I sort of like the idea of adding all of those List methods to ArrayDeque, but it's __weird__ for java code to do that, and remove(int) is a problem when you have ArrayDeque, so it will probably end up rejected. --- Similarly,

Re: RFR 8207314 : Unnecessary reallocation when constructing WeakHashMap from a large Map

Thanks Ivan, what you have now looks good for this bug. Capacity bugs are common because they can only be tested via whitebox tests, which are onerous to write. For future work, the HashMap resize seems important enough to fix, and that one may deserve a whitebox test. Explicit NaN checking is d

Re: [12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

Latest hotspot code still has the limit. It's dependent on element type and VM specifics like header size, so we can't just try to see what the limit is empirically and adjust 8 to 2. // Return the maximum length of an array of BasicType. The length can passed // to typeArrayOop::object_size

Re: [12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

On Jul 23, 2018, at 5:26 PM, Martin Buchholz wrote: > I'm the author of most of the MAX_ARRAY_SIZE code in the jdk. > We should be as consistent as we can given the history. Thanks for the history lesson. > It all looks pretty similar. There are in fact a number of them in java.base: pr

Re: [12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

I'm the author of most of the MAX_ARRAY_SIZE code in the jdk. We should be as consistent as we can given the history. It all looks pretty similar. --- +if (minCapacity < 0) // overflow +throw new OutOfMemoryError("Memory capacity overflow: " ++ minCapacity); +

Re: [12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

Hi Roger, Updated version: http://cr.openjdk.java.net/~bpb/8206403/webrev.01/ On Jul 23, 2018, at 2:10 PM, Roger Riggs wrote: > You might want to add an @requires of 8Gb or whatever so the test only runs > on a system it can succeed on. Re-tested and changed to @requires 2g and dropped the @i

Re: [12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

Hi Brian, You might want to add an @requires of 8Gb or whatever so the test only runs on a system it can succeed on. I don't see the @randomness in the test.  (Other than perhaps available heap). ByteArrayOutputStream:121: A message indicating the nature of the error would be useful. In

[12] 8206403: ByteArrayOutputStream hugeCapacity method can return invalid capacity

https://bugs.openjdk.java.net/browse/JDK-8206403 http://cr.openjdk.java.net/~bpb/8206403/webrev.00/ Disallow creating an internal array of size larger than Integer.MAX_VALUE - 8. The change if approved as-is will require a CSR for the @implNote. Thanks, Brian

Re: API for parsing path strings

Hi Roger, The point about early parsing is a weak one, because it would mostly just seem to apply to JDK itself. That being said, a variant of this argument is that it allows folk to choose how to map strings to Paths, e.g. using a custom (non-default) file system, and that argument is more c

Re: API for parsing path strings

Hi Jon, I agree that supporting Paths leads people in the right direction. Two considerations led me to propose the simpler String version first. 1.  Early parsing of paths can occur before the file systems that support Path have been initialized. 2.  There is an additional exception that can oc

Re: API for parsing path strings

Roger, Having written internal library code for both javac and jtreg to do what you suggest, I would support such an API. I note that as well as parsing system properties, it would also be a useful API for command-line tools that accept paths as options. However, I would suggest that it is

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

Hi Chris, Sorry to be late to the review cycle. The use of initializer blocks instead of constructors reduces the readability of the code. A simple fix is to add the constructor declarations ahead of the initializer to make the code more readable. GetAttrsBase: 69: The signature of setMandat

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Thanks for the review Sean, > On 23 Jul 2018, at 16:58, Sean Mullan wrote: > ... >> http://cr.openjdk.java.net/~chegar/8207846/webrev.00/ > > A few nits and wording suggestions in the java.security file: > > "By default, several exception messages do not include potentially sensitive > infor

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

On 7/23/18 6:09 AM, Chris Hegarty wrote: After given this some more thought, I now think that I gave in to the comment to change whitespace handing too easy. While maybe not consistent, with the already inconsistent, whitespace handling in java.security, I think ( for this particular case ) the

Re: [11] RFR: 8206445: JImageListTest.java failed in Windows

On 23/07/2018 16:02, vyom tewari wrote: Hi Srinivas, If runTests() throws exception then  "System.gc()" will not  be invoked. which probably doesn't matter because the test will fail anyway (this issue is about jtreg doing cleanup when the test passes). -Alan

Re: [11] RFR: 8206445: JImageListTest.java failed in Windows

Hi Srinivas, If runTests() throws exception then  "System.gc()" will not  be invoked. Thanks, Vyom On Monday 23 July 2018 07:46 PM, Srinivas Dama wrote: Hi Alan, As discussed in private conversations, I am pushing below fix for the issue. webrev: http://cr.openjdk.java.net/~sdama/8206445/we

Re: RFR: 8207851 JEP Draft: Support ByteBuffer mapped over non-volatile memory

Hi Florian, Thank you for the feedback. Comments inline below (extensive comments in the case of the memory model question - it is complex). regards, Andrew Dinn --- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903

Re: [11] RFR: 8206445: JImageListTest.java failed in Windows

Hi Alan, As discussed in private conversations, I am pushing below fix for the issue. webrev: http://cr.openjdk.java.net/~sdama/8206445/webrev.04/ Bug: https://bugs.openjdk.java.net/browse/JDK-8206445 Ran all mach5 tests successfully. Regards, Srinivas - Original Message - From: alan.ba

RE: Prototype of jpackager in jdk/sandbox [was: Draft JEP proposal: JDK-8200758: Packaging Tool]

Thanks for the insight. @Alexey: Then, how much work do you see in reactivating service bundler? Cheers Jörg -Original Message- From: Kevin Rushforth [mailto:kevin.rushfo...@oracle.com] Sent: Donnerstag, 12. Juli 2018 01:09 To: Buchberger, Joerg ; core-libs-dev@openjdk.java.net Cc: A

Re: RFR [11] 8207846: Generalize the jdk.net.includeInExceptions security property

Sean, > On 20 Jul 2018, at 18:07, Sean Mullan wrote: > > On 7/20/18 11:08 AM, Chris Hegarty wrote: >> This is ambiguous, and needs to be clarified. Surely, it is >> better to use the same wording as the serial filter: >> "Whitespace is significant and is considered part of the value." > > Kind