July 2012 - core-libs-dev

Codereview request for 6653797: Reimplement JDK charset repository charsets.jar
by Xueming Shen 16 Jul '12

16 Jul '12

Hi This changeset includes the migration of our JIS0201/0208/0212 based single/ double-byte charsets to the new mapping based implementation. This is the left-over of the effort we put in JDK7 to re-implement most of our charsets in charsets.jar to (1)have better performance (2) small storage foot print and (3) ease the maintenance burden. http://cr.openjdk.java.net/~sherman/6653797/webrev/ Notes of the implementation: (1) jis0201/0208/0212 and their variants are now generated from the mapping table during the build time. (See those new .map *.nr and *.c2b tables) (2) EUC_JP/LINUX_OPEN, SJIS, PCK, ISO2022_JP and its variants are now using these new jis0201/02080212 charsets. (3) Those in red (in webrev) are the old implementation, since no charset uses them anymore, I removed them from the repository) (4) There are two approaches for PCK and SJIS. PCK.java_v1 and SJIS.java_v1 are the one that follows the old implementation, which decode/encodes base on the jis0201/0208 (and the variants) mapping via Ken's algorithm. This is known to be slow and buggy (the algothrim does not take care of illegal sjis cp, see #6653797 and http://cr.openjdk.java.net/~sherman/6653797/Sjis2Jis.java) So in this charset, I generated the direct mapping tables for sjis and pck and use the "general" DoubleByte base class for these two charsets. This results in much faster decoding/encoding and correct mapping for all code points. The downside of this approach is that it adds about 50k uncompressed side to the charsets.jar. But given this change actually reduces about 300K from the rt.jar, we still get a net 250K, so I decided to go with this approach for better performance. It appears to be lots of files (80+) in the webrev, but that number includes the removed old implementation and the tests I put in to guarantee the identical de/encoding result from the old and new implementations (those OLD... test cases), the change is actually not that big:-) So please help review. I can then put this multi-year efforts into rest. -Sherman

3 5

hg: jdk8/tl/jdk: 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path
by kumar.x.srinivasan＠oracle.com 15 Jul '12

15 Jul '12

Changeset: 9e5150e8bcf5 Author: ksrini Date: 2012-07-14 18:00 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/9e5150e8bcf5 7184145: (pack200) pack200 --repack throws NullPointerException when JAR file specified without path Reviewed-by: alanb, sherman ! src/share/classes/com/sun/java/util/jar/pack/Driver.java + test/tools/pack200/RepackTest.java

1 0

Please review: 7184145 pack200 NPE
by Kumar Srinivasan 15 Jul '12

15 Jul '12

Hi, Please review the following bug, it is not yet available on bugs.sun.com, there is a discussion thread jdk7u-dev(a)openjdk.java.net http://cr.openjdk.java.net/~ksrini/7184145/ Thanks Kumar

3 3

Update on alternative hashing for String keys with hash-based Maps
by Mike Duigou 14 Jul '12

14 Jul '12

Hello all; About a month ago a significant change was made to the Java SE 7 and 8 hash based Map implementations. This change was previously proposed and discussed on this list[1]. The change affects all of the hashing based Map implementations (HashMap, Hashtable, WeakHashMap, LinkedHashMap, ConcurrentHashMap), the derived Set implementations (HashSet, LinkedHashSet, etc.) and other classes which depend upon these classes (Properties, UIDefaults). The change to hash based Maps improves performance when a large number of key hash code collisions are encountered. This is accomplished by altering the handling of String keys to use a different (better) hash function. As initially proposed, the alternative hashing behaviour was planned to apply to all hash based Maps larger than 512 elements. Smaller maps would continue to use the existing hashing approach. ConcurrentHashMap, because reasons related to the complexity of it's implementation, would always use the improved approach regardless of map capacity. Providing capacity based triggering of the alternative hashing is intended to improve compatibility by ensuring that the order in which elements are iterated does not change. Specifically, at less than the threshold capacity Map elements will be iterated in the same order as today. At or above the threshold, the iteration order will be different than the current order. Testing and evaluation of existing Java applications has shown us that some applications have explicit or implicit dependence upon the order that keys, values or entries will be iterated. The vast majority of iteration order dependent cases involve small maps--once a map contains hundreds of elements generally incorrect assumptions about iteration order will have already been found and resolved. We believed that triggering the alternative hashing behaviour at 512 element capacity would protect iteration order in cases which depended upon the existing iteration order. Java SE 7 and Java SE 8 have different policies. Java SE 8 is intended to always use alternative hashing of String keys regardless of the capacity of the Map. After integration a number of cases of iteration order dependence were encountered within the OpenJDK code itself, in tests and in user code. Some of these faults were easily diagnosed and correct. Some other cases, because iteration order is not consistent from run-to-run under alternative hashing, proved difficult to isolate and resolve. Following this testing and and consultation with Java licensees and developers it was decided disable the alternative hashing behaviour for Java SE 7. To ensure the greatest degree of compatibility with existing applications it seems best to only enable alternative hashing by explicit control. In Java SE 7u6 it will be necessary to set the system property jdk.map.althashing.threshold in order to enable alternative hashing. It is also still possible that the feature may be enabled by default in future Java SE 7 releases but this will only happen if further testing indicates compatibility can be reasonably assured. Because Java 8 is unreleased and we still wish to shake out iteration order dependencies alternative hashing remains enabled in Java SE 8. Alternative hashing is very likely to be enabled by default in Java SE 8. Doug Lea has been investigating further improvements to handling of key hash code collisions and his design is extremely likely to be the basis for all Java SE 8 hash based Map implementations.[2] Developers and deployers are strongly encouraged to test their applications by enabling the alternative String key hashing feature in Java SE 7u6 or later and/or testing with Java SE 8 builds. BE WARNED: it will probably not be possible to disable alternative hashing in Java SE 8. Applications MUST remove dependencies upon iteration order before they can be deployed with Java SE 8. Thanks, Mike TL;DR: - Java SE 7 and 8 both now support alternative hashing for String keys with hash based Maps - Alternative hashing improves performance when many String key hash codes collide - Alternative hashing impacts key, value and element iteration order - Alternative hashing is currently DISABLED by default for Java SE 7 - Future Java SE 7 releases may enable alternative hashing for "large" (>512 capacity) maps - Developers can enable the eature in Java SE 7 for testing and deployment with a system property - Alternative hashing is ENABLED for all maps in Java SE 8 - It will probably not be possible to disable alternative hashing in Java SE 8 - Hash map key, value and element iteration order WILL be different and unpredictable in Java SE 8 - Different implementation approaches are still being investigated for Java SE 8 and remain subject to change [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2012-May/010238.html [2] http://cs.oswego.edu/pipermail/concurrency-interest/2012-June/009505.html

3 2

[PATCH] Sunbug 7131192: Optimize BigInteger.doubleValue(), floatValue()
by Louis Wasserman 14 Jul '12

14 Jul '12

Not entirely sure I'm posting this in the right place, but it looks like it... This is a patch to optimize BigInteger.doubleValue() and floatValue(), which are both currently implemented by converting to a string and back. Doing it with bit-twiddling and Double.longBitsToDouble improves the speed of those methods by something like two orders of magnitude in my benchmarks. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

3 5

hg: jdk8/tl/jdk: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node
by kurchi.subhra.hazra＠oracle.com 13 Jul '12

13 Jul '12

Changeset: e9461aeff91f Author: khazra Date: 2012-07-13 16:02 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e9461aeff91f 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node Summary: Change native code to convey to Java code whether a new node was added Reviewed-by: alanb, chegar ! src/macosx/classes/java/util/prefs/MacOSXPreferences.java ! src/macosx/classes/java/util/prefs/MacOSXPreferencesFile.java ! src/macosx/native/java/util/MacOSXPreferencesFile.m + test/java/util/prefs/AddNodeChangeListener.java

1 0

Code Review Request: 7160252: (prefs) NodeAddedEvent was not delivered when new node add when new Node
by Kurchi Hazra 13 Jul '12

13 Jul '12

Hi, On Mac OS X, for Preferences, a new child added event was not being delivered to a NodeChangeListener since the existing code depended on the return value of addNode() in the native code, which returns true if a new node is added. However, since addNode() was being called erroneously after a child node is already added to an existing node, addNode() would always return false, resulting in thw new node event never being delivered. This fix propagates the required information of whether a node is added from the method adding the child node itself. In addition, I cleaned up the constructors in MacOSXPreferences.java and added a test (AddNodeChangeListener.java) to cover this case. Finally, there were two prefs tests in ProblemList.txt which are now passing, I have removed these from the ProblemList too. Bug: http://bugs.sun.com/view_bug.do?bug_id=7160252 Webrev: http://cr.openjdk.java.net/~khazra/7160252/webrev.00/ Thanks, Kurchi

4 7

Time format in jar and jarsigner output (was Re: Code review request: 7163483 JarSigner -verify -verbose does not format date string according to locale)
by Weijun Wang 13 Jul '12

13 Jul '12

Hi Jonathan I have these questions: 1. Why always CAPITAL letters for month and weekday? 2. Why always "dd HH:mm:ss zzz yyyy" for the rest? Some locales uses "." instead of ":" as times delimiters. 3. Why always dd after MMM? Some locales prefer dd before MMM. Well, if you really think the current "Fri Jul" output is too English, instead of localizing the string, how about we de-localize it totally and choose a neutral format? There are several flavors of ISO date/time format at http://www.w3.org/TR/NOTE-datetime or we can just choose YYYY-MM-dd HH:mm:ss zzz BTW, the jar command is using the same format, therefore I'm adding core-libs-dev. Thanks Max On 07/06/2012 05:16 PM, Jonathan Lu wrote: > Hello Max, > > I's been a long time since my last mail, I did some investigation and > had some discussion with i18n developers, but still did not see a nice > solution for the alignment problem. There does not seem be an existing > API to do this job in JDK scope. So I implemented a simple format > function, and use it to format under different locales. > > http://cr.openjdk.java.net/~luchsh/7163483_3/ > > The patch is trying to format the code in the same way as > java.util.Date.toString() in the format of "EEE MMM dd HH:mm:ss zzz > yyyy", except for using names of month and DOW in localized format. So > far, it works good for me under all supported locales. > > Here's a test case to verify the vertical alignment, which I has been > posted to i18n mailing list before, > http://cr.openjdk.java.net/~luchsh/VerticalAlignmentTest.java > > It may still fail under "vi_VN" locale with this solution due to test > case limit, but I do not think it is a real failure since the result > fields still get aligned except for multiple words in one field. > > Could you please take a look at the patch? > > Many thanks & best regards > Jonathan > > On 04/25/2012 07:48 PM, Weijun Wang wrote: >> Hi Jonathan >> >> I'm using English. >> >> In your test all the files have a similar modified time so you cannot >> see the difference. However, in my example, you can see that the >> widths for date and hour are not zero-padded so the width can be >> either 1 or 2. >> >> French is even worse >> >> smk 76 10 nov. 2009 08:57:54 bin/vbin/go >> smk 1149 8 avr. 2012 16:03:20 bin/vbin/netbeans >> smk 170 20 nov. 2009 16:47:42 bin/vbin/syncdown >> smk 671 8 févr. 2012 20:11:22 bin/vbin/ssh.desktop >> smk 187 20 nov. 2009 16:47:34 bin/vbin/syncsf >> >> So here even the width of month abbr can be different. >> >> Thanks >> Max >> >> >> On 04/25/2012 07:09 PM, Jonathan Lu wrote: >>> Hello Max, >>> >>> Terribly sorry for my misunderstanding! >>> >>> On 04/25/2012 05:39 PM, Weijun Wang wrote: >>>> >>>> >>>> On 04/25/2012 05:23 PM, Jonathan Lu wrote: >>>>> Hi Max, >>>>> >>>>> On 04/25/2012 05:12 PM, Weijun Wang wrote: >>>>>> >>>>>> >>>>>> On 04/25/2012 03:28 PM, Jonathan Lu wrote: >>>>>>> Hi Weijun, >>>>>>> >>>>>>> Thanks for your time, I've updated the webrev, could you please >>>>>>> take a >>>>>>> look? >>>>>>> http://cr.openjdk.java.net/~luchsh/7163483_2/ >>>>>>> >>>>>>> On 04/24/2012 03:06 PM, Weijun Wang wrote: >>>>>>>> Hi Jonathan >>>>>>>> >>>>>>>> Some comments: >>>>>>>> >>>>>>>> 1. Can you be sure that the new format always has the same length? >>>>>>>> jarsigner tries to output in a tabular style and each column >>>>>>>> should be >>>>>>>> aligned. >>>>>>> >>>>>>> I'm not sure of that, so the test case was updated to compare the >>>>>>> first >>>>>>> several tokens to determine whether there's any differences in the >>>>>>> expression of date time. >>>>>> >>>>>> Sorry, I didn't make myself clear last time, I was mainly afraid of >>>>>> unaligned lines that make the output ugly. >>>>>> >>>>>> For example: >>>>>> >>>>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>>>> >>>>> >>>>> I think that would not be a problem in the new test case which >>>>> compares >>>>> tokenized strings splited by blank spaces instead of String#equals. >>>>> Does >>>>> that make sense? >>>> >>>> I'm not talking about the test. It's the output of jarsigner looking >>>> ugly. >>>> >>>> smk 76 Nov 10, 2009 8:57:54 AM bin/vbin/go >>>> smk 1149 Apr 8, 2012 4:03:20 PM bin/vbin/netbeans >>>> smk 170 Nov 20, 2009 4:47:42 PM bin/vbin/syncdown >>>> smk 671 Feb 8, 2012 8:11:22 PM bin/vbin/ssh.desktop >>>> smk 187 Nov 20, 2009 4:47:34 PM bin/vbin/syncsf >>>> >>>> Compare with the current output: >>>> >>>> smk 76 Tue Nov 10 08:57:54 CST 2009 bin/vbin/go >>>> smk 1149 Sun Apr 08 16:03:20 CST 2012 bin/vbin/netbeans >>>> smk 170 Fri Nov 20 16:47:42 CST 2009 bin/vbin/syncdown >>>> smk 671 Wed Feb 08 20:11:22 CST 2012 bin/vbin/ssh.desktop >>>> smk 187 Fri Nov 20 16:47:34 CST 2009 bin/vbin/syncsf >>> >>> I did not see unaligned format in my testing, did you get these >>> unaligned output after applying the patch? From above lines, I see the >>> starting indices of date string in each line are always the same, which >>> is achieved by jarsigner, but the length of the date strings are not the >>> same, which locale were you testing on? >>> >>>> >>>> Thanks >>>> Max >>>> >>>>> >>>>>> Thanks >>>>>> Max >>>>>> >>>>>>> >>>>>>>> >>>>>>>> 2. You might need to reformat the modified line to make it fit >>>>>>>> into 80 >>>>>>>> characters width. >>>>>>>> >>>>>>>> 3. Why not include the test inside the changeset? >>>>>>> 2, 3 were done in the new patch >>>>>>>> >>>>>>>> Thanks >>>>>>>> Max >>>>>>>> >>>>>>>> >>>>>>>> On 04/23/2012 05:46 PM, Jonathan Lu wrote: >>>>>>>>> Hello security-dev, >>>>>>>>> >>>>>>>>> Here's a patch for bug 7163483, could anybody please help to >>>>>>>>> take a >>>>>>>>> look? >>>>>>>>> http://cr.openjdk.java.net/~luchsh/7163483/ >>>>>>>>> >>>>>>>>> The problem is that command "jarsigner -verify -verbose my.jar" >>>>>>>>> does not >>>>>>>>> format date string according to current locale. following simple >>>>>>>>> test >>>>>>>>> case can be used to disclose this problem. >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * Copyright (c) 2012 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. >>>>>>>>> */ >>>>>>>>> >>>>>>>>> /* >>>>>>>>> * Portions Copyright (c) 2012 IBM Corporation >>>>>>>>> */ >>>>>>>>> >>>>>>>>> >>>>>>>>> import java.io.ByteArrayOutputStream; >>>>>>>>> import java.io.PrintStream; >>>>>>>>> import java.util.Locale; >>>>>>>>> import sun.security.tools.JarSigner; >>>>>>>>> >>>>>>>>> public class bug7163483 { >>>>>>>>> >>>>>>>>> public static void main(String[] args) throws Exception { >>>>>>>>> final String[] arg = { "-verify", "-verbose", >>>>>>>>> System.getProperty("java.home")+"/lib/jce.jar"}; >>>>>>>>> >>>>>>>>> ByteArrayOutputStream stream = new ByteArrayOutputStream(1024*64); >>>>>>>>> PrintStream out = new PrintStream(stream); >>>>>>>>> System.setOut(out); >>>>>>>>> >>>>>>>>> Locale.setDefault(Locale.GERMAN); >>>>>>>>> JarSigner js = new JarSigner(); >>>>>>>>> js.run(arg); >>>>>>>>> >>>>>>>>> out.flush(); >>>>>>>>> String s1 = stream.toString(); >>>>>>>>> s1 = s1.substring(0, s1.length()/2); >>>>>>>>> stream.reset(); >>>>>>>>> >>>>>>>>> Locale.setDefault(Locale.FRANCE); >>>>>>>>> js = new JarSigner(); >>>>>>>>> js.run(arg); >>>>>>>>> >>>>>>>>> out.flush(); >>>>>>>>> String s2 = stream.toString(); >>>>>>>>> s2 = s2.substring(0, s2.length()/2); >>>>>>>>> >>>>>>>>> if (s1.equals(s2)) { >>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>> throw new RuntimeException( >>>>>>>>> "JarSigner verbose outputs are the same after setting locale!!"); >>>>>>>>> } else { >>>>>>>>> System.err.println("Header output for GERMAN locale is:"+s1); >>>>>>>>> System.err.println("Header output for FRANCE locale is:"+s2); >>>>>>>>> System.err.println("Test passed!"); >>>>>>>>> } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> Thanks and best regards! >>>>>>>>> - Jonathan Lu >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> Best regards! >>>>>>> - Jonathan >>>>>>> >>>>>> >>>>> Thanks & regards! >>>>> - Jonathan >>>>> >>>> >>> >>> Thanks >>> - Jonathan >>> >> > >

2 2

hg: jdk8/tl/langtools: 7181578: javac reports uninitialized variable with nested try...finally blocks
by maurizio.cimadamore＠oracle.com 13 Jul '12

13 Jul '12

Changeset: 934a89402f85 Author: mcimadamore Date: 2012-07-13 12:58 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/934a89402f85 7181578: javac reports uninitialized variable with nested try...finally blocks Summary: regression introduced in refactoring of Flow.java Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Flow.java + test/tools/javac/DefiniteAssignment/T7181578.java

1 0

hg: jdk8/tl/jaxp: 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled
by huizhe.wang＠oracle.com 13 Jul '12

13 Jul '12

Changeset: 6e444b892c99 Author: joehw Date: 2012-07-12 21:06 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/6e444b892c99 7183760: DocumentBuilder.parse(String uri) is not IPv6 enabled Summary: removing the hack of using escapeNonUSAscii. this is the same patch as 7166896 for 7u8. Reviewed-by: psandoz, lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java

1 0