Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 09:31 AM, Aleksey Shipilev wrote: > Now it might be cleaner to ditch Java version from Unsafe, and make > native entry points like Unsafe_CompareAnd{Exchange,Swap}{Byte,Short} > which would call relevant Atomic::cmpxchg-s. ...or not. There is no Atomic::cmpxchg(jshort), argh. Thanks

Re: Testing hotspot's Atomic::cmpxchg(jbyte*) ?

On 08/19/2016 08:15 AM, David Holmes wrote: > I need to test the jbyte version of Atomic::cmpxchg in the VM, but so > far it doesn't seem to be the case that any library code will actually > invoke it. At the top Java level there is no AtomicByte class. Unsafe > defines compareAndSwapByte variants

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Hi Ivan, ZoneOffset.ofTotalSeconds(Integer.MIN_VALUE) have also the same issue. It' not throwing the expected DTE. May be you can correct this also as part of this. Please update the copyright year also. Rest looks good. -- Thanks and Regards, Nadeesh TV On 8/18/2016 10:23 PM, Ivan Geras

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Hi , Sorry , my bad. I misread 'plusmn'. -- Thanks and Regards, Nadeesh TV On 8/19/2016 11:10 AM, nadeesh tv wrote: Hi Stephen/Ivan, Is not the the statement "Zone offset minutes and seconds must be negative because hours is negative" and the following doc definition contradicts ? 358

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Hi Stephen/Ivan, Is not the the statement "Zone offset minutes and seconds must be negative because hours is negative" and the following doc definition contradicts ? 358 * @param minutes the time-zone offset in minutes, from 0 to ±59 359 * @param seconds the time-zone offset in

Testing hotspot's Atomic::cmpxchg(jbyte*) ?

No I didn't send this to the wrong mailing list :) I need to test the jbyte version of Atomic::cmpxchg in the VM, but so far it doesn't seem to be the case that any library code will actually invoke it. At the top Java level there is no AtomicByte class. Unsafe defines compareAndSwapByte varia

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

I’ve updated the webrev to incorporate most of Paul’s suggestions. http://cr.openjdk.java.net/~sdrach/8164389/webrev.01/index.html > On Aug 18, 2016, at 5:01 PM, Paul Sandoz wrote: > > >> On 18 Aug 2016, at 16:36, Steve Drach

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

>>> You might wanna create a temporary jar file if possible, just in case the >>> test somehow fails to clean things up. >> >> Unsure how to do that, or perhaps I don’t understand your request. > > I believe it’s possible to create a temporary directory, see > Files.createTempDirectory, and use

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

> On 18 Aug 2016, at 17:15, Steve Drach wrote: > >> You might wanna create a temporary jar file if possible, just in case the >> test somehow fails to clean things up. > > Unsure how to do that, or perhaps I don’t understand your request. I believe it’s possible to create a temporary director

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

> You might wanna create a temporary jar file if possible, just in case the > test somehow fails to clean things up. Unsure how to do that, or perhaps I don’t understand your request.

Re: RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

> On 18 Aug 2016, at 16:36, Steve Drach wrote: > > Hi, > > Please review this rather simple fix to JarFileSystem. > > issue: https://bugs.openjdk.java.net/browse/JDK-8164389 > > webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.

RFR: 8164389: jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned entries in a multi-release jar file

Hi, Please review this rather simple fix to JarFileSystem. issue: https://bugs.openjdk.java.net/browse/JDK-8164389 webrev: http://cr.openjdk.java.net/~sdrach/8164389/webrev/index.html

Re: RFR: JDK-8161230 - Create java.util.stream.Stream from Iterator / Enumeration

> On 17 Aug 2016, at 02:39, Patrick Reinhart wrote: > > Hi Paul, > > Thanks for the input. I integrated that into the version here: > > http://cr.openjdk.java.net/~reinhapa/reviews/8161230/ClassLoader_StreamMethods.03 > Onward to the implementation! Paul.

Re: Exceptional behavior of parallel stream

> On 18 Aug 2016, at 03:54, Doug Lea wrote: > > On 08/17/2016 09:01 AM, Tagir F. Valeev wrote: >> Hello! >> >> I found no information in Stream API documentation on how it behaves >> in case if exception occurs during the stream processing. While it's >> quite evident for sequential stream (str

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 18.08.2016 21:27, Claes Redestad wrote: Rather than breaking into Reflection we should likely add an internally public API with a more well-defined contract, ensuring that it addresses arrays, primitives etc, and then Reflection, VerifyAccess and ObjectStream could consolidate their use to

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 2016-08-18 20:23, Ivan Gerasimov wrote: Hi Claes! Thank you for looking into this. On 18.08.2016 15:25, Claes Redestad wrote: On 2016-08-16 19:20, Ivan Gerasimov wrote: ObjectStreamClass: I wonder if the entire getPackageName is replaceable with Class.getPackageName()? If so, ditch the

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Thank you Stephen for review! On 18.08.2016 21:16, Stephen Colebourne wrote: Looks good Stephen On 18 August 2016 at 17:53, Ivan Gerasimov wrote: Hello everybody! The factory methods of ZoneOffset class demonstrate a minor inconsistency. Normally, invalid values of arguments are rejected (e

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

Hi Claes! Thank you for looking into this. On 18.08.2016 15:25, Claes Redestad wrote: On 2016-08-16 19:20, Ivan Gerasimov wrote: ObjectStreamClass: I wonder if the entire getPackageName is replaceable with Class.getPackageName()? If so, ditch the method completely and use Class.getPackageNam

Re: RFR 8138661, Address DataSource javadoc typo

Looks good, Lance. Naoto On 8/18/16 11:08 AM, Lance Andersen wrote: Hi all, This is a trivial fix of a typo in DataSource - ljanders-mac:jdk ljanders$ hg diff diff -r 6f5da13861db src/java.sql/share/classes/javax/sql/DataSource.java --- a/src/java.sql/share/cl

Re: [jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Looks good Stephen On 18 August 2016 at 17:53, Ivan Gerasimov wrote: > Hello everybody! > > The factory methods of ZoneOffset class demonstrate a minor inconsistency. > Normally, invalid values of arguments are rejected (e.g. when minutes > 59), > but the value of Integer.MIN_VALUE is allowed to

RFR 8138661, Address DataSource javadoc typo

Hi all, This is a trivial fix of a typo in DataSource - ljanders-mac:jdk ljanders$ hg diff diff -r 6f5da13861db src/java.sql/share/classes/javax/sql/DataSource.java --- a/src/java.sql/share/classes/javax/sql/DataSource.java Thu Aug 18 16:27:15 2016 +0300 +++

[jdk9] RFR: 8164366: ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input

Hello everybody! The factory methods of ZoneOffset class demonstrate a minor inconsistency. Normally, invalid values of arguments are rejected (e.g. when minutes > 59), but the value of Integer.MIN_VALUE is allowed to be passed in. This is due to using Math.abs(), which cannot handle Integer.M

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 2016-08-18 18:11, Aleksey Shipilev wrote: On 08/18/2016 05:32 PM, Claes Redestad wrote: http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ Doing this twice now? +dedupSet.add(methodTypes[i]); Oops. Fixed and updated in-place. Otherwise thumbs up. Thanks! /Clae

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 08/18/2016 05:32 PM, Claes Redestad wrote: > http://cr.openjdk.java.net/~redestad/8164044/webrev.03/ Doing this twice now? +dedupSet.add(methodTypes[i]); Otherwise thumbs up. -Aleksey

Re: RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work

+1 On 8/18/2016 8:48 PM, Yasumasa Suenaga wrote: > Hi all, > > This review request is related to [1]. > > jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. > However, these tool might be used by JDK developers. So I think we > should fix this issue. > > I uploaded a webrev. Could yo

Re: RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work

+1 On 8/18/16 8:18 AM, Yasumasa Suenaga wrote: Hi all, This review request is related to [1]. jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. However, these tool might be used by JDK developers. So I think we should fix this issue. I uploaded a webrev. Could you review it?

RFR: JDK-8164326: jrtfsviewer.js and jrtls.js does not work

Hi all, This review request is related to [1]. jrtfsviewer.js and jrtls.js are not contained JDK/JRE binaries. However, these tool might be used by JDK developers. So I think we should fix this issue. I uploaded a webrev. Could you review it? http://cr.openjdk.java.net/~ysuenaga/JDK-8164326

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 2016-08-18 16:06, Aleksey Shipilev wrote: On 08/18/2016 12:33 AM, Claes Redestad wrote: Hi, please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the DirectMethodHandles we already pre-generate during linking. webrev: http://cr.openjdk.java

Re: Error at jrt*.js

Yes, those scripts are meant for developers and not part of binary JDK bits. Please do file a bug and send webrev for review. -Sundar On 8/18/2016 7:51 PM, Yasumasa Suenaga wrote: > Hi all, > > I tried to run jrtfsviewer.js and jrtls.js . But they did not work as > below: > > $

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

Michael, Vladimir, thanks for reviewing and suggesting improvements. Getting rid of LF.debugName seems like a rather straight-forward and worthwhile cleanup at this point. /Claes On 2016-08-18 16:13, Vladimir Ivanov wrote: Good work! Reviewed. Best regards, Vladimir Ivanov PS: I wish LF.d

Error at jrt*.js

Hi all, I tried to run jrtfsviewer.js and jrtls.js . But they did not work as below: $ jjs -fx jrtfsviewer.js Exception in Application start method Exception in thread "main" java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 08/16/2016 08:20 PM, Ivan Gerasimov wrote: > Here is the updated webrev: > http://cr.openjdk.java.net/~igerasim/8163517/01/webrev/ Looks good to me. -Aleksey

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

Good work! Reviewed. Best regards, Vladimir Ivanov PS: I wish LF.debugString completely went away, but let's keep it for future cleanup. On 8/18/16 12:33 AM, Claes Redestad wrote: Hi, please review this change which adds pre-generation of simple DelegatingMethodHandles corresponding to the

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

On 08/18/2016 12:33 AM, Claes Redestad wrote: > Hi, > > please review this change which adds pre-generation of simple > DelegatingMethodHandles corresponding to the DirectMethodHandles we > already pre-generate during linking. > > webrev: http://cr.openjdk.java.net/~redestad/8164044/webrev.02/ *

Re: RFR: 8164044: Generate corresponding simple DelegatingMethodHandles when generating a DirectMethodHandle

Hi Claes, thumbs up. Best, Michael > Am 17.08.2016 um 23:33 schrieb Claes Redestad : > > Hi, > > please review this change which adds pre-generation of simple > DelegatingMethodHandles corresponding to the DirectMethodHandles we already > pre-generate during linking. > > webrev: http://cr.

Re: [jdk9] RFR: 8163517: Various cleanup in java.io code

On 2016-08-16 19:20, Ivan Gerasimov wrote: ObjectStreamClass: I wonder if the entire getPackageName is replaceable with Class.getPackageName()? If so, ditch the method completely and use Class.getPackageName everywhere. This may complicate backporting to JDK 8 though. Unfortunately, Class.ge

Re: Exceptional behavior of parallel stream

Hello, Doug! Thank you for your response. DL> In your example, you can witness the delayed termination of other threads DL> upon exception in another because you add side-effecting operations DL> (here, just printing). Avoiding all this would force sequential processing. DL> But if the supplied

Re: Exceptional behavior of parallel stream

On 08/17/2016 09:01 AM, Tagir F. Valeev wrote: Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Joe, Christoph, Thanks for your reviews! With Best Regards, Aleksej On 18/08/16 08:47, Langer, Christoph wrote: +1, nice fix. -Original Message- From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On Behalf Of Joe Wang Sent: Mittwoch, 17. August 2016 18:30 To: Aleks

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Hi Peter, Thank you for review and suggestion to add super constructor call: will add it before pushing the changes. Best Regards, Aleksej On 18/08/16 11:08, Peter Levart wrote: Hi Aleks, Looks OK, but if AbortException is never inspected for a stack trace, then it could be constructed w

Re: RFR (JAXP): 8146961: Fix PermGen memory leaks caused by static final Exceptions

Hi Aleks, Looks OK, but if AbortException is never inspected for a stack trace, then it could be constructed without it. This is perhaps unnecessary if it is not on the hot path, but it is easy to just call the appropriate super constructor: public class AbortException extends RuntimeExcepti