July 2016 - core-libs-dev

JDK 9 (JAXP) RFR of JDK-8156598: jaxp: Use more informative format for problem list
by Amy Lu 04 Jul '16

04 Jul '16

Please review this patch to update jaxp/test/ProblemList.txt to the more informative format, which has been used in "langtools" "jdk", but has not yet in "jaxp". bug: https://bugs.openjdk.java.net/browse/JDK-8156598 webrev: http://cr.openjdk.java.net/~amlu/8156598/webrev.00/ Thanks, Amy

2 1

RFR: 8145418: [macosx] Help message for -Xdock:name has a superfluous trailing quote "
by Kumar Srinivasan 01 Jul '16

01 Jul '16

Hello, Please review simple fix: https://bugs.openjdk.java.net/browse/JDK-8145418 Thanks Kumar diff --git a/src/java.base/share/classes/sun/launcher/resources/launcher.properties b/src/java.base/share/classes/sun/launcher/resources/launcher.properties --- a/src/java.base/share/classes/sun/launcher/resources/launcher.properties +++ b/src/java.base/share/classes/sun/launcher/resources/launcher.properties @@ -141,7 +141,7 @@ The following options are Mac OS X specific:\n\ \ -XstartOnFirstThread\n\ \ run the main() method on the first (AppKit) thread\n\ -\ -Xdock:name=<application name>"\n\ +\ -Xdock:name=<application name>\n\ \ override default application name displayed in dock\n\ \ -Xdock:icon=<path to icon file>\n\ \ override default icon displayed in dock\n\n

2 1

RFR: JDK-8160240 - javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java failed with error "Address already in use: bind"
by Mark Sheppard 01 Jul '16

01 Jul '16

Hi, please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8160240/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8160240 it has been observed that, during continuous integration regression tests on some platforms, there is an intermittent bind failure, when starting the orbd for the test. Thus, as the test is composed of two run commands, one without security manager and one with security manager, it is assumed that, the second run starts before the sockets in use in the first run have been fully released. Therefore, to overcome the bind already in use port conflict, the test's second run with security manager has been modified to use different ports, for cos nameservice and activator, to those of the first run. regards Mark

3 5

RFR: 8056285: java/util/logging/CheckLockLocationTest.java java.lang.RuntimeException: Test failed: should have been able to create FileHandler for %t/writable-dir/log.log in writable directory.
by Daniel Fuchs 01 Jul '16

01 Jul '16

Hi, JDK-8056285 has been sighted again (sigh). I strongly suspect a configuration issue but I have no proof. Here is an attempt at gathering some more data to nail down the root cause of the issue. JBS https://bugs.openjdk.java.net/browse/JDK-8056285 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8056285/webrev.00 best regards, -- daniel

2 1

RFR 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code.
by Daniel Fuchs 01 Jul '16

01 Jul '16

Hi, Please find below a patch for: 8159245: Loggers created by system classes are not initialized correctly when configured programmatically from application code. Issue: https://bugs.openjdk.java.net/browse/JDK-8150173 Patch: http://cr.openjdk.java.net/~dfuchs/webrev_8159245/webrev.00/index.html When an application requests a logger by name, we do not know before hand whether that corresponds to a system logger name or not. So if no system logger by that name already exists, we simply return an application logger. The issue happens if a system class later requests a system logger of the same name. The current implementation would simply copy over the user logger handlers to the system logger, ignoring any other data (level, filter, flags) that might have been set by the application (with permission checks) prior to the creation of the system logger. The proposed patch ensures instead that if a system class later requests a system logger of the same name, then the application logger and system logger configurations will be merged in a single instance of a private static Logger$ConfigurationData value class that both loggers will share. A new test is added to verify that the configuration issue is fixed in the various possible configuration cases: - parent of system logger created by the application before system logger exists, - parent of system logger created by the application after system logger exists, - logger created by the application before system logger of the same name exists - logger created by the application after system logger of the same name exists - all of the above with and without a security manager. The new test will fail without the fix and pass with it. best regards, -- daniel

3 19

Review Request: JDK-8160698 java --dry-run should not cause main class be initialized
by Mandy Chung 01 Jul '16

01 Jul '16

Kumar, I move the call to CreateApplicationArgs before PostJVMInit and dryRun stops before PostJVMInit which shows the splash screen. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160698/webrev.00/index.html This also cleans up the LauncherHelper to use Class::forName instead of loadClass. Mandy

2 1

RFR(L): 8143211: provide bytecode intrinsics for loop and try/finally executors
by Michael Haupt 01 Jul '16

01 Jul '16

Dear all, please review this change. RFE: https://bugs.openjdk.java.net/browse/JDK-8143211 Webrev: http://cr.openjdk.java.net/~mhaupt/8143211/webrev.00/ The change puts the tryFinally and loop method handle combinator implementations, which were introduced as part of the JEP 274 effort, on a LambdaForm basis, which executes in bytecode generating (default) and LambdaForm interpretation (-Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD=-1) modes. It also changes the output formatting of LambdaForms, introducing a (hopefully) more readable format. Thanks, Michael -- <http://www.oracle.com/> Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

4 13

RFR:JDK-8160681:LocalDate.ofEpochDay input validation
by nadeesh tv 01 Jul '16

01 Jul '16

Hi all, Bug Id : https://bugs.openjdk.java.net/browse/JDK-8160681 Issue: Epoch day parameter to LocalDate.ofEpochDay() was not validating Webrev: http://cr.openjdk.java.net/~bgopularam/ntv/8160681/webrev.00/ Tests are already covered under *f**actory_ofEpochDay_aboveMax()* , *factory_ofEpochDay_belowMin()* . Error was obscured. It was throwing *DateTimeException *because of internally calculated YEAR was going out of range. Now it will throw exception due to expected issue 'epoch day is out of range'. -- Thanks and Regards, Nadeesh TV

3 4

RFR 8159616: java.time.Instant falls through switch statement
by Bhanu Gopularam 01 Jul '16

01 Jul '16

Hi all, May I request you to review below simple fix for following issue: Bug id: https://bugs.openjdk.java.net/browse/JDK-8159616 Solution: Removed the unneeded case statement INSTANT_SECONDS from get(TemporalField field) of java.time.Instant class Webrev: http://cr.openjdk.java.net/~bgopularam/8159616/webrev.00/ Thanks, Bhanu

3 3

RFR 9 : 8160370 : System.getProperty("os.version") returns "Unknown" on Mac
by Brent Christian 01 Jul '16

01 Jul '16

Hi, Please review the following change for JDK 9: Bug: https://bugs.openjdk.java.net/browse/JDK-8160370 Webrev: http://cr.openjdk.java.net/~bchristi/8160370/webrev.00/ The fix for 7131356 fills in the "os.version" system property on Mac using [NSProcessInfo operatingSystemVersion], available starting in Mac OS 10.9. While JDK 9 will not support versions of Mac OS prior to 10.9 [1], not all testing infrastructure has been updated, and we've seen failures of java/lang/System/OsVersionTest.java The code to restore behavior on older Mac systems is only a few lines, so that seems like a good way to get testing going again. Thanks, -Brent 1. https://jdk9.java.net/jdk9_supported_platforms.html 2. https://bugs.openjdk.java.net/browse/JDK-8156132

7 13