Re: RFR(XS): 8147844: new method j.l.Thread.onSpinWait() (was j.l.Runtime)

On 07/03/2016 17:40, David Holmes wrote: Hi Ivan, On 8/03/2016 11:04 AM, Ivan Krylov wrote: The current wording of what is being called now JEP-285 [1] has placed onSpinWait() method into j.l.Thread. Hence, a new revision of the webrev. Everything is the same, except now it is the Thread

Re: RFR(XS): 8147844: new method j.l.Thread.onSpinWait() (was j.l.Runtime)

Hi Ivan, On 8/03/2016 11:04 AM, Ivan Krylov wrote: The current wording of what is being called now JEP-285 [1] has placed onSpinWait() method into j.l.Thread. Hence, a new revision of the webrev. Everything is the same, except now it is the Thread class.

Re: RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"

On 3/8/16 9:20 AM, Felix Yang wrote: Joe, thank you for the quick review. Amy, could you sponsor this change? Sure, I will sponsor this for you. Thanks, Amy -Felix On 2016/3/8 2:51, joe darcy wrote: Hello, Looks fine; thanks, -Joe On 3/7/2016 8:04 AM, Felix Yang wrote: Hi

Re: RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"

Joe, thank you for the quick review. Amy, could you sponsor this change? -Felix On 2016/3/8 2:51, joe darcy wrote: Hello, Looks fine; thanks, -Joe On 3/7/2016 8:04 AM, Felix Yang wrote: Hi all, please review the fix for two tests under "test/sample/". Bug:

Re: RFR(XS): 8147844: new method j.l.Thread.onSpinWait() (was j.l.Runtime)

The current wording of what is being called now JEP-285 [1] has placed onSpinWait() method into j.l.Thread. Hence, a new revision of the webrev. Everything is the same, except now it is the Thread class. http://cr.openjdk.java.net/~ikrylov/8147844.jdk.03/ Please, approve. Thanks, Ivan [1]

Re: 8151339 Adding fragment to JAR URLs breaks ant

IIRC, if all goes according to plan, the next build should be available for download on Friday. HTH, -Joe On 3/7/2016 3:51 PM, Steve Drach wrote: Hi Uwe, Thanks for the quick fix! I am not able to test this on the short term, but I trust you that Lucene builds now. I am a bit nervous,

Re: 8151339 Adding fragment to JAR URLs breaks ant

Hi Uwe, > Thanks for the quick fix! I am not able to test this on the short term, but > I trust you that Lucene builds now. I am a bit nervous, because it does not > explain the Ivy issues, but I will try to create some test cases with > relative jar:-URL resolving tomorrow. This may help

RE: 8151339 Adding fragment to JAR URLs breaks ant

Hi Steve, Thanks for the quick fix! I am not able to test this on the short term, but I trust you that Lucene builds now. I am a bit nervous, because it does not explain the Ivy issues, but I will try to create some test cases with relative jar:-URL resolving tomorrow. This may help with

Re: RFR 8150778: Reduce Throwable.getStackTrace() calls to the JVM

Hi Aleksey, This is an interesting experiment. On 3/4/16 8:28 AM, Aleksey Shipilev wrote: On 03/02/2016 11:21 PM, Aleksey Shipilev wrote: On 03/02/2016 10:57 PM, Coleen Phillimore wrote: On 3/2/16 1:58 PM, Aleksey Shipilev wrote: Is there an underlying reason why we can't return the

Re: RFR:JDK-8030864:Add an efficient getDateTimeMillis method to java.time

Look fine. Roger On 3/5/2016 7:05 AM, nadeesh tv wrote: Hi all, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8030864/webrev.06/ Regards, Nadeesh On 3/4/2016 4:34 PM, Stephen Colebourne wrote: long DAYS__TO_1970 should be extracted as a private static final constant.

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Chris, 515 hashCode = name.toLowerCase(Locale.ROOT).hashCode(); otherwise + 1 -sherman On 03/07/2016 01:55 PM, Chris Hegarty wrote: Aleksey, Very helpful, as always. I pushed the methods down into String[Latin1|UTF16], and followed existing style. This is much cleaner.

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Hi Chris, On 03/08/2016 12:55 AM, Chris Hegarty wrote: > Updated links: > http://cr.openjdk.java.net/~chegar/8151384/webrev.01/ *) Your previous patch had the explicit access to CharacterDataLatin1.instance.(toLowerCase|toUpperCase). Any reason not to use it in your new patch? Probably saves

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Aleksey, Very helpful, as always. I pushed the methods down into String[Latin1|UTF16], and followed existing style. This is much cleaner. Thanks for catching the silly mistakes in the benchmarks. Updated links: http://cr.openjdk.java.net/~chegar/8151384/webrev.01/

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

> On Mar 6, 2016, at 8:00 AM, Peter Levart wrote: > > Hi, > > I have been asked to split the changes needed to remove > jdk.internal.ref.Cleaner into two changesets. The first one is to contain the > straightforward non-controversial changes that remove the references

Re: JDK 9 RFR of JDK-8151393: Revert changes for JDK-8087104

On 07/03/2016 19:25, joe darcy wrote: Hello, The changes for JDK-8087104 introduced some test failures which have not yet been addressed (JDK-8151310). In order to get a clean snapshot for the next integration, if the fix for JDK-8151310 doesn't arrive in time, the changes for JDK-8087104

JDK 9 RFR of JDK-8151393: Revert changes for JDK-8087104

Hello, The changes for JDK-8087104 introduced some test failures which have not yet been addressed (JDK-8151310). In order to get a clean snapshot for the next integration, if the fix for JDK-8151310 doesn't arrive in time, the changes for JDK-8087104 should be reverted until they can be

Re: RFR: 8151339 Adding fragment to JAR URLs breaks ant

On 07/03/2016 19:07, Steve Drach wrote: Hi, Please review the following changeset. We’d like to get this into build 109, which means by noon today. This is essentially a temporary fix, but it’s been tested and Lucene has been built against it. We will follow up with a more comprehensive

RFR: 8151339 Adding fragment to JAR URLs breaks ant

Hi, Please review the following changeset. We’d like to get this into build 109, which means by noon today. This is essentially a temporary fix, but it’s been tested and Lucene has been built against it. We will follow up with a more comprehensive fix by build 110. webrev:

Re: RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"

Hello, Looks fine; thanks, -Joe On 3/7/2016 8:04 AM, Felix Yang wrote: Hi all, please review the fix for two tests under "test/sample/". Bug: https://bugs.openjdk.java.net/browse/JDK-8151352 Webrev: http://cr.openjdk.java.net/~xiaofeya/8151352/webrev.00/ Original declaration,

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

> On Mar 6, 2016, at 5:00 AM, Peter Levart wrote: > > Hi, > > I have been asked to split the changes needed to remove > jdk.internal.ref.Cleaner into two changesets. The first one is to contain the > straightforward non-controversial changes that remove the references

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

Hi, Given the issues we are seeing, and I suspect this is not the only code with these assumptions, is there any way this functionality can be limited to "multi-release aware" code, either via a constructor parameter or a new method? What is the most elegant approach? Andre > On 5 Mar, 2016,

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

On 2016-03-05, Uwe Schindler wrote: > This is why I put the Ant developers in CC. The correct way would be > to look at the *decoded* path (not just getPath() because this is also > one of the "famous" traps in the URL class - one reason why it should > be avoided in favor of URI).

Re: Stream API: Fuse sorted().limit(n) into single operation

Hi Tagir, On 03/07/2016 04:30 PM, Tagir F. Valeev wrote: Hello! Thank you for your comments! PL> - in Limiter.put: Nice catch! A good example when series of minor code refactorings lead to something strange. Webrev is updated in-place:

Re: RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

Hi, On 03/07/2016 07:29 PM, Chris Hegarty wrote: > What is in the webrev is specialized versions of compare when > the coder of the strings match. Alternatively, this could be pushed > down to String[Latin1|UTF16]. > > Webrev & bug: > http://cr.openjdk.java.net/~chegar/8151384/webrev.00/ >

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

On 06/03/16 13:00, Peter Levart wrote: Hi, I have been asked to split the changes needed to remove jdk.internal.ref.Cleaner into two changesets. The first one is to contain the straightforward non-controversial changes that remove the references to jdk.internal.ref.Cleaner and swaps them with

RFR [9] 8151384: Examine sun.misc.ASCIICaseInsensitiveComparator

sun.misc.ASCIICaseInsensitiveComparator appears to be a specialized comparator for comparing strings that contain only ASCII characters. Its main usage seems to be in sorted maps that support the character set implementation. This is startup/performance sensitive code. It looks like an

RFR 8151352, jdk/test/sample fails with "effective library path is outside the test suite"

Hi all, please review the fix for two tests under "test/sample/". Bug: https://bugs.openjdk.java.net/browse/JDK-8151352 Webrev: http://cr.openjdk.java.net/~xiaofeya/8151352/webrev.00/ Original declaration, "@library ../../../src/sample...", is invalid with the latest change in

Re: Stream API: Fuse sorted().limit(n) into single operation

Hello! Thank you for your comments! PL> - in Limiter.put: Nice catch! A good example when series of minor code refactorings lead to something strange. Webrev is updated in-place: http://cr.openjdk.java.net/~tvaleev/patches/sortedLimit/webrev/ PL> Also, what do you think of the following

Re: default random access list spliterator

> On 7 Mar 2016, at 15:53, Peter Levart wrote: > > > > On 03/07/2016 01:59 PM, Paul Sandoz wrote: >>> On 7 Mar 2016, at 12:47, Peter Levart wrote: >>> >>> What about a Spliterator based on List.subList() method? While the >>> specification of

Re: default random access list spliterator

On 03/07/2016 03:53 PM, Peter Levart wrote: As there is a good chance that sub-list implementations already provide fail-fast behavior for structural changes in the backing list. Ah, well... I checked AbstractMutableList in Eclipse collections and it doesn't provide fail-fast behavior for

Re: default random access list spliterator

On 03/07/2016 01:59 PM, Paul Sandoz wrote: On 7 Mar 2016, at 12:47, Peter Levart wrote: What about a Spliterator based on List.subList() method? While the specification of List.subList() does not guarantee any specific behavior when underlying list is structurally

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

> On 7 Mar 2016, at 14:46, David M. Lloyd wrote: >> >> My intention was the #runtime fragment should only be used for MR-JARs. > > Does that go far enough though? I think there is a substantial amount of > code which assumes (rightly) that you can build an exact path

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

On 03/07/2016 03:43 AM, Paul Sandoz wrote: Hi Uwe, Alan, Uwe, thanks so much for testing and investigating, that is very helpful and really appreciated. The EA process is working as intended, although i wish the result was not so debilitating in this case. Sorry about that. [...] Here is a

Re: default random access list spliterator

> On 7 Mar 2016, at 12:47, Peter Levart wrote: > > What about a Spliterator based on List.subList() method? While the > specification of List.subList() does not guarantee any specific behavior when > underlying list is structurally modified, the implementations (at

Re: default random access list spliterator

> On 7 Mar 2016, at 12:35, Michael Hixson wrote: > > Hi Tagir, Paul, > > Ah, it looks like Donald Raab had exactly the same suggestion. Sorry > for the repeat. I was following that list at that time, and now I'm > wondering whether my idea was my own. I agree with

Re: default random access list spliterator

What about a Spliterator based on List.subList() method? While the specification of List.subList() does not guarantee any specific behavior when underlying list is structurally modified, the implementations (at least implementations in JDK based on AbstractList) do have a fail-fast behavior

Re: default random access list spliterator

Hi Tagir, Paul, Ah, it looks like Donald Raab had exactly the same suggestion. Sorry for the repeat. I was following that list at that time, and now I'm wondering whether my idea was my own. I agree with everything he said. > One problem which would arise is that such spliterator will not be

Re: default random access list spliterator

Hi Michael, It could, stay tuned for some possible action on this. This is something we did discuss a while ago [1]. At the time we thought most List implementations would override so did not bother, and admittedly with the frenzy of all other stuff got de-prioritized. But, perhaps we

Re: default random access list spliterator

Hello! I thought about such possibility. One problem which would arise is that such spliterator will not be able to properly track modCount and throw ConcurrentModificationException. As a consequence it might produce silently inconsistent result if the structural changes were performed on your

Re: Multi-Release JAR file patch as applied to build 108 of Java 9 breaks almost every project out there (Apache Ant, Gradle, partly Apache Maven)

Hi Uwe, Alan, Uwe, thanks so much for testing and investigating, that is very helpful and really appreciated. The EA process is working as intended, although i wish the result was not so debilitating in this case. Sorry about that. > On 5 Mar 2016, at 15:03, Alan Bateman

default random access list spliterator

The default List.spliterator() is iterator-based. Could this be improved for random access lists, using List.get(int) to fetch elements instead of List.iterator()? I think it could improve most on Spliterator.trySplit(). The current implementation allocates a new array for split-off elements.