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

Hello! When a WeakHashMap is constructed from another Map m, then the initial capacity is calculated as (int) (m.size() / DEFAULT_LOAD_FACTOR) + 1. For large values of m.size() this becomes negative due to integer overflow. The result is that the WeakHashMap is initially constructed with the

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Roger, +1 Have a great weekend! Best Lance > On Jul 13, 2018, at 4:38 PM, Roger Riggs wrote: > > Hi Lance, > > Updated in place with your suggestion. > http://cr.openjdk.java.net/~rriggs/webrev-process-8189717/ > > Thanks, Roger > > On 7/13/2018 4:31 PM, Lance Andersen wrote: >> Hi Roger

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Lance, Updated in place with your suggestion. http://cr.openjdk.java.net/~rriggs/webrev-process-8189717/ Thanks, Roger On 7/13/2018 4:31 PM, Lance Andersen wrote: Hi Roger, On Jul 13, 2018, at 3:48 PM, Roger Riggs > wrote: Hi Lance, How about: Subsequent m

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Roger, > On Jul 13, 2018, at 3:48 PM, Roger Riggs wrote: > > Hi Lance, > > How about: > Subsequent modifications to any of {@code builder}s will not affect > the returned {@link Process}. ….. to any of the specified builders …. At a minimum, you need ‘the’ added to the above > Roger > >

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Lance, How about: Subsequent modifications to any of {@code builder}swill not affect the returned {@link Process}. Roger On 7/13/2018 3:26 PM, Lance Andersen wrote: Hi Roger, I am struggling with the wording at: ——— * Subsequent modifications to any of process builders in the {@code

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Roger, +1 Brian On Jul 13, 2018, at 12:07 PM, Roger Riggs wrote: > Please review a doc change to improve the description of > ProcessBuilder.startPipeline. > The clarifications are not intended to imply any change in behavior and only > focus the description > on the steps taken for each

Re: RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Hi Roger, I am struggling with the wording at: ——— * Subsequent modifications to any of process builders in the {@code builders} 1198 * argument will not affect the returned {@link Process}. Maybe specified/provided process builders Not sure, will think about it a bit. Otherwise

RFR 8189717: Too much documentation of ProcessBuilder.start copied to ProcessBuilder.startPipeline

Please review a doc change to improve the description of ProcessBuilder.startPipeline. The clarifications are not intended to imply any change in behavior and only focus the description on the steps taken for each command in the pipeline. (A CSR will be needed also when the wording is finalized)

Re: javac --release 11 not support by jdk 12

Hi Remi, On 7/13/2018 11:31 AM, Remi Forax wrote: There is a weird bug with javac of jdk 12. /usr/jdk/jdk-12/bin/javac --release 11 error: release version 11 not supported Usage: javac use --help for a list of possible options while javac --release 10 or javac --release 12 works ? That is

Re: javac --release 11 not support by jdk 12

Remi, This should go to compiler-dev. It requires an update to make the historical data available for an earlier release. -- Jon On 07/13/2018 11:31 AM, Remi Forax wrote: There is a weird bug with javac of jdk 12. /usr/jdk/jdk-12/bin/javac --release 11 error: release version 11 not support

javac --release 11 not support by jdk 12

There is a weird bug with javac of jdk 12. /usr/jdk/jdk-12/bin/javac --release 11 error: release version 11 not supported Usage: javac use --help for a list of possible options while javac --release 10 or javac --release 12 works ? Rémi

Re: RFR: 8206863: A closed JarVerifier.VerifierStream should throw IOException

Looks good to me. > From: Martin Buchholz > Date: Mon, Jul 9, 2018 at 11:17 AM > Subject: RFR: 8206863: A closed JarVerifier.VerifierStream should throw > IOException > To: core-libs-dev , Xueming Shen < > xueming.s...@oracle.com>, Tobias Thierer > > > Here's another fix from Tobias and myself:

Re: RFR(S): 8207233: Minor improvements of jdk C-coding

font change .. and all the rest look fine to me. -phil. On 7/13/18, 8:40 AM, Lindenmaier, Goetz wrote: Hi Roger, Thanks for looking at this! Since the assignment is done in both branches of the if, it could be moved up. You're right, that's better. Done. Best regards, Goetz. ---

RE: RFR(S): 8207233: Minor improvements of jdk C-coding

Hi Roger, Thanks for looking at this! > Since the assignment is done in both branches of the if, it could be > moved up. You're right, that's better. Done. Best regards, Goetz. > -Original Message- > From: core-libs-dev On Behalf > Of Roger Riggs > Sent: Friday, July 13, 2018 5

Re: RFR(S): 8207233: Minor improvements of jdk C-coding

Hi Goetz, Thanks for the cleanup; looks fine with or without the suggestion below. src/jdk.crypto.ec/share/native/libsunec/impl/ecl_mult.c: 84, 89    Since the assignment is done in both branches of the if, it could be moved up. Regards, Roger On 7/13/2018 6:54 AM, Lindenmaier, Goetz wrote:

RFR(S): 8207233: Minor improvements of jdk C-coding

Hi, I ran coverity on the jdk11 jdk sources and want to propose the following fixes. I scanned the linux x86_64 build. Some issues are similar to previous parfait fixes (check for NULL). I also identified some issues I consider real problems. If you think some are tooo conservative, I'm happy

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

Hi Chris, latest webrev looks good to me, thanks for explanation about copyright date. Thanks, Vyom On Friday 13 July 2018 11:44 AM, Chris Yin wrote: Hi, Vyom Thank you for the review and comments, update webrev as below and comment inline webrev: http://cr.openjdk.java.net/~xyin/8198882