May 2012 - core-libs-dev

Code Review Request: 7165118: (prefs) AbstractPreferences.remove(null) does not throw NPE
by Kurchi Hazra 03 May '12

03 May '12

Hi, This is a simple fix to enable AbstractPreferences.remove() to check for a null argument and throw a NullPointerException if required. I have also modified test/java/util/prefs/RemoveNullKeyCheck.java to cover this case. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7165118 Webrev: http://cr.openjdk.java.net/~khazra/7165118/webrev.00/ Thanks, Kurchi

4 7

RFR: 5015163 "(str) String merge/join that is the inverse of String.split()" into JDK 8
by Jim Gish 03 May '12

03 May '12

This enhancement proposal has a long history. The most recent attempt to get some String.join() methods was by Joe Darcy back in 2009 ( http://mail.openjdk.java.net/pipermail/core-libs-dev/2009-October/002967.ht…) He started with the changes that Remi Forax had done 8 months prior to that, which Remi had attempted a year before that! I've taken the work that Remi and Joe did and am trying again. There was a lot of discussion that was generated and that is why this has died on the vine a number of times. I realize that the current proposal may also generate discussion, but I think this had merit 4 years ago and still does. We won't satisfy everyone. It may not be perfect (what is?!), but if we can look at it from the perspective that something is better than nothing, then we ought to attempt a quick review and get this in. Having said that, I ask that you please take a look at the http://cr.openjdk.java.net/~jgish/5015163/webrev/ <http://cr.openjdk.java.net/%7Ejgish/5015163/webrev/> Just a few words, based on the previous discussion, to set some context. * join() is (roughlty) intended to be the inverse of split() * example: "Hi there".join("-", "Bill", "Joe", "Zoe") will yield "Hi there-Bill-Joe-Zoe" * in the original proposal the delimiter character was what you started with, i.e. o "-".join( "Hi there", "Bill", "Joe", "Zoe") yielded the same result as above o it seemed awkward to have the delimiter be the String instance that the join was performed on. I agree and so have made the first parameter of the join be the delimiter. * there was a lot of discussion about the pros and cons of making join() a static method vs an instance method. The point was made then, and I concur, that given that split() is an instance method, it only makes sense that join() be one too. Certainly there are other perspectives on this and one could argue the merit of each and every one of them, but in the interests of progress, I think the the split()/join() similarity argument is the most compelling and natural. Thanks, Jim Gish

4 13

[7u6] Request for approval: 7118100: (prefs) Inconsistency when using system and user preference on OSX Lion
by Kurchi Hazra 03 May '12

03 May '12

Requesting approval to commit fix for CR 7118100. Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7118100 Webrev: http://cr.openjdk.java.net/~khazra/7118100/webrev.01/ This had been reviewed by Alan Bateman. [1] This fix has been pushed into jdk8 [2] Thanks, Kurchi [1] http://mail.openjdk.java.net/pipermail/macosx-port-dev/2012-February/003081… [2] http://hg.openjdk.java.net/jdk8/tl/jdk/rev/108a02a57b75

2 1

Re: Proposed refactoring: introduce JLS7 language features to core libs
by Stefan Reich 02 May '12

02 May '12

Hello, is there any interest to accept change sets based on OpenJDK 7 that update the java classes in jdk/src/share/classes to use * multi-catch * string switch statements as opposed to nested if statements when comparing strings with string literals * type inference by removing duplicative type information in the constructor when using generics * indexOf(int) when indexOf(String) is used with a String literal that contains only one character, and similar small-scale improvements? The proposed change sets would pass all jtreg tests. If there is interest, what would be next steps? Regards, Stefan Reich

3 5

[PATCH] Use #valueOf()-methods in Unsafe-based FieldAccessors
by Andrej Golovnin 02 May '12

02 May '12

Hi all, Is there some reason for not using #valueOf-methods from wrapper classes in Unsafe-based FieldAccessors in sun.reflect-package (see the attached patch)? The main motivation for this patch is to reduce memory consumption in applications which make heavy use of reflection API (e.g. apps which use ORM solutions). The patch does not modify Unsafe-based FieldAccessors for double and float fields as the wrapper classes does not provide caching for fields of this types. Best regards Andrej Golovnin

2 2

hg: jdk8/tl/jdk: 7160714: Strange or obsolete @see tags in some exception java.util javadoc
by alan.bateman＠oracle.com 02 May '12

02 May '12

Changeset: 531ebfd8eb65 Author: jgish Date: 2012-05-02 21:46 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/531ebfd8eb65 7160714: Strange or obsolete @see tags in some exception java.util javadoc Reviewed-by: mduigou, dholmes, alanb ! src/share/classes/java/util/NoSuchElementException.java

1 0

hg: jdk8/tl/jdk: 7165102: Only run assertion on Integer autoboxing cache size once
by alan.bateman＠oracle.com 02 May '12

02 May '12

Changeset: bb2cefc89bc0 Author: forax Date: 2012-05-02 20:01 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bb2cefc89bc0 7165102: Only run assertion on Integer autoboxing cache size once Reviewed-by: darcy, alanb ! src/share/classes/java/lang/Integer.java

1 0

Review Request: 7164376 Replace use of sun.security.action.LoadLibraryAction
by Mandy Chung 02 May '12

02 May '12

7164376 Replace use of sun.security.action.LoadLibraryAction with direct call of System.loadLibrary Webrev: http://cr.openjdk.java.net/~mchung/jdk8/webrevs/7164376/webrev.00/ This change is required for jdk modularization. High level summary: it replaces the use of LoadLibraryAction: FROM: java.security.AccessController.doPrivileged(new LoadLibraryAction("net")); TO: AccessController.doPrivileged( new java.security.PrivilegedAction<Void>() { public Void run() { System.loadLibrary("net"); return null; } }); It touches files in awt, security and serviceability area (cc'ed). For this type of simple change, I think 1-2 reviewers can review all files (simpler to review jdk.patch) and no need for all teams to do the reviews. System.loadLibrary and Runtime.loadLibrary loads a system library of the given library name that requires RuntimePermission("loadLibrary."+lib) permission. Many places in the JDK code loading a system native library is using the sun.security.action.LoadLibraryAction convenient class that will load the system library as a privileged action: java.security.AccessController.doPrivileged(new LoadLibraryAction("net")); The search path of native libraries are coupled with an associated class loader. For example, the application class loader uses the path specified in the "java.library.path" system property for native library lookup. The loadLibrary implementation uses the caller's class loader for finding the native library being requested. For system libraries, the class loader is null and the system library lookup is handled as a special case. When the sun.security.action.LoadLibraryAction class is used that is the caller of System.loadLibrary, the caller's class loader in this case is "null" loader and thus it always finds the native library from the system library path. In a modular world, JDK modules may be loaded by multiple different module class loader. The following code would not work if it is expected to load a native library from a module which is not the module where the sun.security.action.LoadLibraryAction lives. For example, the management module is trying to load libmanagement.so. Calling the following will fail to find libmanagement.so because the caller of System.loadLibrary is the LoadLibraryAction which is in the base module and search the library from the base module only. To prepare for jdk modularization, the use of LoadLibraryAction should be replaced with a direct call of System.loadLibrary. This patch also removes sun.security.action.LoadLibraryAction class to avoid regression. Thanks Mandy

5 7

hg: jdk8/tl/jdk: 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10
by vincent.x.ryan＠oracle.com 02 May '12

02 May '12

Changeset: d78c6095dc98 Author: vinnie Date: 2012-05-02 14:50 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d78c6095dc98 7087021: TEST: com/sun/crypto/provider/Mac/MacClone.java failed on Solaris sparc 5.10 Reviewed-by: mullan ! test/com/sun/crypto/provider/Mac/MacClone.java

1 0

Request for review: updated 2 files to use generic type
by Sean Chou 02 May '12

02 May '12

Hi all, I updated 2 files(src/share/classes/sun/font/StrikeCache.java, src/share/classes/sun/java2d/Disposer.java) to use generic type, but I'm not sure if I modified too much. Especially I changed the return type of Disposer.getQueue from ReferenceQueue to ReferenceQueue<Object> . The webrev is: http://cr.openjdk.java.net/~zhouyx/OJDK-389/webrev.00/ Please take a look. -- Best Regards, Sean Chou

4 3