August 2014 - core-libs-dev

FilterOutputStream.close() throws exception from flush()
by Bernd Eckenfels 20 Oct '14

20 Oct '14

Hello, back in 2011 there was a discussion about the new changed behavior of FilterOutputStream (and BufferedOutputStream) in regards to not anymore swalloging IOExceptions from flush() on this list (thats where I got the subject from). This was generally a very good improvement (and I am glad that https://bugs.openjdk.java.net/browse/JDK-6335274 thereby got fixed). However the implementation with the try-with-resource has a problem: when flush() and close() report the same exception instance the construction of the suppressed exception will actually fail with an IllegalArgumentException. This IllegalArgumentException of Throwable.addSuppressed is very unfortunate (it would be better simply ignore it). Anyway, this new behavior broke a Unit-Test for Apache VFS as you can see here: https://issues.apache.org/jira/browse/VFS-521 I think this can only be fixed in Throwable by avoiding this IllegalArgumentException or by the close() method not using try-with-resource. For reference, according to this changeset other locations are affected as well: http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/759aa847dcaf Gruss Bernd PS: I wrote a german blogpost about the FilterOutputStream here: http://itblog.eckenfels.net/archives/505-FOS-considered-harmfull.html The following exception is produced by the testcode: Exception in thread "main" java.lang.IllegalArgumentException: Self-suppression not permitted at java.lang.Throwable.addSuppressed(Throwable.java:1043) at java.io.FilterOutputStream.close(FilterOutputStream.java:159) at testfos.Main.main(Main.java:6) Caused by: java.io.IOException: remebered IO Exception at testfos.FailingOS.<init>(FailingOS.java:10) at testfos.Main.main(Main.java:5) package testfos; public class Main { public static void main(String[] args) throws java.io.IOException { java.io.BufferedOutputStream buf = new java.io.BufferedOutputStream(new testfos.FailingOS()); buf.close(); // expected: IOException } } package testfos; public class FailingOS extends java.io.OutputStream { private java.io.IOException ex; public FailingOS() { ex = new java.io.IOException("remebered IO Exception"); } public void write(int b) throws java.io.IOException { } public void flush() throws java.io.IOException { throw ex; } public void close() throws java.io.IOException { throw ex; } }

4 5

Review request for JDK-8051561: Convert JAXP function tests: javax.xml.xpath.* to jtreg (testNG) tests
by Eric Wang 15 Oct '14

15 Oct '14

Hi Joe, alan and every one I'm working on jaxp functional test colocation which is traced by the bug JDK-8043091 <https://bugs.openjdk.java.net/browse/JDK-8043091>. We have finished to convert a few suite and the jaxp/xpath tracked by bug JDK-8051561 <https://bugs.openjdk.java.net/browse/JDK-8051561> is the first one chosen for public review. Can you please review the webrev below? your comments given would be helpful for our future work. http://cr.openjdk.java.net/~ewang/JDK-8051561/webrev.00/ Thanks, Eric

8 24

java.util.logging.FileHandler integer overflow prevents file rotation
by Stanimir Simeonoff 06 Oct '14

06 Oct '14

java.util.logging.FileHandler uses ints to track the written bytes that can cause negative value for java.util.logging.FileHandler.MeteredStream.written as there is no check in any of the write methods. The overflow prevents the check in FileHandler.publish(LogRecord) meter.written >= limit to ever trigger, esp. setting limit to Integer.MAX_VALUE that effectively always prevents file rotation. On a flip note, MeteredStream should be a static class. On another flip note, FileHandler should be using long as part of the API and internal implementation. ints are limited to 2GiB even when properly implemented that's a relatively low amount for certain types of logging files. So I propose adding overloaded c-tors FileHandler(String pattern, long limit, int count, boolean append) and FileHandler(String pattern, long limit, int count). LogManager should have a method "long getLongProperty(String name, long defaultValue)" to initialize limit. Thanks Stanimir

3 2

JEP 198: Light-Weight JSON API
by mark.reinhold＠oracle.com 01 Oct '14

01 Oct '14

New JEP Candidate: http://openjdk.java.net/jeps/198 - Mark

5 4

RFR [9]: 8050142: Optimize java.util.Formatter
by Claes Redestad 24 Sep '14

24 Sep '14

Hi, please review this patch which optimizes away some allocations from java.util.Formatter and achieve 1.1-1.3x speedups of micros targetting String.format. See bug for more details. webrev: http://cr.openjdk.java.net/~redestad/8050142/webrev.0 bug: https://bugs.openjdk.java.net/browse/JDK-8050142 Testing: JPRT, jtreg (java/lang/String, java/util/Formatter), SPECjbb2013 and microbenchmarks Thanks! /Claes

8 32

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

RFR [8046339] sun.rmi.transport.DGCAckHandler leaks memory
by Ivan Gerasimov 12 Sep '14

12 Sep '14

Hello everyone! It has been reported that under some conditions instances of sun.rmi.transport.DGCAckHandler accumulate and can cause OOM Error. This is because they are stored in the global DGCAckHandler.idTable map, and may fail to be removed if a timeout has expired. The webrev contains a fix proposed by Darryl Mocek back in 2011. Unfortunately I couldn't come up with a regression test for the fix. However, the fix looks obviously correct, especially taking into account the comment to the constructor: * References added to this DGCAckHandler will be held strongly * until its "release" method is invoked or (after the * "startTimer" method has been invoked) the timeout has expired. Would you please help review the fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8046339 WEBREV: http://cr.openjdk.java.net/~igerasim/8046339/0/webrev/ Sincerely yours, Ivan

2 2

RFR: JDK-8056934: ZipInputStream does not correctly handle local header data descriptors with the optional signature missing
by Martin Buchholz 11 Sep '14

11 Sep '14

Hi Xueming and Alan, I'd like you to do a code review. https://bugs.openjdk.java.net/browse/JDK-8056934 http://cr.openjdk.java.net/~martin/webrevs/openjdk9/zip-DataDescriptorSigna… This seems like an atypical off-by-one, so I'm not sure how it happened, and I have the nagging feeling I'm missing something. Greg, this java code review contains a python program!

3 7

RFR(S): 8055055: Improve numeric parsing in java.sql
by Claes Redestad 11 Sep '14

11 Sep '14

Hi, can I have a review of this small patch which improves performance of java.sql.Time::valueOf (~1.3x) and java.sql.Timestamp::valueOf (~1.9x). Uses Integer.parseInt with offset to make intermediary substrings unnecessary and improves the nanosecond fraction calculation to not use String concatenation. bug: https://bugs.openjdk.java.net/browse/JDK-8055055 webrev: http://cr.openjdk.java.net/~redestad/8055055/webrev.0/ Thanks! /Claes

2 7

RFR: 5043030 (reflect) unnecessary object creation in reflection
by Andrej Golovnin 11 Sep '14

11 Sep '14

Hi Joe, I have prepared a patch for the issue JDK-5043030. The patch consists of two parts: one for jdk and one for hotspot. You can find the webrevs here: JDK-patch: https://db.tt/7DYph0OH Hotspot-patch: https://db.tt/hHsN0yn4 The JDK-patch has two tests to verify the changes. Please review it and I hope you can sponsor it. Best regards, Andrej Golovnin

4 24