May 2018 - core-libs-dev

Re: [concurrency-interest] Durations in existing JDK APIs
by Gregg Wonderly 31 May '18

31 May '18

I am not sure I understand this implementation, but isn’t > long s = convert(duration.getSeconds(), SECONDS); needing to actually be > long s = convert(duration.getSeconds(), NANOSECONDS); so that s+n is in a common unit of measure? Gregg > On May 30, 2018, at 7:19 PM, Martin Buchholz via Concurrency-interest <concurrency-interest(a)cs.oswego.edu> wrote: > > v.0.2 has both conversion methods in TimeUnit. The unexpected weirdness is that convert(Duration) saturates while toDuration throws ArithmeticException, but both seem author-culture-consistent. Perhaps TimeUnit#toDuration doesn't provide enough value in view of the existing Duration.of and TimeUnit#toChronoUnit. And most of the time you'd expect to convert from Duration to long, just before calling a TimeUnit based method. > > /** > * Converts the given time duration to this unit. > * > * @param duration the time duration > * @return the converted duration in this unit, > * or {@code Long.MIN_VALUE} if conversion would negatively overflow, > * or {@code Long.MAX_VALUE} if it would positively overflow. > * @throws NullPointerException if {@code duration} is null > */ > public long convert(Duration duration) { > long s = convert(duration.getSeconds(), SECONDS); > if (s == Long.MIN_VALUE) return s; > long n = convert(duration.getNano(), NANOSECONDS); > assert n >= 0 && n < 1_000_000_000; > return (s + n < s) ? Long.MAX_VALUE : s + n; > } > > /** > * Converts the given time duration in this unit to a Duration. > * > * @param duration the time duration > * @return the time duration represented as a Duration > * @throws ArithmeticException if the duration cannot be represented > * as a Duration due to numeric overflow > */ > public Duration toDuration(long duration) { > return Duration.of(duration, toChronoUnit()); > } > > _______________________________________________ > Concurrency-interest mailing list > Concurrency-interest(a)cs.oswego.edu > http://cs.oswego.edu/mailman/listinfo/concurrency-interest

2 1

RFR: jsr166 jdk integration 2018-05
by Martin Buchholz 31 May '18

31 May '18

Time to do this, since Claes is also touching ArrayList. http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/overview.… 8202685: Improve ArrayList replaceAll http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/replaceAl… https://bugs.openjdk.java.net/browse/JDK-8202685 8201386: Miscellaneous changes imported from jsr166 CVS 2018-05 http://cr.openjdk.java.net/~martin/webrevs/jdk/jsr166-integration/miscellan… https://bugs.openjdk.java.net/browse/JDK-8201386

9 38

RFR: 8201274: Launch Single-File Source-Code Programs
by Jonathan Gibbons 30 May '18

30 May '18

Please review an initial implementation for the feature described in JEP 330: Launch Single-File Source-Code Programs. The work is described in the JEP and CSR, and falls into various parts: * The part to handle the new command-line options is in the native Java launcher code. * The part to invoke the compiler and subsequently execute the code found in the source file is in a new class in the jdk.compiler module. * There are some minor Makefile changes, to add support for a new resource file. There are no changes to javac itself. JEP: http://openjdk.java.net/jeps/330 JBS: https://bugs.openjdk.java.net/browse/JDK-8201274 CSR: https://bugs.openjdk.java.net/browse/JDK-8201275 Webrev: http://cr.openjdk.java.net/~jjg/8201274/webrev.00/ -- Jon

7 18

RFR: JDK-8050818 Predicate::not - provide an easier way to negate a predicate
by Jim Laskey 30 May '18

30 May '18

Introduce a new static method Predicate::not which will allow developers to negate predicate lambdas trivially. webrev: http://cr.openjdk.java.net/~jlaskey/8050818/webrev/index.html bug: https://bugs.openjdk.java.net/browse/JDK-8050818 csr: https://bugs.openjdk.java.net/browse/JDK-8203428

5 4

RFR: JDK-8203839: API clarification: versioned jar entry verification in multi-release jar file
by Xueming Shen 30 May '18

30 May '18

Hi, Please help review the proposed api spec update for JDK-8203839 (and its CSR) issue: JDK-8203839: API clarification: versioned jar entry verification in multi-release jar file csr: https://bugs.openjdk.java.net/browse/JDK-8203840 webrev: http://cr.openjdk.java.net/~sherman/8203839/webrev Thanks, Sherman

4 3

RFR: 8203886: Invoke LambdaMetafactory::altMetafactory exactly from the BootstrapMethodInvoker
by Claes Redestad 29 May '18

29 May '18

Hi, similarly to JDK-8198418[1], we can avoid creation of various LambdaForms and SpeciesData types in various benchmarks by adapting calls to the altMetafactory as exactly as possible in the BootstrapMethodInvoker. Webrev: http://cr.openjdk.java.net/~redestad/8203886/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8203886 As an example, this means something Comparator.comparingInt(s -> s.hashCode())); uses 14 fewer LFs to set up. Thanks! /Claes [1] https://bugs.openjdk.java.net/browse/JDK-8198418

2 2

[11] RFR JDK-8203474: Update description of "Cyrillic Supplementary" block name in Character.UnicodeBlock class.
by Rachna Goel 29 May '18

29 May '18

Hi, Kindly review this small doc fix to Character.UnicodeBlock class. Bug: https://bugs.openjdk.java.net/browse/JDK-8203474 Patch: --- a/src/java.base/share/classes/java/lang/Character.java Sun May 27 12:00:16 2018 +0530 +++ b/src/java.base/share/classes/java/lang/Character.java Mon May 28 11:48:58 2018 +0530 @@ -1419,7 +1419,8 @@ "YIRADICALS"); /** - * Constant for the "Cyrillic Supplementary" Unicode character block. + * Constant for the "Cyrillic Supplement" Unicode character block. + * This block was previously known as the "Cyrillic Supplementary" block. * @since 1.5 */ CSR : https://bugs.openjdk.java.net/browse/JDK-8203475 -- Thanks, Rachna

2 1

RFR: 8193154: methods in java.time's TCKZoneRules OpenJDK test miss @Test annotation
by Vivek Theeyarath 27 May '18

27 May '18

Hi All, Please review fix for https://bugs.openjdk.java.net/browse/JDK-8193154 . http://cr.openjdk.java.net/~vtheeyarath/8193154/webrev.00/ The test ran fine with Mach5 http://java.se.oracle.com:10065/mdash/jobs/root-jdk-dev-20180526-0645-24095 Regards Vivek

2 3

[8u-dev] Request for Review and Approval to Backport 8203369 : Check for both EAGAIN and EWOULDBLOCK error codes
by Ivan Gerasimov 26 May '18

26 May '18

Hello! I'd like to backport this fix to jdk8u-dev. Some changes were required, comparing to the fix in JDK 11 (mostly due to the difference in the way to generate UnixConstants.java), thus the Request for Review. The patch was successfully built and tested on all supported platforms with no issues. Bug: https://bugs.openjdk.java.net/browse/JDK-8203369 JDk8u-dev webrev: http://cr.openjdk.java.net/~igerasim/8203369/01/webrev/ Jdk11 change: http://hg.openjdk.java.net/jdk/jdk/rev/69204b98dc3d Jdk11 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053429.html Thanks in advance! -- With kind regards, Ivan Gerasimov

1 0

Re: RFR: 8203028: Simplify reference processing in light of JDK-8175797
by mandy chung 25 May '18

25 May '18

Hi Kim, Thanks for doing this work and rewriting the comments. It's great to see this simplification. It looks good in general. I have a couple of personal preferences if you are okay to update them. I like to keep the existing indentation of the description of different states (line 50-75) that makes them easy to read. "normal reference" - I suggest to change it to "soft, weak, or phantom reference". FinalReference is also a Reference object and it's an implementation class that supports finalization. Making it explicit would avoid confusion. 86 * FinalReference (which exists to support finalization, which was 87 * deprecated in JDK 9) differs from normal references I suggest to drop "which was deprecated in JDK 9" since @Deprecated is in the javadoc and no implication to the implementation. Thanks for adding the comment of the possible transitions. I was tempted to make an ascii flow chart. State change due to the API makes it harder to draw. This is my first snap but it's not yet in a satisfying state. I think this is clearer than the text description. What do you think? If we like this, I can clean that up and send you a revised version. * Transitions: * clear * active/registered ------> inactive/registered * | | enqueue [2] * | GC enqueue [2] v * | ------> inactive/enqueued * v * pending/registered --- * | | * | enqueue [2] |-> inactive/enqueued (pending list processing) * v | | * pending/enqueued --| | * | | poll/remove * | poll/remove | * v v * pending/dequeued -----> inactive/dequeued * * clear/enqueue * active/unregistered -----> inactive/unregistered * | * | GC * v * pending/unregistered -> inactive/unregistered - pending list processing 114 * -> inactive/unregistered - GC, clear, enqueue Under what circumstance does GC make a reference from active/unregistered -> inactive/unregistered? Mandy On 5/20/18 8:12 AM, Kim Barrett wrote: >> On May 15, 2018, at 12:09 AM, Kim Barrett <kim.barrett(a)oracle.com> wrote: >> New webrev, rebased to include JDK-8201491: >> http://cr.openjdk.java.net/~kbarrett/8203028/open.01/ >> >> New webrevs with above changes: >> full: http://cr.openjdk.java.net/~kbarrett/8203028/open.02/ >> incr: http://cr.openjdk.java.net/~kbarrett/8203028/open.02.inc/ > Following up on a suggestion from Mark Reinhold in the discussion of JDK-8203327 > on the core-libs list, I’ve added the following comment to the Reference.queue field. > > diff -r 98982cddbac0 -r 2429129c4d48 src/java.base/share/classes/java/lang/ref/Reference.java > --- a/src/java.base/share/classes/java/lang/ref/Reference.java Mon May 14 18:01:36 2018 -0400 > +++ b/src/java.base/share/classes/java/lang/ref/Reference.java Sun May 20 11:06:48 2018 -0400 > @@ -131,6 +131,14 @@ > > private T referent; /* Treated specially by GC */ > > + /* The queue this reference gets enqueued to by GC notification or by > + * calling enqueue(). > + * > + * When registered: the queue with which this reference is registered. > + * enqueued: ReferenceQueue.ENQUEUE > + * dequeued: ReferenceQueue.NULL > + * unregistered: ReferenceQueue.NULL > + */ > volatile ReferenceQueue<? super T> queue; > > /* The link in a ReferenceQueue's list of Reference objects. >

2 3