December 2017 - core-libs-dev

Incorrect validation of DST in java.util.SimpleTimeZone
by Venkateswara R Chintala 11 Dec '17

11 Dec '17

Hi, In a multi-threaded environment, when java.util.SimpleTimeZone object is used to create a default timezone, there can be a race condition between the methods java.util.Timezone.getDefault() and java.util.Timezone.getDefaultRef() which can result in inconsistency of cache that is used to validate a particular time/date in DST. When a thread is cloning a default timezone object (SimpleTimeZone) and at the same time if a different thread modifies the time/year values, then the cache values (cacheYear, cacheStart, cacheEnd) can become inconsistent which leads to incorrect DST determination. We considered two approaches to fix the issue. 1)Synchronize access to cloning default timezone object when cache is being modified. 2)Invalidate the cache while returning the clone. We preferred the second option as synchronization is more expensive. We have attached the patch and jtreg testcase. Please review. -- Regards -Venkat

6 25

[10] RFR 8171826 Comparator.reverseOrder(c) mishandles singleton comparators
by Paul Sandoz 11 Dec '17

11 Dec '17

Hi, Please review this simple fix. http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8171826-comparator-equality/w… The method Comparator<T> reverseOrder(Comparator<T> cmp) is updated to be a little smarter returning constant comparators for natural and reverse-natural. Paul.

2 1

Re: Odd result with canonical paths with intermixed usage of java.io.File and java.nio.file.Files APIs
by Jaikiran Pai 11 Dec '17

11 Dec '17

Moved this thread from discussions mailing list[1] to here. Comments inline. On 11/12/17 7:55 PM, Alan Bateman wrote: > On 11/12/2017 14:06, Jaikiran Pai wrote: >> : >> >> So a few related questions that I have are: >> >> 1. Is this inconsistency an expected behaviour or is this a bug? >> 2. If this is an expected behaviour, then would it be a better >> idea (as an application developer) to use Path.toRealPath[2] instead >> of using the File.getCanonicalPath()? Are these 2 APIs semantically >> equivalent? The File.getCanonicalPath() talks about the canonical >> path being "unique" paths but the Path.toRealPath has no such mentions. >> > The correctness issues with the canonicalization cache is a long > standing issue [1]. You can workaround it by running with > -Dsun.io.useCanonCaches=false as I think you have found. The goal is > to eventually disable and remove it. The first steps to get there > happened in JDK 9 when FilePermission was changed to not canonicalize > by default (FilePermission was the original motivation for this cache). > > If you have follow-up questions then please bring the thread to > core-libs-dev. > > -Alan > > [1] https://bugs.openjdk.java.net/browse/JDK-7066948 Thanks Alan. Given that the cache itself is being planned to be eventually removed, that answers the main part of my question and I can workaround this issue in a couple of ways (disabling the cache using that system property is one way) in the application, till that time. The only remaining part that I'm curious about is this: > ... would it be a better idea (as an application developer) to use Path.toRealPath[2] instead of using the File.getCanonicalPath()? Are these 2 APIs semantically equivalent? The File.getCanonicalPath() talks about the canonical path being "unique" paths but the Path.toRealPath has no such mentions. [1] http://mail.openjdk.java.net/pipermail/discuss/2017-December/004655.html -Jaikiran

2 2

RFR(s): 8177681: Remove methods Runtime.getLocalized{Input,Output}Stream
by Stuart Marks 09 Dec '17

09 Dec '17

Hi all, Please review the removal of these methods, which were part of an obsolete internationalization mechanism. They were deprecated in JDK 1.1 and deprecated for removal in JDK 9. As far as I can see, there is no usage of these methods anywhere. Bug link: https://bugs.openjdk.java.net/browse/JDK-8177681 Diffs below. s'marks diff -r 6ee80cd217e0 -r 3443fda73ab6 src/java.base/share/classes/java/lang/Runtime.java --- a/src/java.base/share/classes/java/lang/Runtime.java Mon Dec 04 11:50:04 2017 -0800 +++ b/src/java.base/share/classes/java/lang/Runtime.java Wed Dec 06 13:55:35 2017 -0800 @@ -877,62 +877,6 @@ } /** - * Creates a localized version of an input stream. This method takes - * an {@code InputStream} and returns an {@code InputStream} - * equivalent to the argument in all respects except that it is - * localized: as characters in the local character set are read from - * the stream, they are automatically converted from the local - * character set to Unicode. - * <p> - * If the argument is already a localized stream, it may be returned - * as the result. - * - * @param in InputStream to localize - * @return a localized input stream - * @see java.io.InputStream - * @see java.io.BufferedReader#BufferedReader(java.io.Reader) - * @see java.io.InputStreamReader#InputStreamReader(java.io.InputStream) - * @deprecated As of JDK 1.1, the preferred way to translate a byte - * stream in the local encoding into a character stream in Unicode is via - * the {@code InputStreamReader} and {@code BufferedReader} - * classes. - * This method is subject to removal in a future version of Java SE. - */ - @Deprecated(since="1.1", forRemoval=true) - public InputStream getLocalizedInputStream(InputStream in) { - return in; - } - - /** - * Creates a localized version of an output stream. This method - * takes an {@code OutputStream} and returns an - * {@code OutputStream} equivalent to the argument in all respects - * except that it is localized: as Unicode characters are written to - * the stream, they are automatically converted to the local - * character set. - * <p> - * If the argument is already a localized stream, it may be returned - * as the result. - * - * @deprecated As of JDK 1.1, the preferred way to translate a - * Unicode character stream into a byte stream in the local encoding is via - * the {@code OutputStreamWriter}, {@code BufferedWriter}, and - * {@code PrintWriter} classes. - * This method is subject to removal in a future version of Java SE. - * - * @param out OutputStream to localize - * @return a localized output stream - * @see java.io.OutputStream - * @see java.io.BufferedWriter#BufferedWriter(java.io.Writer) - * @see java.io.OutputStreamWriter#OutputStreamWriter(java.io.OutputStream) - * @see java.io.PrintWriter#PrintWriter(java.io.OutputStream) - */ - @Deprecated(since="1.1", forRemoval=true) - public OutputStream getLocalizedOutputStream(OutputStream out) { - return out; - } - - /** * Returns the version of the Java Runtime Environment as a {@link Version}. * * @return the {@link Version} of the Java Runtime Environment

5 4

Add EnumMap.keyType() and EnumSet.elementType()
by Andrej Golovnin 09 Dec '17

09 Dec '17

Hi all, it would be nice if we would have access to the class of the enum type used to create an EnumMap or an EnumSet. This is usefull when you write a custom serialization library and would like to serialize/deserialize an empty EnumMap or an empty EnumSet. For the empty EnumSet there is a workaround to get the enum class: EnumSet<MyEnum> empty = EnumSet.noneOf(MyEnum.class); EnumSet<MyEnum> tmp = EnumSet.complementOf(empty); Class<?> elementType = tmp.iterator().next().getClass(); But this only works when the enum class has at least one enum. For EnumMap there is no such workaround at all and we have to use the Reflection API. And you know the warnings since Java 9 :-) : WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by c.r.r.k.EnumMapSerializer to field java.util.EnumMap.keyType WARNING: Please consider reporting this to the maintainers of c.r.r.k.EnumMapSerializer WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release So to avoid this warning and to avoid that our application stops to work with a future release of Java I would like to propose to add the following two methods: EnumMap: /** * Returns the {@code Class} object of the key type for this enum map. * * @return the {@code Class} object of the key type for this enum map. * * @since 10 */ public Class<K> keyType() EnumSet: /** * Returns the {@code Class} object of all the elements of this set. * * @return the {@code Class} object of all the elements of this set. * * @since 10 */ public Class<E> elementType() The suggested change is attached as diff. Best reagrds, Andrej Golovnin

3 3

RFR JDK-8187485: Update Zip implementation to use Cleaner, not finalizers
by Xueming Shen 09 Dec '17

09 Dec '17

Hi Please review the revision to the change for JDK-8187485: Update Zip implementation to use Cleaner, not finalizers For compatibility with previous jdk releases, in this proposed revision the corresponding close()/end() methods will be called when the ZipFile/Inflater/Deflater object has become unreachable, if the ZipFile/Inflater/Deflater has been subclassed and its close()/end() method has been overridden. In this case, the finalization mechanism is used to clean up the underlying resources. If the ZipFile/Inflater/Deflater has not been subclassed OR the corresponding close()/end() method has not been overridden, then the Cleaner mechanism is used to do the cleanup. issue: https://bugs.openjdk.java.net/browse/JDK-8185582 webrev: http://cr.openjdk.java.net/~sherman/8185582/webrev csr: https://bugs.openjdk.java.net/browse/JDK-8187485 Thanks, Sherman

3 3

Re: RFR 4358774: Add null InputStream and OutputStream
by Brian Burkhalter 09 Dec '17

09 Dec '17

Hi Brent, On Dec 8, 2017, at 4:50 PM, Brent Christian <brent.christian(a)oracle.com> wrote: > I just noticed a couple small things in the test: > > test/jdk/java/io/InputStream/NullInputStream.java > > […] > > Line 113 should read "... != 0", yes? > > […] > > On 132, it's "skip() != 0". You are correct on both accounts. I shuffled that test completely around today converting it to TestNG and obviously made some typos. Webrev updated in place http://cr.openjdk.java.net/~bpb/4358774/webrev.03/. Thanks, Brian

1 0

RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc
by Martin Buchholz 08 Dec '17

08 Dec '17

1. JDK-8192935 <https://bugs.openjdk.java.net/browse/JDK-8192935> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/EnumSet-SerializationP…

3 11

RFR 4358774: Add null InputStream and OutputStream
by Brian Burkhalter 08 Dec '17

08 Dec '17

https://bugs.openjdk.java.net/browse/JDK-4358774 http://cr.openjdk.java.net/~bpb/4358774/webrev.00/ Add nullStream() method to each of InputStream and OutputStream. Thanks, Brian

9 19

RFR 8193271 : ProblemList tools/launcher/TestXcheckJNIWarnings.java
by Brent Christian 08 Dec '17

08 Dec '17

Hi, Please review my change to add the intermittently-failing tools/launcher/TestXcheckJNIWarnings.java to the problem list. diff -r a1f88c937a77 test/jdk/ProblemList.txt --- a/test/jdk/ProblemList.txt Tue Nov 28 10:15:47 2017 -0800 +++ b/test/jdk/ProblemList.txt Fri Dec 08 11:42:55 2017 -0800 @@ -261,6 +261,7 @@ tools/pack200/CommandLineTests.java 8059906 generic-all tools/launcher/FXLauncherTest.java 8068049 linux-all,macosx-all +tools/launcher/TestXcheckJNIWarnings.java 8190984 solaris-all tools/jimage/JImageExtractTest.java 8170120 generic-all Thanks! -Brent

2 2