Re: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562

> On May 9, 2019, at 1:47 PM, Roger Riggs wrote: > > Hi Bob, > > jdk/internal/platform/cgroupv1/SubSystem.java: > 64: Is that the same as cgroupPath.startsWith(root)? That might be slightly > more readable. > Sure, that works. I’ll change it. > Regardless, that looks fine. > Thanks,

Re: RFR 8223593 : Refactor code for reallocating storage

Thank you Pavel for careful review. On 5/9/19 5:09 AM, Pavel Rappo wrote: Ivan, Many thanks for doing this! This code is both error-prone and abundant in the JDK, which indeed makes it a perfect candidate for refactoring. Since that particular change touches quite a few foundational parts of

Re: RFR: 8221340 - [TESTBUG] TestCgroupMetrics.java fails after fix for JDK-8219562

Hi Bob, jdk/internal/platform/cgroupv1/SubSystem.java: 64: Is that the same as cgroupPath.startsWith(root)?  That might be slightly more readable. Regardless, that looks fine. Roger On 05/08/2019 10:24 AM, Bob Vandette wrote: Thanks Misha! Could I get a “Review” from someone in core libs,

Re: Inno setup 6 broke javapacker/jpackage

Although we plan to remove dependency on Inno Setup in the future, if that is not done soon after initial integration we can fix this in WinExeBundler.java by handling this case.  I will add line item to one of the post integration fix CR's to do this. Thanks. /Andy On 5/9/2019 12:19 PM,

Re: RFR(JDK 13/java.xml) 8222991: Xerces 2.12.0: Validation

Thanks Lance! I re-ran all of tests (inc JCK), they all still pass. Pushed the patch now. Best, Joe On 5/8/19, 1:30 PM, Lance Andersen wrote: Hi Joe, Sorry for the delay. The patch looks good. Best Lance On Apr 29, 2019, at 6:03 PM, Joe Wang > wrote:

Inno setup 6 broke javapacker/jpackage

On 2019-04-27 jrsoftware release innosetup-6.0.2.exe. I am using the old javapackager and I see that it perform a check to version 5 or newer. But it check the version by looking for a number in the output of iscc /? wich now return Nothing in version 6 and iscc is detected as version 0. By

Problem with jpackage/Windows and using a different runtime

Hi, I downloaded the jpackage EA version from https://jdk.java.net/jpackage/ for some tests and I run into problems when using a different runtime (OpenJDK12) on Windows. This is my setting: OpenJDK12 installed in c:\Program Files\OpenJDK12 OpenJDK13 with jpackage installed c:\Program

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi, Goetz. The error messages using "cannot", the preferred word according to the Chicago Manual of Style [0], look good to me. Thanks, Iris [0] https://www.chicagomanualofstyle.org/qanda/data/faq/topics/Usage/faq0010.html -Original Message- From: Lindenmaier, Goetz Sent: Thursday,

Re: [13]RFR 8222969 : Migrate RuleBasedCollatorTest to JDK Repo

Looks good. Please add "noreg-self" label to the issue. Naoto On 5/8/19 10:01 PM, Ying Zhou wrote: Hello, Please help to review this patch for migrating RuleBasedCollatorTest from Tong to Jtreg. Bug: https://bugs.openjdk.java.net/browse/JDK-8222969 webrev:

Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

Hi Christoph, I'm only commenting on the HttpClient changes, I'll let others comment on the other changes... http://cr.openjdk.java.net/~clanger/webrevs/8223553.0/src/java.net.http/share/classes/jdk/internal/net/http/ExchangeImpl.java.udiff.html I have a profound dislike for using

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

Hi Alan, I've got a new iteration for the zipfs POSIX support and addressed your concerns: http://cr.openjdk.java.net/~clanger/webrevs/8213031.9/ The new change bases on the proposal for JDK-876, which I created to factor out changes unrelated to POSIX to facilitate easier reviewing of

RE: RFR: 8222276: (zipfs) Refactoring and cleanups to prepare for JDK-8213031

Hi, after exchanging a few mails with Lance, I have a new version ready: http://cr.openjdk.java.net/~clanger/webrevs/876.2/ I stepped back from changing the class hierarchy for ZipFileSystem.IndexNode and ZipFileSystem.Entry. It’s not a prerequisite for my current proposal for JDK-8213031

Re: RFR 8223593 : Refactor code for reallocating storage

Ivan, Many thanks for doing this! This code is both error-prone and abundant in the JDK, which indeed makes it a perfect candidate for refactoring. Since that particular change touches quite a few foundational parts of the libraries I felt the urge to make sure the change doesn't introduce any

Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer

Thanks Jim! /Claes On 2019-05-09 13:47, Jim Laskey wrote: +1 On May 8, 2019, at 11:49 AM, Claes Redestad wrote: Hi, yet another String concat startup/footprint optimization. As the subject implies, we could fold the initialLengthCoder it into the final mixer. This way we end up with one

Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer

+1 > On May 8, 2019, at 11:49 AM, Claes Redestad wrote: > > Hi, > > yet another String concat startup/footprint optimization. > > As the subject implies, we could fold the initialLengthCoder it into the > final mixer. This way we end up with one less bound argument into the > larger method

Re: RFR: 8223454: Reduce String concatenation shapes by folding initialLengthCoder into last mixer

To give some context ("Why are you doing this to us?!") I've extracted a few simple concatenation expressions (most of these are commonly seen in the JDK sources) to create a reasonably realistic test to assess String concat bootstrap overheads[1] (timings for a simple noop and difference

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi, here a webrev which uses 'cannot'. Nothing else changed. http://cr.openjdk.java.net/~goetz/wr19/8218628-exMsg-NPE/10-cannot/ Best regards, Goetz. > -Original Message- > From: Lindenmaier, Goetz > Sent: Donnerstag, 9. Mai 2019 08:55 > To: coleen.phillim...@oracle.com; Schmelter,

RE: RFR(L): 8218628: Add detailed message to NullPointerException describing what is null.

Hi, > Cannot is apparently preferable in English. OK, changed. Best regards, Goetz. > -Original Message- > From: coleen.phillim...@oracle.com > Sent: Mittwoch, 8. Mai 2019 17:32 > To: Lindenmaier, Goetz ; Schmelter, Ralf > ; Java Core Libs ; >

RE: RFR(trivial): 8222394: HashMap.compute() throws CME on an empty Map if clear() called concurrently

> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-May/060068.html Thanks for sharing this thread. I saw Pavel's comments: "I believe it should be incremented on an attempt to modify the collection, rather than on the effective result of that attempt" It can be true for bulk