RE: [12] JDK-8211841 [testbug] sun/nio/cs/OLD/TestIBMDB.java does not compile (aix)

Hi, Our nightly tests with the updated patch are green, too, So I pushed it to 12: http://hg.openjdk.java.net/jdk/jdk12/rev/6b37a7ba9b66 Best regards, Goetz. > -Original Message- > From: core-libs-dev On Behalf > Of Lindenmaier, Goetz > Sent: Thursday, January 10, 2019 10:29 PM > To:

RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi All, I posit that you shouldn't be able to change the contents of a a final field. However, if you use Field.setAccessible(true) before calling Lookup.unreflectSetter(Field), then you can get a MethodHandle that allows you to set the (reflected) value of a static final field. This seems w

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

It's not wrong, it's part of the spec. while most the semantics of the method handle is based on the bytecode semantics, the method unreflect* semantics are based on the java.lang.reflect semantics, so if field.set(object, value) is able to change the value of the field then unreflectSetter(fiel

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 11/01/2019 10:46 pm, Adam Farley8 wrote: Hi All, I posit that you shouldn't be able to change the contents of a a final field. Nice in theory, but not true in practice. However, if you use Field.setAccessible(true) before calling Lookup.unreflectSetter(Field), then you can get a MethodHan

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

- Mail original - > De: "David Holmes" > À: "Adam Farley8" , "core-libs-dev" > > Envoyé: Vendredi 11 Janvier 2019 14:02:06 > Objet: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw > IllegalAccessException for final fields > On 11/01/2019 10:46 pm, Adam Farley8 wro

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

On 11/01/2019 04:16, David Holmes wrote: I see three choices for you here :) 1. Don't try to run all tests under Xcomp but just stick to the "core" sets of tests already tested by others. 2. Fix the given test as outlined. (I tested it on linux-x64 and it fixed the problem.) 3. Exclude th

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi All, First; thanks for responding so quickly. :) Second, it sounds like changing the contents of a final field is acceptable under the spec, but *not* changing the contents of a static final field. The test case uploaded to the bug uses a static final field for the test, so I think we can

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Thanks Alan. On 2019年01月11日 22:14, Alan Bateman wrote: On 11/01/2019 04:16, David Holmes wrote: I see three choices for you here :) 1. Don't try to run all tests under Xcomp but just stick to the "core" sets of tests already tested by others. 2. Fix the given test as outlined. (I tested i

Re: [PATCH] Performance improvement of StringBuilder.append(CharSerquence, int, int)

Hello! Your benchmark tests only one of many possible cases. What if string contains non-latin1 characters? What if many strings are appended to the same string builder? What if you append only one character from the long string? Performance fixes in such widely used class could be introduced only

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Hi, The proposed patch changes the test in a way that is unintended. Adding the infinite loop of gc() and sleep, will change the timeout behavior from the existing timeout of TIMEOUT to the jtreg default timeout of the whole test. Further, it renders the check at lines 114-120 irrelevant sinc

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

Hi Adam, This is indeed a bug.    I suggest to do the check in the checkAccess method closes to where it performs the instance final field check.  Please also add a test case. Mandy On 1/11/19 6:38 AM, Adam Farley8 wrote: Hi All, First; thanks for responding so quickly. :) Second, it soun

RFR 8216401 : Allow "file:" URLs in Class-Path of local JARs

Hi, Please review my change for 8216401[1]. Webrev: http://cr.openjdk.java.net/~bchristi/8216401/webrev-01/ The Class-Path section of the JAR spec[2] states that entries must be relative URLs, however this hasn't been enforced for most of Java's history. There is now code to enforce this, th

Re: 8212620: Provide a mechansim to allow a class/method to request filtering from the stack trace

On 10/01/2019 22:59, Mandy Chung wrote: On 1/10/19 11:30 AM, Rob Spoor wrote: I had an idea that can possibly help solve three issues: * 8212620 Provide a mechansim to allow a class/method to request filtering from the stack trace This RFE is not just about stack trace format and a generic

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

This issue requires a spec change and it's a behavioral change. Field::set on a static final field throws IAE.  Although there are few cases in the world that hack around it, I think the compatibility risk is low in this change. I added a suggested fix in the JBS issue. Mandy On 1/11/19 10:0

Re: JDK 12 RFR of JDK-8213299: runtime/appcds/jigsaw/classpathtests/EmptyClassInBootClassPath.java failed with java.lang.NoSuchMethodException

Drat, you pushed this already. But I wanted to mention a couple style points: On 1/10/19 10:13 PM, Joe Darcy wrote: +    sb.append(Stream.of(argTypes).map(c -> {return (c == null) ? "null" : c.getName();}). +          collect(Collectors.joining(","))); Since argTypes is an array,

[13] RFR: Correct UnicodeDecoder U+FFFE handling

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8216140 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8216140/webrev.00/ This issue was previously discussed in https://bugs.openjdk.java.net/browse/JDK-8150449 and was clo

RFR: JDK-8212780: JEP 343: Packaging Tool Implementation (update 2)

This is the second update to the Request For Review of the implementation of the Java Packager Tool (jpackager) as described in JEP 343: Packaging Tool This webrev corresponds to the second EA build, Build 8 (2019/1/8), posted at http://jdk.j

Re: [13] RFR: Correct UnicodeDecoder U+FFFE handling

Hi Naoto, Looks fine. I don't think it needs to be run in 'othervm' since it does not pollute the VM it is running in. It might run a few milliseconds faster without that.  No updated webrev needed. Regards, Roger On 01/11/2019 02:15 PM, naoto.s...@oracle.com wrote: Hello, Please revie

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field is final? Same for findSetter? This issue seems to be much bigger than just a simple bug fix. A CSR request will need to be filed. David - On 12/01/2019 5:07 a

Re: RFR 8216401 : Allow "file:" URLs in Class-Path of local JARs

On 1/11/19 10:35 AM, Brent Christian wrote: Hi, Please review my change for 8216401[1]. Webrev: http://cr.openjdk.java.net/~bchristi/8216401/webrev-01/ This looks fine to me. Mandy

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 1/11/19 2:38 PM, David Holmes wrote: There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field is final? Same for findSetter? This issue seems to be much bigger than just a simple bug fix. I don't see any issue wit

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Hi Roger, On 12/01/2019 2:22 am, Roger Riggs wrote: Hi, The proposed patch changes the test in a way that is unintended. Adding the infinite loop of gc() and sleep, will change the timeout behavior from the existing timeout of TIMEOUT to the jtreg default timeout of the whole test. Partial

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 12/01/2019 8:47 am, Mandy Chung wrote: On 1/11/19 2:38 PM, David Holmes wrote: There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field is final? Same for findSetter? This issue seems to be much bigger than just a simpl

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 11/01/2019 11:11 pm, Remi Forax wrote: - Mail original - De: "David Holmes" À: "Adam Farley8" , "core-libs-dev" Envoyé: Vendredi 11 Janvier 2019 14:02:06 Objet: Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields On 11

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 1/11/19 3:03 PM, David Holmes wrote: On 12/01/2019 8:47 am, Mandy Chung wrote: On 1/11/19 2:38 PM, David Holmes wrote: There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field is final? Same for findSetter? This issu

Re: RFR: JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp

Thanks David and Roger. On 2019年01月12日 06:52, David Holmes wrote: Hi Roger, On 12/01/2019 2:22 am, Roger Riggs wrote: Hi, The proposed patch changes the test in a way that is unintended. Adding the infinite loop of gc() and sleep, will change the timeout behavior from the existing timeout

Re: RFR: JDK-8216558: Lookup.unreflectSetter(Field) fails to throw IllegalAccessException for final fields

On 12/01/2019 10:13 am, Mandy Chung wrote: On 1/11/19 3:03 PM, David Holmes wrote: On 12/01/2019 8:47 am, Mandy Chung wrote: On 1/11/19 2:38 PM, David Holmes wrote: There seem to be a number of spec issues around this. Shouldn't findStaticSetter say something about what happens when the field