RFR: JDK-8087104: DateFormatSymbols triggers this.clone() in the constructor

Hi all, Please review the fix for bug: https://bugs.openjdk.java.net/browse/JDK-8087104 Bug Description: DateFormatSymbols caches its own instance and calls this.clone() in the constructor. Because of this, any subclass implementation (which expects a field is always initialized to non-null in th

Re: RFR 8124977 cmdline encoding challenges on Windows

On 2/23/16 9:52 PM, Vladimir Shcherbakov wrote: Hi Sherman, 1) If you can point out the regression test cases that are compromised by the fix - it would be very helpful; I don't have a specific regression test for now. Guess running a "old" awt app with Japanese/Chinese characters as menu it

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

onXXX is VERY relevant to this situation. And it's exactly that precedent and common convention for event notification calls that drove the choice of onSpinWait as a method name. onSpinWait() it is delivering a notification [from the calling code to the Runtime, or the Thread] about what is goin

Re: RFR 8124977 cmdline encoding challenges on Windows

Vladimir, sun.jnu.encoding is used by JNU_NewStringPlatform/JNU_GetStringPlatformChars. The JNU_ pair is "widely" used by the various native library code to convert between the jstring and native char*, with the assumption that the "platform encoding" for the native char* is the "default" enco

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Yes, I was going to mention onXXX being common for event handler names (e.g onMouseClick), but didn't bother for the same reason you mentioned - it's irrelevant to this situation. On Tuesday, February 23, 2016, Paul Benedict wrote: > The onXXX prefix does have precedent as event handler callback

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

The onXXX prefix does have precedent as event handler callbacks, but this method does not fit that purpose. Thus, I agree dropping "on" is sensible. On Feb 23, 2016 8:48 PM, "Vitaly Davidovich" wrote: > On Tuesday, February 23, 2016, Doug Lea wrote: > > > On 02/23/2016 04:30 PM, Vitaly Davidovic

RFR: jsr166 jdk9 integration wave 5

A very boring jsr166 integration, focused on reliability. This one has the promised "even more unnecessarily robust" ThreadLocalRandom. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On Tuesday, February 23, 2016, Doug Lea wrote: > On 02/23/2016 04:30 PM, Vitaly Davidovich wrote: > >> Why not drop the (superfluous, IMO) "on" prefix while you're changing the >> receiver? >> > > Because then it reads as if the method itself is doing a spinWait. vs who else logically speaking?

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

> On Feb 23, 2016, at 3:22 PM, Kim Barrett wrote: > > I'm not sure what to do about any of this; I'm just feeling like maybe > the proposed API / implementation isn't quite right yet. I suggest restore the JavaLangRefAccess used by direct byte buffer code and revisit such explicit mechanism un

Re: Replacement of Quicksort in java.util.Arrays with new Dual-Pivot Quicksort

I think this is the best place to contact the original authors. The link to Vladimir Yaroslavskiy's original whitepaper describing the algorithm and its proofs was, unfortunately, broken. Using Archive.org's Wayback Machine, I was able to get the last known revision. I reformatted the document in

Re: RFR: 8072727 - add variation of Stream.iterate() that's finite

Finally getting back to this. So, now that this has been clarified to model a for-loop, this seems fine. It looks like Paul is sponsoring this for you. Great, let's move ahead with it. As the author of this particular RFE, though, I should say that this isn't what I had in mind when I wrote t

Re: RFR 8124977 cmdline encoding challenges on Windows

Hi Vladimir, I think it would work fine with the Java launcher, but what about other areas, which may rely on the native encodings? Java runtime is in itself a "non-Unicode" application, so still there may be the area affected by hardcoding "UTF-8" as the native encoding. Have you checked in s

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

On 02/23/2016 04:30 PM, Vitaly Davidovich wrote: Why not drop the (superfluous, IMO) "on" prefix while you're changing the receiver? Because then it reads as if the method itself is doing a spinWait. "onSpinWait" is the only proposed name that no one has said they cannot live with. So, live wit

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

The change looks good. Thanks Aleksej, again, for catching the issue. For future changes, we'll need to make sure we run the JCK tests. Best, Joe On 2/23/2016 3:51 PM, Langer, Christoph wrote: Sorry, this one is the right webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/

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

Sorry, this one is the right webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/ From: Langer, Christoph Sent: Dienstag, 23. Februar 2016 21:13 To: 'Aleksej Efimov' ; huizhe wang Subject: RE: JDK 9 RFR of JDK-8149915: enabling validate-annotations feature for xsd schema with ann

RFR 8150470: JCK: api/xsl/conf/copy/copy19 test failure

Hi, the changeset for 8149915 (enabling validate-annotations feature for xsd schema with annotation causes NPE) introduced a regression. Here is the fix. Bugid: https://bugs.openjdk.java.net/browse/JDK-8150470 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8150470.1/ Please review a

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

> On Feb 23, 2016, at 11:35 AM, Peter Levart wrote: > > Hi Roger, Mandy, > > Here's another webrev: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05/ > > I renamed the method and reworded the specification. Is this better now? > > > On 02/22/2016 10:56 PM, Rog

RFR 9: 8150346 : java/lang/ProcessHandle/Infotest.java failed: startTime after process spawn completed

Please review a test fix to resolve a timing race with the start time of a spawned process. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-start-8150346/ Jira: https://bugs.openjdk.java.net/browse/JDK-8150346 Thanks, Roger

Re: RFR 9: 8150337 : sun/misc/SunMiscSignalTest.java failed intermittently

Hi Roger, I am no expert in this area but the changes appear to be reasonable and consistent. One thumb up. Brian On Feb 23, 2016, at 7:29 AM, Roger Riggs wrote: > Please review a test update to skip tests using SIGINT, SIGTERM, and SIGHUP > when > run with those signals are ignored. For ex

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

Why not drop the (superfluous, IMO) "on" prefix while you're changing the receiver? Thread::spinWait would be in the same style/spirit as Thread::yield, and I don't think there will be much contention. On Tue, Feb 23, 2016 at 4:20 PM, Gil Tene wrote: > > > On Feb 22, 2016, at 10:11 AM, mark.rein

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

> On Feb 22, 2016, at 10:11 AM, mark.reinh...@oracle.com wrote: > > 2016/1/28 9:25 -0800, g...@azul.com: >> This thread seems to have "hopped away" to the concurrency-interest >> list in mid-Dec-2015. This posting is intended to capture a summary of >> reasoning and some of the discussion there s

Re: Collectors.minBy/maxBy behavior for null value

I agree with Peter, nulls in stream are tolerated for backward compatibility with existing code, null is not something that should trigger a specific behavior apart a NPE. regards, Rémi - Mail original - > De: "Peter Levart" > À: "Tagir Valeev" , "core-libs-dev" > > Envoyé: Lundi 22 Fé

RE: RFR 8124977 cmdline encoding challenges on Windows

Hi Kumar, (*) Highlights of the changes from the previous revision: 1) Conversion from UTF-16 to UTF-8. a) in webrev 4 was implemented in a standalone function JLI_DecodeArgs - the declaration and definition and usage affected 5 files: src/java.base/share/native/libjli/jli_util.h

Re: RFR 8124977 cmdline encoding challenges on Windows

Hello, Sorry if this has already been discussed, but this is my first time looking at the fix. In java_props_md.c, sprops.sun_jnu_encoding is now always "UTF-8". Is it always the case? What if the system admin switches the locale for "non-Unicode" applications in the Windows control panel? N

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On Tue, Feb 23, 2016 at 7:20 AM, Ivan Gerasimov wrote: > While writing this, I just noticed that I actually made a mistake when did > newCapacity < 0 check. > This wouldn't catch the overflow when the oldCapacity happens to be > Integer.MAX_VALUE (which is not possible with the current hotspot, bu

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

Hi Alan, On 02/23/2016 04:33 PM, Alan Bateman wrote: On 22/02/2016 21:41, Mandy Chung wrote: : I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanable::clea

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

Hi Roger, Mandy, Here's another webrev: http://cr.openjdk.java.net/~plevart/jdk9-dev/removeInternalCleaner/webrev.05/ I renamed the method and reworded the specification. Is this better now? On 02/22/2016 10:56 PM, Roger Riggs wrote: Hi Mandy, On 2/22/2016 4:41 PM, Mandy Chung wrote: The

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

On 22/02/2016 21:41, Mandy Chung wrote: : I added new method to Cleaner: public boolean helpClean() { } I’m in two minds of making this a public method. An explicit way to enqueue pending references as well as invoke Cleanable::clean. If it goes in, the method name needs to be rename

RFR 9: 8150337 : sun/misc/SunMiscSignalTest.java failed intermittently

Please review a test update to skip tests using SIGINT, SIGTERM, and SIGHUP when run with those signals are ignored. For example, using nohup or trap in a shell. It also includes a small enhancement adding sun.misc.Signal.toString ease debugging. Webrev: http://cr.openjdk.java.net/~rriggs/web

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

On 23.02.2016 9:23, Martin Buchholz wrote: Thanks, Ivan. I see that the capacity growth x -> 2*x + 2 is mandated by the spec, so we can't change that. Growing by more than a factor of two may mean that the "overflow-conscious" code I originally wrote may need more checks than ArrayList, where

Re: RFR (S) 8150180: String.value contents should be trusted

Yes, sorry, pushing these two: http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02 http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ -Aleksey On 02/23/2016 05:39 PM, Claes Redestad wrote: > Looks good to me, but I assume you mean to push > http://cr.openjdk.java.net/~shade/8150180/w

Re: RFR (S) 8150180: String.value contents should be trusted

Looks good to me, but I assume you mean to push http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.02 (which looks even better)? Thanks! /Claes On 2016-02-23 11:24, Aleksey Shipilev wrote: On 02/19/2016 05:42 PM, Vladimir Ivanov wrote: http://cr.openjdk.java.net/~shade/8150180/webrev.

Re: RFR:JDK-8032051:"ZonedDateTime" class "parse" method fails with short time zone offset ("+01")

Thanks for the changes. In `DateTimeFormatter`, the code should be .parseLenient() .appendOffsetId() .parseStrict() and the same in the other case. This ensures that existing callers who then embed the formatter in another formatter (like the ZONED_DATE_TIME constant) are unaffected. The logic

Re: RFR: 8149330: Capacity of StringBuilder should not get close to Integer.MAX_VALUE unless necessary

Okay, Vitaly, you convinced me and I replaced the combined check with two ORed checks: -return (((SAFE_BOUND - newCapacity) | newCapacity) < 0) +return (newCapacity < 0 || SAFE_BOUND - newCapacity < 0) The webrev was updated in place: http://cr.openjdk.java.net/~igerasim/8149330

Re: RFR (S) 8150180: String.value contents should be trusted

On 02/19/2016 05:42 PM, Vladimir Ivanov wrote: >>http://cr.openjdk.java.net/~shade/8150180/webrev.jdk.01/ >>http://cr.openjdk.java.net/~shade/8150180/webrev.hs.02/ > Looks good. A few more reviews, please? Cheers, -Aleksey

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

Hi Paul, thanks - all right; I'll consider using "and" rather than "/" and push the result. Best, Michael > Am 23.02.2016 um 09:13 schrieb Paul Sandoz : > >> >> On 23 Feb 2016, at 07:39, Michael Haupt wrote: >> >> Hi Paul, >> >> thank you. I'm holding off on pushing; a new webrev is at >

Re: RFR(S): 8143410: augment pseudo-code descriptions in MethodHandles API

> On 23 Feb 2016, at 07:39, Michael Haupt wrote: > > Hi Paul, > > thank you. I'm holding off on pushing; a new webrev is at > http://cr.openjdk.java.net/~mhaupt/8143410/webrev.01. See below for two > specific comments. > >> Am 22.02.2016 um 21:45 schrieb Paul Sandoz : >>> Webrev: http://cr.o