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

Hello! LW> Worth noting: Guava uses a similar implementation for LW> Ordering.leastOf, but instead of sorting the array when it's LW> filled, does a quickselect pass to do it in O(k) time instead of O(k log k).  Thank you for mentioning Guava. Unfortunately quickselect is not stable, while

Re: RFR 8150840: Add an internal system property to control the default level of System.Logger when java.logging is not present.

> On Mar 4, 2016, at 9:05 AM, Daniel Fuchs wrote: > > http://cr.openjdk.java.net/~dfuchs/webrev_8150840/webrev.01/ Looks okay in general. I’m not a fan of using GetPropertyAction. While it’s convenient as the class already exists, method refs and anonymous class

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 Stefan, > -Original Message- > From: Stefan Bodewig [mailto:bode...@apache.org] > Sent: Saturday, March 05, 2016 7:56 PM > To: d...@ant.apache.org; Uwe Schindler > Cc: 'Alan Bateman' ; core-libs- > d...@openjdk.java.net;

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

Hello! One of the popular bulk data operation is to find given number of least or greatest elements. Currently Stream API provides no dedicated operation to do this. Of course, it could be implemented by custom collector and some third-party libraries already provide it. However it would be quite

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)

Thanks Alan, I am glad that the appending of "#resource" is indeed a bug. > > I'd suggest to please ASAP revert the Multi-Release JAR file patch and > provide a new preview build as soon as possible. I think there is more work > needed to fix this. If this does not revert to the original state,

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 Claes, is there a way to just build a new runtime library without compiling a full JDK (including Hotspot). So just replacing the jimage files locally? Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany

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 05/03/2016 13:24, Uwe Schindler wrote: : I'd suggest to please ASAP revert the Multi-Release JAR file patch and provide a new preview build as soon as possible. I think there is more work needed to fix this. If this does not revert to the original state, it will be impossible to build

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, similar issues were discovered too late to stop b108, e.g., https://bugs.openjdk.java.net/browse/JDK-8150920. Fix is already in jdk9/dev, so I think the next build should be more well-behaved and hope we can provide it more promptly than normal. If you can build OpenJDK from jdk9/dev and

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 OpenJDK Core Developers, you may know the Apache Lucene team is testing early access releases of Java 9. We reported many bugs already, but most of them only applied to Hotspot and Lucene itsself. But this problem since build 108 is now really severe, because it breaks the build system

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

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. Otherwise looks good. Stephen On 3 March 2016 at 18:54,