June 2015 - core-libs-dev

[9] Review request: JDK-8129532: LFMultiThreadCachingTest.java failed with ConcurrentModificationException
by Konstantin Shefov 23 Jun '15

23 Jun '15

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8129532 Webrev is http://cr.openjdk.java.net/~kshefov/8129532/webrev.00/ Thanks -Konstantin

2 1

[9] RFR of 8129499: Structure of java/rmi/activation/rmidViaInheritedChannel tests masks exception
by Brian Burkhalter 22 Jun '15

22 Jun '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8129499 Patch: http://cr.openjdk.java.net/~bpb/8129499/webrev.00/ Summary: The instance variable ‘rmid’ is never initialized due to some error which occurs before the statement which would initialize it but it is dereferenced in the finally block which causes any exception within the try block to be suppressed. This issue blocks obtaining further information from tests runs with respect to https://bugs.openjdk.java.net/browse/JDK-8077668. Thanks, Brian

3 2

RFR 8129120 Terminal operation properties should not be back-propagated to upstream operations
by Paul Sandoz 22 Jun '15

22 Jun '15

Hi, http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8129120-flag-back-propagation/… I am a little red in the face (of the embarrassed kind) about this fix. We found an issue reported on stack overflow whereby a stream can report incorrect results. I may be wrong but this might be the first reported case in 8. We thought we had a clever little way of back-propagating characteristics of the terminal operation upstream to optimise stream pipelines. More specifically to back-propafate the unordered characteristic up through the pipeline until a stateful short-circuiting operation was reached. The general idea we had in mind, but never implemented, was to elide operations such as sort in the following case: parallel().sorted().forEach(...) There is no need to sort then parallel execution of the terminal operation does not care about order. Although one can reasonably argue it's a user issue in this case. The current implementation approach is wrong and causes incorrect results in the following cases: // http://stackoverflow.com/questions/30843279/stream-skip-behavior-with-unord… List<Integer> input = IntStream.rangeClosed(1, 20).collect(Collectors.toList()); Set<Integer> output = input.parallelStream().filter(x -> x > 0) .skip(1) .unordered() .collect(Collectors.toSet()); // The output set may contain 1 List<Integer> input = IntStream.rangeClosed(1, 20).mapToObj(i -> new Integer(0)). collect(Collectors.toList()); Integer v = input.get(0); System.out.println(Integer.toHexString(System.identityHashCode(v))); Collection<Integer> output = input.parallelStream() .distinct() .collect(Collectors.toSet()); Integer v1 = output.iterator().next(); System.out.println(Integer.toHexString(System.identityHashCode(v1))); // Distinct may not be stable Thankfully these are kind of edge cases so the damage is limited. There are two main aspects to the webrev: 1) remove the back propagation logic, which simplifies the preparation of the pipeline for parallel execution and also cleans up a certain aspect of toArray optimisation that i had been meaning get around to (regarding how the pipeline is sliced in this case). 2) adjust the tests in UnorderedTest. While i could of placed such tests in each corresponding op-specific test i thought it better to keep this focused, plus bulking out the op-specific tests in certain cases can increase the execution time (more specifically when certain HotSpot flags are used like -Xcomp). Paul.

2 2

RFR 9: 8129344 : (process) ProcessHandle instances should define equals and be value-based
by Roger Riggs 22 Jun '15

22 Jun '15

Please review this update to ProcessHandle to specify the equals method and that (JDK provided) instances have value-base semantics. This update to the spec is needed to support pending work to uniquely identify processes (8078099) using the process start time if available from the operating system. Wordsmithing may be needed. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-equals-8129344/ Issue: https://bugs.openjdk.java.net/browse/JDK-8078099 Thanks, Roger

2 1

RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version
by Roger Riggs 20 Jun '15

20 Jun '15

Please review code for Windows 10 that sets the System properties for os.name and os.version from the version of kernel32.dll. The update uses the same technique used by Hotspot in src/os/windows/vm/os_windows.cpp. The Windows link of CoreLibraries.gmk includes version.lib/dll. The behavior of GetVersionEx has changed so it reports whatever version the application asserts it is compatible with instead of the current version of Windows. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85… The same change is desirable for 8u60. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/ Issue: https://bugs.openjdk.java.net/browse/JDK-8066504 Thanks, Roger

5 10

[verona.stage] RFR 8087203: Add support for PATCH field and remove unused fields of new version string
by Alejandro E Murillo 19 Jun '15

19 Jun '15

Please review these changes: Bug: https://bugs.openjdk.java.net/browse/JDK-8087202 Webrev: http://cr.openjdk.java.net/~amurillo/9/8087202 These are intended to: (1) Add support for the patch field of the new version string format (2) Remove unused fields remaining from the old version string format (3) Patch some jaxp initialization code to be able to handle the new version string. this will be pushed under a different bug number, but is required to be able to run and pass all the tests associated with "-testset hotspot" (for JFR tests the VM can't be started without that). These will be pushed under this sub-task: https://bugs.openjdk.java.net/browse/JDK-8098588 (4) Additional notes: (a) Some pieces of code, only necessary for 1.5 or older, were removed (b) update_version and special_update_version were removed (c) The code to parse the version string in jdk/test/sun/misc/Version/Version.java will probably change when the Version.java class is available. (d) As with the changes for 8085822, this is all being pushed to [1] and then later to jdk9/dev (e) These changes should address most, if not all, of the issues raised during the code review for JDK-8085822 (see also https://bugs.openjdk.java.net/browse/JDK-8087203) (f) All builds and tests pass for "-testset hotspot". [1] http://hg.openjdk.java.net/verona/stage Thanks -- Alejandro

4 8

RFR of 8074819: Resolve disabled warnings for libzip
by Xueming Shen 19 Jun '15

19 Jun '15

Hi, Please help review the change to resolve the disabled "parentheses" warnings for libzip issue: https://bugs.openjdk.java.net/browse/JDK-8074819 webrev: http://cr.openjdk.java.net/~sherman/8074819 thanks, Sherman

5 5

[9] RFR of 8079539: java/util/prefs/CodePointZeroPrefsTest.java fails with "java.util.prefs.BackingStoreException: Couldn't get file lock."
by Brian Burkhalter 18 Jun '15

18 Jun '15

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8079539 Diff: --- a/test/java/util/prefs/CodePointZeroPrefsTest.java +++ b/test/java/util/prefs/CodePointZeroPrefsTest.java @@ -28,6 +28,7 @@ * @test * @bug 8068373 8075110 8075156 * @summary Ensure a code point U+0000 null control character is detected. + * @run main/othervm -Djava.util.prefs.userRoot=. CodePointZeroPrefsTest */ public class CodePointZeroPrefsTest { The problem was due to a lack of permissions to set up the user root. This resulted from my omission to include the definition of the java.util.prefs.userRoot property in a @run tag. Regression test job is in progress. Thanks, Brian

2 2

JDK-8057919 Class.getSimpleName() should work for non-JLS compliant class names
by Jochen Theodorou 18 Jun '15

18 Jun '15

Hi all, this mail is refering to http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-April/032733.html and JDK-8057919 In a groovy program def cl = { -> '' } assert cl.class.anonymousClass == false the open block {->''} is compiled into an inner class. We had problems with this in the past, because for several reasons we did not follow the JLS naming conventions here. The change in JDK-8057919 was supposed to make things better, but the change also means that our open block class will now have an empty simple name. At the same time reflection tells me the class is not an anonymous class. If I see this right, then regardless of if we set the attributes right or not, reflection and getSimpleName have a differing understanding about the nature of that class. I consider that a bug. They should have a common understanding about what a anonymous inner class is, since getSimpleName is supposed to return an empty string for that case. plus... it would be really really nice if someone could tell me how a non-anonymous class in a method has to look like with javap, so that I can know from there if it is no anonymous and finally fix he flags for Groovy's class generation. Because javap and the asm lib really don't help much with getting inner classes and their flags right. bye jochen -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/

5 13

Spliterators of iterators
by Martin Buchholz 17 Jun '15

17 Jun '15

Staring at LinkedTransferQueue.java, I see: return Spliterators.spliterator (a, 0, i, (Spliterator.ORDERED | Spliterator.NONNULL | Spliterator.CONCURRENT)); but ... that's a spliterator over an immutable array, so shouldn't we have IMMUTABLE instead of CONCURRENT? Looking further, I see ArraySpliterator requires its input array to be unmodified during operation * @param array the array, assumed to be unmodified during use ("assumed" is weird in javadoc. maybe "required"?) but ArraySpliterator does not include IMMUTABLE in characteristics, even though Arrays.spliterator does. I suggest fixing all these array spliterator characteristics to always report IMMUTABLE and never report CONCURRENT, and to document this fact, as we already do with SIZED and SUBSIZED.

2 6