February 2017 - core-libs-dev

JDK 9 RFR of JDK-8173864: Problem list src/jdk/nashorn/api/tree/test/ParseAPITest.java for some platforms
by Amy Lu 03 Feb '17

03 Feb '17

src/jdk/nashorn/api/tree/test/ParseAPITest.java This nashorn test keeps failing at linux-i586, windows-i586 and solaris-sparcv9 (JDK-8173863) Please review this patch to put the test to problem list until issues addressed. bug: https://bugs.openjdk.java.net/browse/JDK-8173864 webrev: http://cr.openjdk.java.net/~amlu/8173864/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-02-03 12:45:00.000000000 +0800 +++ new/test/ProblemList.txt 2017-02-03 12:44:59.000000000 +0800 @@ -23,4 +23,4 @@ # ########################################################################### -# No nashorn tests are on the problem list. +src/jdk/nashorn/api/tree/test/ParseAPITest.java 8173863 linux-i586,windows-i586,solaris-sparcv9

3 2

RFR(s): 8044626 & 8165649 RMI spec changes for modularization
by Stuart Marks 02 Feb '17

02 Feb '17

Hi all, Please review these small spec changes that adjust RMI specifications for the modular environment in Java 9. RMI does some reflection to handle stubs and to activate objects. The changes specify what kind of accessibility (package exports/opens, and class/method/constructor accessibility) is required for RMI to work. Note that any existing RMI applications will end up in an unnamed module in Java 9. Since unnamed modules export and open all packages, there should be no compatibility impact. Bugs: 8044626: Update RMI specifications to reflect modularization changes https://bugs.openjdk.java.net/browse/JDK-8044626 8165649: Re-examine if Activatable object can be created from non-public class https://bugs.openjdk.java.net/browse/JDK-8165649 Diffs below. thanks, s'marks # HG changeset patch # User smarks # Date 1485907664 28800 # Tue Jan 31 16:07:44 2017 -0800 # Node ID b84c67d49349b56e6c95307cd1a4c0d64c48a817 # Parent 0e0e0fbc5bf325ce0fc4d8cc2776c2038fbe6aa3 8044626: Update RMI specifications to reflect modularization changes 8165649: Re-examine if Activatable object can be created from non-public class and/or constructor Reviewed-by: XXX diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java --- a/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java Fri Jan 13 12:35:53 2017 -0800 +++ b/src/java.rmi/share/classes/java/rmi/activation/ActivationInstantiator.java Tue Jan 31 16:07:44 2017 -0800 @@ -60,7 +60,19 @@ * initialization data, and * * <li> returning a MarshalledObject containing the stub for the - * remote object it created </ul> + * remote object it created.</ul> + * + * <p>In order for activation to be successful, one of the following requirements + * must be met, otherwise {@link ActivationException} is thrown. + * + * <ul><li>If the class to be activated and the special activation contructor are both public, + * the class must reside in a package that is exported or open to the + * {@code java.rmi} module. + * + * <li>If either the class to be activated or the special activation constructor + * is non-public, the class must reside in a package that is open to the + * {@code java.rmi} module. + * </ul> * * @param id the object's activation identifier * @param desc the object's descriptor diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/activation/Activator.java --- a/src/java.rmi/share/classes/java/rmi/activation/Activator.java Fri Jan 13 12:35:53 2017 -0800 +++ b/src/java.rmi/share/classes/java/rmi/activation/Activator.java Tue Jan 31 16:07:44 2017 -0800 @@ -48,7 +48,7 @@ * The <code>Activator</code> works closely with * <code>ActivationSystem</code>, which provides a means for registering * groups and objects within those groups, and <code>ActivationMonitor</code>, - * which recives information about active and inactive objects and inactive + * which receives information about active and inactive objects and inactive * groups. <p> * * The activator is responsible for monitoring and detecting when diff -r 0e0e0fbc5bf3 -r b84c67d49349 src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java --- a/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java Fri Jan 13 12:35:53 2017 -0800 +++ b/src/java.rmi/share/classes/java/rmi/server/UnicastRemoteObject.java Tue Jan 31 16:07:44 2017 -0800 @@ -107,8 +107,9 @@ * the binary name of the root class with the suffix {@code _Stub}. * * <li>The stub class is loaded by name using the class loader of the root - * class. The stub class must extend {@link RemoteStub} and must have a - * public constructor that has one parameter of type {@link RemoteRef}. + * class. The stub class must be public, it must extend {@link RemoteStub}, it must + * reside in a package that is exported to the {@code java.rmi} module, and it + * must have a public constructor that has one parameter of type {@link RemoteRef}. * * <li>Finally, an instance of the stub class is constructed with a * {@link RemoteRef}. @@ -124,12 +125,20 @@ * * <ul> * - * <li>The proxy's class is defined by the class loader of the remote - * object's class. + * <li>The proxy's class is defined according to the specifications for the + * <a href="{(a)docRoot}/java/lang/reflect/Proxy.html#membership"> + * {@code Proxy} + * </a> + * class, using the class loader of the remote object's class. * * <li>The proxy implements all the remote interfaces implemented by the * remote object's class. * + * <li>If all remote interfaces are public, they must reside in packages that + * are either exported or open to the {@code java.rmi} module. Or, if one or more + * of the remote interfaces are non-public, they must reside in a package that + * is open to the {@code java.rmi} module. + * * <li>The proxy's invocation handler is a {@link * RemoteObjectInvocationHandler} instance constructed with a * {@link RemoteRef}.

3 6

Heads up: Fwd: hg: jdk9/dev/jdk: 8173607: JMX RMI connector should be in its own module
by Daniel Fuchs 02 Feb '17

02 Feb '17

Hi, A direct consequence of this change is that you may have to either blow up your ./build directory, or run 'make clean-java' after pulling this fix. Otherwise you may see strange build failures like below: Error occurred during initialization of VM java.lang.RuntimeException: Package com.sun.jmx.remote.protocol.rmi in both module java.management.rmi and module java.management at jdk.internal.module.ModuleBootstrap.fail(java.base/ModuleBootstrap.java:699) at jdk.internal.module.ModuleBootstrap.boot(java.base/ModuleBootstrap.java:329) at java.lang.System.initPhase2(java.base/System.java:1928) best regards, -- daniel

1 0

RFR: 8160302: Reduce number of lambdas created when loading java.util.regex.Pattern
by Claes Redestad 02 Feb '17

02 Feb '17

Hi, changes to java.util.regex in 9+119 has been cause for a number of startup regressions due to early use of lambdas, which has both helped motivate work to reduce the overall cost of lambda initialization[1], while in other cases the use of regexes could be reconsidered (VersionProps). While this work and workarounds has helped a lot, the changes to java.util.regex can still be the cause of noticeable regressions[2] when using regular expressions that depend on predicates defined in java.util.regex.CharPredicate, simply because of how this class eagerly creates a substantial amount of lambdas during clinit. This patch makes the initialization lazy, which improves startup metrics without affecting performance of regular use. Bug: https://bugs.openjdk.java.net/browse/JDK-8160302 Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/ Thanks! /Claes PS. Yes, I know final is redundant on static methods, and realized I forgot to remove them after turning constants into methods, but looking at again it seems there's a convention of defining static methods final in this code already, so unless there is a lot of outrage I'd like to defer cleaning up this particular bikeshed. [1] https://bugs.openjdk.java.net/browse/JDK-8086045 [2] 12-15ms startup regressions due to generating and loading up to 60 loaded classes, more early JIT compilations etc..

4 6

RFR: jsr166 jdk9 integration wave 14
by Martin Buchholz 02 Feb '17

02 Feb '17

Another too-big too-scary wave for this phase of jdk9, but I still think it should go in. Or we can put into jdk10 first, then down-integrate into jdk9 (when??). http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ --- concurrent-collections has spliterator bug fixes and fixes for rare but serious performance problems in LinkedTransferQueue. And it continues the optimization of bulk collection methods begun months ago. --- common-pool has a fix for unwanted ClassLoader retention via an inaccessible thread context class loader. This differs from Chris' approach of setting the internal TCCL to null. Instead, it unifies the handling in the default FJTF and the innocuous FJTF by simply setting the TCCL to the system class loader. Except that the innocuous TCCL cannot be reset by a task.

5 21

RFR: 8075617, 8075616 Create tests to check wsgen, schemagen work with multi-version jar
by Andrey Nazarov 01 Feb '17

01 Feb '17

Hi, I’ve added sanity checks that wsgen and schemagen tools works with multi-release jar files. Review http://cr.openjdk.java.net/~anazarov/8075617/webrev.00/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8075616 <https://bugs.openjdk.java.net/browse/JDK-8075616>, https://bugs.openjdk.java.net/browse/JDK-8075617 <https://bugs.openjdk.java.net/browse/JDK-8075617> —Andrey

3 10

RFR: 8171524: jar --help doesn't provide information that stdout and stdin can be used as output and input for tool
by Henry Jen 01 Feb '17

01 Feb '17

Hi, Please review a trivial fix[1] for JDK-8171524. The fix added a short paragraph about @argfile. Clarify stdin or stdout is used if —file is omitted. It also correct that -h, not -? is for the short option for —help. Cheers, Henry [1] http://cr.openjdk.java.net/~henryjen/jdk9/8171524/0/webrev/

2 1