September 2018 - core-libs-dev

[12]RFR 8210443: Migrate Locale matching tests to JDK Repo.
by Dora Zhou 24 Sep '18

24 Sep '18

Hello, Please help review the fix for migrating GS-auto Locale matching tests to JDK repository. Please refer to the bug description for details. Bug: https://bugs.openjdk.java.net/browse/JDK-8210443 Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ <http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/> Regards, Dora

3 2

Collections.removeIf spec says nothing whether predicate may refer to collection
by Tagir Valeev 24 Sep '18

24 Sep '18

Hello! When using removeIf, sometimes it's tempting to refer to the collection from the predicate. E.g.: static List<Integer> select(Collection<Integer> input) { List<Integer> result = new LinkedList<>(input); result.removeIf(left -> result.stream().noneMatch(right -> right == left * 2)); return result; } Here one may assume that every time the predicate returns true, the collection is updated and the subsequent predicate invocations see the updated collection. This works for default removeIf implementation, but doesn't work for optimized ones like ArrayList, so replacing LinkedList with ArrayList in this weird algorithm produces different result (e.g. with List.of(1, 4, 2) input). I think that spec should explicitly say that intermediate updates are not guaranteed to be visible for predicate. What do you think? With best regards, Tagir Valeev

2 1

RFR(M) : 8210894 : remove jdk/testlibrary/Asserts
by Igor Ignatyev 21 Sep '18

21 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html > 1188 lines changed: 252 ins; 591 del; 345 mod; Hi all, could you please review the next clean up of jdk testlibrary? now we are replacing all usages of jdk.testlibrary.Asserts w/ jdk.test.lib.Assert class and remove j.t.Asserts. While working on it, I've also replaced '(../)+lib/testlibrary/' w/ '/lib/testlibrary/' in the touched tests. webrev: http://cr.openjdk.java.net/~iignatyev//8210894/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210894 testing: tier[1-3], :jdk_svc, :jdk_security_infra and :jdk_desktop + test/jdk/java/awt tests locally on mac Thanks, -- Igor

2 2

RFR: 8210275: Source Launcher should fail if --source is used without a source file
by Jonathan Gibbons 21 Sep '18

21 Sep '18

Please review a small fix to the source launcher that showed up as the launcher sometimes ignoring the --source option and finding/running a class on the class path. The problem occurs when the classpath is set after the --source option, causing LM_CLASS mode to override the setting of LM_SOURCE. In addition, some of the error messages that may be reported by the source launcher are improved to use "source file" instead of "file" as an indication that source-file mode is being used. JBS: https://bugs.openjdk.java.net/browse/JDK-8210275 Webrev: http://cr.openjdk.java.net/~jjg/8210275/webrev.00/index.html -- Jon

3 3

RFR(XS): 8210925 : move bytecode testlibrary to top-level testlibrary
by Igor Ignatyev 21 Sep '18

21 Sep '18

http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html > 14 lines changed: 0 ins; 0 del; 14 mod; Hi all, could you please review this small and trivial patch which moves bytecode testlibrary to top-level testlibrary directory? webrev: http://cr.openjdk.java.net/~iignatyev//8210925/webrev.00/index.html JBS: https://bugs.openjdk.java.net/browse/JDK-8210925 testing: java/lang/invoke/condy tests Thanks, -- Igor

3 4

RFR 12 : 8072130 : java/lang/instrument/BootClassPath/BootClassPathTest.sh fails on Mac OSX
by Brent Christian 21 Sep '18

21 Sep '18

Hi, Please review this change to how the platform encoding is determined on Mac when loading agents. Webrev: http://cr.openjdk.java.net/~bchristi/8072130/webrev.01.cleanned/ Additional details in the bug report: https://bugs.openjdk.java.net/browse/JDK-8072130 Some background: Since JDK 8, if MacOS reports an encoding of US-ASCII, but no encoding hints are provided in environment variables (LANG, LC_ALL, LC_CTYPE), the JDK uses UTF-8 instead; see JDK-8011194[1]. (This allowed apps launched via double-clicked jar to display files correctly for non-ASCII languages). A similar encoding tweak was not made in the code path used for loading agents. This can come into play when an agent jar includes a Boot-Class-Path entry containing non-ASCII characters. iconv() gets setup to convert UTF-8 to US-ASCII[2], but will fail when encountering extended characters in the entry, so the path in question is not added to the bootclasspath[3]. This will likely lead to a ClassNotFoundException. When java/lang/instrument/BootClassPath/BootClassPathTest.sh is run on a Mac with no values for LANG/LC_ALL/LC_CTYPE, Setup.java sees a default encoding of UTF-8 (per 8011194) and creates Agent.jar with a Boot-Class-Path that includes non-ASCII characters. But the Boot-Class-Path entry gets skipped when loading Agent.jar, so the AgentSupport class can't be found. I propose this be fixed by adding the same UTF-8 encoding adjustment on MacOS from 8011194 to the agent loading code path. An additional note: This bug was challenging to reproduce, in large part because the 8011194 code checks for an absent env var (getenv() == null), but not for env vars with a blank/empty string value (getenv() == ""), so the test environment had to be setup in a specific way (e.g. 'unset LANG' vs 'export LANG=') to reproduce this bug. So I'd like to update the code to also check for empty string. I also added a couple small improvements to the test. Thanks! -Brent 1. https://bugs.openjdk.java.net/browse/JDK-8011194 2. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/un… 3. http://hg.openjdk.java.net/jdk/jdk/file/0517bd2a0eda/src/java.instrument/sh…

2 3

[12] RFR 8199931: java/net/MulticastSocket/UnreferencedMulticastSockets.java fails with "incorrect data received"
by Chris Yin 21 Sep '18

21 Sep '18

Please review below minor change for 8199931, thanks A little explanation about the change here, since the failure samples are too less (seems too hard to repro), so below scenario which caused the failure is a guess. MultcastSocket constructor set reuse address true by default, when call “new MulticastSocket(0)” to create client socket that maybe in a little possibility it used same address with server, that will explain why the failure looks like client received data package from itself. Follow the guessing, I modified test code to explicit create client socket use same port with server, then got same failure error as reported bug on OEL7. Though I cannot make sure the guess is 100% match with the original failure, but at least we could try to prevent such possible scenario. bug: https://bugs.openjdk.java.net/browse/JDK-8199931 changes: diff -r 43668e3cae4d test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java --- a/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java Thu Sep 20 08:59:03 2018 +0200 +++ b/test/jdk/java/net/MulticastSocket/UnreferencedMulticastSockets.java Thu Sep 20 16:37:36 2018 +0800 @@ -40,6 +40,7 @@ import java.net.DatagramSocket; import java.net.DatagramSocketImpl; import java.net.InetAddress; +import java.net.InetSocketAddress; import java.net.MulticastSocket; import java.net.UnknownHostException; import java.nio.file.Files; @@ -119,7 +120,10 @@ Thread thr = new Thread(svr); thr.start(); - MulticastSocket client = new MulticastSocket(0); + MulticastSocket client = new MulticastSocket(null); + // prevent MulticastSocket reuse previous address, see 8199931 + client.setReuseAddress(false); + client.bind(new InetSocketAddress(0)); client.connect(svr.getHost(), svr.getPort()); pendingSockets.add(new NamedWeak(client, pendingQueue, "clientMulticastSocket")); extractRefs(client, "clientMulticastSocket”); Regards, Chris

2 4

SSL session cache default maximum number of entries
by Hohensee, Paul 20 Sep '18

20 Sep '18

The default value for the maximum number of entries in the SSL session cache (which is a SoftReference cache) is infinite, and the entry timeout is 24 hours. With larger heaps, we’re running into situations where the cache ends up with several million entries when the 24 hours are up. They’re then all invalidated at the same time, resulting in multi-minute pauses (effectively service failures). We’ve experimented with using 10k as the default maximum number of entries with good results (i.e., no latency increases due to sessions falling out of the cache). It’s late and a long shot for JDK11: we’d love to see it changed there because 11 is an LTS release and this is, at least nominally, a behavior change which might not be acceptable in 11u. What do people think? Thanks, Paul

2 5

Source file launcher - Handling of pre-compiled classes of the source file
by Jaikiran Pai 20 Sep '18

20 Sep '18

Please consider this trivial code C.java: public class C { public static void main(String[] args) throws Exception { System.out.println("main() execution started"); } } > ls C.java Similar to a previous discussion[1] while doing random testing, I ended up compiling C.java explicitly using javac: > javac C.java > ls C.java C.class and then at a later date tried to use the source file launcher feature of Java 11 (without realizing C.class was already present in the dir): > java C.java This threw the error: error: class found on application class path: C Although the error isn't that clear for the reason I note in [2], having run into this before, I was aware what this meant and deleted the C.class and moved on. The important part here is that the source launcher noticed this condition and aborted even before it auto compiled(?) and launched and executed the main() of the program. Now consider a slight modification to that source file: public class C { public static void main(String[] args) throws Exception { System.out.println("main() execution started"); final B b = new B(); System.out.println("Done"); } private static class B { } } Again at some point I compiled this explicitly using javac, so my directory is (among other things): > ls C$B.class C.class C.java Then ran the source file launcher feature: > java C.java error: class found on application class path: C As expected, ran into the same previous error. As before, in order to move on, deleted C.class: > rm C.class but forgot to delete the nested static class that belonged to it. So the directory now contained: > ls C$B.class C.java Now used the source launcher feature again: > java C.java This time it failed with: main() execution started Exception in thread "main" java.lang.IllegalAccessError: failed to access class C$B from class C (C$B is in unnamed module of loader 'app'; C is in unnamed module of loader com.sun.tools.javac.launcher.Main$MemoryClassLoader @1b1473ab) at C.main(C.java:4) The error message isn't clear to pinpoint the issue, but at least the reference to MemoryClassLoader was a hint that was enough for me to understand where to look. It did take me a few minutes to realize that C$B.class was lying around which I needed to remove too. However, IMO, the important part here is that unlike in the first case where the program itself wasn't launched and instead was aborted early, in this case the program did get executed (notice the System.out.println "main() execution started" message that got printed) and failed at runtime. Would it be possible to make these two behaviours consistent and detect such cases and abort early here too? Or would that add too much complexity to this feature? Finally, any thoughts on the error messages for this feature to make it a bit easier in terms of debugging (classloading) issues like these? [1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001425.html [2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-June/001438.html -Jaikiran

4 9

RFR - JDK-8202442 - String::unescape (Code Review)
by Jim Laskey 20 Sep '18

20 Sep '18

Please review the code for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. webrev: http://cr.openjdk.java.net/~jlaskey/8202442/webrev/index.html jbs: https://bugs.openjdk.java.net/browse/JDK-8202442 csr: https://bugs.openjdk.java.net/browse/JDK-8202443 Cheers, — Jim

6 16