Re: StringJoiner: detect or fix delimiter collision?

Are we really going ahead with an implementation that: - checks even string literal parameters for null - does it again when String.join calls StringJoiner - makes defensive copies of just some of the arguments - creates a StringBuilder with only the default capacity People would be better off ta

Re: StringJoiner: detect or fix delimiter collision?

I don't think my needs are in any way particular or unusual. This is the third attempt at a StringJoiner that has not stopped me having to roll my own. Arrays.toString and AbstractCollection.toString already meet logging needs and serve as simple useful examples for where people don't care about

Re: Replacement of sun.reflect.Reflection#getCallerClass

I just subscribed so I apologize that this message is probably not going to be threaded properly. It seems mailman has no way for me to retrieve a message. I'd like to add a couple points to what you have below: 1. In addition to Log4j, Logback has been adding this same information to the stack

Various Random things (Was: Java 8 RFC 7189139: BigInteger's staticRandom field can be a source of bottlenecks)

Sorry, I haven't been following the Random discussions until now, I haven't been subscribed to core-lib-dev in a while. I was specifically asked to comment on Brian's proposed change. Paul pointed out something Bill Pugh wrote: > Right, see here: > > http://mail.openjdk.java.net/pipermail/cor

Replacement of sun.reflect.Reflection#getCallerClass

Hi Nick, Thanks for the patch. JEP 176 [1] describes the caller-sensitive method and the need for a mechanical checking of caller-sensitive methods. Also Peter Levart in [2] explained the change in MethodHandles.Lookup related to @CS. I assume you understand the rationale behind and the pot

RFR: 8024140: [TESTBUG] Profile based regression test groups for jdk repo

webrev: http://cr.openjdk.java.net/~dholmes/8024140/webrev/ Similar to what was recently done on the hotspot side, this introduces profile-based test groups for the jdk regression tests. The primary groups are: - jdk - jre - compact3 - compact2 - compact2_minimal - compact1 - compact1_

Re: RFR: 8024014 & 8024015 : (xs) TEST.groups updates

On 3/09/2013 2:05 AM, Alan Bateman wrote: On 30/08/2013 21:30, Mike Duigou wrote: : Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk... Sorry Mike, I somehow missed your reply on this to

hg: jdk8/tl/langtools: 8016177: structural most specific and stuckness

Changeset: 4a6acc42c3a1 Author:vromero Date: 2013-09-02 22:38 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/4a6acc42c3a1 8016177: structural most specific and stuckness Reviewed-by: jjg, vromero Contributed-by: maurizio.cimadam...@oracle.com ! src/share/classes/com/su

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Some minor modification (and further simplifying of conditions) : http://cr.openjdk.java.net/~coffeys/webrev.8023563.3/webrev/ regards, Sean. On 02/09/13 21:07, Alan Bateman wrote: On 02/09/2013 19:06, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first

hg: jdk8/tl/langtools: 8022162: Incorrect signature determination for certain inner class generics

Changeset: 2bf4c132bf90 Author:vromero Date: 2013-09-02 22:44 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/2bf4c132bf90 8022162: Incorrect signature determination for certain inner class generics Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/jvm/ClassReade

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/2013 19:06, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ This is nicer (and I see Chris has already pointed out the redundant check). -Alan

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 2 Sep 2013, at 20:07, Seán Coffey wrote: > Chris - > > you're right on the redundant checks. Had to re-read it! Will get those > removed. Thanks. Otherwise looks fine to me. -Chris. > > regards, > Sean. > > On 02/09/13 19:15, Chris Hegarty wrote: >> On 09/02/2013 07:06 PM, Seán Coffey

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Chris - you're right on the redundant checks. Had to re-read it! Will get those removed. Thanks. regards, Sean. On 02/09/13 19:15, Chris Hegarty wrote: On 09/02/2013 07:06 PM, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.ja

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 02/09/13 19:15, Chris Hegarty wrote: On 09/02/2013 07:06 PM, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ The 'javaAWTAccess != null ' checks are redundant. It will always be the

hg: jdk8/tl/jdk: 7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing

Changeset: a7d463f5a5b9 Author:egahlin Date: 2013-09-02 16:03 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/a7d463f5a5b9 7172176: java/jconsole test/sun/tools/jconsole/ImmutableResourceTest.sh failing Reviewed-by: mchung, mfang ! src/share/classes/sun/tools/jconsole/Resourc

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 09/02/2013 06:45 PM, Nick Williams wrote: On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote: It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So the suggestion to start out small was to leave that out and focus on some of the use-cases initially. I don't think this sug

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

On 09/02/2013 07:06 PM, Seán Coffey wrote: This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ The 'javaAWTAccess != null ' checks are redundant. It will always be the case, right? -Chris. regards, Sean.

Re: RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

This might be a slightly easier one to read. (fast path logic code first) http://cr.openjdk.java.net/~coffeys/webrev.8023563.2/webrev/ regards, Sean. On 02/09/13 16:47, Seán Coffey wrote: Performance regression reported where a high number of threads calling TimeZone.getDefault can run into a

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote: > It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So > the suggestion to start out small was to leave that out and focus on some of > the use-cases initially. I don't think this suggestion is unreasonable as it > allows th

hg: jdk8/tl/jdk: 8016127: NLS: logging.properties translatability recommendation; ...

Changeset: 92d594a938ff Author:dfuchs Date: 2013-09-02 18:28 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/92d594a938ff 8016127: NLS: logging.properties translatability recommendation 8024131: Issues with cached localizedLevelName in java.util.logging.Level Summary: This fix

Re: RFR: 8024014 & 8024015 : (xs) TEST.groups updates

On 30/08/2013 21:30, Mike Duigou wrote: : Did you see David Holmes' suggestion? Do you think it's adequate? I agree about the maintainability aspect as I really felt guilty re-creating FILES_JAVA.gmk... Sorry Mike, I somehow missed your reply on this topic. Do you mean reorganizing the tests, s

RFR :8023563: Bottleneck in java.util.TimeZone.getDefaultInAppContext

Performance regression reported where a high number of threads calling TimeZone.getDefault can run into a bottleneck on AppContext accessor calls. The bug ID is 8023563 but it's not visible on bugs.sun.com yet. Turns out that we're unnecessarily going through the AppContext in certain scenario

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 9/2/2013 6:29 AM, Daniel Fuchs wrote: Hi, Please find below a fix for: 8016127: NLS: logging.properties translatability recommendation This change looks fine. As for the cached localized name and the tranisent localizedLeve

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 02/09/2013 15:57, Alan Bateman wrote: On 02/09/2013 15:21, Daniel Fuchs wrote: Hi Alan, This field was introduced recently by changeset d1668eca22bf, and should have been declared transient from the start.

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 09/02/2013 03:56 PM, Tom Hawtin wrote: On 02/09/2013 09:33, Alan Bateman wrote: From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone can (or should) sponsor this patch until there is further discussion on the API and the security impl

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 02/09/2013 15:08, Jörn Huxhorn wrote: : Nick also explained a performance issue in Thread#getStackTrace() and Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for "start small" (i.e. leaving that issue alone) would be a wise decision. It was a non goal of JEP 176 to p

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 02/09/2013 15:21, Daniel Fuchs wrote: Hi Alan, This field was introduced recently by changeset d1668eca22bf, and should have been declared transient from the start. Mandy asked me t

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 9/2/13 4:00 PM, Alan Bateman wrote: On 02/09/2013 14:29, Daniel Fuchs wrote: Hi, Please find below a fix for: 8016127: NLS: logging.properties translatability recommendation One thing I notice is that you've changed Level.loca

Re: RFR 8023463 Update HashMap and LinkedHashMap to use bins/buckets or trees (red/black)

FYI: this has been soaking in the lambda repo for over a weak now. AFAICT there have been no issues. Paul. On Aug 24, 2013, at 6:31 PM, Mike Duigou wrote: > I will need to spend more time reviewing the HashMap/LinkedHashMap > implementations but here are some initial comments. > > Mike

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 2. September 2013 at 10:33:59, Alan Bateman (alan.bate...@oracle.com) wrote: On 01/09/2013 21:04, Nick Williams wrote:  > :  >  > So David says he thinks he can find someone at RedHat to sponsor this, > assuming it looks good.  >  > Nick  I see the patch is accessible now.  From a quick scan t

Re: RFR: 8016127 - NLS: logging.properties translatability recommendation

On 02/09/2013 14:29, Daniel Fuchs wrote: Hi, Please find below a fix for: 8016127: NLS: logging.properties translatability recommendation One thing I notice is that you've changed Level.localizedLevelName to be transient so this c

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 02/09/2013 09:33, Alan Bateman wrote: From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone can (or should) sponsor this patch until there is further discussion on the API and the security implications. I've barely looked through the

RFR: 8016127 - NLS: logging.properties translatability recommendation

Hi, Please find below a fix for: 8016127: NLS: logging.properties translatability recommendation This fix corrects localized Level names in JDK 8. It updates the logging.properties resource bundles to follow internationalization g

RFR 8010293 Re: Potential issue with CHM.toArray

On Sep 2, 2013, at 1:18 PM, Doug Lea wrote: > On 08/28/2013 09:13 AM, Peter Levart wrote: >> On 08/28/2013 12:10 PM, Paul Sandoz wrote: >>> Hi, >>> >>> Intermittent failures were reported with the CHM toArray test in the JDK. >>> >>> I updated the tests to increase the number of runs and the n

hg: jdk8/tl/jdk: 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg

Changeset: 441da45931fa Author:chegar Date: 2013-09-02 14:02 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/441da45931fa 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg Reviewed-by: alanb, psandoz ! src/share/classes/java/util/conc

Re: Review: lamda expressions and bulk data operations on collections.

On Aug 31, 2013, at 8:25 AM, Ali Ebrahimi wrote: > I see nobody using mangled (comparing&map) methods (even oracle guys) and > this is the thing that I already have expected, just since we all lazy and > this would hurt performance. I suspect this is more to do with the examples being coded again

Re: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg

On Sep 2, 2013, at 2:19 PM, Alan Bateman wrote: > On 02/09/2013 13:10, Chris Hegarty wrote: >> This is a small issue that was spotted by one of the TCK engineers. >> Trivially, the args should be long. > Looks fine to me (and no compatibility issues as these are new methods in 8). > +1. Paul.

Re: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg

Thanks Alan. On 09/02/2013 01:19 PM, Alan Bateman wrote: On 02/09/2013 13:10, Chris Hegarty wrote: This is a small issue that was spotted by one of the TCK engineers. Trivially, the args should be long. Looks fine to me (and no compatibility issues as these are new methods in 8). Yes, of cou

Re: RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg

On 02/09/2013 13:10, Chris Hegarty wrote: This is a small issue that was spotted by one of the TCK engineers. Trivially, the args should be long. Looks fine to me (and no compatibility issues as these are new methods in 8). -Alan.

RFR 8024103: AtomicLongArray getAndAccumulate/accumulateAndGet have int type for new value arg

This is a small issue that was spotted by one of the TCK engineers. Trivially, the args should be long. Doug has already pull this change into his CVS. This RFR is to pull the change into JDK8. diff --git a/src/share/classes/java/util/concurrent/atomic/AtomicLongArray.java b/src/share/class

Re: Potential issue with CHM.toArray

On 08/28/2013 09:13 AM, Peter Levart wrote: On 08/28/2013 12:10 PM, Paul Sandoz wrote: Hi, Intermittent failures were reported with the CHM toArray test in the JDK. I updated the tests to increase the number of runs and the number of workers and i can reliably reproduce on my laptop, see below

Re: [PATCH] 4851444: Exposing sun.reflect.Reflection#getCallerClass as a public API in Java 8

On 01/09/2013 21:04, Nick Williams wrote: : So David says he thinks he can find someone at RedHat to sponsor this, assuming it looks good. Nick I see the patch is accessible now. From a quick scan then it appears that you've decided to ignore the security concerns so I don't think anyone ca