March 2017 - core-libs-dev

JDK 9 RFR(s): 8150488: add note to Scanner.findAll() regarding possible infinite streams
by Stuart Marks 08 Apr '17

08 Apr '17

Hi all, Please review these non-normative textual additions to the Scanner.findAll() method docs. These methods were added earlier in JDK 9; there's a small pitfall if the regex can match zero characters. Thanks, s'marks # HG changeset patch # User smarks # Date 1490749958 25200 # Tue Mar 28 18:12:38 2017 -0700 # Node ID 6b43c4698752779793d58813f46d3687c17dde75 # Parent fb54b256d751ae3191e9cef42ff9f5630931f047 8150488: add note to Scanner.findAll() regarding possible infinite streams Reviewed-by: XXX diff -r fb54b256d751 -r 6b43c4698752 src/java.base/share/classes/java/util/Scanner.java --- a/src/java.base/share/classes/java/util/Scanner.java Mon Mar 27 15:12:01 2017 -0700 +++ b/src/java.base/share/classes/java/util/Scanner.java Tue Mar 28 18:12:38 2017 -0700 @@ -2808,6 +2808,10 @@ * } * }</pre> * + * <p>The pattern must always match at least one character. If the pattern + * can match zero characters, the result will be an infinite stream + * of empty matches. + * * @param pattern the pattern to be matched * @return a sequential stream of match results * @throws NullPointerException if pattern is null @@ -2829,6 +2833,11 @@ * scanner.findAll(Pattern.compile(patString)) * }</pre> * + * @apiNote + * The pattern must always match at least one character. If the pattern + * can match zero characters, the result will be an infinite stream + * of empty matches. + * * @param patString the pattern string * @return a sequential stream of match results * @throws NullPointerException if patString is null

3 12

[8u] RFR: 8177776: Create an equivalent test case for JDK9's SupplementalJapaneseEraTest
by Naoto Sato 06 Apr '17

06 Apr '17

Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8177776 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8177776/webrev.00/ This is for backporting fixes for JapaneseEra related issues (8054214, 8173423). The original fixes in JDK9 included a test case, SupplementalJapaneseEraTest which is intended for the system property testing. The above proposed fix intends to adapt that test case into JDK8, where calendars.properties file is used instead of the system property. The test is pretty much identical to JDK9's. The difference is to deal with the calendars.properties file and removed some non-applicable cases in JDK8. Naoto

3 5

Java 9 and IntSummaryStatistics et al.
by Chris Dennis 05 Apr '17

05 Apr '17

Hi All, I’m currently working on a project thats attempting to do a lot of heavy lifting work with Java Streams (implementing, extending, adapting, etc). One issue we ran in to is the inflexibility around unmarshalling the IntSummaryStatistics class (and it’s other primitive variations). I had originally decided to not push on this since it had already been filed as a enhancement request and dismissed (JDK-8043747) and since in Java 8 and earlier it wasn’t a huge problem for us as we could use reflection to force the initialization of one of these objects without much issue (modulo SecurityManager usage). In Java 9 this starts to get much more unpalatable. I’m left with having to open up parts of the java.base module in order to get to what I need (in classpath mode this looks particularly ugly since I have to open up to ALL-UNNAMED). What I’m trying to do here is get a roadmap in place for how to approach these kinds of problems in a Java ecosystem which is (presumably) moving towards a gradually more strict position on strong encapsulation. Right now code that treats a stream pipeline as anything more complex than a ‘literal’ pipeline of operations through which events are pushed is going to hit this problem - a simple example would be any kind of calculation being performed in advance of stream creation. Right now the lack of interface decoupling here means I have no choice but to ‘brute-force’ all these calculations. Thanks, Chris Dennis

5 12

JDK 9 RFR(xs): 8177653: clarify restrictions on Iterator.forEachRemaining
by Stuart Marks 31 Mar '17

31 Mar '17

Hi all, Please review this small change to the spec of Iterator.forEachRemaining. I claim this change is non-normative, since the text to be added "other mutator methods of Iterator subtypes" is already covered by existing text "modifies the collection in any way". However, this bug arose because the originator of this bug report was calling ListIterator.add() within forEachRemaining, and expecting specific behavior, so I felt some amplification was warranted. Thanks, s'marks # HG changeset patch # User smarks # Date 1490984679 25200 # Fri Mar 31 11:24:39 2017 -0700 # Node ID 7f316f93f2bd46a9a554c760034c1c25a18d3e05 # Parent a1d25a8fdc9855e59260345c32a5e7ad64051a4e 8177653: clarify restrictions on Iterator.forEachRemaining Reviewed-by: XXX diff -r a1d25a8fdc98 -r 7f316f93f2bd src/java.base/share/classes/java/util/Iterator.java --- a/src/java.base/share/classes/java/util/Iterator.java Thu Mar 30 11:26:31 2017 -0700 +++ b/src/java.base/share/classes/java/util/Iterator.java Fri Mar 31 11:24:39 2017 -0700 @@ -109,7 +109,8 @@ * Exceptions thrown by the action are relayed to the caller. * <p> * The behavior of an iterator is unspecified if the action modifies the - * collection in any way (even by calling the {@link #remove remove} method), + * collection in any way (even by calling the {@link #remove remove} method + * or other mutator methods of {@code Iterator} subtypes), * unless an overriding class has specified a concurrent modification policy. * <p> * Subsequent behavior of an iterator is unspecified if the action throws an

2 1

RFR: JDK-8177910, Update zlib copyright note in idk/src/java.base/share/legal/zlib.md
by Xueming Shen 31 Mar '17

31 Mar '17

Hi, Please help review the copyright update change for issue: https://bugs.openjdk.java.net/browse/JDK-8177910 webrev: http://cr.openjdk.java.net/~sherman/8177910/ Thanks! Sherman

3 2

Re: Bug in File.getLastModified()
by David Holmes 31 Mar '17

31 Mar '17

Hi Ricardo, This isn't a build issue. Redirecting to core-libs-dev. Please don't reply to build-dev. Thanks, David On 30/03/2017 12:40 AM, Ricardo Almeida wrote: > Hi, > > I could not raise a bug in https://bugs.openjdk.java.net/ so I hope it > is ok to say it here, hoping someone can take a look at it... > > File.getLastModified() always returns with second precision, losing > the miliseconds (i.e. a number ending in 000). I tried using > Files.getLastModifiedTime and it seems to work correctly as the output > of the following test app shows: > > Test f.lastModified [1490606336000]: false > Test Files.getLastModifiedTime [1490606336718]: true > > The code: > > package com.espatial.test; > > import java.io.File; > import java.io.IOException; > import java.nio.file.Files; > > public class FileTest { > private static final long LM = 1490606336718L; > > public static void main(String[] args) throws IOException { > File f = new File("test.txt"); > f.createNewFile(); > > f.setLastModified(LM); > > System.out.printf("Test f.lastModified [%s]: %b\n", > f.lastModified(), f.lastModified() == LM); > System.out.printf("Test Files.getLastModifiedTime [%s]: %b\n", > Files.getLastModifiedTime(f.toPath()).toMillis(), > (Files.getLastModifiedTime(f.toPath()).toMillis() == LM)); > > f.delete(); > } > } > > Thanks you, > Regards, > Ricardo Almeida >

5 7

[9] RFR: 8177835: System.LoggerFinder#getLogger or getLocalizedLogger does not throw NPE
by Daniel Fuchs 31 Mar '17

31 Mar '17

Hi, Please find below a trivial fix for a JCK conformance issue: https://bugs.openjdk.java.net/browse/JDK-8177835 8177835: System.LoggerFinder#getLogger or getLocalizedLogger does not throw NPE webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8177835/webrev.00 The issue is only apparent if you directly call System.LoggerFinder.getLoggerFinder().getLogger(null,module) when java.logging is not present. The regular System.getLogger methods and the java.logging implementation of LoggerFinder already do the null check. Because this is a conformance issue I will ask for approval to fix this in 9 best regards, -- daniel

3 4

JDK 9 RFR of JDK-8177638: com/sun/jarsigner, jdk/internal/loader (and more) are missed in TEST.group
by Amy Lu 31 Mar '17

31 Mar '17

jdk/internal/loader jdk/internal/util com/sun/jarsigner jdk/internal/agent Somehow these are missed in TEST.group. Please review this patch to update TEST.group Tested on all platforms, TestVersionedStream.java fails on Windows, put it in ProblemList.txt for now. bug: https://bugs.openjdk.java.net/browse/JDK-8177638 webrev: http://cr.openjdk.java.net/~amlu/8177638/webrev.00/ Thanks, Amy --- old/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 +++ new/test/ProblemList.txt 2017-03-27 10:57:36.000000000 +0800 @@ -286,6 +286,7 @@ java/util/BitSet/BitSetStreamTest.java 8079538 generic-all +jdk/internal/util/jar/TestVersionedStream.java 8177640 windows-all ############################################################################ --- old/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 +++ new/test/TEST.groups 2017-03-27 10:57:38.000000000 +0800 @@ -70,6 +70,7 @@ sun/reflect \ jdk/internal/reflect \ jdk/lambda \ + jdk/internal/loader \ jdk/internal/misc \ jdk/internal/ref \ jdk/internal/jimage \ @@ -87,6 +88,7 @@ jdk_util_other = \ java/util \ sun/util \ + jdk/internal/util \ -:jdk_collections \ -:jdk_concurrent \ -:jdk_stream @@ -189,6 +191,7 @@ lib/security jdk_security4 = \ + com/sun/jarsigner \ com/sun/security/jgss \ javax/security/auth/kerberos \ sun/security/krb5 \ @@ -207,7 +210,8 @@ jdk_management = \ java/lang/management \ com/sun/management \ - sun/management + sun/management \ + jdk/internal/agent jdk_instrument = \ java/lang/instrument

3 5

Re: [9] RFR(L) 8158168: SIGSEGV: CollectedHeap::fill_with_objects(HeapWord*, unsigned long, bool)+0xa8
by David Holmes 31 Mar '17

31 Mar '17

Hi Dean, I fixed the cc from core-libs-dev-request(a)openjdk.java.net to core-libs-dev(a)openjdk.java.net On 16/03/2017 7:28 AM, dean.long(a)oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8158168 > > http://cr.openjdk.java.net/~dlong/8158168/ Not a full review sorry, just a couple of comments. src/share/vm/classfile/javaClasses.hpp Given the the only call to java_lang_String::set_debug_intrinsics is within an ifdef, shouldn't the declaration and definition of the method also be guarded the same way? > This crash is caused by missing array bounds checks on compact string > intrinsics. It shows up when unsynchronized access to a StringBuilder > object causes inconsistent field values. > > To convince myself that all the necessary bounds checks are being done, > I put callers into two groups, trusted and untrusted. Untrusted callers > are all directed through StringUTF16 methods, so that bounds checks are > done in one place and can be tested easily. Trusted callers bypass the > bounds checks, so they must do their own checking. The changes to the JDK core classes are quite extensive. This will need rigorous functional and performance testing and it is very late in the release cycle to make these kinds of changes. But I'll leave that to the core-libs folk to comment on. David ----- > As a safety net, I added asserts around the intrinsic calls, and a > try/catch that so any out of bounds exception turns into an assert error > as well. Finally, I restored some C2 debug code that was previously > removed, and I use it to do bounds checking in debug builds. In a > product build C2 will remove all of these. > > See the bug report for tests run. > > There are some unavoidable performance regressions on micro benchmarks, > because now we are doing bounds checks that we weren't before. > > dl >

5 23

JDK 9 RFR(s): 8155052: add notes and links to j.u.Observer/Observable deprecation comments
by Stuart Marks 30 Mar '17

30 Mar '17

Hi all, Please review this small, non-normative textual change to j.u.Observable. This class, and its companion Observer interface, were deprecated earlier in JDK 9. Doug Lea suggested adding a link to j.u.c.Flow in case people confused these APIs with reactive streams. (AFAICS reactive streams doesn't use the terms observer/observable, but RxJava does.) Thanks, s'marks # HG changeset patch # User smarks # Date 1490835538 25200 # Wed Mar 29 17:58:58 2017 -0700 # Node ID 7b9ea7fa93c00698325d38cfc108cd6e79bffe10 # Parent 6b43c4698752779793d58813f46d3687c17dde75 8155052: add notes and links to j.u.Observer/Observable deprecation comments Reviewed-by: XXX diff -r 6b43c4698752 -r 7b9ea7fa93c0 src/java.base/share/classes/java/util/Observable.java --- a/src/java.base/share/classes/java/util/Observable.java Tue Mar 28 18:12:38 2017 -0700 +++ b/src/java.base/share/classes/java/util/Observable.java Wed Mar 29 17:58:58 2017 -0700 @@ -69,6 +69,8 @@ * {@link java.beans} package. For reliable and ordered * messaging among threads, consider using one of the concurrent data * structures in the {@link java.util.concurrent} package. + * For reactive streams style programming, see the + * {@link java.util.concurrent.Flow} API. */ @Deprecated(since="9") public class Observable {

2 1