[PATCH] Collectors.counting() does unnecessary boxing on every accumulation

Hello! Could you please consider the following very simple patch to Collectors.counting() implementation? diff --git a/src/java.base/share/classes/java/util/stream/Collectors.java b/src/java.base/share/classes/java/util/stream/Collectors.java ---

Re: RFR(m) 2: 8072722: add stream support to Scanner

As an alternative to additional boolean field, you could use one bit of expectedCount/modCount int field(s): - let initial value of expectedCount be 1 (odd value) - instead of (expectedCount >= 0) ==> (expectedCount != 1) - let initial value of modCount be 0 (even value) - instead of modCount++

Re: RFR: 8136656: Check in blessed-modifier-order.sh

On 16 Sep 2015, at 20:36, Martin Buchholz wrote: > Hi guys, > > Here's the requested script checkin: > > https://bugs.openjdk.java.net/browse/JDK-8136656 > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/ Looks fine. Just add an appropriate

Re: RFR: 8136656: Check in blessed-modifier-order.sh

On 2015-09-16 21:36, Martin Buchholz wrote: Hi guys, Here's the requested script checkin: https://bugs.openjdk.java.net/browse/JDK-8136656 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order.sh/ Martin, We're trying to retire the "make/scripts" directory, since this

Re: [PATCH] Collectors.counting() does unnecessary boxing on every accumulation

Hi Tagir, Thanks, looks good. I created: https://bugs.openjdk.java.net/browse/JDK-8136686 and i also included an update to a test. Assuming no further review comments i will commit tomorrow. Paul. diff -r 4be07e0eb9b6

RFR(XS): 8136690: AIX: libjimage should be linked with the C++ compiler

Hi, can somebody please review the following AIX change which fixes the build on AIX after "8087181 Move native jimage code to its own library (maybe libjimage)": http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/ https://bugs.openjdk.java.net/browse/JDK-8136690 Change 8087181 moved the

ProcessBuilder still leaking memory

Hi all, I am still seeing a memory leak caused by process builder It seems to be the same as reported here: https://bugs.openjdk.java.net/browse/JDK-8054841 which is claimed to be fixed, but in 8u45 and 8u60 it still reproduces on my Amazon Linux Linux ip-10-208-67-36 3.2.30-49.59.amzn1.x86_64 #1

Re: [PATCH] Collectors.counting() does unnecessary boxing on every accumulation

Hello! Thank you very much! With best regards, Tagir Valeev. PS> Hi Tagir, PS> Thanks, looks good. PS> I created: PS> https://bugs.openjdk.java.net/browse/JDK-8136686 PS> and i also included an update to a test. PS> Assuming no further review comments i will commit tomorrow. PS> Paul.

Re: RFR(XS): 8136690: AIX: libjimage should be linked with the C++ compiler

On 2015-09-17 12:08, Volker Simonis wrote: Hi, can somebody please review the following AIX change which fixes the build on AIX after "8087181 Move native jimage code to its own library (maybe libjimage)": http://cr.openjdk.java.net/~simonis/webrevs/2015/8136690/

Re: RFR: 8136656: Check in blessed-modifier-order.sh

On 17 Sep 2015, at 17:08, Martin Buchholz wrote: > Done! The updated webrev ( in-place ) looks good to me Martin. -Chris. > On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty > wrote: > On 16 Sep 2015, at 20:36, Martin Buchholz

Re: ProcessBuilder still leaking memory

Hi Fabian! The issue JDK-8054841 was due to failing to free natively allocated memory. It wouldn't cause Java heap space exhaustion, so you must be observing something different. Can you please provide some more details about your use case? Sincerely yours, Ivan On 17.09.2015 12:09, Fabian

Re: RFR: 8136570: Avoid setting environment variables related to /usr/dt

+1 ( ie approved). May need a core-libs reviewer too ? -phil. On 9/16/2015 10:53 AM, Martin Buchholz wrote: Webrev regenerated http://cr.openjdk.java.net/~martin/webrevs/openjdk9/usr-dt-environment/usr-dt-environment.patch

Running blessed-modifier-order on the rest of the JDK

flush with success, I ran blessed-modifier-order on the entire JDK forest, and it seems to work fine. But we want to leave out code maintained elsewhere. How to identify that? Below are changes inside javadoc, which seem fine to me. $ hg tcommand hg diff | g '^[+-] *\*' - * Access to

Re: RFR 9: 8132735: java/lang/ProcessHandle/TreeTest failed with java.lang.AssertionError: Start with zero children

Looks ok to me Roger. -Chris. On 16 Sep 2015, at 22:44, Roger Riggs wrote: > Please review this test fix so the test code only operates on processes it > spawns. > On Windows, other processes may show up as children that are not part of the > test. > > Webrev: >

Re: RFR: 8136570: Avoid setting environment variables related to /usr/dt

Too late, I just committed... If people have second thoughts, this change should be watered down rather than reverted anyways, so an independent followup change seems reasonable. On Thu, Sep 17, 2015 at 9:10 AM, Phil Race wrote: > +1 ( ie approved). May need a core-libs

Re: RFR: 8129957 - Deadlock in JNDI LDAP implementation when closing the LDAP context

Your proposed fix looks fine Rob. Thanks. > On 14 Sep 2015, at 16:25, Rob McKenna wrote: > > Hi folks, > > So on further investigation it looks like we could get away with reducing the > amount of locking in LdapClient. Here is a proposed fix followed by a >

RFR (xs) : 8077874 : [TESTBUG] The test com/sun/corba/cachedSocket/7056731.sh should not be run on JRE

Test bug correction to allow the jdb command to be launched via compilejdk parameter where necessary. I've checked for similar usage across other corba tests and this one seems to be the only one. Also made a small edit to use the $JAVA variable where possible. (was already defined) bug

Re: [verona.stage] RFR 8134365: Test test/sun/misc/Version/Version.java should follow Verona rules for trailing zeros

On 9/16/2015 6:44 PM, Mandy Chung wrote: On Sep 16, 2015, at 11:23 AM, Alejandro E Murillo wrote: Please review this change: Bug: https://bugs.openjdk.java.net/browse/JDK-8134365 Webrev: http://cr.openjdk.java.net/~amurillo/9/8134365/ This change modifies the

Re: RFR: 8136570: Avoid setting environment variables related to /usr/dt

Doctor Deprecator approves. Not only is this a win because it's a pure-deletion change, it's a double win because it removes a side effect from a function that's supposed to "get" and initialize Java properties values. s'marks On 9/17/15 9:12 AM, Martin Buchholz wrote: Too late, I just

Re: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java

Hi Joe, This looks fine. +1. Brian On Sep 15, 2015, at 7:11 PM, Joseph D. Darcy wrote: > At long last, I've started the port of the C version of FDLIBM (freely > distributable math library) from C to Java, beginning with the pow method: > >JDK-8134795: Port fdlibm

RE: [verona.stage] RFR 8087203: Adapt Version.java.template to the JEP-223 new version string format

Hi, Alejandro. This cleanup looks good to me. Thanks, iris (not a JDK 9 Reviewer) -Original Message- From: Alejandro E Murillo Sent: Wednesday, September 16, 2015 11:04 AM To: core-libs-dev@openjdk.java.net Cc: verona-...@openjdk.java.net Subject: [verona.stage] RFR 8087203: Adapt

Re: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java

Hi. >At long last, I've started the port of the C version of FDLIBM (freely >distributable math library) from C to Java, beginning with the pow method: I ran it through tests of my math lib (jafama), and found the following issue: // ok     StrictMath.pow(1.0004, 2.1E9) =

Re: JDK 9 RFR of JDK-8134795: Port fdlibm pow to Java

Hi Jeff, Thanks for the bug report; I'll take a look into this, -Joe On 9/17/2015 3:12 PM, Jeff Hain wrote: Hi. >At long last, I've started the port of the C version of FDLIBM (freely >distributable math library) from C to Java, beginning with the pow method: I ran it through tests of