August 2016 - core-libs-dev

RFR: 8164483: Generate field lambda forms at link time
by Claes Redestad 24 Aug '16

24 Aug '16

Hi, this patch adds link-time generation of the simplest field lambda forms. This avoid generating these forms during bootstrapping, which is commonly done early on in even the simplest startup tests. To make this work, injecting Unsafe as a constant replacement had to be replaced with a getter function, resulting in a few more bytecodes to do the same thing, but which after inlining should turn into equivalent code; performance testing indicate this change is performance neutral. Bug: https://bugs.openjdk.java.net/browse/JDK-8164483 Webrev: http://cr.openjdk.java.net/~redestad/8164483/webrev.01/ Together with JDK-8164569 (which I've tested together with this) this removes all class generation from runtime in the tests associated with JDK-8086045 Thanks! /Claes

2 3

RFR: 8164569: Generate non-customized invoker forms at link time
by Claes Redestad 24 Aug '16

24 Aug '16

Hi, this patch adds configurable link-time generation of the invoker forms. Some such forms is commonly used early on in even the simplest startup tests, and an unbounded number of invoker forms can be generated in more complex cases. Bug: https://bugs.openjdk.java.net/browse/JDK-8164569 Webrev: http://cr.openjdk.java.net/~redestad/8164569/webrev.01/ Together with JDK-8164483 (which I've tested together with this) this removes all class generation from runtime in the tests associated with JDK-8086045 I'd also note that the default setting in this patch is rather arbitrary: although it removes a handful of invokers in a number of tests, it's admittedly complicated to detect which ones are needed (same goes for already implemented options to select Direct-/DelegatingMethodHandles and BoundMethodHandle$Species_*). The plan is to implement JDK-8163371 in such a way that running a application with a tracing flag enabled will produce a file to use as the sole input to --generate-jli-classes. Thanks! /Claes

2 1

RFR: 8164669: Lazier initialization of java.time
by Claes Redestad 24 Aug '16

24 Aug '16

Hi, this tiny cleanup reduces number of loaded classes from a minimal test touching java.time.ZoneId.systemDefault() by ~40, by virtue of avoiding pulling in regex and some internal Calendar-related classes. Bug: https://bugs.openjdk.java.net/browse/JDK-8164669 Webrev: http://cr.openjdk.java.net/~redestad/8164669/webrev.01/ Thanks! /Claes

4 6

RFR of JDk9 8164623: Doc typo in java/util/concurrent/ConcurrentLinkedDeque.java and ConcurrentLinkedQueue.java
by Hamlin Li 24 Aug '16

24 Aug '16

Below doc is not correct, because for ConcurrentLinkedDeque and ConcurrentLinkedQueue, addAll is a atomic operation. "Additionally, the bulk operations addAll, removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically. For example, an iterator operating concurrently with an addAll operation might view only some of the added elements." It should be modified as some thing like below: "Additionally, the bulk operations removeAll, retainAll, containsAll, equals, and toArray are not guaranteed to be performed atomically." bug: https://bugs.openjdk.java.net/browse/JDK-8164623 webrev: http://cr.openjdk.java.net/~mli/8164623/webrev.00/ Thank you -Hamlin

3 10

RFR 8160971 Re-enable VarHandle tests quarantined by JDK-8160690
by Paul Sandoz 23 Aug '16

23 Aug '16

Hi, Please review an update to test/ProblemList.txt remove some VarHandle tests now that JDK-8160690 has been fixed. I will push to jdk9/dev unless HotSpot team members have a preference for me to push to hs-comp where the fix for JDK-8160690 was pushed. Paul. diff -r 5612c35465f3 test/ProblemList.txt --- a/test/ProblemList.txt Tue Aug 23 10:51:17 2016 -0700 +++ b/test/ProblemList.txt Tue Aug 23 15:07:22 2016 -0700 @@ -124,10 +124,6 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java 8160690 generic-all -java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java 8160690 generic-all

2 1

Exceptional behavior of parallel stream
by Tagir F. Valeev 23 Aug '16

23 Aug '16

Hello! I found no information in Stream API documentation on how it behaves in case if exception occurs during the stream processing. While it's quite evident for sequential stream (stream processing is terminated and exception is propagated to the caller as is), the behavior for parallel streams differs from one might expect. Consider the following test: String[] data = IntStream.range(0, 100).mapToObj(String::valueOf) .toArray(String[]::new); data[20] = "oops"; try { int sum = Arrays.stream(data).parallel().mapToInt(Integer::valueOf) .peek(System.out::println).sum(); System.out.println("Sum is "+sum); } catch (NumberFormatException e) { System.out.println("Non-number appeared!"); } This parses integers stored in string array and sums them outputting every number to stdout once it processed. As data set contains non-number, the stream obviously fails with NumberFormatException. The typical output looks like this: 62 63 12 31 87 ... 28 92 29 8 Non-number appeared! 9 30 So as you can see, the stream is not actually terminated when exception is thrown and caught: even after that some parallel tasks continue running, and you see more numbers printed after catch block is executed. I consider such behavior as confusing and unexpected. Given the fact that stream may produce side-effects (e.g. if terminal op is forEach) this might lead to unforeseen consequences in user programs as left-over parallel stream tasks may continue mutate shared state after main stream thread exceptionally returns the control to the caller. So I suggest that such behavior should be either fixed or explicitly documented. What do you think? With best regards, Tagir Valeev.

4 6

RFR 8157797: SAX Parser throws incorrect error on invalid xml
by Joe Wang 23 Aug '16

23 Aug '16

Hi, Please review a quick fix for an incorrect error that should never have been thrown. JBS: https://bugs.openjdk.java.net/browse/JDK-8157797 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8157797/webrev/ Thanks, Joe

2 2

Create java.util.stream.Stream from Iterator / Enumeration
by Patrick Reinhart 23 Aug '16

23 Aug '16

Hi there, I know you are busy getting the latest release ready. Still I have question according the java.util.stream.Stream's static helper methods. During my work I ran into a couple places where creating a Stream out of a Iterator or Enumeration directly would be quite handy. At the moment I have made me two methods like this on a helper class in oder to not duplicate the code: public static <T> Stream<T> iterate(Iterator<T> iterator) { Objects.requireNonNull(iterator); return StreamSupport.stream(Spliterators .spliteratorUnknownSize(iterator, Spliterator.ORDERED | Spliterator.IMMUTABLE), false); } public static <T> Stream<T> iterate(Enumeration<T> enumeration) { Objects.requireNonNull(enumeration); final Iterator<T> iterator = new Iterator<T>() { @Override public boolean hasNext() { return enumeration.hasMoreElements(); } @Override public T next() { return enumeration.nextElement(); } }; return iterate(iterator); } My question is now, if it would be worth while having something like this on the Stream itself? Cheers Patrick

3 18

RFR: 8148859 Fix module dependences for java/time tests
by Alexandre (Shura) Iline 23 Aug '16

23 Aug '16

Hi. Please review a quick fix for the java/time test module dependencies. http://cr.openjdk.java.net/~shurailine/8148859/webrev.00/ It is using new syntax added in JTReg, which allows to only build certain classes from a test library for TestNG tests: https://bugs.openjdk.java.net/browse/CODETOOLS-7901667 Shura

2 2

8164585: JarFile::isMultiRelease does not return true in all cases where it should return true
by Steve Drach 23 Aug '16

23 Aug '16

Hi, Please review this simple change to JarFile issue: https://bugs.openjdk.java.net/browse/JDK-8164585 <https://bugs.openjdk.java.net/browse/JDK-8164585> webrev: http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/ <http://cr.openjdk.java.net/~sdrach/8164585/webrev.00/> Thanks, Steve

3 2