May 2018 - core-libs-dev

8202076: test/jdk/java/io/File/WinSpecialFiles.java on windows with VS2017
by Brian Burkhalter 22 May '18

22 May '18

https://bugs.openjdk.java.net/browse/JDK-8202076 http://cr.openjdk.java.net/~bpb/8202076/webrev.00/ If all else fails, obtain the file length via the FindFirstFileW function [1]. Thanks, Brian [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa364418(v=vs.85).…

3 17

RFR: 8203233: (tz) Upgrade time-zone data to tzdata2018e
by Ramanand Patil 22 May '18

22 May '18

Hi all, Please review the latest TZDATA integration (tzdata2018e) to JDK. Bug: https://bugs.openjdk.java.net/browse/JDK-8203233 Webrev: http://cr.openjdk.java.net/~rpatil/8203233/webrev.00/ All the TimeZone related tests are passed after integration. Note: Using the rearguard version of the tzdata, to avoid the negative save value problem. https://mm.icann.org/pipermail/tz/2018-February/026203.html Regards, Ramanand.

3 2

RFR: JDK-8200380 String::lines
by Jim Laskey 22 May '18

22 May '18

String::lines instance method that returns a Stream<String> with elements composed of substrings from the original string delimited by any recognized new line character sequence. webrev: http://cr.openjdk.java.net/~jlaskey/8200380/webrev/index.html <http://cr.openjdk.java.net/~jlaskey/8200380/webrev/index.html> bug: https://bugs.openjdk.java.net/browse/JDK-8200380 <https://bugs.openjdk.java.net/browse/JDK-8200380> csr: https://bugs.openjdk.java.net/browse/JDK-8200425 <https://bugs.openjdk.java.net/browse/JDK-8200425>

5 11

Bug: Typo in ICUBinary.java
by Adam Farley8 22 May '18

22 May '18

Hi All, There's a typo here on line 258, where is says "Magin number" but means "Magic number". http://hg.openjdk.java.net/jdk/jdk/file/ec881a19d294/src/java.base/share/cl… Can a committer review and correct the typo? Thanks. Best Regards Adam Farley Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

4 5

RFR JDK-8196987: Resolve disabled warnings for libzip
by Xueming Shen 22 May '18

22 May '18

Hi Please help review the change for JDK-8196987. issue: https://bugs.openjdk.java.net/browse/JDK-8196987 webrev: http://cr.openjdk.java.net/~sherman/8196987/webrev It appears the change for JDK-6341887 in Deflater.c#169 "accidentally" fixed the offending "implicit-fallthrough" warning/error [1] [1] http://cr.openjdk.java.net/~sherman/6341887.David.Lloyd/webrev/src/java.bas… So the proposed change is to simply restore/enable the warning_as_error. Verified with mach5 job. Thanks, Sherman

2 1

RFR (S): 8203500: Fix broken links to Specification in "specs" directory
by Iris Clark 21 May '18

21 May '18

Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris

3 4

RE: RFR (S): 8203500: Fix broken links to Specification in "specs" directory
by Iris Clark 21 May '18

21 May '18

Hi, Jon. Thanks for the speedy review! iris From: Jonathan Gibbons Sent: Monday, May 21, 2018 4:00 PM To: compiler-dev(a)openjdk.java.net Subject: Re: RFR (S): 8203500: Fix broken links to Specification in "specs" directory Looks good to me. -- Jon On 5/21/18 3:54 PM, Iris Clark wrote: Hi. Please review this small change to fix a few broken links to Specification in the "specs" directory from the JavaDoc API. The incorrect references either not include "{@docRoot}" or include the non-existent "{@docRootParent}". They should all begin with "HYPERLINK "mailto:%7b@docRoot%7d/../specs/"{@docRoot}/../specs/". Bug: 8203500 Fix broken links to Specification in "spec" directory https://bugs.openjdk.java.net/browse/JDK-8203500 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eiris/8203500/webrev/"http://cr.openjdk.java.net/~iris/8203500/webrev/ Thanks, Iris

1 0

RFR 8203368: ObjectInputStream filterCheck method throws NullPointerException
by Roger Riggs 21 May '18

21 May '18

Please review a fix for the serial filter mechanism to prevent a NPE in the case where ObjectInputStream has been subclassed and the input stream is not available. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-ois-override-8203368/ Thanks, Roger

2 4

RFC: Experiment in accessing/managing persistent memory from Java
by Andrew Dinn 21 May '18

21 May '18

I have been helping one of my Red Hat colleagues, Jonathan Halliday, to investigate provision of a Java equivalent to Intel's libpmem suite of C libraries [1]. This approach avoids the significant cost of using the Intel libraries from Java via JNI (or, worse, as a virtual driver for a persistent memory device). Jonathan has modified the JVM/JDK to allow a MappedByteBuffer to be mapped over persistent memory, providing equivalent function to libpmem itself. On top of this he implemented a Java journaled log class providing equivalent functionality to one of the Intel client libs, libpmemlog, built over libpmem. The modified MappedByteBuffer can be configured to use either i) a registered native method or ii) a JIT intrinsic to perform the critical task of cache line writeback i.e. the persistence step (the intrinsic is my contribution). Jonathan's tests compare use of JNI, registered native and intrinsic with an equivalent C program to write a large swathe of records to a journaled log file stored in persistent memory. Performance is worse than C when relying on JNI and significantly better with JVM/JDK support. Indeed, as one might reasonably expect, use of the JIT intrinsic almost completely eliminates writeback costs. The journaled log code, jdk dev tree patch, build instructions, test code plus C equivalent and test results are all available from Jonathan's git repo [2]. For those who do not want to look at the actual code, the README file [3] provides background to use of persistent memory, an overview of the design, and summary details of the test process and results. [1] https://pmem.io/pmdk/ [2] https://github.com/jhalliday/pmem [3] http://github.com://jhalliday/pmem/README.md n.b. Jonathan has experimented with using this same prototype to replace the journaled log used in the Red Hat Narayana transaction manager. It provides a significant improvement on the current disk file based log, both for throughput and latency (the code is not yet available as getting it to work involved some horrible hacking of the build to migrate up to jdk11). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander

1 0

RFR: Small cleanups in java.lang.ref
by Martin Buchholz 20 May '18

20 May '18

I've been confused by NULL vs null for years. 8203327: Small cleanups in java.lang.ref http://cr.openjdk.java.net/~martin/webrevs/jdk/Reference-cleanup/ https://bugs.openjdk.java.net/browse/JDK-8203327

7 11