Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Shilpi, _CLASS suffix looks redundant and you can abbreviate LAMBDA_FORM to LF: LF_HIDDEN_SIG LF_COMPILED_SIG FORCEINLINE_SIG DONTINLINE_SIG Otherwise, looks fine. Best regards, Vladimir Ivanov On 2/17/16 5:47 PM, shilpi rastogi wrote: Hi All, Please review fix for the following

Re: RFR[9u-dev] 8130425: libjvm crash due to stack overflow in executables with 32k tbss/tdata

Hi Cheleswer, Looks good to me. Thanks Kevin (Also, as one of the comments was that there may be no real cost to using default stack sizes here (on most systems...?), having jdk.lang.processReaperUseDefaultStackSize gives us a way to test that widely, and one day the 32k may be able to

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Thank You Vladimir! I have done the changes. Please review the updated patch- http://cr.openjdk.java.net/~srastogi/8144931/webrev.02/ Regards, Shilpi On 2/18/2016 1:58 PM, Vladimir Ivanov wrote: Shilpi, _CLASS suffix looks redundant and you can abbreviate LAMBDA_FORM to LF: LF_HIDDEN_SIG

Re: RFR 9: 8149750 Decouple sun.misc.Signal from the base module

On 16 Feb 2016, at 21:38, Roger Riggs wrote: > Hi Chris, > > Webrev updated in place: >http://cr.openjdk.java.net/~rriggs/webrev-signal-9149750/ Thanks Roger, I’m happy with the source changes. -Chris. > On 2/15/2016 6:22 AM, Chris Hegarty wrote: >> On 12/02/16

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 15/02/2016 16:30, Steve Drach wrote: Thank you Alan. I’ll address the issues you bring up before integration. Thanks. Are you planning to update the webrev too as it would be nice to see the final javadoc? -Alan

RFR [9] 8150163: JarFileSystem support for MRJARs should use the JDK specific Version API

To support MRJARs, currently JarFileSystem uses sun.misc.Version to retrieve the major version. It should be updated to use the new JDK specific Version API. http://cr.openjdk.java.net/~chegar/8150163/ https://bugs.openjdk.java.net/browse/JDK-8150163 -Chris.

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Reviewed. Best regards, Vladimir Ivanov On 2/18/16 2:18 PM, shilpi.rast...@oracle.com wrote: Thank You Vladimir! I have done the changes. Please review the updated patch- http://cr.openjdk.java.net/~srastogi/8144931/webrev.02/ Regards, Shilpi On 2/18/2016 1:58 PM, Vladimir Ivanov wrote:

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

Hi Joe, here is the next version: http://cr.openjdk.java.net/~clanger/webrevs/8149915.2/ Hopefully the final one :-) > Yes, it's good to have some cleanups. For the generic initialization, > it's preferable to have no redundant type arguments, for example, > instead of: > > protected Stack

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

> On 18 Feb 2016, at 12:18, shilpi.rast...@oracle.com wrote: > > Thank You Vladimir! > > I have done the changes. Please review the updated patch- > > http://cr.openjdk.java.net/~srastogi/8144931/webrev.02/ > Looking good. There are also a few other cases in InvokerBytecodeGenerator you can

RE: RFR 8144931: Assert class signatures are correct and refer to valid classes

Hi, just a stupid question from somebody outside the OpenJDK developers: You are already using ASM to generate the class files. Why not also use the Type class in ASM to generate the signatures of a class constant?: Instead of: static final String LF_HIDDEN_SIG =

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Hi Uwe Not a stupid question. We took the conservative approach to preserve the existing costs (avoid linkage and string generation). Paul. > On 18 Feb 2016, at 14:54, Uwe Schindler wrote: > > Hi, > > just a stupid question from somebody outside the OpenJDK

RE: RFR 8144931: Assert class signatures are correct and refer to valid classes

Hi, Thanks! I was expecting something like this. You just want to check the class name in an assertion - that’s fine. Kind regards, Uwe P.S.: You could improve the assertion with the Type class, so it would also fail on otherwise broken descriptor strings (missing "L" or missing ";"):

Re: RFR [9] 8150163: JarFileSystem support for MRJARs should use the JDK specific Version API

On 18/02/2016 12:56, Chris Hegarty wrote: To support MRJARs, currently JarFileSystem uses sun.misc.Version to retrieve the major version. It should be updated to use the new JDK specific Version API. http://cr.openjdk.java.net/~chegar/8150163/ https://bugs.openjdk.java.net/browse/JDK-8150163

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

P.S.: You could improve the assertion with the Type class, so it would also fail on otherwise broken descriptor strings (missing "L" or missing ";"): I like how it shapes out with Type. Thanks, Uwe! Best regards, Vladimir Ivanov static boolean checkClassName(String cn) { Type

Re: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

Thanks for the reviews, David and Alan! Rachel On 2/18/2016 2:48 AM, Alan Bateman wrote: On 17/02/2016 21:21, Rachel Protacio wrote: Hello, everyone, We are moving forward with "JNI_VERSION_9". If it later turns out that it should be "9_0", we will file a separate bug, but the plain 9 is

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

> On 18 Feb 2016, at 15:55, Vladimir Ivanov > wrote: > >> P.S.: You could improve the assertion with the Type class, so it would also >> fail on otherwise broken descriptor strings (missing "L" or missing ";"): > I like how it shapes out with Type. Thanks, Uwe! >

RFR [9] 8150162: Move sun.misc.Version to a truly internal package

sun.misc.Version is the core libraries part of a private interface with the JVM to query and set specific JVM version and capabilities, as well as being responsible for setting the system properties for "java.version”, "java.runtime.version", and "java.runtime.name" ( which are generated during

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> Thank you Alan. I’ll address the issues you bring up before integration. > Thanks. Are you planning to update the webrev too as it would be nice to see > the final javadoc? http://cr.openjdk.java.net/~sdrach/8132734/webrev.07/index.html

Re: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

On 2/18/2016 5:15 AM, Langer, Christoph wrote: Hi Joe, here is the next version: http://cr.openjdk.java.net/~clanger/webrevs/8149915.2/ Looks good! Thanks. Copyright year in XSAttributeChecker.java is still incorrect. I meant to say the year "2016" needs to have a comma, so in this case,

RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with annotation causes NPE

Hi Joe, I fixed the copyright in http://cr.openjdk.java.net/~clanger/webrevs/8149915.3/. So I think I'm done. Can you review and push the change then? Thanks Christoph -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Donnerstag, 18. Februar 2016 19:19 To:

Re: RFR: JDK-8149925 We don't need jdk.internal.ref.Cleaner any more

Hi Peter, Nice to see this improvement. I would support adding the drainQueue method to java.lang.ref.Cleaner; it provides a mechanism to share the cleanup load (as in the case of Direct buffers) that may be useful to other use cases. It is preferable to hacking in to the CleanerImpl.

RE: RFR [9] 8150163: JarFileSystem support for MRJARs should use the JDK specific Version API

Hi, Chris. I think this change looks fine. I've added a note to JDK-8144062 (module for jdk.Version), indicating that parts of this changeset may need to be updated depending on where jdk.Version lands. Thanks, iris -Original Message- From: Chris Hegarty Sent: Thursday, February 18,

JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

Hello, Right now, we are seeing some cross-platform intermittent failures of java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java as noted in bug JDK-8150014. Until that test instability is resolved, the test should be demoted from tier 1 to tier 2. Please see the patch below.

RE: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

Hi, Alan and Rachel. Here's a proposal for the new text for JEP 223: --- [ insert between existing sections "@since..." and "Mercurial..."] JNI Version The [JNI Specification][JNISpec] defines a constant representing the JNI version number. The constant will drop the initial "1" and

Re: RFR 8144931: Assert class signatures are correct and refer to valid classes

Hi All, Please see the updated webrev http://cr.openjdk.java.net/~srastogi/8144931/webrev.03/ Regards, Shilpi On 2/18/2016 8:33 PM, Paul Sandoz wrote: On 18 Feb 2016, at 15:55, Vladimir Ivanov wrote: P.S.: You could improve the assertion with the Type class,

Re: JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

It's easy enough to get the test to pass by delambdafication. But we may not want to fix the test because it's not clear whether it's a jdk lambda bug or not, and we don't sweep bugs under the rug. Maybe instead of a "tier2" bucket we really want a "test found a bug that's not yet fixed" bucket?

Re: JDK 9 RFR of 8150206: Demote LFMultiThreadCachingTest.java to tier 2 until resolution of JDK-8150014

Hi Martin, On 2/18/2016 10:18 PM, Martin Buchholz wrote: It's easy enough to get the test to pass by delambdafication. But we may not want to fix the test because it's not clear whether it's a jdk lambda bug or not, and we don't sweep bugs under the rug. Maybe instead of a "tier2" bucket we

Re: RFR 9: 8149750 Decouple sun.misc.Signal from the base module

On 18/02/2016 11:54 AM, David Holmes wrote: On 18/02/2016 1:49 AM, Roger Riggs wrote: Hi David, On 2/17/2016 3:33 AM, David Holmes wrote: Hi Roger, On 17/02/2016 7:37 AM, Roger Riggs wrote: Hi David, Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-signal-9149750/