Re: RFR: 8029019: (ann) Optimize annotation handling in core reflection

Hi Peter, On 2017-10-13 12:05, Peter Levart wrote: Forgive me the maybe stupid question, but isn't your proposed code changing semantics because it doesn't check for the first parameter in equals() to be of type java.lang.Object anymore? E.g. like "method.getParameterTypes()[0] ==

Re: RFR 8187772 : JVM crash when currency set on MacOS 10.10 and earlier

Thanks, Naoto. An automated test run looked fine, so I've pushed this change. -Brent On 10/12/17 12:38 PM, Naoto Sato wrote: Looks fine, Brent. Naoto On 10/12/17 11:52 AM, Brent Christian wrote: Hi, Please review my change to prevent a startup crash on earlier versions of MacOS.    

Re: java 9 AKST timezone parsing

Hi, I verified that using java.locale.providers=COMPAT with java 9 makes the AKST to be parsed as America/Juneau Is http://bugreport.java.com/ the correct way to file a jira? Le mer. 11 oct. 2017 à 10:50, Naoto Sato a écrit : > (replying to appropriate aliases, instead

Re: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to the non-existent jmage tool doc

Thanks! Fixed in JIRA. -Sundar On 16/10/17, 6:03 PM, David Holmes wrote: Hi Sundar, Please fix the typo in the bug synopsis: jmage Thanks, David On 16/10/2017 10:22 PM, Sundararajan Athijegannathan wrote: Please review: Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/ Bug:

Re: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to the non-existent jmage tool doc

Hi Sundar, Please fix the typo in the bug synopsis: jmage Thanks, David On 16/10/2017 10:22 PM, Sundararajan Athijegannathan wrote: Please review: Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189262 Thanks, -Sundar

Re: RFR 8189262: jdk.jlink module-info.java javadoc comment refers to the non-existent jmage tool doc

On 16/10/2017 13:22, Sundararajan Athijegannathan wrote: Please review: Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189262 Looks fine.

RFR 8189262: jdk.jlink module-info.java javadoc comment refers to the non-existent jmage tool doc

Please review: Webrev: http://cr.openjdk.java.net/~sundar/8189262/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8189262 Thanks, -Sundar

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

Hi Ogata, I found a problem in my last suggestion. See below... On 10/16/2017 11:36 AM, Peter Levart wrote: On 10/16/2017 11:02 AM, Peter Levart wrote: For example: - let public readObject() / readUnshared() entry and exit points just clear the cached loader (set it to null). An

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

On 10/16/2017 11:02 AM, Peter Levart wrote: For example: - let public readObject() / readUnshared() entry and exit points just clear the cached loader (set it to null). An alternative would be for entry point to save and clear the cached loader while exit point would restore / clear it if

Re: RFR: 8188858: Caching latestUserDefinedLoader() results in ObjectInputStream.readObject()

Hi Ogata, I think that webrev.02 is safe as you describe. But there's one case which now has some overhead. It's a common practice to subclass ObjectInputStream and override resloveClass() method and implement custom resolving (without calling super.resolveClass()). In such case, the cached