August 2016 - core-libs-dev

RFE to re-purpose option --version:<version>
by Paul Benedict 17 Aug '16

17 Aug '16

Dear Committers, In Java 9, the --version:<version> has been deprecated. The error message returned to me is: Error: Specifying an alternate JDK/JRE version is no longer supported. The use of the flag '-version:' is no longer valid. Please download and execute the appropriate version. Unrecognized option: -version:9 I am happy with that. This is not a complain on removing that "alternate" feature. However, I would like to propose bringing back the option with a different purpose. I would like to use --version:<version> as a validation check. I want Java to execute ONLY if the version specified matches the actual platform version. This would be a wonderful help to scripts that require a particular version of the Java platform, and should fail if the environment has been accidentally setup with the wrong Java platform version. Examples: java --version:9 java --version:9.1 AFAICT, the only way to do this now is to execute Java twice. Once to pipe --version to some find/grep command and check return code, and then execute java again if the check pass. Loading the runtime twice is not optimal, wouldn't you agree? Yet if you agree to this proposal, it would be a big win for script writers, I believe. Opinions please. Thank you. Cheers, Paul

6 13

[9] RFR: 8164159: java/nio/file/WatchService/UpdateInterference.java test leaves daemon threads
by Artem Smotrakov 16 Aug '16

16 Aug '16

Hello, Please review the following patch for java/nio/file/WatchService/UpdateInterference.java test. The test creates a couple of daemon threads which have an infinite loop inside. When the test finishes, those daemon still keep running as long as jtreg use this instance of JVM to run other tests (the test doesn't run in othervm mode). The test also creates a WatchService which creates a "FileSystemWatchService" daemon thread. Then, the test doesn't close this WatchService, and as a result, this daemon thread keeps running as well. The test shouldn't leave daemon threads when it finishes. It may slow down further test execution. If other tests also leave daemon threads, it may cause intermittent test failures, see for example JDK-8160642 and JDK-8162757. The patch updates the test with the following: - threads are not daemons any more - "while" loops are not infinite - the test waits for threads to finish before closing a watch service to avoid ClosedWatchServiceException - the test closes a watch service in try-with-resources block - the test removes temporary files and directories in the end Bug: https://bugs.openjdk.java.net/browse/JDK-8164159 Webrev: http://cr.openjdk.java.net/~asmotrak/8164159/webrev.00/ Artem

1 0

RFR (JAXP) 6211561: XPath.evaluate(String, Object, QName) throws exception if context node is null
by Joe Wang 16 Aug '16

16 Aug '16

Hi, Please review a javadoc fix for XPath, and the same for XPathExpression. Error message is improved to be more relevant. Please ignore the Lic header for XPATHErrorResources.java, they will be handled in the future. JBS: https://bugs.openjdk.java.net/browse/JDK-6211561 Webrev: http://cr.openjdk.java.net/~joehw/jdk9/6211561/webrev/ Thanks, Joe

2 1

RFR of JDK9 8162519: Remove ParallelPrefix.java from ProblemList.txt
by Hamlin Li 16 Aug '16

16 Aug '16

There are 2 issues related to test/java/util/Arrays/ParallelPrefix.java, 1. JDK-8080165, which is marked as samebinary-highfrequency. Based on below information, I think this bug should have been resolved, although I don't know which change set resolve the issue, 1. the last failure happened more than one year before; 2. run 3 loops concurrently, in every loop run ParallelPrefix 1000 times sequentially, PrefixBug(Paul's reproducible code above) is run in below mode on jdk9-b128: java -server -XX:LoopUnrollLimit=0 -XX:TieredStopAtLevel=4 PrefixBug java -server -XX:LoopUnrollLimit=0 PrefixBug java -server PrefixBug 3. issue easily reproduced by build/run "javac/java PrefixBug" on jdk9-b64. 2. JDK-8085982, which is not reproduced. So, I think ParallelPrefix.java should be removed from ProblemList.txt bug: https://bugs.openjdk.java.net/browse/JDK-8162519 webrev: http://cr.openjdk.java.net/~mli/8162519/webrev.00/ Thank you -Hamlin

2 1

RFR 8162458 Buffer view implementations use incorrect offset for Unsafe access
by Paul Sandoz 16 Aug '16

16 Aug '16

Hi, I made an embarrassing mistake in the fix for https://bugs.openjdk.java.net/browse/JDK-8151163 All Buffer implementations should leverage Unsafe unaligned accessors The offset calculation for Unsafe access was incorrect, it’s easy to get confused because for heap buffers the offset is relative to the array, and for direct buffers the address (which can update for slices/duplicates). Disturbingly all existing tests were passing both for core and hotspot when i pushed to hs. As a penance i wrote a combinatorial test for buffer views to navigate the twisty maze of heap/direct, aligned/unaligned, little/big endian for accessing binary data and views from the source buffer. Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8162458-byte-buffer-view-offse… (This may be a duplicate of [1]). Test has been verified to fail with the existing code. Focused JPRT runs pass, but i will kick off core/hotspot runs later on today. I will push to hs since that is where JDK-8151163 and it has not been integrated into jdk9/dev. Paul. [1] https://bugs.openjdk.java.net/browse/JDK-8159257 unsafe.cpp: assert(byte_offset < p_size) failed: Unsafe access: offset 32767 > object's size 16 For the test runtime/Unsafe/RangeCheck.java I can reproduce a crash in jdk9/dev which does not have JDK-8151163, and i can reproduce on jdk9/hs with this fix for JDK-8162458.

6 10

NIO Path enhancements?
by Stephen Colebourne 15 Aug '16

15 Aug '16

I've been using the java.nio.file.Path API in the last few days and have found it a little tricky to use. I'd like to understand if the following ideas were ever considered (to consider whether an issue should be raised). Currently, developers create a Path instance and it contains various methods for managing the path, plus a few that actually access the filing system. However, for most filing system operations, developers have to use the static methods on Files. This feels very non-intuitive and hard to discover. Current code: Path path = Paths.get("/my/path/to/file.txt"); if (Files.exists(path)) { boolean dir = Files.isDirectory(path); ... } Almost all methods on Files simply obtain the FileSystemProvider from the FileSystem and invoke methods on that. Why not add a new class PathOperations that binds the Path to the static methods? Path path = Paths.get("/my/path/to/file.txt"); if (path.operations().exists()) { boolean dir = path.operations().isDirectory(); ... } I can't see any reason why this wouldn't work, but perhaps I'm missing something obvious. (All methods on Files would need to be replicated on PathOperations, and maybe Files could be deprecated if the deprecation tools improve.) Separately, it is a little tricky grasping the ZIP file system, and that it needs to be opened and closed separately. Could we see a new method to indicate if a given path/file can be expanded to another FileSystem? if (path.operations().isExpandableToFileSystem()) { try (FileSystem fs = path.operations().expand()) { // work with ZIP or similar } } This would be a lot more discoverable with appropriate docs. BTW, this also relates to Jigsaw as the new JFS provider may make expandable paths more widely used. Stephen

1 1

Executors enhancement
by Christian Schulte 14 Aug '16

14 Aug '16

Hello, whenever I need to update an existing codebase to add some kind of parallelization, I am in the need of an executor matching the number of processors available at runtime. Most of the time I end up using something like: 'Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors())' If every library used by an application needs to maintain its' own executors the application ends up with starting number of libraries used times number of available processors threads. That does not scale. I think there really is a need for some kind of default executor provided by the platform. I am suprised I cannot find anything like that anywhere. I would like to request an enhancement providing such a default platform executor everyone can use to add parallelization without ending up with tons of threads when all you want is making use of the system's parallelization capabilities. Regards, -- Christian

7 12

RFR: 8163946: java/lang/String/concat/WithSecurityManager.java fails after 8163878
by Claes Redestad 12 Aug '16

12 Aug '16

Hi, changing to use GetPropertyAction in MethodHandleImpl unexpectedly caused a nasty bootstrap issue. Moving the MAX_ARITY constant to MethodHandleStatics avoids the issue and might be sensible to do regardless. bug: https://bugs.openjdk.java.net/browse/JDK-8163946 webrev: http://cr.openjdk.java.net/~redestad/8163946/webrev.01/ Thanks! /Claes

3 2

RFR: jsr166 jdk9 integration wave 9
by Martin Buchholz 12 Aug '16

12 Aug '16

Again, no spec changes, but larger than expected. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ --- Joe and Amy may be interested in http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration… where we rewrite flaky tests with new mechanisms that are hopefully less flaky. We have some footprint tests that try to catch memory leaks, using reflective methods that the jigsaw folks might frown upon. There seems to be a need for module-privileged code for e.g. whitebox testing and running a debugger. Perhaps these tests will be an example of code so privileged, someday. Or we could decide such tests are more trouble than they're worth and simply discard them.

4 9

RFR: 8163878: Remove unnecessary bridge methods, allocations in java.lang.invoke
by Claes Redestad 11 Aug '16

11 Aug '16

Hi, while further untangling the bootstrap of java.lang.invoke I found a number of trivial/minor/small contrivances, including: - calling of private methods and constants in parent classes generates and heavily exercise synthetic bridge methods; carefully making more of these package-private cleans the air - use of MethodType.parameterList() and .subList() pull in extra classes in places I missed during JDK-8163370 analysis; preferring parameterType/parameterCount/Arrays.copyOf also reduces allocations - removed some pointless bookkeeping and duplicate checks of constant placeholders in InvokerBytecodeGenerator - since I was already changing around in StringConcatFactory I reworked some changes I made during JDK-8163370 that proved controversial Webrev: http://cr.openjdk.java.net/~redestad/8163878/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8163878 All in all -45K executed bytecodes and 9 fewer loaded classes in my favored startup test. Thanks! /Claes

4 3