May 2015 - core-libs-dev

JDK 9 RFR of JDK-8075284: fix up miscellaneous TM constructions
by joe darcy 19 May '15

19 May '15

Hello, Please review these changes for JDK-8075284: fix up miscellaneous TM constructions http://cr.openjdk.java.net/~darcy/8075284.0/ which replace convoluted HTML markup for expressing a trademark sign with the HTML ™ --- build and docs build pass with the changes Thanks, -Joe

4 4

RFR: 8077822: javac does not recognize '*.java' as file if '-J' option is specified
by Rob McKenna 19 May '15

19 May '15

Hi folks, Because of platform specifics the Java launcher contains some extra wildcard expansion processing on Windows. As part of this processing the list of args received by CreateApplicationArgs (java_md.c) is compared to the original list in the java launchers main method. Unfortunately the CreateApplicationArgs list has already been filtered by TranslateApplicationArgs which removes VM specific flags. This results in the launcher incorrectly neglecting to expand wildcard arguments. This fix filters the main method args in the same way so CreateApplicationArgs will be comparing like with like. http://cr.openjdk.java.net/~robm/8077822/webrev.01/ -Rob

2 2

RFR(XS) : 8055269 : java/lang/invoke/MethodHandles/CatchExceptionTest.java fails intermittently
by Igor Ignatyev 19 May '15

19 May '15

http://cr.openjdk.java.net/~iignatyev/8055269/webrev.00/ 23 lines changed: 8 ins; 9 del; 6 mod Hi all, please review the tiny fix for CatchExceptionTest test. problem: the tests generates a target w/ 255 parameters, so a corresponding handler should have 256 parameters. that violates restrictions. fix: limit target's arity by 254 side changes: - cover a handler w/o dropped arguments case - fix a typo in a comment - always print maxArg, maxDrop and generated parameters' classes - print test properties in runTest method instead of ctor. testing: locally, w/ and w/o -Dthorough JBS: https://jbs.oracle.com/bugs/browse/JDK-8055269 -- Igor

2 4

JDK 9 RFR of JDK-8080658: Update FindDecoderBugs.java to use random number generator library
by Amy Lu 19 May '15

19 May '15

sun/nio/cs/FindDecoderBugs.java This test uses randomness and has been observed to intermittently fail. This patch is to update the test to use the random number testing library, to better identify the cause of any future failures. Please review the patch. I also need a sponsor for this change. bug: https://bugs.openjdk.java.net/browse/JDK-8080658 webrev: http://cr.openjdk.java.net/~amlu/8080658/webrev.00/ Thanks, Amy

4 3

RFR 8072002: The spec on javax.script.Compilable contains a typo and confusing inconsistency
by A. Sundararajan 19 May '15

19 May '15

Please review http://cr.openjdk.java.net/~sundar/8072002/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8072002 Thanks, -Sundar

3 2

RFR (XXS) 8080535: (ch) Expected size of Character.UnicodeBlock.map is not optimal
by Ivan Gerasimov 19 May '15

19 May '15

Hello! When constructing the map, the expected size is specified to be 256, but then 510 elements are inserted. A new whitebox test is provided, so the next time the number of entries grows, the expected size will not be forgotten. Would you please help review this fix? BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080535 WEBREV: http://cr.openjdk.java.net/~igerasim/8080535/00/webrev/ Sincerely yours, Ivan

4 6

Review Request for 8074431: Remove native2ascii tool
by Mandy Chung 19 May '15

19 May '15

This patch removes native2ascii command-line tool from JDK 9 as proposed in March [1]. Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8074431/webrev.00/ Jon - A langtools test is updated to use a new Native2Ascii.java helper class instead. Existing code that calls sun.tools.native2ascii.Main can copy the implementation or Native2Ascii.java. thanks Mandy [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-March/032634.html

4 3

RFR(XS): JDK-8077866: [TESTBUG] Some of java.lang tests cannot be run on compact profiles 1, 2
by denis kononenko 19 May '15

19 May '15

Hi All, Please review the very small change in TEST.groups file. Webrev link: http://cr.openjdk.java.net/~skovalev/dkononen/8077866/webrev.00/ Bug id: JDK-8077866 <https://bugs.openjdk.java.net/browse/JDK-8077866> Testing: automated Description: The following tests cannot be run on compact profiles 1 and 2: java/lang/invoke/lambda/LambdaStackTrace.java: requires javax.tools.StandardJavaFileManager (JEP-161, available in Compact Profile 3); java/lang/invoke/LFCaching/LFMultiThreadCachingTest.java: inherits from the LambdaFormTestCase class which, in turn, has dependency on java.lang.management package (JEP-161, available in Compact Profile 3); java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java: the same as above; java/lang/invoke/LFCaching/LFGarbageCollectedTest.java the same as above; The fix simply adds these tests into the :needs_compact3 group. Thank you, Denis.

3 2

Naming of thread pools (Executors)
by Peter Hansson 18 May '15

18 May '15

Hi, I would like create a patch for https://bugs.openjdk.java.net/browse/JDK-8016248. MOTIVATION: Today thread pools created by the Executors method are always prefixed with "pool". The developer can work around this by providing his own ThreadFactory but if he wants to have the default JDK behaviour then it means he has to replicate code in the JDK. The string "pool" is hardcoded in the JDK. The fact that threads cannot be identified by their purpose is annoying especially when working with JEE servers. SUGGESTION: The idea is to amend private classes Executors.DefaultThreadFactory and Executors.PrivilegedThreadFactory to optionally accept a name prefix in their constructor.Then methods Executors.defaultThreadFactory() and Executors.privilegedThreadFactory() will be overloaded to optionally accept a name prefix. With this change the developer can now use a custom thread name prefix. If he wanted to do: Executors.newFixedThreadPool(3); // standard, results in "pool" prefix He could instead use a developer supplied ThreadFactory yet still using JDK's ThreadFactory: Executors.newFixedThreadPool(3, Executors.defaultThreadFactory("snmpworker")); Good idea ? Bad idea? Any negative side effects ? Thanks Peter

3 2

RFR [9] 8080422: some docs cleanup for core libs
by alexander stepanov 18 May '15

18 May '15

Hello, Could you please review the following fix http://cr.openjdk.java.net/~avstepan/8080422/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8080422 Just some HTML markup fix. The affected packages should (probably) not be visible in the new modular system, but nevertheless... Thanks, Alexander

3 7