Re: RFR: JDK-8222373 Improve CDS performance for custom class loaders

On 20/06/2019 02:36, yumin qi wrote: Hi, Please review: bug: https://bugs.openjdk.java.net/browse/JDK-8222373 webrev: http://cr.openjdk.java.net/~minqi/8222373/01/ To load shared class from CDS, first class file stream is read from jar file, then load the class with the stream. In vm, the stream

Re: [14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

Hi Vladimir, Indeed these are test issues that the tests will need to grant permissions to jdk.internal.vm.compiler as the default policy grants. Thanks for going extra miles to fix the tests. My suggestion may be a bit general.  What I intend to say the custom security policy should extend the

[14] RFR(M) 8185139: [Graal] Tests which set too restrictive security manager fail with Graal

http://cr.openjdk.java.net/~kvn/8185139/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8185139 For Graal to work we have to give Graal module all permissions which is specified in default policy [1]. Unfortunately this cause problem for Graal running tests which overwrite default policy.

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

On 6/19/2019 6:26 PM, Alexander Matveev wrote: Hi Andy, 1) Looks like you forgot to update HelpResources_ja.properties and HelpResources_zh_CN.properties. Yes I need to re-run my script to update these. 2) http://cr.openjdk.java.net/~herrick/8225428/webrev.01/src/jdk.jpackage/share/class

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

Hi Andy, 1) Looks like you forgot to update HelpResources_ja.properties and HelpResources_zh_CN.properties. 2) http://cr.openjdk.java.net/~herrick/8225428/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties.frames.html Line 84: Error: creating ap

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

On 6/19/2019 2:08 PM, Alexey Semenyuk wrote: http://cr.openjdk.java.net/~herrick/8225428/webrev.01/test/jdk/tools/jpackage/JPackageMissingArgumentsTest.java.sdiff.html: --- private static final String [] RESULT_7 = {"--module-path", "--runtime-image", "app-image"}; --- Should it be "--app-

Re: RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

http://cr.openjdk.java.net/~herrick/8225428/webrev.01/test/jdk/tools/jpackage/JPackageMissingArgumentsTest.java.sdiff.html: --- private static final String [] RESULT_7 = {"--module-path", "--runtime-image", "app-image"}; --- Should it be "--app-image"? - Alexey On 6/19/2019 1:34 PM, Andy Herri

RFR: JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). JDK-8225428: CLI change to remove "mode", rename to "package", and build only one target [1] https://bugs.openjdk.java.net/browse/JDK-8225428 [2] ht

Re: RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1

Hi Sean, +1 > On Jun 19, 2019, at 12:29 PM, Seán Coffey wrote: > > Reports that this test is failing intermittently over past few months. It's a > rare occurrence but I'd like to take steps to correct it. > > I've removed the dependence on randomness in the bug. > I've fixed up the zip file cr

RFR: 8213561: ZipFile/MultiThreadedReadTest.java timed out in tier1

Reports that this test is failing intermittently over past few months. It's a rare occurrence but I'd like to take steps to correct it. I've removed the dependence on randomness in the bug. I've fixed up the zip file creation logic to produce a real zip file I've renamed the file to a unique fil

Re: RFR(XS): 8226286 Remove unused method java.lang.Integer::formatUnsignedInt

+1 Thanks, Brian > On Jun 19, 2019, at 4:49 AM, Claes Redestad wrote: > > On 2019-06-19 07:28, Tagir Valeev wrote: >> Hello, Brian! >> Thank you for review. Here's updated version: >> http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r2/ >>

Re: [PATCH] Use StringJoiner where appropriate in java.base

Hi, On 6/19/19 2:12 PM, Сергей Цыпанов wrote: > in JDK code base we have many places (mainly in j.u.Arrays) where we > convert array to String using verbose constructions with > StringBuilder. > > As far as we have got StringJoiner for a long time we can use it > making the code more simple. >

[PATCH] Use StringJoiner where appropriate in java.base

Hello, in JDK code base we have many places (mainly in j.u.Arrays) where we convert array to String using verbose constructions with StringBuilder. As far as we have got StringJoiner for a long time we can use it making the code more simple. Also toString() of AtomicIntegerArray, AtomicLongArr

Re: RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

On 19/06/2019 11:07, Andrew Dinn wrote: : Do I still need to wait for confirmation for the CSR from Joe Darcy before pushing to the jdk13 repo? (He already knows about the CSR). Yes, anything that has a CSR needs to wait until it is approved. -Alan

Re: RFR(XS): 8226286 Remove unused method java.lang.Integer::formatUnsignedInt

Hi Tagir, On 2019-06-19 07:28, Tagir Valeev wrote: Hello, Brian! Thank you for review. Here's updated version: http://cr.openjdk.java.net/~tvaleev/webrev/8226286/r2/ this looks like a good cleanup! It's partly my fault that these format methods ended up a bit messy. I exposed some of the int

RE: Suggestion for a more sensible implementation of EMPTY_MAP

Hi Abraham Wouldn’t it have been possible to use Map::isEmpty? Ideally just returning at the very beginning of your method if `data` is an empty Map. That way you’d still be able to use computeIfPresent, and use emptyMap() as well. Kind regards, Anthony

Re: RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

On 19/06/2019 11:03, Alan Bateman wrote: > I added myself as Reviewer to the the CSR so you can finalize. The > webrev looks good. Thanks, Alan. I have finalized the CSR. Do I still need to wait for confirmation for the CSR from Joe Darcy before pushing to the jdk13 repo? (He already knows about t

Re: RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

On 19/06/2019 10:21, Andrew Dinn wrote: : I raised this CSR: CSR:https://bugs.openjdk.java.net/browse/JDK-8226385 and tagged it for jdk13. Also, I labelled it SE -- but is it, perhaps, meant to be JDK? (apologies, I am still a noob to this process). Yes, it's "SE" as it's normative tex

Re: RFR (T): 8226203: MappedByteBuffer.force method may have no effect on implementation specific map modes

Hi Alan, On 18/06/2019 18:08, Alan Bateman wrote: > This looks good. Will you create a CSR for this? I think it can be fixed > in jdk/jdk13 as it follows JDK-8221397 and JDK-8221696 (and there is no > risk as it's javadoc only). I raised this CSR: CSR:https://bugs.openjdk.java.net/browse/JD

Re: Suggestion for a more sensible implementation of EMPTY_MAP

Hi Stuart, Roger, First of all, thank you for such a detailed response, this really shows the big picture. I guess no implementation will be perfect, there will always be some wrinkles that we need to accept, and the most suitable implementation will be the one with the fewest or least impactin