September 2018 - core-libs-dev

RFR - JDK-8203703 String::transform (CSR Review)
by Jim Laskey 20 Sep '18

20 Sep '18

Please review the API for String::transform. The goal is to provide a String instance method to allow function application of custom transformations applied to an instance of String. csr: https://bugs.openjdk.java.net/browse/JDK-8203703 jbs: https://bugs.openjdk.java.net/browse/JDK-8203442 Cheers, — Jim

2 3

RFR: JDK-8210924 Remove PACKAGE_PATH
by Magnus Ihse Bursie 19 Sep '18

19 Sep '18

The variable PACKAGE_PATH crept into the build when the macosx port was integrated. It is not used, however, and should be removed. (This is a BSD construct, and the macosx port was based on the BSD port.) If/when the BSD port ever gets integrated upstream, we'll know better then how to restore PACKAGE_PATH on the proper places. Bug: https://bugs.openjdk.java.net/browse/JDK-8210924 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8210924-remove-PACKAGE_PATH/webrev.01 /Magnus

1 0

RFR - JDK-8210718 String::detab, String::entab (CSR Review)
by Jim Laskey 19 Sep '18

19 Sep '18

Please review the API for String::detab and String::entab. Used to expand tabs into spaces, and spaces back to tabs. csr: https://bugs.openjdk.java.net/browse/JDK-8210718 jbs: https://bugs.openjdk.java.net/browse/JDK-8210717 Cheers, — Jim

2 2

RFR JDK-8210899: (zipfs) ZipFileSystem.EntryOutputStreamCRC32 mistakenly set the crc32 value into size field
by Xueming Shen 19 Sep '18

19 Sep '18

Hi, Please help codereview the change for JDK-8210899. issue: https://bugs.openjdk.java.net/browse/JDK-8210899 webrev: http://cr.openjdk.java.net/~sherman/8210899/webrev Thanks, Sherman

2 3

[12] RFR: 8209880: tzdb.dat is not reproducibly built
by Naoto Sato 18 Sep '18

18 Sep '18

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8209880 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8209880/webrev.00/ The fix is to remove the use of HashSet/Map which is not guaranteed to preserve the same order on iteration. Naoto

5 4

RFR(JDK12/JAXP/java.xml) 8210874: Test for JDK-8209615
by Joe Wang 18 Sep '18

18 Sep '18

Hi Lance, I accidentally missed checking in the test for JDK-8209615. Here's the original webrev for JDK-8209615: http://cr.openjdk.java.net/~joehw/jdk12/8209615/webrev/ and here's the webrev for requesting checking in the test: http://cr.openjdk.java.net/~joehw/jdk12/8210874/webrev/ I kept the @bug id and name of the test as 8209615. Thanks, Joe

2 2

RFR - JDK-8202443 - String::unescape (CSR Review)
by Jim Laskey 18 Sep '18

18 Sep '18

Please review the API for String::unescape. Used to translate escape sequences in a string, typically in a raw string literal, into characters represented by those escapes. We decided to simplify the interface to the basics, i.e., translate all escape sequences. No reciprocating method since the complexity of variations outweigh any likely need. csr: https://bugs.openjdk.java.net/browse/JDK-8202443 jbs: https://bugs.openjdk.java.net/browse/JDK-8202442 Cheers, — Jim

1 0

8210496: Improve filtering for classes with security sensitive fields
by Alan Bateman 18 Sep '18

18 Sep '18

Core reflection has a filtering mechanism to hide a number of fields that are critical to security or the integrity of the runtime. It's a bit of a band aid but it helps to reduce hacking on fields such as java.lang.System.security and java.lang.Class.classLoder. I'd like to extend the filters to hide a few additional fields from integrity-sensitive (and non-serializable) classes in java.lang.reflect and java.lang.invoke. There are of course a number of nasty hacks around that might break due to this but these hacks would be broken anyway with simple rename or other innocent refactoring (we had some of this during JDK 11 when Mandy fixed JDK-8202113 for example). The webrev with the changes is here: https://bugs.openjdk.java.net/browse/JDK-8210496 Mandy has already reviewed the CSR [1]. -Alan [1] https://bugs.openjdk.java.net/browse/JDK-8210522

3 5

Sized Collector supplier
by Roman Leventov 18 Sep '18

18 Sep '18

Is there a reason why java.util.stream.Collector doesn't support sized supply of a mutable result container? It seems that it could be hugely beneficial when the size of the stream is known, e. g. for precise ArrayList and HashMap.

2 1

Thought on multiplicity of properties in Java
by Martin Desruisseaux 18 Sep '18

18 Sep '18

I’m deriving Java interfaces from the UML of ISO 19111 international standard, and a though come to my mind. This is not a request for changing anything in the Java language now, I’m just wondering if this is something worth to be considered for the future. This proposal would require javac to handle Optional<Foo> and maybe Collection<Foo> method return types in a special way, but would not require JVM change in my understanding. Sometime a property is optional in a parent class, but become mandatory in some subclasses. In UML, the [0…1] multiplicity in parent class become restricted to [1…1] multiplicity in subclasses. I wonder if javac could do a special case for catching this model as below. Allow to override: class Parent { Optional<Foo> getFoo(); } with: class Child extends Parent { @MaybeSomeAnnotationMakingIntentClear @Override Foo getFoo(); } Those two methods differ only by the return type, which I think is allowed at the JVM level. In the Child class, javac would generate the following synthetic method: @Override final Optional<Foo> getFoo() { return Optional.of(getFoo()); // Invoke the getFoo() method that return Foo. } Subclasses of Child can override only the method returning Foo, not Optional<Foo>. In UML parlance, the [0…1] multiplicity can be restricted to [1…1] but the converse is not allowed (this is the same reasoning than method return type covariance in Java, applied to multiplicity instead than type). Invocation of getFoo() on Parent class would invoke the methods returning Optional<Foo>, while invocation of getFoo() on Child class would invoke the method returning Foo. Whether the following should be a compiler error or not is an open question: Child a = ...; Optional<Foo> foo = a.getFoo(); Something similar could be done for method returning Collection<Foo> too, if we consider those methods as properties having a [0…∞] multiplicity which can be restricted to [0…1] or [1…1] multiplicity in subclasses. In summary, Java already has type covariance and I wonder if it could be extended to "multiplicity covariance" with javac handling Collection<Foo> as [0…∞], Optional<Foo> as [0…1] and Foo as [1…1]. I'm of course not asking for any action; just curious if it is worth to put on a list of possible future Java evolutions. Regards, Martin

3 4