July 2016 - core-libs-dev

Review request: JDK-8160398 (jdeps) Replace a list of JDK 8 internal API for detecting if it's removed in JDK 9 or later
by Mandy Chung 13 Jul '16

13 Jul '16

This patch includes a generated list of JDK 8 internal packages (a trimmed down list) such that jdeps can determine if any JDK internal API is referenced but removed in JDK 9 or later release. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8160398/webrev.00/ Mandy

2 3

RFR: 8132379: -J options can cause crash or "Warning: app args parsing error passing arguments as-is"
by Henry Jen 13 Jul '16

13 Jul '16

Hi, Please review a fix for JDK-8132379, the fix is to build matching index to the original arguments for the application arguments, used later for the sanity check and wildcard expansion. The fix is specific to Windows platform. -J prefix used by launcher-based tools such as javac need to be filtered out, but not for java itself, where -J prefix could be used by the main class. Use index table avoid copy of arguments and use less memory. The fix is tested on Windows 10. Bug: https://bugs.openjdk.java.net/browse/JDK-8132379 Webrev: http://cr.openjdk.java.net/~henryjen/jdk9/8132379.0/webrev/ Cheers, Henry

2 2

RFR - 8141148: LDAP "follow" throws ClassCastException with Java 8
by Rob McKenna 13 Jul '16

13 Jul '16

Hi folks, Looking for a review for this change: https://bugs.openjdk.java.net/browse/JDK-8141148 http://cr.openjdk.java.net/~robm/8141148/webrev.01/ A fairly straightforward fix for a class cast problem. From the bug: As a result of https://bugs.openjdk.java.net/browse/JDK-7072353: http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/rev/18329abcdb7c The test attached to the bug fails with the following trace: Exception in thread "main" java.lang.ClassCastException: com.sun.jndi.ldap.LdapSearchEnumeration cannot be cast to com.sun.jndi.ldap.LdapNamingEnumeration at com.sun.jndi.ldap.LdapNamingEnumeration.getReferredResults(LdapNamingEnumeration.java:78) at com.sun.jndi.ldap.LdapNamingEnumeration.getReferredResults(LdapNamingEnumeration.java:36) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreReferrals(AbstractLdapNamingEnumeration.java:330) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:227) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189) at com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreElements(AbstractLdapNamingEnumeration.java:117) at TestLdap.query(TestLdap.java:43) at TestLdap.main(TestLdap.java:19) Post refactor we have a NamingEnumeration interface which is implemented by an abstract class AbstractLdapNamingEnumeration. 3 implementations, LdapBindingEnumeration, LdapNamingEnumeration & LdapSearchEnumeration extend AbstractLdapNamingEnumeration. Each implementation has its own getReferredResults method which returns an object of the individual implementations type. Unfortunately this falls down (as can be seen in the stack) because an LdapNamingEnumeration.getReferredResults can call refCtx.search, which returns an LdapSearchEnumeration. This leads to a situation where LdapNamingEnumeration needs to cast an LdapSearchEnumeration which results in the exception above. -Rob

2 1

JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"
by Amy Lu 12 Jul '16

12 Jul '16

Please review this trivial fix for test:java/lang/ThreadGroup/Stop.java Though this is a test for a deprecated API, failed with very very low frequency and hard to reproduce (I got no luck to reproduce it), I’d like to patch it as suggested: extend the sleep in the main thread from one second to five seconds. Also added 'volatile' to the boolean variable 'groupStopped'. bug: https://bugs.openjdk.java.net/browse/JDK-8132548 webrev: http://cr.openjdk.java.net/~amlu/8132548/webrev.00/ Thanks, Amy --- old/test/java/lang/ThreadGroup/Stop.java 2016-07-04 14:53:59.000000000 +0800 +++ new/test/java/lang/ThreadGroup/Stop.java 2016-07-04 14:53:58.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1999, 2011, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1999, 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 @@ -29,7 +29,7 @@ */ public class Stop implements Runnable { - private static boolean groupStopped = false ; + private static volatile boolean groupStopped = false ; private static final Object lock = new Object(); private static final ThreadGroup group = new ThreadGroup(""); @@ -70,7 +70,7 @@ while (!groupStopped) { lock.wait(); // Give the other thread a chance to stop - Thread.sleep(1000); + Thread.sleep(5000); } }

4 23

ByteBuffer views, alignment, word tearing
by Andrew Haley 12 Jul '16

12 Jul '16

I saw a few ACCEPTABLE_SPEC results for ByteBuffer views in jcstress. This results from word tearing. I was rather surprised, because I'd worked on the HeapByteBuffer implementation, and I knew that on we would't expect to see any word tearing for HeapByteBuffers or DirectByteBuffers, at least for aligned word fetches and stores. Unfortunately, we're still doing this in e.g. ByteBufferAsIntBufferL: public int get(int i) { return Bits.getIntL(bb, ix(checkIndex(i))); } where Bits.getIntL is defined as: static int getIntL(ByteBuffer bb, int bi) { return makeInt(bb._get(bi + 3), bb._get(bi + 2), bb._get(bi + 1), bb._get(bi )); } instead of what I'd thought we were doing, which was: public int get(int i) { return bb.getInt(ix(i)); } ... so we get slow byte-at-a-time implementations of all the getX and putX methods -- with no HotSpot intrinsic optimizations. And we get word tearing even though the data in a ByteBuffer view is always aligned. It never occurred to me that the ByteBuffer views didn't defer to the ByteBuffer.{get,put} methods. Either that or I forgot, but I should have fixed ByteBuffer views at the same time as HeapByteBuffer. It's not a huge job to fix this, but rather late for JDK 9. Andrew. [P.S. It's a little bit more complicated than this because a ByteBuffer view has the endianness that its parent had when the view was created. But that's not hard to do.]

2 3

RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup
by Jim Laskey (Oracle) 12 Jul '16

12 Jul '16

http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161067

3 6

--dry-run description enhancement
by Paul Benedict 12 Jul '16

12 Jul '16

The current help of --dry-run is this: "create VM but do not execute main method" But I think it's pretty important to note that the class is also not even loaded. Not even static initializers will execute. Does anyone think this would would be a worthwhile tweak? Suggestion: "create VM but do not load mainclass or execute main method" My allusion to "mainclass" comes from the --module option Cheers, Paul

5 10

JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better
by Brian Burkhalter 11 Jul '16

11 Jul '16

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160215 Diff: --- a/test/java/io/Reader/ReaderBulkReadContract.java +++ b/test/java/io/Reader/ReaderBulkReadContract.java @@ -148,7 +148,8 @@ private static File createTempFileWithContents(String contents) { try { - File file = File.createTempFile("ReaderContract", ""); + File testDir = new File(System.getProperty("test.dir", ".")); + File file = File.createTempFile("ReaderContract", "", testDir); try (FileWriter w = new FileWriter(file)) { w.write(contents); Summary: Create temporary files in the test scratch directory instead of in the default temporary file directory. Thanks, Brian

3 5

CompletableFuture eventual race condition
by Francois Green 11 Jul '16

11 Jul '16

I sorry for posting in list, but I need an authoritative answer. I was told by one of the developers of another JVM (Ceylon) language that CompletableFuture.supplyAsync(() -> "Hejjo Worjd from Java") .thenApply(s -> s.replaceAll("j","l")) .thenAccept(System.out::println); would eventual fail to print if run enough times. Is this true?

3 3

Fwd: CompletableFuture eventual race condition
by Francois Green 11 Jul '16

11 Jul '16

---------- Forwarded message ---------- From: Francois Green <francois.green(a)gmail.com> Date: Mon, Jul 11, 2016 at 3:22 PM Subject: Re: CompletableFuture eventual race condition To: Martin Buchholz <martinrb(a)google.com> I'm sorry for not posting the complete example. The claim was, given enough trials, this program will eventually fail to print due to a race condition. import java.util.concurrent.*; public class HelloWorld { public static void main(String[] args) { CompletableFuture.supplyAsync(() -> "Hejjo Worjd from Java") .thenApply(s -> s.replaceAll("j","l")) .thenAccept(System.out::println); } } I doubt this claim, but I'm in no position to counter it. Thanks for help you can provide.

1 0