December 2017 - core-libs-dev

RFR (JDK10/JAXP Doc-only) 8193568 : @LastModified tag in license header
by Joe Wang 21 Dec '17

21 Dec '17

Hi, Refer to the previous change for JDK-8191938[1], the @LastModified tag needs to be moved to the class description section. This change affects 341 files and may be hard to look through. But it's done with a script that simply moves the tag from the top header to the class description section, the majority therefore are two-line changes ( e.g "2 lines changed"). If the original description section didn't have any tags, an additional comment-line is added to separate the tag with the description ( look for "3 lines changed"). If a class didn't have a class description at all, a new one is added (therefore "4 lines changed"). Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8193568 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8193568/webrev/ [1] https://bugs.openjdk.java.net/browse/JDK-8191938 Thanks, Joe

2 2

[PATCH] Support for UTC Zones with TimeZone.getTimeZone()
by Mohamed Naufal 21 Dec '17

21 Dec '17

Hi, I noticed that with the following data: LocalDateTime ldt = LocalDateTime.parse("2017-01-01T00:00:00"); ZonedDateTime dt1 = ZonedDateTime.of(ldt, ZoneId.of("GMT+10")); ZonedDateTime dt2 = ZonedDateTime.of(ldt, ZoneId.of("UTC+10")); dt1.equals(dt2) returns true as expected, but with: GregorianCalendar gc1 = GregorianCalendar.from(dt1); GregorianCalendar gc2 = GregorianCalendar.from(dt2); gc1.equals(gc2) returns false. Looking at the code, I see when a GregorianCalendar is being constructed, TimeZone.getTimeZone() gets called, but it doesn't recognise UTC time-zones with offsets, and falls back to GMT(+0), whereas ZoneId treats GMT and UTC based zones equivalently. PFA a patch to fix this. Thank you, Naufal

2 3

RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()
by Stuart Marks 21 Dec '17

21 Dec '17

Hi all, Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. Corresponding methods are also added to OptionalDouble, Int, and Long. The orElseThrow() method is functionally identical to get(). It has some affinity with the existing orElseThrow(exceptionSupplier) method, being equivalent to orElseThrow(NoSuchElementException::new). The get() method is functionally unchanged. It is NOT being deprecated, although some wording in the doc has been added to point to orElseThrow() as the "preferred alternative." This is part of a (slow) migration away from Optional.get(), which has an obvious, attractive name that is often misused. These issues have been discussed on this list previously: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-April/040484.html Please note that much of that discussion was about the then-proposed deprecation of Optional.get(), which is NOT part of this proposal. There are no plans to deprecate Optional.get() at this time. This proposal ONLY introduces a new method orElseThrow() that is identical in function to get(). Bug report: https://bugs.openjdk.java.net/browse/JDK-8140281 Webrev: http://cr.openjdk.java.net/~smarks/reviews/8140281/webrev.1/ Thanks, s'marks

7 12

[10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap
by Paul Sandoz 21 Dec '17

21 Dec '17

Hi, Please review this fix for a bug in the stream takeWhile operation: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8193856-takeWhile-incorrect-r… <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8193856-takeWhile-incorrect-r…> The flatMap operation is currently aggressive and does not detect if a downstream operation may or has cancelled processing, and will push all of it’s elements downstream. Short-circuiting operations should be guarded against such behaviour but unfortunately takeWhile was not guarded. — Separately i plan to figure out a way to ensure flatMap operations become less aggressive if there are short-circuiting downstream operations. This may increase efficiency and also allow support for flat map results that are infinite. Paul.

3 3

RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit
by Ramanand Patil 20 Dec '17

20 Dec '17

Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8153955 Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266 Webrev: http://cr.openjdk.java.net/~rpatil/8161266/webrev.00/ Summary(also added to backport bug description): The fix from JDK9 cannot be backported as is into the jdk8u and earlier update releases, since it contains JDK API spec changes. In JDK9 the fix is added by altering the FileHandler spec, which introduces a new configurable property "java.util.logging.FileHandler.maxLocks" to java.util.logging.FileHandler, defined in .../conf/logging.properties. The solution proposed for update releases is: To introduce an internal JDK implementation specific property- "jdk.internal.FileHandlerLogging.maxLocks" which will be used to control/override FileHandler's MAX_LOCKS value. The default value of the maxLocks (100) will be retained if this new System property is not set. The new property is read only once during FileHandler class initialization. Regards, Ramanand.

3 3

[11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support
by David Holmes 20 Dec '17

20 Dec '17

Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b11. So we then need to ensure that jtreg 4.2 b11 is used by updating the requiredVersion in each of the TEST.ROOT files, and in the jib configuiration. bug: https://bugs.openjdk.java.net/browse/JDK-8193838 webrev: http://cr.openjdk.java.net/~dholmes/8193838/webrev/ Testing - TBD once b11 is promoted - local build using jib - hs/jdk tier1 and tier2 Thanks, David

3 4

RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad
by Baesken, Matthias 20 Dec '17

20 Dec '17

Hello , Mark reported this issue on AIX with OpenJDK8 : > >I'm getting an unsatisfied link error when using logstash on AIX but I suspect the issue is with AIX or the JRE, the exception is: > > java.lang.UnsatisfiedLinkError: sun.management.OperatingSystemImpl.getProcessCpuLoad()D > getProcessCpuLoad at sun/management/OperatingSystemImpl.java:-2 > <init> at org/logstash/instrument/monitors/ProcessMonitor.java:40 > detect at org/logstash/instrument/monitors/ProcessMonitor.java:79 > generate at org/logstash/instrument/reports/ProcessReport.java:15 > > this is the line in logstash: > > this.cpuProcessPercent = scaleLoadToPercent(unixOsBean.getProcessCpuLoad()); > > https://github.com/elastic/logstash/blob/master/logstash-core/src/main/java… > > > Could anybody help steer me in the right direction? > This fix addresses the missing getSystemCpuLoad and getProcessCpuLoad on AIX . JDK8 is only affected , JDK9 and higher is not affected . Could I get a review for this change ? Change : http://cr.openjdk.java.net/~mbaesken/webrevs/8193807/ Bug : https://bugs.openjdk.java.net/browse/JDK-8193807 Thanks, Matthias

3 2

[11] RFR 8193085 Vectorize the nio Buffer equals and compareTo implementations
by Paul Sandoz 19 Dec '17

19 Dec '17

Hi, Please review this patch to vectorize the buffer equals and compareTo implementations, using the same approach that was used for arrays: http://cr.openjdk.java.net/~psandoz/jdk/JDK-8193085-buffer-equals-compareTo… <http://cr.openjdk.java.net/~psandoz/jdk/JDK-8193085-buffer-equals-compareTo…> This patch expands on using the double address mode of unsafe to uniformly access a memory region covered by a buffer be it on or off heap. Only buffers with the same endianness can support optimized equality and comparison. — A follow on issue will explore a mismatch method (thus enabling support for float/double comparison that is compatible with arrays), and equals/compareTo methods that accept absolute positions (to avoid the dup.pos.limit.slice dance). Thanks, Paul.

3 6

RFR: JDK-8193780: (ref) Remove an undocumented "jdk.lang.ref.disableClearBeforeEnqueue" system property
by mandy chung 19 Dec '17

19 Dec '17

Webrev: http://cr.openjdk.java.net/~mchung/jdk11/webrevs/8193780/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8193781 This patch removes the "jdk.lang.ref.disableClearBeforeEnqueue" system property support which was added to provide an interim solution to restore to JDK 8 behavior of `Reference::enqueue` not to clear the referent. I propose to remove this in 11. Mandy

2 1

[8u] RFR(S) 8059036: Implement Diagnostic Commands for heap and finalizerinfo
by David Buck 18 Dec '17

18 Dec '17

Hi! May I please get a review of the following very simple backport of this serviceability improvement to JDK 8? The two hotspot jtreg test cases needed to be modified slightly because of the lack of dcmd-specific test support in JDK 8's HS code base. The only non-test difference from the JDK 9 changeset is modifying an include directive (objArrayOop.inline.hpp -> objArrayOop.hpp) to compensate for JDK-8072911. bug report: https://bugs.openjdk.java.net/browse/JDK-8059036 JDK 9 changesets: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/56a527afc34a http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/9b17d0a2720f JDK 9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-May/033169.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/033835.html JDK 8 backport webrevs for review: http://cr.openjdk.java.net/~dbuck/8059036.0_jdk8/ Cheers, -Buck [0] https://bugs.openjdk.java.net/browse/JDK-8072911

2 2