March 2017 - core-libs-dev

JDK 9 ServiceLoader bug
by Chris Dennis 17 Mar '17

17 Mar '17

Hi All, I’ve found what I believe could (or should) be considered a bug with the way the ServiceLoader interacts with the classpath in JDK 9. Consider the following code: ==================== package example; import java.util.ServiceLoader; public class Main { public static void main(String[] args) { ServiceLoader.load(MyService.class).forEach(s -> System.out.println(s + " : " + s.getClass().hashCode()));; } } ==================== where MyService is an empty interface and MyServiceImpl is an associated empty implementation. If we JAR the compiled results up with a suitable services declaration and then make two copies of the resultant jar the following behaviors are seen: [cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 1.8 -exec java -showversion -cp one.jar:one.jar example.Main java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) example.MyServiceImpl@16b98e56 : 2129789493 [cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 1.8 -exec java -showversion -cp one.jar:two.jar example.Main java version "1.8.0_102" Java(TM) SE Runtime Environment (build 1.8.0_102-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.102-b14, mixed mode) example.MyServiceImpl@16b98e56 : 2129789493 [cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 9 -exec java -showversion -cp one.jar:one.jar example.Main java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+159) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+159, mixed mode) example.MyServiceImpl@6108b2d7 : 1449621165 [cdennis@Chriss-MacBook-Pro services-test]$ /usr/libexec/java_home -v 9 -exec java -showversion -cp one.jar:two.jar example.Main java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+159) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+159, mixed mode) example.MyServiceImpl@6bf256fa : 357863579 example.MyServiceImpl@1a407d53 : 357863579 Since I’m not using the module path here (and neither of my jars are modular) I would expect to see the same behavior from JDK 9 as I get in 8 (and as is specified in both Javadocs): "If a particular concrete provider class is named in more than one configuration file, or is named in the same configuration file more than once, then the duplicates are ignored. The configuration file naming a particular provider need not be in the same JAR file or other distribution unit as the provider itself. The provider must be visible from the same class loader that was initially queried to locate the configuration file; note that this is not necessarily the class loader from which the file was actually loaded.” This will obviously cause confusion for anyone using the ServiceLoader to load singleton services who is not currently in total control of their classpath. Dependencies that are both present and shaded would cause a problem for example. Thanks, Chris Dennis

2 1

RFR[9] 8160956: Runtime.Version.compareTo/compareToIgnoreOpt problem
by Pavel Rappo 16 Mar '17

16 Mar '17

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8160956/webrev.00/ The code change fixes the implementation and makes it adhere to the specification for Version comparison: /** * Compares this version to another. * ... * <p> A version without a build number is always less than one with a * build number; otherwise build numbers are compared numerically. </p> ... */ @Override public int compareTo(Version ob) The existing test was incorrectly testing these cases. So rather than bringing the test case provided in the linked issue, I updating those existing cases. The patch also fixes a bunch of javadoc typos. P.S. While we are in this area, may I ask if anybody knows why exactly Version class has lost its 'final' modifier while moving from 'jdk' package to 'java.lang' [2]? Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8160956 [2] https://bugs.openjdk.java.net/browse/JDK-8144062

3 7

RFR[9] 8176882: Incorrect integer comparison in version numbers
by Pavel Rappo 16 Mar '17

16 Mar '17

Hello, Please review the following trivial change for [1]: http://cr.openjdk.java.net/~prappo/8176882/webrev.00/ Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8176882

2 1

RRF(XS)(10): 8176797: [TESTBUG] tools/launcher/Settings.java -Xss size is too small
by Chris Plummer 16 Mar '17

16 Mar '17

Hello, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8176797 http://cr.openjdk.java.net/~cjplummer/8176797/webrev.00/webrev.jdk After fixing 8175342 (see the other RFR I just posted), this test started to fail instead of assert. The problem is 256000 is too small of a stack size on the platform in question. It needs to be at least 256k. The test has a "stackSize" local variable that is the String "256". It runs the jvm with -Xss of this size, appending "k" to it on one run and "000" in the next. The -Xss256k version is fine. The -Xss256000 version is not. I'm not sure why the test chose to specify the stackSize as a String instead of an int. As part of this fix I changed it to an int, and just multiply it by 1024 in the case where -Xss is specified with a byte size rather the an k size. The test passes now on the platform where it was failing. thanks, Chris

5 5

RFR 9: 8176272 : (process) ProcessHandle::onExit fails to wait for non-child process
by Roger Riggs 16 Mar '17

16 Mar '17

Please review a change to the implementation of ProcessHandle.onExit to correctly handle waiting for any process to terminate and a corresponding new test. On Linux, waitpid only waits for direct children; waiting for non-children now polls for termination. Please review and comment: Webrev: http://cr.openjdk.java.net/~rriggs/webrev-processhandle-onexit-8176272/inde… Issue: https://bugs.openjdk.java.net/browse/JDK-8176272 Thanks, Roger

3 5

Re: RFR(L) : 8176176 : fix @modules in jdk_svc tests
by Igor Ignatyev 16 Mar '17

16 Mar '17

Shura, Thank you for review, I agree that having separate bugs is more convenient. [1] is new webrev w/ changes only in the files w/ incorrect module dependency declarations. [1] http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html <http://cr.openjdk.java.net/~iignatyev//8176176/webrev.01/index.html> Thanks, — Igor > On Mar 9, 2017, at 5:02 PM, Alexandre (Shura) Iline <alexandre.iline(a)oracle.com> wrote: > > Igor, > > I have reviewed some number tests which change the @modules - they are fine. > > You, however, fix more things with this than missing module dependency declaration. There is a redesign of line-number-sensitive tests [1] and other multiple improvements such as in [2]. Would it be more convenient to have that as separate bugs? > > Shura > > [1] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/Ar… > [2] http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/test/com/sun/jdi/Ar… > >> On Mar 7, 2017, at 1:07 PM, Igor Ignatyev <igor.ignatyev(a)oracle.com> wrote: >> >> http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >>> 2586 lines changed: 669 ins; 484 del; 1433 mod; >> >> Hi all, >> >> Could you please review this changeset which fix @modules dependency declaration in jdk_svc tests? >> there are a couple issues w/ modules in jdk_svc tests: >> - some tests do not specify modules which they depend on >> - modules in TEST.properties is not used in cases there all tests (should) have the same @modules directive >> - @modules directive isn't placed according to current convention (before the 1st run directive) >> >> Since this fix has already touched lots of tests, I have decided to use this opportunity and reordered some of jtreg tags as well, so there won’t be two massive updates in the tests. >> >> Some of our tests are line number sensitive, and then I fixed jtreg declaration, they started to fail. It was really hard to find our all line number sensitive tests, so I have unified the way we declare that as a part of this fix. Please let me know if you prefer to have it done separately. >> >> There are two one-liners which, I hope, can simplify review: >> [1] shows only the changes which are not in comments. Besides obvious new added TEST.properties, there are changes in the following line number sensitive tests (which I mentioned before): >> test/com/sun/jdi/ArgumentValuesTest.java >> test/com/sun/jdi/BreakpointTest.java >> test/com/sun/jdi/FetchLocals.java >> test/com/sun/jdi/GetLocalVariables.java >> test/com/sun/jdi/GetSetLocalTest.java >> test/com/sun/jdi/LambdaBreakpointTest.java >> test/com/sun/jdi/LineNumberOnBraceTest.java >> test/com/sun/jdi/PopAndStepTest.java >> >> [2] shows changes in jtreg tags, it can help to see that almost all changes in jtreg tags are either moving of tags which does not affect execution order or @modules changes. >> >> webrev: http://cr.openjdk.java.net/~iignatyev/8176176/webrev.00/index.html >> bug: https://bugs.openjdk.java.net/browse/JDK-8176176 >> Testing: >> - jdk_svc on linux, windows, mac >> - checked that all tests which could be executed with full jdk before still can be executed with full jdk >> >> Thanks, >> — Igor >> >> [1] $ hg diff -w | grep "^[+-]" | grep -v "^[+-]\s*[*#]" >> [2] $ hg diff -w | grep -e "^$+++ b$\|$--- a$" -e "^[+-]\s*[*#]\s*@" >

3 5

RFR of JDK-8176563: @since value errors in apis of java.base/java.logging module
by Hamlin Li 16 Mar '17

16 Mar '17

Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8176563 webrev: http://cr.openjdk.java.net/~mli/8176563/webrev.00/ Thank you -Hamlin

9 15

RFR: 8176834: jdk/nio/zipfs/MultiReleaseJarTest.java test fails after JDK-8176709
by Claes Redestad 15 Mar '17

15 Mar '17

Hi, it appears the test we wrote to test the Multi-Release checking in JarFile, based on the jar manifest specification[1] and now adapted for JDK-8176709 is too strict when actually using java.util.jar.Manifest, which means the test I added for JDK-8176709 fails on the version that I pushed (but not on the version I tested it on - shame! shame!) Webrev: http://cr.openjdk.java.net/~redestad/8176834/jdk.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8176834 I've filed a bug to re-examine the Manifest specification/implementation here, which may or may not need to be higher priority: https://bugs.openjdk.java.net/browse/JDK-8176843 Thanks! /Claes

2 2

Review Request: JDK-8176815: Remove StackFramePermission and use RuntimePermission for stack walking
by Mandy Chung 15 Mar '17

15 Mar '17

StackWalker::getInstance is currently specified to check for StackFramePermission("retainClassReference“) due to an early review feedback . Given it has only one target, it’s overkill to define a specific permission type for stack walking use. This patch proposes to replace the StackWalker permission check with RuntimePermission("getStackWalkerWithClassReference”) and remove StackFramePermission class. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8176815/webrev.00/ Mandy

3 3

RFR: 8176709: JarFileSystem::isMultiReleaseJar is incorrect
by Claes Redestad 15 Mar '17

15 Mar '17

Hi, please review this change to adapt the JarFileSystem::isMultiReleaseJar method to align with the evolved specification in JEP 238 Bug: https://bugs.openjdk.java.net/browse/JDK-8176709 Webrev: http://cr.openjdk.java.net/~redestad/8176709/jdk.01/ This unfortunately adds a qualified export from java.base to jdk.zipfs, but since the jdk.internal.util.jar package was already exported to three other modules I think it's a low cost option that is preferable to other alternatives such as maintaining separate implementations. Thanks! /Claes

3 8