Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

Looks good to me too. Would you want to update the Copyright year? For the apache file (ToStream.java), it would also be good to update the @LastModified tag. Thanks, Joe On 2/23/2018 12:33 PM, Roger Riggs wrote: There are two more changes in the java.xml package. (Thanks Joe) Webrev

[11] RFR JDK-8198653: ClassLoader::getSystemClassLoader throws InternalError when called after shutdown

JDK-8198249 added a new shutdown VM initLevel. ClassLoader::getSystemClassLoader should be updated to handle the new case. I checked all other callers of VM::initLevel and no other place needs update. Thanks Mandy diff --git a/src/java.base/share/classes/java/lang/ClassLoader.java

Re: RFR: Here are some URLClassPath patches

[+Paul] On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman wrote: > > 8198484: URLClassPath should use an ArrayDeque instead of a Stack > http://cr.openjdk.java.net/~martin/webrevs/jdk/URLClassPath-ArrayDeque/ > https://bugs.openjdk.java.net/browse/JDK-8198484 > > Can

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

Hello, A few initial comments, not my final review. Objects implementing the AnnotatedElement interface are also created in javac during annotation processing. As a secondary concern, it would be good to be have behavior between both javac and runtime annotations consistent when possible.

Re: RFR: 8197901: Crash during GC when logging level is debug

Thank you for review. I will add @bug info in the test. Leonid > On Feb 22, 2018, at 8:26 PM, David Holmes wrote: > > Hi Leonid, > > Looks fine. Please also add this bug id to @bug in > > test/jdk/java/lang/StackWalker/VerifyStackTrace.java > > Thanks, > David > >

Re: RFR: Here are some URLClassPath patches

On Fri, Feb 23, 2018 at 6:28 AM, Alan Bateman wrote: > Just getting to the updated webrev now. > > On 21/02/2018 20:30, Martin Buchholz wrote: > > : > > > 8198480: Improve ClassLoaders static init block >

RFR JDK-8187653: Lock in CoderResult.Cache becomes performance bottleneck

Hi, Please help review the proposed change to remove the potential performance bottleneck in CoderResult caused by the "over" synchronization the cache mechanism. issue: https://bugs.openjdk.java.net/browse/JDK-8187653 webrev: http://cr.openjdk.java.net/~sherman/8187653/webrev Notes: While the

Re: [11] RFR JDK-8198653: ClassLoader::getSystemClassLoader throws InternalError when called after shutdown

Looks good. Is there an existing test that caught this? Thanks, David On 24/02/2018 7:57 AM, mandy chung wrote: JDK-8198249 added a new shutdown VM initLevel. ClassLoader::getSystemClassLoader should be updated to handle the new case.  I checked all other callers of VM::initLevel and no

Re: [11] RFR JDK-8198653: ClassLoader::getSystemClassLoader throws InternalError when called after shutdown

Yes, test/hotspot/jtreg/compiler/jvmci/events/JvmciShutdownEventTest.java. This test passes with the change. Mandy On 2/23/18 10:18 PM, David Holmes wrote: Looks good. Is there an existing test that caught this? Thanks, David On 24/02/2018 7:57 AM, mandy chung wrote: JDK-8198249 added a

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

On 23/02/2018 15:28, Peter Levart wrote: Hi Adam, Did you know that native memory is already tracked on the Java side for direct ByteBuffers? See class java.nio.Bits. Could you make use of it? Right, these are the fields that are exposed at runtime via BufferPoolMXBean. A SA based tool

Re: RFR 8181594: Efficient and constant-time modular arithmetic

ArrayUtil.java: === I'm not very sure how widely this utilities will be used in the future. Looks like only BigIntegerModuloP uses this classes. I may prefer to define private methods for byte array swap in BigIntegerModuloP. BigIntegerModuloP.java: === As

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

On 22/02/2018 23:20, Liam Miller-Cushon wrote: Hello, Please consider this fix for JDK-7183985. bug: https://bugs.openjdk.java.net/browse/JDK-7183985 webrev: http://cr.openjdk.java.net/~cushon/7183985/webrev.01/ I started a CSR for the change:

Re: [11] RFR JDK-8060094: java/util/Formatter/Basic.java failed in tr locale

+1 Naoto On 2/23/18 12:33 AM, Nishit Jain wrote: Thanks Naoto, Please check the updated webrev http://cr.openjdk.java.net/~nishjain/8060094/webrev.04/ Edits made: In FormatLocale.java, clarified the exception messages about the locale used and removed an unused import. Regards, Nishit

Re: [11] RFR JDK-8060094: java/util/Formatter/Basic.java failed in tr locale

Thanks Naoto, Please check the updated webrev http://cr.openjdk.java.net/~nishjain/8060094/webrev.04/ Edits made: In FormatLocale.java, clarified the exception messages about the locale used and removed an unused import. Regards, Nishit Jain On 23-02-2018 00:56, Naoto Sato wrote: Hi Nishit,

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Hi Adam, Did you know that native memory is already tracked on the Java side for direct ByteBuffers? See class java.nio.Bits. Could you make use of it? Regards, Peter On 23 Feb 2018 1:09 pm, "Adam Farley8" wrote: > Hi Paul, > > The larger picture for (read: effect of)

Re: [PATCH] Optimization of AbstractStringBuilder.ensureCapacityInternal()

Hi Claes, indeed, seems that this change breaks the zeroing optimization, so ensureCapacityInternal() becomes slower when the char count is comparable with the array length. Thanks. On 22 February 2018 at 18:35, Claes Redestad wrote: > Hi, > > interesting - do you

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

On 2/23/2018 9:39 AM, Alan Bateman wrote: On 22/02/2018 23:20, Liam Miller-Cushon wrote: Hello, Please consider this fix for JDK-7183985. bug: https://bugs.openjdk.java.net/browse/JDK-7183985 webrev: http://cr.openjdk.java.net/~cushon/7183985/webrev.01/ I started a CSR for the change:

RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). It uses the line separator from System instead of looking it up in the properties each time. Also fixed one javadoc @see reference. The affected files are in several packages:

Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

Looks good Roger > On Feb 23, 2018, at 2:39 PM, Roger Riggs wrote: > > Please review cleanup replacements of System.getProperty("line.separator") > with System.lineSeparator(). > It uses the line separator from System instead of looking it up in the > properties each

JDK-6372077: JarFile.getManifest() should handle manifest attribute names up to 70 bytes

Please review this contribution from Philipp Kunz to handle manifest attribute names up to 70 bytes. The change passes the available regression tests. Manifest handling is somewhat sensitive so an additional review is appreciated. Webrev: (rebased from the original patch of 2/22/18)    

Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

Looks fine to me. Thanks! Xuelei On 2/23/2018 11:39 AM, Roger Riggs wrote: Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). It uses the line separator from System instead of looking it up in the properties each time. Also fixed one

Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

+1 On 02/23/2018 11:39 AM, Roger Riggs wrote: Please review cleanup replacements of System.getProperty("line.separator") with System.lineSeparator(). It uses the line separator from System instead of looking it up in the properties each time. Also fixed one javadoc @see reference. The

Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

There are two more changes in the java.xml package. (Thanks Joe) Webrev updated in place.   http://cr.openjdk.java.net/~rriggs/webrev-line-separator-8198645/ Thanks, Roger On 2/23/2018 2:50 PM, Xueming Shen wrote: +1 On 02/23/2018 11:39 AM, Roger Riggs wrote: Please review cleanup

Re: RFR 8198645 Use System.lineSeparator() instead of getProperty("line.separator")

still looks good > On Feb 23, 2018, at 3:33 PM, Roger Riggs wrote: > > There are two more changes in the java.xml package. (Thanks Joe) > Webrev updated in place. > > http://cr.openjdk.java.net/~rriggs/webrev-line-separator-8198645/ > > Thanks, Roger > > On

Re: [PATCH] RFR Bug-pending: Enable Hotspot to Track Native Memory Usage for Direct Byte Buffers

Hi Paul, The larger picture for (read: effect of) these changes is best explained in my email here: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051441.html See the hyperlink I posted, and the few lines before it. Unfortunately the only understanding I have regarding the

RE: RFR (XS): 8198539: Cleanup of unused imports in java/util/jar/Attributes.java (java.base) and JdpController.java (jdk.management.agent)

Thanks, Thomas. From: Thomas Stüfe [mailto:thomas.stu...@gmail.com] Sent: Donnerstag, 22. Februar 2018 09:54 To: Langer, Christoph Cc: Java Core Libs ; serviceability-...@openjdk.java.net; andrew_m_leon...@uk.ibm.com Subject: Re: RFR

Re: RFR: Here are some URLClassPath patches

Just getting to the updated webrev now. On 21/02/2018 20:30, Martin Buchholz wrote: : 8198480: Improve ClassLoaders static init block http://cr.openjdk.java.net/~martin/webrevs/jdk/ClassLoaders-static/