February 2017 - core-libs-dev

[9] RFR 8170113: jimage extract to readonly directory causes MissingResourceException
by Denis Kononenko 06 Feb '17

06 Feb '17

Hi, Could someone please review this very small fix. The class JImageTask (src/jdk.jlink/share/classes/jdk/tools/jimage/JImageTask.java) has references to an info message by 'err.cannot.create.dir' key. Unfortunately the corresponding resource file (src/jdk.jlink/share/classes/jdk/tools/jimage/resources/jimage.properties) doesn't contain this key. This results in long not user friendly stacktraces in output when jimage cannot create a directory. The fix is very small, I added the missing definition into the resource file. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170113 WEBREV: http://cr.openjdk.java.net/~dkononenko/8170113/webrev.00 Thank you, Denis.

2 1

Ping: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring
by Langer, Christoph 06 Feb '17

06 Feb '17

Hi, Ping - anyone out there who could have a look at my JAXP test update? Thanks Christoph From: Langer, Christoph Sent: Montag, 30. Januar 2017 15:28 To: core-libs-dev(a)openjdk.java.net Subject: [JAXP] RFR: 8173602: TESTBUG: javax/xml/jaxp/unittest/transform/TransformerTest.java needs refactoring Hi, please review a test fix for javax/xml/jaxp/unittest/transform/TransformerTest.java: Bug: https://bugs.openjdk.java.net/browse/JDK-8173602 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8173602.0/ The main motivation for this refactoring is to remove the dependency to the JDK internal classes com.sun.org.apache.xml.internal.serialize.OutputFormat and com.sun.org.apache.xml.internal.serialize.XMLSerializer. Generally, TransformerTest.java contains several subtests which do similar things (test XALAN transformations) but the implementations differ. I created a common template with helper methods which all tests take advantage of now. I also introduced data sources to some tests to make them more readable and adaptable. Thanks Christoph

2 4

JDK 10 RFR of JDK-8173903: Update various tests to pass under JDK 10
by joe darcy 06 Feb '17

06 Feb '17

Hello, After the version update to "10" in JDK 10 ( JDK-8029942 ), various libraries tests failed including: java/lang/module/MultiReleaseJarTest.java java/security/Provider/ProviderVersionCheck.java sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java These tests need to be updated for the new JDK. When it is clear how to do so, I've updated the tests in a way so that they don't need to be updated again for JDK 11. Webrev: http://cr.openjdk.java.net/~darcy/8173903.0/ and patch below. I'll update the other copyrights before pushing. Thanks, -Joe diff -r 72f33dbfcf3b test/java/lang/module/MultiReleaseJarTest.java --- a/test/java/lang/module/MultiReleaseJarTest.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/java/lang/module/MultiReleaseJarTest.java Fri Feb 03 11:18:23 2017 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2016, 2017, 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 @@ -65,7 +65,7 @@ private static final String MODULE_INFO = "module-info.class"; - private static final int RELEASE = Runtime.version().major(); + private static final String RELEASE = "" + Runtime.version().major(); // are multi-release JARs enabled? private static final boolean MULTI_RELEASE; @@ -88,8 +88,8 @@ .moduleInfo("module-info.class", descriptor) .resource("p/Main.class") .resource("p/Helper.class") - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -131,9 +131,9 @@ .moduleInfo(MODULE_INFO, descriptor1) .resource("p/Main.class") .resource("p/Helper.class") - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -161,8 +161,8 @@ Path jar = new JarBuilder(name) .resource("p/Main.class") .resource("p/Helper.class") - .resource("META-INF/versions/9/p/Helper.class") - .resource("META-INF/versions/9/p/internal/Helper9.class") + .resource("META-INF/versions/" + RELEASE + "/p/Helper.class") + .resource("META-INF/versions/" + RELEASE + "/p/internal/HelperNew.class") .build(); // find the module @@ -200,7 +200,7 @@ Path jar = new JarBuilder(name) .moduleInfo(MODULE_INFO, descriptor1) - .moduleInfo("META-INF/versions/9/" + MODULE_INFO, descriptor2) + .moduleInfo("META-INF/versions/" + RELEASE + "/" + MODULE_INFO, descriptor2) .build(); // find the module diff -r 72f33dbfcf3b test/java/security/Provider/ProviderVersionCheck.java --- a/test/java/security/Provider/ProviderVersionCheck.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/java/security/Provider/ProviderVersionCheck.java Fri Feb 03 11:18:23 2017 -0800 @@ -42,7 +42,7 @@ for (Provider p: Security.getProviders()) { System.out.print(p.getName() + " "); - if (p.getVersion() != 9.0d) { + if (p.getVersion() != 10.0d) { System.out.println("failed. " + "Version received was " + p.getVersion()); failure = true; diff -r 72f33dbfcf3b test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java --- a/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Tue Jan 31 19:26:10 2017 -0500 +++ b/test/sun/security/tools/jarsigner/multiRelease/MVJarSigningTest.java Fri Feb 03 11:18:23 2017 -0800 @@ -74,7 +74,8 @@ private static final String KEYPASS = "changeit"; private static final String SIGNED_JAR = "Signed.jar"; private static final String POLICY_FILE = "SignedJar.policy"; - private static final String VERSION_MESSAGE = "I am running on version 9"; + private static final String VERSION = "" + Runtime.version().major(); + private static final String VERSION_MESSAGE = "I am running on version " + VERSION; public static void main(String[] args) throws Throwable { // compile java files in jarContent directory

4 3

RFR: 8173607: JMX RMI connector should be in its own module
by Daniel Fuchs 05 Feb '17

05 Feb '17

Hi, Please find below a patch for: 8173607: JMX RMI connector should be in its own module https://bugs.openjdk.java.net/browse/JDK-8173607 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05 This patch makes it possible to remove the requires transitive java.rmi from the java.management module. For convenience here is the HTML module-level API documentation produced by javadoc for the new java.management.rmi module: http://cr.openjdk.java.net/~dfuchs/webrev_8173607/webrev.05/java.management… The patch has some temporary hacks (mainly ConnectorBootstrap.java) that we will be able to revert when JDK-8173608 Separate JDK management agent from java.management module is pushed. The changes were mainly mechanical except for: ConnectorBootstrap.java: see above JMXConnectorFactory.java/JMXConnectorServerFactory.java: ServiceLoader is now used to load the default RMI Connector provider as a service. There should however be no observable behavior change to existing application. ProxyRef.java, Unmarshal.java: are moved to a new com.sun.jmx.remote.internal.rmi package in the new module. ClientNotifForwarder.java: is modified to no longer depend on java.rmi.UnmarshalException - NotSerializableException is used instead RMIConnector.java: fetchNotif is updated to throw NotSerializableException instead of UnmarshalException The PRef serialization bytes are updated to accomodate the new ProxyRef package name. Some further cleanup of java.base and java.rmi module-info.java should become possible once JDK-8173608 is in (as well as moving RMIExporter to java.management.rmi - which is not possible yet). Further cleanup of @modules in tests might become possible as well. Note: JCK tests for api/javax_management and api/java_lang/management are passing with this change. best regards, -- daniel

4 8

RFR 8173604: Proposal to move java.annotations.common -> java.xml.ws.annoations
by Lance Andersen 04 Feb '17

04 Feb '17

Hi all, Attached is the webrev for renaming the module javax.annotation.commons to java.xml.ws.annotations: http://cr.openjdk.java.net/~lancea/8173604/ <http://cr.openjdk.java.net/~lancea/8173604/> JPRT has been run showing no issues. Best Lance <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen(a)oracle.com <mailto:Lance.Andersen@oracle.com>

4 4

RFR: 8167063: spurious message "A JNI error has occurred" if start-class cannot be initialized
by Ramanand Patil 04 Feb '17

04 Feb '17

Hi all, Please review the following bug fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8167063 Webrev: http://cr.openjdk.java.net/~rpatil/8167063/webrev.00/ Handled the SecurityException and LinkageError which can be thrown from Class.forName(...) method used in LauncherHelper.java and added corresponding error messages to launcher.properties. Though the reported bug is because of the LinkageError, Security exception is also handled to be safe from calling Class.forName method. Regards, Ramanand.

4 13

Review Request: JDK-8173412 @Test in java/lang/annotation and java/lang/reflect/Proxy tests not run
by Mandy Chung 04 Feb '17

04 Feb '17

Fix @Test tests to be public. Mandy diff --git a/test/java/lang/annotation/AnnotationWithLambda.java b/test/java/lang/annotation/AnnotationWithLambda.java --- a/test/java/lang/annotation/AnnotationWithLambda.java +++ b/test/java/lang/annotation/AnnotationWithLambda.java @@ -43,7 +43,7 @@ public class AnnotationWithLambda { @Test - void testAnnotationWithLambda() { + public void testAnnotationWithLambda() { Method[] methods = AnnotationWithLambda.MethodsWithAnnotations.class.getDeclaredMethods(); for (Method method : methods) { assertTrue((method.isAnnotationPresent(LambdaWithParameter.class)) && diff --git a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java --- a/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java +++ b/test/java/lang/reflect/Proxy/ProxyForMethodHandle.java @@ -46,7 +46,7 @@ * to a dynamic module */ @Test - static void testRunnableMethodHandle() throws Exception { + public static void testRunnableMethodHandle() throws Exception { MethodHandles.Lookup lookup = MethodHandles.lookup(); MethodType mt = MethodType.methodType(void.class); MethodHandle mh = lookup.findStatic(ProxyForMethodHandle.class, "runForRunnable", mt);

2 1

JDK 10 RFR of JDK-8173908: Problem list tools/jar/multiRelease/RuntimeTest.java until JDK-8173905 is fixed
by joe darcy 03 Feb '17

03 Feb '17

Hello, Until JDK-8173905 is fixed, the test tools/jar/multiRelease/RuntimeTest.java should be problem listed so we can get clean test runs on JDK 10. Patch below. Thanks, -Joe diff -r 829a62c56e9c test/ProblemList.txt --- a/test/ProblemList.txt Fri Feb 03 12:36:42 2017 -0800 +++ b/test/ProblemList.txt Fri Feb 03 12:40:45 2017 -0800 @@ -260,6 +260,8 @@ tools/jmod/JmodTest.java 8172870 windows-all +tools/jar/multiRelease/RuntimeTest.java 8173905 generic-all + ############################################################################ # jdk_jdi

3 2

Guaranteed order of annotations?
by Gunnar Morling 03 Feb '17

03 Feb '17

Hi, Is there any order guaranteed in which an element's annotations are returned by AnnotatedElement#getDeclaredAnnotations()? Specifically, is this the order in which the annotations are given in the source code? Section 9.7.5. of the JLS ("Multiple Annotations of the Same Type") makes a statement of the source order being considered by the array of the implicit container annotation created for a repeatable annotation ("[...] all the base annotations in the left-to-right order in which they appeared in the context"). But I couldn't find any authoritative description on the ordering behaviour of getDeclaredAnnotations(). Should we assume that we cannot rely on the order in the source? Thanks for any pointers, --Gunnar

5 7

RFR: 8171522: Jar prints error message with old (non gnu-style options).
by Henry Jen 03 Feb '17

03 Feb '17

Hi, Please review a trivial patch for JDK-8171522, basically we just add two missing main operations into the message. This message is appropriate for both compatible style or new gnu style. Cheers, Henry diff -r 0e2935453091 src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties --- a/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Wed Feb 01 11:05:33 2017 -0800 +++ b/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties Thu Feb 02 10:48:11 2017 -0800 @@ -36,7 +36,7 @@ error.bad.file.arg=\ Error parsing file arguments error.bad.option=\ - One of options -{ctxu} must be specified. + One of the option -{ctxuid} must be specified. error.bad.cflag=\ 'c' flag requires manifest or input files to be specified! error.bad.uflag=\

2 2