September 2014 - core-libs-dev

[9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly
by olivier.lagneau＠oracle.com 23 Sep '14

23 Sep '14

Please review this fix in for wrong rounding-mode mode behavior of NumberFormat.format(double) in HALF_UP case. https://bugs.openjdk.java.net/browse/JDK-8039915 webrev: http://cr.openjdk.java.net/~olagneau/8039915/webrev.00 <http://cr.openjdk.java.net/%7Eolagneau/8039915/webrev.00> Bug came from a mix of a '5' and 'greater than 5' last digit, when this digit was the last one. Fix consists in properly separating the two cases and cleanly test all possible cases (see JDK-8039915 comments) for the HALF_UP rounding-mode. TieRoundingTest test has been extended with a few cases to check such cases (last digit at the rounding position and != '5') testing: jtreg, jck8, jprt Best regards, Olivier Lagneau

3 8

RFR [8058875]: CharsetEncoder.maxBytesPerChar() should return 4 for UTF-8
by Ivan Gerasimov 23 Sep '14

23 Sep '14

Hello! The UTF-8 encoding allows characters that are 4 bytes long. However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which is not always enough. Would you please review the simple fix for this issue? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8058875 WEBREV: http://cr.openjdk.java.net/~igerasim/8058875/0/webrev/ Sincerely yours, Ivan

4 6

RFR (XXS): 8058887: TEST_BUG: java/util/Formatter/genBasic.sh points to old location of Spp.java
by Claes Redestad 22 Sep '14

22 Sep '14

Hi, can I have a review and sponsor for this trivial fix to make the jtreg test generator script jdk/test/java/util/Formatter/genBasic.sh work in the new build system? bug: https://bugs.openjdk.java.net/browse/JDK-8058887 webrev: http://cr.openjdk.java.net/~redestad/8058887/webrev.01/ /Claes

2 5

RFR for 8043740 (Doubles with large exponents overflow to Infinity incorrectly)
by Sandipan Razzaque 22 Sep '14

22 Sep '14

Hi Brian/all, Fix for the above-mentioned bug is complete. If you (or anyone else as appropriate) could please review the changes and let me know of your comments that would be great! Link for the webrev: http://www.sandipan.net/public/webrevs/8043740/webrev.00/ The patch is inlined below my signature. Cheers, SR --- old/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 22:33:34.947651253 -0400 +++ new/src/share/classes/sun/misc/FloatingDecimal.java 2014-06-01 22:33:34.827651251 -0400 @@ -1992,7 +1992,10 @@ break expLoop; // stop parsing exponent. } } - int expLimit = BIG_DECIMAL_EXPONENT+nDigits+nTrailZero; + + int expLimit = BIG_DECIMAL_EXPONENT + nDigits + nTrailZero + - (nLeadZero - decPt); + if ( expOverflow || ( expVal > expLimit ) ){ // // The intent here is to end up with --- /dev/null 2014-05-28 21:22:08.061671015 -0400 +++ new/test/java/lang/Double/Bug8043740.java 2014-06-01 22:33:35.227651260 -0400 @@ -0,0 +1,40 @@ +/* + * Copyright (c) 2001, 2014, Oracle and/or its affiliates. All rights reserved. + * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. + * + * This code is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 only, as + * published by the Free Software Foundation. + * + * This code is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License + * version 2 for more details (a copy is included in the LICENSE file that + * accompanied this code). + * + * You should have received a copy of the GNU General Public License version + * 2 along with this work; if not, write to the Free Software Foundation, + * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. + * + * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA + * or visit www.oracle.com if you need additional information or have any + * questions. + */ + +/* + * @test + * @bug 8043740 + * @summary Test for Double.parseDouble incorrect normalization of exponent. + */ +public class Bug8043740 { + + public static void main(String[] args) { + String text326 = "00.000000000000000001e326"; // expect 1e308 + double value326 = Double.parseDouble(text326); + if (Double.isInfinite(value326)) { + throw new RuntimeException("String [" + text326 + + "] was incorrectly parsed to Infinity."); + } + } + +}

3 6

RE: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly
by William Price 22 Sep '14

22 Sep '14

> Hi Oliver, First, sorry about mistyping your name, Olivier! > I copied your patch into my shim locally and ran my test cases and > still get a couple failures (see output below). Your patch and my version > differ in the way and order in which we interpret allDecimalDigits and > alreadyRounded. And I should have been more diligent. On second look these are all "very close to a tie" as described in JDK-7131459, so I now believe my test suite is incorrect. It matched the JDK 6-7 behavior but did not account for the JDK8 intended changes for these edge cases. JDK-7131459 test case: 0.15 is actually: 0.1499999999999999944488848768742172978818416595458984375 HALF_UP --> 0.1 OK 0.35 is actually: 0.34999999999999997779553950749686919152736663818359375 HALF_UP --> 0.3 OK 0.85 is actually: 0.84999999999999997779553950749686919152736663818359375 HALF_UP --> 0.8 OK 0.95 is actually: 0.9499999999999999555910790149937383830547332763671875 HALF_UP --> 0.9 OK Above tests used Java 1.8.0_20 (Oracle Corporation) installed at C:\JAVA\latest8\jre Agent installed: yes Patch applied : yes Overall result : FIXED -- William Price | Software Architect | PROS, Inc.

2 1

extcheck
by Pavel Rappo 22 Sep '14

22 Sep '14

Hi everyone, We are thinking of removing the extcheck tool. For those who doesn't remember what it is, here is an extract from its man page: extcheck(1) NAME extcheck - jar conflict detection utility SYNOPSIS extcheck [ -verbose ] [ -Joption ] targetfile.jar DESCRIPTION The extcheck utility checks a specified jar file for title and version conflicts with any extensions installed in the JDK software. Before installing an extension, you can use this utility to see if the same or a more recent version of the extension is already installed... We don't think it is widely used. And will become even less useful with upcoming modularization. Are there any good reasons to keep this thing in the JDK? -Pavel

2 1

JDK 9 RFR of 8058679: More bad characters in BigIntegerTest
by Brian Burkhalter 19 Sep '14

19 Sep '14

Hello bad characters, Issue: https://bugs.openjdk.java.net/browse/JDK-8058679 Webrev: http://cr.openjdk.java.net/~bpb/8058679/webrev.00/ Tested with "-encoding US-ASCII” passed to javac. Thanks, Brian

3 4

Use of internal APIs to protect against memory leaks
by Mark Thomas 19 Sep '14

19 Sep '14

All, As you may know I am one of the Apache Tomcat committers. The Tomcat project was approached recently[1] to see what, if any, internal APIs Tomcat was using as part of the JDK 9 preparations. My response was that the only place Tomcat does this is in the memory leak prevention class [2]. I also commented that if the memory leaks could be addressed then we'd have no need to us the internal API. The response from Oracle was a suggestion to bring up these memory leaks on this list. The memory leaks stem from the generally more complex class loader structure present in a JavaEE container than is typically present in a standalone Java app. At this point, I have two questions. 1. Is this community interested in examining these memory leaks further to see what can be done in the JDK to avoid them? 2. If yes, would you prefer a discussion thread for each leak or one thread for all leaks? Personally, I think a thread per leak would be easier to manage but it might make sense just to look at one leak first as there may well be some common themes that emerge which would save us discussing them on each thread. Mark [1] http://tomcat.markmail.org/thread/n3n6arf3j7f27zhb [2] http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/Jre…

3 2

Re: Urgent [9] RFR (S) : JDK-8039915 NumberFormat.format() does not consider required no. of fraction digits properly
by William Price 19 Sep '14

19 Sep '14

Hi Oliver, I wrote a javaagent-based patch for this bug. I haven't contributed it formally since my employer's legal department is still hung up on the Oracle Contributor Agreement (though we have released it on GitHub under GPLv2 w/CPE). I'm not linking to it here under the assumption that your patch was developed independently and I don't want to confuse the issue with legalities. I copied your patch into my shim locally and ran my test cases and still get a couple failures (see output below). Your patch and my version differ in the way and order in which we interpret allDecimalDigits and alreadyRounded. PATCH SELF TEST: java.text.DigitList.shouldRoundUp(int,boolean,boolean) HALF_UP case StackOverflow.com question 24426438 test case 1: 6.2088 HALF_UP --> 6.209 OK 6.2089 HALF_UP --> 6.209 OK StackOverflow.com question 24426438 test case 2: 0.0 HALF_UP --> 0 OK ... 0.14 HALF_UP --> 0.1 OK 0.15 HALF_UP --> 0.1 expected: 0.2 0.16 HALF_UP --> 0.2 OK ... 0.34 HALF_UP --> 0.3 OK 0.35 HALF_UP --> 0.3 expected: 0.4 0.36 HALF_UP --> 0.4 OK ... 0.84 HALF_UP --> 0.8 OK 0.85 HALF_UP --> 0.8 expected: 0.9 0.86 HALF_UP --> 0.9 OK ... 0.94 HALF_UP --> 0.9 OK 0.95 HALF_UP --> 0.9 expected: 1 0.96 HALF_UP --> 1 OK ... 0.99 HALF_UP --> 1 OK JDK-8041961 test case: 99.9989 HALF_UP --> 100 OK 99.999 HALF_UP --> 100 OK JDK-8039915 test case: 0.95000055 HALF_UP --> 0.950001 OK 0.9500006 HALF_UP --> 0.950001 OK Above tests used Java 1.8.0_20 (Oracle Corporation) installed at C:\JAVA\latest8\jre Agent installed: yes Patch applied : yes Overall result : BAD PATCH (!) on Oracle Corporation Java 1.8.0_20 -- William Price | Software Architect | PROS, Inc. Phone: +1 713-335-5244

1 0

[8u40] RFR (S): Missing part of 8057656 in 8u40 compared to 9
by Vladimir Ivanov 19 Sep '14

19 Sep '14

http://cr.openjdk.java.net/~vlivanov/8058626/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8058626 I've noticed a difference between 8057656 fixes in 8u-dev [1] and 9 [2]. It seems I integrated [3] into 8u and [4] into 9. This change syncs 8u to 9. Thanks! Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/4b2bc06d521c [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/5ae5da7305a8 [3] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.00/ [4] http://cr.openjdk.java.net/~vlivanov/8057656/webrev.01/

3 3