Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

Hi Joel, Paul, A coworker ran into the change of behavior here in jdk9. Specifically, we noticed that a local class constructor has a receiver parameter, but getAnnotatedReceiverType returns null. The changed jdk9 spec is actually very clear about that:

Re: [8u-dev] RFR (JAXP) 8028363: XmlGregorianCalendarImpl.getTimeZone() bug when offset is less than 10 minutes

Looks fine to me also Svetlana. Regards, Sean. On 21/07/2016 13:13, Svetlana Nikandrova wrote: Little reminder. On 19.07.2016 19:29, Svetlana Nikandrova wrote: Hello, please review this fix for 8u-dev. For jdk9 problem has been addressed in JEP 255

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

Hi Martin, I'm away from my workstation at the moment, so this is from memory. IIRC a local class is pure scoping and lacks an "outer this" which is what you annotate for constructors. There should not be receiver type to annotate. Since I can't run your code I can't see what's wrong but I might

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

> On Jul 21, 2016, at 1:32 PM, Brian Burkhalter > wrote: > > And the java.desktop description was already checked in so it should be > examined for consistency I suppose. OK, will take a look > > Brian > > On Jul 21, 2016, at 10:03 AM, Alan Bateman

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

This is the first time I noticed the second paragraph of $14.3, strange indeed! I'd ping compiler-dev with this, Alex will probably know if this is a spec bug in $14.3 or just an irregularity. Cheers /Joel On Jul 21, 2016 20:39, "Martin Buchholz" wrote: > Joel, Thanks for

Re: [9] RFR: 8161937: non-ASCII characters in source code comments

Thanks Ivan. I've already pushed the fix, so I created a new one (JDK-8162343) Naoto On 7/21/16 5:59 AM, Ivan Gerasimov wrote: Hi Naoto! I see that the same non-ASCII chars are used in src/java.base/share/native/libjimage/jimage.hpp and in

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Peter, On 7/21/2016 3:42 AM, Peter Levart wrote: Hi Roger, On 07/20/2016 04:44 PM, Roger Riggs wrote: - What is the purpose of the UNDECIDED return? I suspect it is meant to be used in some filter implementation that delegates the validation to some "parent" filter and respects its

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

Joel, Thanks for responding so quickly! Here' s a slightly modified version of my repro recipe: You can see that local classes in instance methods have a receiver type, just like a member inner class. local classes in static methods (naturally!) do not. I expect the two flavors of local classes

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

> On Jul 21, 2016, at 1:03 PM, Alan Bateman wrote: > > On 21/07/2016 17:37, Lance Andersen wrote: > >> I took a stab at the javadoc descriptions for the modules modeled after what >> we discussed for the java.prefs module. >> >> The webrev can be found at

RFR: jsr166 jdk9 integration wave 8

Time for the next round. No spec changes! http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

RE: RFR(s) 8161236: Runtime.Version.{compareTo, equals}IgnoreOpt should be renamed

Hi, Kumar. Thank you very much for pushing the changesets to resolve this bug! Regards. iris From: Iris Clark Sent: Wednesday, July 20, 2016 1:11 PM To: Kumar Srinivasan; Java Core Libs; compiler-...@openjdk.java.net; kulla-...@openjdk.java.net Subject: RFR(s) 8161236:

Re: RFR: jsr166 jdk9 integration wave 8

Hi Martin, On 07/21/2016 09:07 PM, Martin Buchholz wrote: Time for the next round. No spec changes! http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ 86 @SuppressWarnings("unchecked") // can now be removed from AtomicReference.get(), right? Regards, Peter

Re: RFR: JDK-8044629: (reflect) Constructor.getAnnotatedReceiverType() returns wrong value

On 22/07/2016 4:50 AM, Joel Borggrén-Franck wrote: This is the first time I noticed the second paragraph of $14.3, strange indeed! I'd ping compiler-dev with this, Alex will probably know if this is a spec bug in $14.3 or just an irregularity. It is an irregularity - for want of a better word.

Re: RFR: jsr166 jdk9 integration wave 8

Thanks! Done. On Thu, Jul 21, 2016 at 1:45 PM, Peter Levart wrote: > Hi Martin, > > On 07/21/2016 09:07 PM, Martin Buchholz wrote: > > Time for the next round. No spec changes! > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > > 86

Re: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev

> On 21 Jul 2016, at 14:04, Alan Bateman wrote: > > On 21/07/2016 12:40, Paul Sandoz wrote: > >> Hi, >> >> The fix for: >> >> https://bugs.openjdk.java.net/browse/JDK-8161129 >> 8161129 Unsafe::getUnsafe should allow the platform class loader to access >> it >>

Re: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev

> On 21 Jul 2016, at 14:37, David Holmes wrote: > >> >> JDK test changes >> — >> >> diff --git a/test/sun/misc/Safe.java b/test/sun/misc/GetSunMiscUnsafe.java >> rename from test/sun/misc/Safe.java >> rename to test/sun/misc/GetSunMiscUnsafe.java >> ---

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi Nadeesh, Found the changes in http://cr.openjdk.java.net/~ntv/8066806/webrev.09/ Editorial: " Inthe lenient mode,*the *parser will be greedy and parse*the *maximum digits possible." TCKDateTimeFormatterBuilder.java: The lines 1473, 1479, 1485, etc. are way too long, perhaps wrap/break

Re: RFR(XXS): 8161951: 8132379 introduced non ANSI C coding

On Thu, Jul 21, 2016 at 7:49 AM, David Holmes wrote: > Hi Volker, > > On 21/07/2016 4:49 AM, Volker Simonis wrote: >> >> Hi, >> >> can somebody please review the following trivial fix: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8161951/ >>

Re: RFR 9: JEP 290: Filter Incoming Serialization Data

Hi Roger, On 07/20/2016 04:44 PM, Roger Riggs wrote: - What is the purpose of the UNDECIDED return? I suspect it is meant to be used in some filter implementation that delegates the validation to some "parent" filter and respects its decision unless it is UNDECIDED in which case it decides

Re: RFR:JDK-8066806:java.time.format.DateTimeFormatter cannot parse an offset with single digit hour

Hi, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8066806/webrev.08/ Changes in this webrev: For leninent mode , doc change in DateTimeFormatterBuilder.java " In the lenient mode, parser will be greedy and parse maximum digits possible. " Added new test cases for lenient

Re: RFR(s) 8161236: Runtime.Version.{compareTo, equals}IgnoreOpt should be renamed

On 20/07/2016 21:10, Iris Clark wrote: Hi. Please review changes in jdk and langtools (module jdk.jshell) to address the following bug: The rename looks okay to me. -Alan

RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev

Hi, The fix for: https://bugs.openjdk.java.net/browse/JDK-8161129 8161129 Unsafe::getUnsafe should allow the platform class loader to access it broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted. There is an existing test in the JDK repo

Re: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev

Hi Paul, On 21/07/2016 9:40 PM, Paul Sandoz wrote: Hi, The fix for: https://bugs.openjdk.java.net/browse/JDK-8161129 8161129 Unsafe::getUnsafe should allow the platform class loader to access it broke a test in the Hotspot repo test area that i did not realize existed. That test can be

Re: [9] RFR: 8161937: non-ASCII characters in source code comments

Hi Naoto! I see that the same non-ASCII chars are used in src/java.base/share/native/libjimage/jimage.hpp and in src/java.base/share/native/libjimage/imageDecompressor.hpp It might make sense to change them as well. With kind regards, Ivan On 20.07.2016 22:51, Naoto Sato wrote: Hello,

Re: RFR 8161947 runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev

On 21/07/2016 12:40, Paul Sandoz wrote: Hi, The fix for: https://bugs.openjdk.java.net/browse/JDK-8161129 8161129 Unsafe::getUnsafe should allow the platform class loader to access it broke a test in the Hotspot repo test area that i did not realize existed. That test can be deleted.

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Kindly reminder. On 19.07.2016 16:26, Svetlana Nikandrova wrote: Hi Joe, thank you for your replay. As I'm new to javadoc writing feel free to add any comments. Please see updated webrev: http://cr.openjdk.java.net/~snikandrova/8021787/webrev.01/

RE: RFR(s) 8161236: Runtime.Version.{compareTo, equals}IgnoreOpt should be renamed

Hi, Alan. Thanks! iris -Original Message- From: Alan Bateman Sent: Thursday, July 21, 2016 4:36 AM To: Iris Clark; Kumar Srinivasan; Java Core Libs; compiler-...@openjdk.java.net; kulla-...@openjdk.java.net Subject: Re: RFR(s) 8161236: Runtime.Version.{compareTo, equals}IgnoreOpt

RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

I took a stab at the javadoc descriptions for the modules modeled after what we discussed for the java.prefs module. The webrev can be found at http://cr.openjdk.java.net/~lancea/8161965/ Once we reach agreement, will a CCC be needed given this is

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

On 21/07/2016 17:37, Lance Andersen wrote: I took a stab at the javadoc descriptions for the modules modeled after what we discussed for the java.prefs module. The webrev can be found at http://cr.openjdk.java.net/~lancea/8161965/ It's good to

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

Hi Svetlana, It would be good to apply the same format to these get* methods. Please see below. @@ -510,16 +510,16 @@ * @see #getYear() */ public abstract BigInteger getEonAndYear(); /** - * Return number of month or {@link

Re: RFR (JAXP): 8021787: javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documented wrong

The editor of the new version of Thunderbird seems to be troublesome, with missing or added whitespace as a result of copy But when you "@return the hour of dayof this", you know I meant "@return the hour of day of this" :-) Or the double whitespace should have been a single one. -Joe On

Re: RFR 9 8161039 : System.getProperty("os.version") returns incorrect version number on Mac

On 21/07/2016 18:08, Brent Christian wrote: Hi, The fix for 7131356 introduced a minor behavior change in the value of the "os.version" system property on MacOS. On systems running an OS with a patch version of 0, we've started including this in the value of os.version (e.g. "10.11.0"),

Re: RFR 8161965 -> Fwd: JDK 9 RFR of 8161402: Provide a javadoc description for java.prefs module

And the java.desktop description was already checked in so it should be examined for consistency I suppose. Brian On Jul 21, 2016, at 10:03 AM, Alan Bateman wrote: > I think Jon Gibbons is working on text for java.compiler and jdk.compiler so > you might be able to