RFR-8148250: Stream.limit parallel ordered performance

Hello! Here's webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148250/r1/ With best regards, Tagir Valeev. >> On 26 Jan 2016, at 16:51, Tagir F. Valeev wrote: >> >> Hello! >> >> Thank you for review! Here's the issue: >> https://bugs.openjdk.java.net/browse/JDK-8148250

Re: RFR-8148250: Stream.limit parallel ordered performance

> On 29 Jan 2016, at 14:47, Tagir F. Valeev wrote: > > Hello! > > Here's webrev: > http://cr.openjdk.java.net/~tvaleev/webrev/8148250/r1/ > Thanks, reviewed and in my queue to push. Paul.

Re: RFR 8148115: Stream.findFirst for unordered source optimization

Here's updated webrev: http://cr.openjdk.java.net/~tvaleev/webrev/8148115/r2/ PS> 293 if (!this.mustFindFirst) { PS> 310 if (this.mustFindFirst) { PS> Small thing, no need for “this”. Done. PS> You can now use Optional.ifPresentOrElse, which was added in 9: PS>

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

On 27/01/2016 23:37, Steve Drach wrote: I'm still wondering about the phrase "root entry" as it continues to give the impression (to me anyway) that it's a resource in the root directory. I think "root" works in the JEP because it deals with simple resources like A.class and B.class that are

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi Nadeesh, Looks fine, Thanks, Roger On 1/27/2016 11:34 AM, nadeesh tv wrote: Hi all, Thanks for the suggestions. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8141452/webrev.01/ Regards, Nadeesh TV On 1/25/2016 10:24 PM, Roger Riggs wrote: Hi Stephen, Nadeesh,

Re: RFR (L) JEP 280: Indify String Concatenation (integration)

On 2016-01-27 14:55, Aleksey Shipilev wrote: c) (XS) Build changes that force emitting the "legacy" inline StringBuilder concat in a few cases (e.g. when pre-JDK 9 bytecode is expected): http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/ In what context do we need pre-JDK 9

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

On 29/01/16 14:52, Roger Riggs wrote: Hi Nadeesh, Looks fine, Thanks, Roger On 1/27/2016 11:34 AM, nadeesh tv wrote: Hi all, Thanks for the suggestions. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8141452/webrev.01/ +1 This looks fine. Martin, Doug, I assume you

Stream.foldLeft, one more time (8133680)

Hello! What do you think, is it still reasonable to add foldLeft operation to JDK-9 Stream API (foldLeft only, no foldRight)? I propose the following signatures: interface Stream { public U foldLeft(U seed, BiFunction accumulator); public Optional foldLeft(BinaryOperator

Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

> On 29 Jan 2016, at 13:43, Hamlin Li wrote: > > Hi Paul, > > Sorry for delayed response, have been occupied by other higher priority task. > Thanks for your review, I agree with you that your second approach is better. > New webrev:

Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

Hi Paul, Sorry for delayed response, have been occupied by other higher priority task. Thanks for your review, I agree with you that your second approach is better. New webrev: http://cr.openjdk.java.net/~mli/8076458/webrev.01/ Below are times cost for different ops: total:169.996

Re: RFR 8138578:MethodHandles.Lookup.findSpecial() Javadoc fails to consider static methods

Hi All, Please review the updated patch- http://cr.openjdk.java.net/~srastogi/8138578/webrev.01/ I verified Lookup.unreflectSpecial() also throws java.lang.IllegalAccessException so updated the JavaDoc. Thanks, Shilpi Original Message Subject: Re: RFR

Re: ArrayList.subList().spliterator() is not late-binding

Hi Tagir, Last-binding while adding some complexity to the implementation is an important property, as it is to fail-fast on a best effort basis. When one has mutable collections that can be structurally modified and lazy views over those collections (Streams/Iterators) then those views really

Re: JNI VERSION CHANGE: RFR: 8145098: JNI GetVersion should return JNI_VERSION_9

Thanks for the review, Dan. We'll see how the 9 v. 9_0 discussion plays out. Rachel On 1/28/2016 1:37 PM, Daniel D. Daugherty wrote: On 1/27/16 4:02 PM, Rachel Protacio wrote: Hello! Small but important change for review: updating the JNI_VERSION and in so doing, changing the format from

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

I missed that this was modifying jsr166 files - looking now... On Fri, Jan 29, 2016 at 7:12 AM, Chris Hegarty wrote: > On 29/01/16 14:52, Roger Riggs wrote: >> >> Hi Nadeesh, >> >> Looks fine, >> >> Thanks, Roger >> >> >> On 1/27/2016 11:34 AM, nadeesh tv wrote: >>> >>>

Re: RFR: 8079136: Accessing a nested sublist leads to StackOverflowError

Thank you Tagir for the review! On 29.01.2016 7:16, Tagir F. Valeev wrote: Hello! AbstractList::subListRangeCheck could be replaced with new Objects::checkFromToIndex for consistency with other methods. Also Yes, that would be good. However, for AbstractList.subList() we have this in spec:

Re: RFR 8148115: Stream.findFirst for unordered source optimization

> On 29 Jan 2016, at 15:20, Tagir F. Valeev wrote: > > Here's updated webrev: > > http://cr.openjdk.java.net/~tvaleev/webrev/8148115/r2/ > Thanks, reviewed and in my queue. > PS> 293 if (!this.mustFindFirst) { > PS> 310 if (this.mustFindFirst) {

Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

On 2016/1/29 20:53, Paul Sandoz wrote: On 29 Jan 2016, at 13:43, Hamlin Li wrote: Hi Paul, Sorry for delayed response, have been occupied by other higher priority task. Thanks for your review, I agree with you that your second approach is better. New webrev:

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

I propose that we the jsr166 maintainers take over this change (sorry for butting in!), pushing it into openjdk from jsr166 CVS. The tests as they are written today won't work because TimeUnit/Basic.java is not a testng test. But I don't think we should fix that - instead, tests for these methods

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

In the ideal fix, all methods that take the combination (long, TimeUnit) would be supplemented by an override that takes (Duration). eg. Future.get(long, TimeUnit) has an additional get(Duration). However, this is a lot of work, might be unpopular and would be slower for j.u.concurrent use. The

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>> I’ve released a new webrev, >> http://cr.openjdk.java.net/~sdrach/8132734/webrev.04/index.html >> that >> addresses the above issue. >> > Thank you, the javadoc is much clearer and readable now. > > The first mention of

RFR [9]: 8138699 Iproving JAX-B javadoc

Hi everybody, please review following patch - those are changes to javadoc, previously consulted with sqe. The javadoc now is not always clear, which makes difficult to develop proper tests. JIRA: https://bugs.openjdk.java.net/browse/JDK-8138699 webrev:

Re: RFR: 8148570: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file

Hi Ramanand, Is there a specific regression test that can be written for the case? Otherwise, looks fine. Roger On 1/29/2016 12:56 PM, Ramanand Patil wrote: HI all, Please review this trivial fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8148570 Bug Description - While

Re: RFR: 8076458: java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java timeout

> On 29 Jan 2016, at 17:43, Hamlin Li wrote: > > > > On 2016/1/29 20:53, Paul Sandoz wrote: >>> On 29 Jan 2016, at 13:43, Hamlin Li wrote: >>> >>> Hi Paul, >>> >>> Sorry for delayed response, have been occupied by other higher priority >>>

RFR: 8148570: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file

HI all, Please review this trivial fix for Bug - https://bugs.openjdk.java.net/browse/JDK-8148570 Bug Description - While compiling and building TZDB data file(tzdata2016a) when transition rule(for Iran) doesn't have the day-of-week data a null pointer exception is thrown. Webrev -

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 29 Jan 2016, at 18:27, Steve Drach wrote: >> >> This may have come up before but JarFile has two sets of constructors, one >> takes the file path as a String, the other as a File. I just wondering about >> introduce a second constructor so that they match. > > We

Please approve fix for failing test JDK-8148638

Sorry, I made a mistake in 8146467 and checked in a broken test. Please approve my temporary fix https://bugs.openjdk.java.net/browse/JDK-8148638 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/CompletableFuture-temporary-revert/

Re: Please approve fix for failing test JDK-8148638

Thanks! Pushed. On Fri, Jan 29, 2016 at 1:56 PM, Roger Riggs wrote: > +1 > > > On 1/29/2016 4:49 PM, Martin Buchholz wrote: >> >> Sorry, I made a mistake in 8146467 and checked in a broken test. >> Please approve my temporary fix >>

Re: RFR 7183985: Class.getAnnotation() throws an ArrayStoreException when the annotation class not present

On Thu, Jan 28, 2016 at 11:50 AM, Joel Borggrén-Franck < joel.borggren.fra...@gmail.com> wrote: > Thanks for the update. I think it makes sense to expand testing > slightly, testing all three parsing clauses that you fixed, and for > all three of them also checking that a "thing" after the broken

JDK 9 RFR of JDK-8148653: Problem list B5086147.java on windows

The test java/net/URL/B5086147.java has been failing on windows since the changesets for JDK-8147462 and JDK-8145104 were pushed. The test should be problem listed until the root cause of JDK-8148626 is found and fixed. Please review the patch to do this below. Thanks, -Joe diff -r

RFR 9: 8146773 java/lang/ref/CleanerTest.java CleanerTest.testRefSubtypes() fails

Please review a fix for two test issues. When run with -Xcomp and other switches that change GC behavior; the CleanerTest was not giving enough to time to see the result of cleaning. Also, added an adjustment of the number of cycles by the timeoutFactor. Webrev:

JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java

Hello, Until JDK-8148540 is addressed, the test sun/nio/ch/TestMaxCachedBufferSize.java should be problem listed on the platforms is fails on. Please review the patch below. Thanks, -Joe diff -r eecb3e75b0d8 test/ProblemList.txt --- a/test/ProblemList.txtThu Jan 28 18:08:53 2016 -0800

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Here is a proposed alternative patch (against jsr166 CVS). Code is reworded and reformatted. Tests are junit-ified. Round-trip tests are added. toChronoUnit no longer throws IAE, because it cannot (and we commit to having ChronoUnit be a superset of TimeUnit, in perpetuity; toChronoUnit will

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

On Fri, Jan 29, 2016 at 11:17 AM, Roger Riggs wrote: > Hi Martin, > > Where did IllegalMonitorStateException creep in from? Oops. My Emacs keeps suggesting the wrong completion. Fixed. > Should I update the CCC I started or will you start fresh? If you could update

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi Martin, Where did IllegalMonitorStateException creep in from? Should I update the CCC I started or will you start fresh? Otherwise, ok. Roger On 1/29/2016 2:12 PM, Martin Buchholz wrote: Here is a proposed alternative patch (against jsr166 CVS). Code is reworded and reformatted. Tests

RE: RFR: 8148570: TzdbZoneRulesCompiler.java throws Null Pointer Exception While Compiling and building TZDB data file

Hi Roger, Writing the regression test will be little tricky, because the transition rules are read from the IANA provided tzdata files and during JDK building the tzdb.dat file is created. This issue was actually found after JDK9 build failure with integrated tzdata2016a files. Being a

Re: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java

On 29/01/2016 18:53, joe darcy wrote: Hello, Until JDK-8148540 is addressed, the test sun/nio/ch/TestMaxCachedBufferSize.java should be problem listed on the platforms is fails on. Please review the patch below. I think this test will be tricky to be reliable on 32-bit so the simplest

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

Hi Martin, On 1/29/2016 2:28 PM, Martin Buchholz wrote: On Fri, Jan 29, 2016 at 11:17 AM, Roger Riggs wrote: Hi Martin, Where did IllegalMonitorStateException creep in from? Oops. My Emacs keeps suggesting the wrong completion. Fixed. Should I update the CCC I

Re: JDK 9 RFR of JDK-8148627: Problem list TestMaxCachedBufferSize.java

Hi Alan, Limiting the test to 64-bit platforms is fine with me; I'll push the change as you've suggested later today. Thanks, -Joe On 1/29/2016 11:59 AM, Alan Bateman wrote: On 29/01/2016 18:53, joe darcy wrote: Hello, Until JDK-8148540 is addressed, the test

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

>>> One other thing that I've been wondering about is the stream() and >>> entries() methods. Has there been any discussion about these doing filter? >> >> Not that I’m aware of. >> >>> Maybe it is too expensive and best left to the user of the API? Part of the >>> context for asking is

Re: RFR:JDK-8141452:Convert between TimeUnit and ChronoUnit

On Fri, Jan 29, 2016 at 9:37 AM, Stephen Colebourne wrote: > In the ideal fix, all methods that take the combination (long, > TimeUnit) would be supplemented by an override that takes (Duration). > eg. Future.get(long, TimeUnit) has an additional get(Duration). > However,