August 2015 - core-libs-dev

RFR [9] 8133040: docs: replace <tt> tags (obsolete in html5) for java.management
by Alexander Stepanov 06 Aug '15

06 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8133040/webrev.00 for https://bugs.openjdk.java.net/browse/JDK-8133040 specdiffs: java.lang.management - no changes detected: http://cr.openjdk.java.net/~avstepan/8133040/java.lang.management/overview-… javax.management - one (expected) change in TabularDataSupport: http://cr.openjdk.java.net/~avstepan/8133040/javax.management/openmbean/pac… Regards, Alexander

2 3

RFR [9] 8132468: docs: replace <tt> tags (obsolete in html5) for java.io, java.lang, java.math
by Alexander Stepanov 06 Aug '15

06 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8132468/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132468 Just some cleanup for docs (replacing obsolete "<tt></tt>"). Thanks, Alexander

4 11

Review request for JDK-8132660: Change jaxp unit test package name to be different with jaxp api
by Frank Yuan 06 Aug '15

06 Aug '15

Hi, Joe and all Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8132660? This is already on our plan for a while, but I have to finish it now because these unit tests failed with latest Jigsaw build. However I made the changes based on 9-dev repo, I tested them with both Jigsaw build and 9-dev build. The JPRT successful mail is enclosed in the bug. The webrev is at: http://cr.openjdk.java.net/~fyuan/8132660/webrev.00/. It seems to be a big change but actually there are only some directories changed. Thanks, Frank

2 3

Review request: JDK-8080108: [TEST_BUG] ERROR: No IPv6 address returned from platform
by Alexander Fomin 05 Aug '15

05 Aug '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8080108 See webrev here http://cr.openjdk.java.net/~kshefov/8080108/webrev.00/ The original test (com/sun/jndi/dns/IPv6NameserverPlatformParsingTest.java @bug 6991580) fails automatically if /etc/resolv.conf file doesn't contain IPv6 nameserver entries. It's needed to edit /etc/resolv.conf manually before the test run, so this is a manual regression test. The test is intended to be run on non-Windows systems. Fix: - provided standard test machinery for regression manual tests with instructions for a user; - the test excluded for Windows. Tested on Linux and Windows(to make sure it's excluded). Thanks, Alexander

2 4

RFR [9] 8132877: docs: replace <tt> tags (obsolete in html5) for java.naming
by Alexander Stepanov 05 Aug '15

05 Aug '15

Hello, Could you please review the following fix: http://cr.openjdk.java.net/~avstepan/8132877/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8132877 Just some cleanup for docs (replacing obsolete "<tt></tt>"). Thanks, Alexander

4 11

RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes
by Stuart Marks 05 Aug '15

05 Aug '15

Hi all, The sequential() and parallel() methods on a stream set the execution mode for the entire pipeline. Unfortunately this isn't particularly clear from the documentation. This has been a recurring question. Please review this change to the java.util.stream package documentation to help clarify this point. I've also added a couple anchor tags that were missing from various sections. This is intended to be a purely editorial change, not a specification change. Bug: https://bugs.openjdk.java.net/browse/JDK-8132800 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8132800/webrev.0/ Thanks, s'marks

3 8

RFR(m): 8072722: add stream support to Scanner
by Stuart Marks 04 Aug '15

04 Aug '15

Hi all, Please review this API enhancement that adds streams support to java.util.Scanner. Scanner is essentially a regular expression matcher that matches over arbitrary input (e.g., from a file) instead of a fixed string like Matcher. Scanner will read and buffer additional input as necessary when looking for matches. This change proposes to add two streams methods: 1. tokens(), which returns a stream of tokens delimited by the Scanner's delimiter. Scanner's default delimiter is whitespace, so the following will collect a list of whitespace-separated words from a file: try (Scanner sc = new Scanner(Paths.get(FILENAME))) { List<String> words = sc.tokens().collect(toList()); } 2. findAll(pattern), which returns a stream of match results generated by searching the input for the given pattern (either a Pattern or a String). For example, the following will extract from a file all words that are surrounded by "_" characters, such as _foo_ : try (Scanner sc = new Scanner(Paths.get(FILENAME))) { return sc.findAll("_([\\w]+)_") .map(mr -> mr.group(1)) .collect(toList()); } Implementation notes. A Scanner is essentially already an iterator of tokens, so tokens() pretty much just wraps "this" into a stream. The findAll() methods are a wrapper around repeated calls to findWithinHorizon(pattern, 0) with a bit of refactoring to avoid converting the MatchResult to a String prematurely. The tests are pretty straightforward, with some additional cleanups, such as using try-with-resources. Bug: https://bugs.openjdk.java.net/browse/JDK-8072722 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8072722/webrev.0/ Specdiff: http://cr.openjdk.java.net/~smarks/reviews/8072722/specdiff.0/overview-summ… Thanks, s'marks

1 0

JDK 9 RFR of JDK-8132854: Adjust tier 1 and 2 definitions for nio-related intrinsics
by joe darcy 04 Aug '15

04 Aug '15

Hello, With the fix for JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate methods for which Java Runtime has intrinsics the sources for the libraries clearly indicate which methods might have intrinsic support in HotSpot, that is, which methods might have their Java source implementation replaced by some other code sequence maintained in HotSpot, such as a special-purpose processor-specific instruction. To ease testing, it would be help if all the intrinsified methods were included in the tier 1 test group. Most of the intrinics are in java.lang, java.math, and java.util, packages whose tests are already in tier 1. Two nio-related classes are marked with @HotSpotIntrinsicCandidate: ./java.base/share/classes/sun/nio/cs/ISO_8859_1.java # implEncodeISOArray marked ./java.base/share/classes/java/nio/Buffer.java # index check Therefore, I propose moving the tests that directly cover those areas to tier 1: --- a/test/TEST.groups Mon Aug 03 09:25:02 2015 +0800 +++ b/test/TEST.groups Sun Aug 02 20:16:00 2015 -0700 @@ -28,11 +28,15 @@ tier1 = \ :jdk_lang \ :jdk_util \ + sun/nio/cs/ISO8859x.java \ + java/nio/Buffer \ :jdk_math tier2 = \ :jdk_io \ :jdk_nio \ + -sun/nio/cs/ISO8859x.java \ + -java/nio/Buffer \ :jdk_net \ :jdk_time \ :jdk_security \ Full webrev at http://cr.openjdk.java.net/~darcy/8132854.0/ Thanks, -Joe

2 1

Encapsulating internal APIs in JDK 9 (sun.misc.Unsafe, etc.)
by mark.reinhold＠oracle.com 04 Aug '15

04 Aug '15

FYI: http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-August/004433.html (Please reply on jigsaw-dev rather than on jdk9-dev or core-libs-dev.) - Mark

1 0

Spliterator documentation on Priority(Blocking)Queue
by Tagir Valeev 04 Aug '15

04 Aug '15

Hello! The PriorityQueue class iterator() returns elements in no particular order. This is explicitly stated in JavaDoc for iterator() method [1] as well as in class description [2]. However it's not mentioned mentioned that spliterator() method also traverses the queue in no particular order. Well, the user might guess that the order is not specified, because the spliterator does not have ORDERED characteristic, but it's not so obvious for any user. Probably it's would be good to add an explicit note like it's done for iterator. The same thing is for PriorityBlockingQueue. What do you think? With best regards, Tagir Valeev. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/sha… [2] http://hg.openjdk.java.net/jdk9/dev/jdk/file/022d45d94d0a/src/java.base/sha…

2 5