June 2014 - core-libs-dev

RFR: 8042872: Fix raw and unchecked warnings in sun.applet
by Henry Jen 09 Jul '14

09 Jul '14

Hi, Please review another webrev to clean up rawtypes and unchecked warning, this time for sun.applet. The webrev applied to both jdk9/dev and jdk9/client cleanly, I am not sure which repo should the webrev go once pass review. Webrev can be found at http://cr.openjdk.java.net/~henryjen/jdk9/8042872/0/webrev/ Please also let me know any particular test I should do other than regular jprt. Cheers, Henry

2 2

Review request: 8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API
by Mandy Chung 08 Jul '14

08 Jul '14

This patch is also intended to target for 8u40 backport. It fixes the following issues: JDK-8029548 (jdeps) use @jdk.Exported to determine supported vs JDK internal API JDK-8039007 jdeps incorrectly reports javax.jnlp as JDK internal APIs JDK-8031092 jdeps does not recognize --help option. JDK-8048063 (jdeps) Add filtering capability Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8029548/webrev.00/ jdeps will determine if it's a JDK internal API by checking the @jdk.Exported. It also reads tools.jar and flags if they are non-exported. javax.jnlp is supported API but not annotated with @jdk.Exported and so we special case it as a workaround. A new -filter option is added to provide an easy way to do filtering e.g. -filter java.lang.*, -filter:archive to filter out all dependences from the same archive (i.e the input JAR file or directory). The default is changed to filter out the dependences within the same package. I also have cleaned up and refactored some code between JdepsTask and Analyzer to prepare for source restructuring and modularization work. thanks Mandy

4 7

[9] RFR (S): 8038261: JSR292: cache and reuse typed array accessors
by Vladimir Ivanov 08 Jul '14

08 Jul '14

http://cr.openjdk.java.net/~vlivanov/8038261/webrev.00 https://bugs.openjdk.java.net/browse/JDK-8038261 56 lines changed: 26 ins; 14 del; 16 mod Cache typed array element getters/setters and reuse them. Initially, it was part of 8037209, but I decided to integrate it separately. Contributed-by: john.r.rose(a)oracle.com Testing: jdk/java/{lang/invoke,util}, vm.mlvm.testlist, nashorn, jruby Configs: -ea -esa -Xverify:all -D...COMPILE_THRESHOLD={0,30} Best regards, Vladimir Ivanov

2 4

Zombie FileHandler locks can exhaust all available log file locks.
by Jason Mehrens 07 Jul '14

07 Jul '14

Daniel, Jim, In JDK8 the FileHandler file locking was changed to use FileChannel.open with CREATE_NEW. If the file exists (locked or not) the FileHandler will rotate due to safety concerns about writing to the same log file. The FileHandler has an upper bound of 100 as the number of file locks that can be attempted to be acquired. Given the right pattern, enough time, and enough failures it seems at it is possible for a program to end up in a state where the FileHandler is surrounded by zombie lock files refuses log or perform a clean up action. (A.K.A Farmer Rick Grimes). This means that the lck files have to manually be deleted or the FileHandler will just fail with an IOException every time it is created. A simple test to emulate crashing is to run (JDK7 vs. JDK8) the following code twice without deleting the log and lck files: public static void main(String[] args) throws Exception { System.out.println(System.getProperty("java.runtime.version")); ReferenceQueue<FileHandler> q = new ReferenceQueue<>(); for (int i=0; i<100; i++) { WeakReference<FileHandler> h = new WeakReference<>( new FileHandler("./test_%u.log", 10000, 2, true), q); while (q.poll() != h) { System.runFinalization(); System.gc(); System.runFinalization(); Thread.yield(); } } } I understand that if you can't trust that the file locking always works then there isn't much that can be done. Leaving the number of locks as unbounded isn't really an option either. Seems like there should be a way to identify zombie lock files (ATOMIC_MOVE) and delete them. Any thoughts on this? The source discussion on this can be found at http://stackoverflow.com/questions/24321098/is-java-util-logging-filehandle… Regards, Jason

3 23

RFR: 8047722: @since tag cleanup in corba
by Henry Jen 03 Jul '14

03 Jul '14

Hi, Please review a trivial webrev for jdk9/corba that do the same @since tag normalization as in jdk9/jdk. http://cr.openjdk.java.net/~henryjen/jdk9/8047722/0/webrev/ Cheers, Henry

4 6

RFR: 8023276: Java SE should include the full DOM API from JAXP
by huizhe wang 03 Jul '14

03 Jul '14

Hi, Three packages are missing from the DOM API documentation in JAXP: org.w3c.dom.views org.w3c.dom.ranges org.w3c.dom.traversal We added org.w3c.dom.views in JAXP 1.6 and fixed JDK-8006843. But since we were too close to the deadline for JAXP 1.6 MR, we left the other two packages for JDK 9. CCC has been approved for this addition. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8023276/webrev/ Thanks, Joe

6 8

RFR 8047737 Move array component mirror to instance of java/lang/Class
by Coleen Phillimore 02 Jul '14

02 Jul '14

Summary: Add field in java.lang.Class for componentType to simplify oop processing and intrinsics in JVM This is part of ongoing work to clean up oop pointers in the metadata and simplify the interface between the JDK j.l.C and the JVM. There's a performance benefit at the end of all of this if we can remove all oop pointers from metadata. mirror in Klass is the only one left after this full change. See bug https://bugs.openjdk.java.net/browse/JDK-8047737 There are a couple steps to this change because Hotspot testing is done with promoted JDKs. The first step is this webrev: http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_jdk/ http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot/ When the JDK is promoted, the code to remove ArrayKlass::_component_mirror will be changed under a new bug id. http://oklahoma.us.oracle.com/~cphillim/webrev/8047737_hotspot_full Finally, a compatibility request and licensee notification will occur to remove the function JVM_GetComponentType. Performance testing was done that shows no difference in performance. The isArray() call is a compiler intrinsic which is now called instead of getComponentType, which was recognized as a compiler intrinsic. JDK jtreg testing, hotspot jtreg testing, hotspot NSK testing and jck8 tests were performed on both the change requested (1st one) and the full change. hotspot NSK tests were run on the hotspot-only change with a promoted JDK. Please send your comments. Thanks, Coleen

6 17

Long valueOf instead of new Long
by Otávio Gonçalves de Santana 01 Jul '14

01 Jul '14

Reason: The Long class has cache and using it, will save memory and will faster than using create new instance of Long. webrev: https://dl.dropboxusercontent.com/u/16109193/open_jdk/long_value_of.zip similar: https://bugs.openjdk.java.net/browse/JDK-8044461 -- Otávio Gonçalves de Santana blog: http://otaviosantana.blogspot.com.br/ twitter: http://twitter.com/otaviojava site: http://www.otaviojava.com.br (11) 98255-3513

6 18

RFR : 7095856: OutputStreamHook doesn't handle null values
by Seán Coffey 01 Jul '14

01 Jul '14

Looking for a review around this CORBA issue. bug report : https://bugs.openjdk.java.net/browse/JDK-7095856 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7095856/ Null values cause issue when processed by an IIOPOutputStream and I can't see a reason why they wouldn't be allowed. Note that the glassfish code already employs a HashMap to hold such values. I've run CORBA SQE tests, unit tests and relevant TCK tests. No issues seen. regards, Sean.

3 3

RFR: 8037948: Improve documentation for org.w3c.dom package
by huizhe wang 30 Jun '14

30 Jun '14

Hi, This is a quick fix for a broken link in org.w3c.dom package. Also included is removal of unnecessary (and bad) link to jaxp api in a catalog class. Please review. http://cr.openjdk.java.net/~joehw/jdk9/8037948/webrev/ Thanks, Joe

4 7