March 2016 - core-libs-dev

JDK 9 RFR of JDK-8152749: Mark AdaptorCloseAndInterrupt.java and WatchService/Basic.java as intermittently failing
by Amy Lu 25 Mar '16

25 Mar '16

Below nio tests are known to fail intermittently: java/nio/channels/etc/AdaptorCloseAndInterrupt.java (JDK-8136899, JDK-8150811) java/nio/file/WatchService/Basic.java (JDK-7158947) This patch is to mark the test accordingly with keyword 'intermittent'. bug: https://bugs.openjdk.java.net/browse/JDK-8152749 webrev: http://cr.openjdk.java.net/~amlu/8152749/webrev.00/ Thanks, Amy --- old/test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java 2016-03-25 16:46:48.000000000 +0800 +++ new/test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java 2016-03-25 16:46:48.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2016, 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 @@ -24,7 +24,7 @@ /* @test * @bug 7184932 * @summary Test asynchronous close and interrupt of timed socket adapter methods - * @key randomness + * @key randomness intermittent */ import java.io.*; --- old/test/java/nio/file/WatchService/Basic.java 2016-03-25 16:46:49.000000000 +0800 +++ new/test/java/nio/file/WatchService/Basic.java 2016-03-25 16:46:49.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2008, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2008, 2016, 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 @@ -23,6 +23,7 @@ /* @test * @bug 4313887 6838333 7017446 8011537 8042470 + * @key intermittent * @summary Unit test for java.nio.file.WatchService * @library .. * @run main Basic

2 3

RFR (JAXP) 8151154: IllegalArgumentException not thrown when wrong syntax value is set for javax.xml.catalog.files
by huizhe wang 24 Mar '16

24 Mar '16

Hi, The issue was that the CatalogFeatures builder did not conduct any verification on inputs. The file path verification was done in the CatalogImpl before parsing started. This change added that to where the property was set in the builder, thus some refactoring (moving the verification methods to Util) was involved. Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8151154 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/8151154/ Thanks, Joe

2 2

Review request 8152715: Problem list tools/pack200/Pack200Props.java
by Mandy Chung 24 Mar '16

24 Mar '16

Exclude this test until JDK-8152622 is resolved. diff --git a/test/ProblemList.txt b/test/ProblemList.txt --- a/test/ProblemList.txt +++ b/test/ProblemList.txt @@ -354,6 +354,9 @@ # 8059906 fails on solaris and macosx, 8151901 tools/pack200/Pack200Test.java generic-all +# 8152622 +tools/pack200/Pack200Props.java macosx-all + # 8068049 tools/launcher/FXLauncherTest.java linux-all,macosx-all Mandy

3 2

Review request for 8151571: System/LoggerFinder tests fail after JDK-8149925
by Mandy Chung 24 Mar '16

24 Mar '16

http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8151571/webrev.00/ This restores the change in NativeBuffer to use the common Cleaner created by the system. JDK-8149925 causes InnocuousThread be created early during startup before the system class loader is initialized. Since the common Cleaner is intended for system cleaning code to use, this patch now creates InnocuousThread with null TCCL and expects the system cleaning code to handle null TCCL only if it uses it. Mandy

4 5

Re: RFR: JDK-8152545: Use preprocessor instead of compiling a program to generate native nio constants
by Erik Joelsson 24 Mar '16

24 Mar '16

(adding core-libs) On 2016-03-23 12:13, Erik Joelsson wrote: > In the gensrc step for java.base, we generate a couple of java classes > with the purpose of extracting native constants from the system. We > currently do this by compiling a C program that when run, generates > the java source file. The problem with this approach is that when > cross compiling, we can't do it, so we have to provide pregenerated > versions of the java source files for each cross compiled platform. > > I have fixed this by changing the method to instead just run the C > preprocessor to extract the constants into java source files. This > works fine for most of the constants. There are however 3 that, at > least on Linux, are defined as an enum and not constants, which makes > them unavailable to the preprocessor. These are: > > IPPROTO_TCP = 6 > IPPROTO_IP = 0 > IPPROTO_PV6 = 41 > > I would say that this is fine. They have the same value on all our > supported platforms and are actually part of the IP spec. I cannot > imagine a reason for ever defining them differently. So the solution > is to simply define these as constants in the java source. > > By fixing this, cross compiling new or existing platforms becomes much > easier. > > I have verified this patch by manually comparing the output and by > running the jdk_nio tests in JPRT. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8152545 > Webrev: http://cr.openjdk.java.net/~erikj/8152545/webrev.jdk.01/ > > /Erik

2 4

RFR: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient
by Daniel Fuchs 24 Mar '16

24 Mar '16

Hi, Please find below a patch for: 8152606: java.base no longer needs to export sun.util.logging to java.httpclient https://bugs.openjdk.java.net/browse/JDK-8152606 Now that JDK-8151281 is fixed, java.base module-info.java can be cleaned up to no longer export sun.util.logging to java.httpclient. best regards, -- daniel diff --git a/src/java.base/share/classes/module-info.java b/src/java.base/share/classes/module-info.java --- a/src/java.base/share/classes/module-info.java +++ b/src/java.base/share/classes/module-info.java @@ -274,7 +274,6 @@ jdk.localedata; exports sun.util.logging to java.desktop, - java.httpclient, java.logging, java.prefs;

3 2

RFR [9] 8152642: Remove sun.misc.Unsafe dependency from java.lang.reflect.Proxy
by Chris Hegarty 24 Mar '16

24 Mar '16

Trivially, looks like a minor oversight that inadvertently introduced a dependency on sun.misc.Unsafe. diff --git a/src/java.base/share/classes/java/lang/reflect/Proxy.java b/src/java.base/share/classes/java/lang/reflect/Proxy.java --- a/src/java.base/share/classes/java/lang/reflect/Proxy.java +++ b/src/java.base/share/classes/java/lang/reflect/Proxy.java @@ -48,8 +48,8 @@ import jdk.internal.loader.BootLoader; import jdk.internal.module.Modules; +import jdk.internal.misc.Unsafe; import jdk.internal.misc.VM; -import sun.misc.Unsafe; import sun.reflect.CallerSensitive; import sun.reflect.Reflection; import sun.reflect.misc.ReflectUtil; -Chris.

3 2

RFR (S) 8150463: StringConcat MH_INLINE_SIZED_EXACT should skip storage initialization
by Aleksey Shipilev 24 Mar '16

24 Mar '16

Hi, I'd like to improve our advanced String concat strategy, MH_INLINE_SIZED_EXACT, with skipping the storage initialization: https://bugs.openjdk.java.net/browse/JDK-8150463 Webrev: http://cr.openjdk.java.net/~shade/8150463/webrev.01/ Performance had improved, as planned: http://cr.openjdk.java.net/~shade/8150463/perf.txt The rest of the difference against BC_SB strategy is code-generation quirks, to be addressed separately. We pay some price for a runtime final index check to strengthen against inadvertent bugs in concatenation code. This patch does not affect the String concatenation at this point, because we are still running with BC_SB strategy. I ran through java/lang/String jtregs to see if MH_INLINE_SIZED_EXACT works as expected. Therefore, I don't think this needs to wait for Jigsaw integration. But, it can also wait, no problem. I'll let Jigsaw folks to decide on integration timing. Thanks, -Aleksey

3 4

RFR [9] 8152277: Move URLClassPath.pathToURLs(String) to RegistryImpl
by Chris Hegarty 23 Mar '16

23 Mar '16

In the context of 8149122 & 8152190 it was noticed that sun.rmi.registry.RegistryImpl is the only invoker of URLClassPath::pathToURLs. Rather that adding a qualified export to java.rmi for this, it makes sense to move pathToURLs(String) to RegistryImpI ( and "modernize" the implementation a little ). http://cr.openjdk.java.net/~chegar/8152277/ https://bugs.openjdk.java.net/browse/JDK-8152277 -Chris.

3 4

Code Review Request, 8152237 Support BigInteger.TWO
by Xuelei Fan 23 Mar '16

23 Mar '16

Hi, Please review the update for the supporting of BigInteger.TWO: http://cr.openjdk.java.net/~xuelei/8152237/webrev/ BigInteger.valueOf(2) is a common BigInteger value used in binary and cryptography operation calculation. The BigInteger.TWO is not exported, and hence BigInteger.valueOf(2) is used instead in applications and JDK components. The export of static BigInteger.TWO can improve performance and simplify existing code. Thanks, Xuelei

5 13