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 m

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 Vers

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) = 1.00

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 pow to Java >http:/

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 comm

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 f

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 reviewer too ? > > -phil.

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 wrote: > > > Hi guys, > > > > Here's the requested script checkin:

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

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: > http://cr.openjdk.java.net/~

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

Done! On Thu, Sep 17, 2015 at 1:14 AM, Chris Hegarty wrote: > 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-m

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 L

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 repor

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 toString() method of: test/sun

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 > description: > > http://cr.openj

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/ https://bugs.openjdk.java.net/b

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 j

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. P

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 test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest

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: 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 licence header, move t

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 is

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++