April 2020 - core-libs-dev

Re: RFR: JDK-8244018: No error message for non-existent icon path
by Andy Herrick 30 Apr '20

30 Apr '20

revised webrev at [3] - copyrights were updated by previous issue. /Andy [3] http://cr.openjdk.java.net/~herrick/8244018/webrev.02/ On 4/29/2020 4:56 PM, Alexander Matveev wrote: Hi Andy, http://cr.openjdk.java.net/~herrick/8244018/webrev.01/src/jdk.incubator.jpa… http://cr.openjdk.java.net/~herrick/8244018/webrev.01/src/jdk.incubator.jpa… Typo in year: 20120 -> 2020 Otherwise looks fine. Thanks, Alexander On 4/29/20 7:31 AM, Andy Herrick wrote: > Please review fix at [1] for issue [2] > > The change just adds error when specified icon is not found, and a > test for that. > > /Andy > > [1] - http://cr.openjdk.java.net/~herrick/8244018/webrev.01/ > > [2] - https://bugs.openjdk.java.net/browse/JDK-8244018 > >

2 1

RFR: JDK-8219536: Add Option for user defined jlink options
by Andy Herrick 30 Apr '20

30 Apr '20

Please review webrev at [1] to address issue [2]. This is the new feature to add the jpackage option --jlink-options as specified in CSR at [3] /Andy [1] http://cr.openjdk.java.net/~herrick/8219536/webrev.03 [2] https://bugs.openjdk.java.net/browse/JDK-8219536 [3] https://bugs.openjdk.java.net/browse/JDK-8243272

3 10

RFR: 7147994 Hashtable rehash‎(‎) javadoc describes implementation details
by Jayashree Sk1 30 Apr '20

30 Apr '20

Hi All, Please find the below changes for the issues https://bugs.openjdk.java.net/browse/JDK-7147994 It is a description change, which was already approved by the reviewer. Thanks! diff -r 59b5bd9a7168 src/java.base/share/classes/java/util/Hashtable.java --- a/src/java.base/share/classes/java/util/Hashtable.java Mon Mar 16 02:16:49 2020 -0400 +++ b/src/java.base/share/classes/java/util/Hashtable.java Mon Mar 30 15:45:43 2020 +0530 @@ -399,9 +399,9 @@ /** * Increases the capacity of and internally reorganizes this * hashtable, in order to accommodate and access its entries more - * efficiently. This method is called automatically when the - * number of keys in the hashtable exceeds this hashtable's capacity - * and load factor. + * efficiently. This method is called to increase the capacity of and + * internally reorganize this hashtable in order to more efficiently + * accommodate and access its entries. */ @SuppressWarnings("unchecked") protected void rehash() {

2 3

REMINDER of RFR CSR JDK-8202555: Double.toString(double) sometimes produces incorrect results
by Raffaello Giulietti 30 Apr '20

30 Apr '20

Hi, after more than one year after first publication, the patches [1] and the CSR [2] are still awaiting a review... Here's a breakdown of estimated times: * Reading the CSR: 15-30 min. This can be done and approved independently. * Checking that the implementation matches the documentation [3]: 1-2 hours. * Reading the detailed documentation: 0.5-1.0 days. * Overall review of the code, including the extensive tests: 0.5-1.0 days. Greetings Raffaello ---- [1] https://cr.openjdk.java.net/~bpb/4511638/webrev.04/ [2] https://bugs.openjdk.java.net/browse/JDK-8202555 [3] https://drive.google.com/open?id=1luHhyQF9zKlM8yJ1nebU0OgVYhfC6CBN

2 3

RFR[8183266] - [TESTBUG]Add test to cover XPathEvaluationResult.XPathResultType.getQNameType method
by Fernando Guallini 30 Apr '20

30 Apr '20

Hi all, Please, review the following change: webrev: http://cr.openjdk.java.net/~joehw/jdk15/8183266/webrev/ bug: https://bugs.openjdk.java.net/browse/JDK-8183266 Change details: - Added test coverage for XPathEvaluationResult.XPathResultType.getQNameType method - Added type check for the getQNameType flow restricting the Number class subtypes to satisfy the spec (Integer, Double and Long) - Updated equalsClassType method to be null safe. Kind regards, Fernando

2 2

RFR(XS): 8244094: Fix Amazon copyright in various test files
by Volker Simonis 30 Apr '20

30 Apr '20

Hi, can I please get a review for the following trivial change which fixes the Amazon copyright in several test files: http://cr.openjdk.java.net/~simonis/webrevs/2020/8244094/ https://bugs.openjdk.java.net/browse/JDK-8244094 Notice that the new version intentionally contains no copyright year any more. Thank you and best regards, Volker Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879

2 1

Java 11 vs 14 MethodHandle behavior change
by Simone Bordet 29 Apr '20

29 Apr '20

Hi, in Jetty 10, we use method handles in the WebSocket implementation. We need to scan WebSocket EndPoint application classes (MyEndPoint) for annotated methods whose signature may vary and may take application classes, for example `@OnMessage void onMessage(Session s, MyString m)` where @OnMessage and Session are JSR 356 classes and MyEndPoint and MyString are application classes. It may be possible that the same web application is deployed twice, perhaps with different configurations. Therefore we have: * class "Impl" is the Jetty implementation class that creates MethodHandle.Lookup, loaded by serverClassLoader and in a named JPMS module * class MyEndPoint and MyString are in webapp1's WEB-INF/classes, loaded by webClassLoader1 in an unnamed JPMS module * class MyEndPoint and MyString are also in webapp2's WEB-INF/classes, loaded by webClassLoader2 in another unnamed JPMS module Class Impl does this: MethodHandles.publicLookup().in(endPointClass).findVirtual(...), where "endPointClass" is class MyEndPoint loaded by the web class loader (either webClassLoader1 or webClassLoader2). We must call .in() to separate the 2 web applications (failing to call .in() results in linkage errors). Calling publicLookup().in() works in Java 11-13. In Java 14, it does not work anymore. The reason seems to stem from the fixes for https://bugs.openjdk.java.net/browse/JDK-8173978. In particular, in Java 14 publicLookup() returns a Lookup with mode=UNCONDITIONAL (but not PUBLIC? Is this intended?) and Lookup.lookupClassOrNull() returns Object.class rather than the class passed to .in() - like it was doing in Java 11. We have debugged and manually changed the return value of lookupClassOrNull() from Object.class to the endPoint class, and it works again. We have written a simple reproducer and been able to workaround the issue (we need to test it better in Jetty to confirm that the workaround for the simple reproducer also works in Jetty) by changing the Lookup from: publicLookup().in() to: lookup().dropLookupMode(<all apart PUBLIC>).in() and it also works. Note that we really want to have a Lookup object with the minimum set of "powers" to lookup public methods in public classes of the web application - otherwise the JPMS configuration becomes more complicated. We do have a simple reproducer that works in Java 11 and fails in 14. I am a JDK author so I can open an issue about this. Thanks! -- Simone Bordet --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz

2 3

LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet
by Tagir Valeev 29 Apr '20

29 Apr '20

Hello! To me, it was always a pity that the internal structure of LinkedHashMap allows doing more things easily, yet this functionality is not exposed to the external clients, so if somebody really needs such things they will need to waste memory/CPU to emulate them. The functionality I'm speaking about includes: - getting the last (i.e. most recently added/accessed) entry - getting the descending iterator going from newest to oldest entries - getting the iterator that starts at given existing entry It's easy to do such things with TreeMap and other NavigableMap implementations. However, LinkedHashMap provides no additional visible methods in addition to the Map interface (well, except removeEldestEntry()). The same considerations apply to LinkedHashSet. So we can provide new interfaces j.u.OrderedMap and OrderedSet that provide the additional functionality and make LinkedHashMap/LinkedHashSet implement them. Aside from new functionality, the interfaces will carry additional semantics: their iteration order is always predictable and their spliterators return DISTINCT|ORDERED characteristics, so some clients may require OrderedMap/Set just to assert that they rely on predictable iteration order. We can even make existing NavigableMap/Set extend OrderedMap/Set because NavigableMap/Set are ordered. Some of NavigableMap/Set methods will naturally fit the OrderedMap/Set interfaces. I think I can devote my spare time to write the spec, implementation, and tests for this enhancement, participate in the API design discussions and do any other job necessary to make this improvement happen. However, I'd like to know in advance whether such kind of change would be met positively. What do you think? Is it possible to do this or this improvement contradicts the OpenJDK goals and will likely be rejected? Also, do I need to write a JEP for this? It's probably too early to discuss the exact API, but for more specificity of my proposal, here's the quick draft: package java.util; public interface OrderedSet<E> extends Set<E> { // First or NSEE if empty E first() throws NoSuchElementException; // Last or NSEE if empty E last() throws NoSuchElementException; // Retrieve&remove first or null if empty E pollFirst(); // Retrieve&remove last or null if empty E pollLast(); // Iterator starting from element, or NSEE if not found Iterator<E> iteratorFrom(E fromElement) throws NoSuchElementException; // Descending Iterator<E> descendingIterator(); // Descending iterator starting from element, or NSEE if not found Iterator<E> descendingIteratorFrom(E fromElement) throws NoSuchElementException; // TBD: descendingSet() } All the methods except iteratorFrom and descendingIteratorFrom are already present in NavigableSet, so the spec will be mostly copied from there. For iteratorFrom and descendingIteratorFrom it's easy to provide a default implementation in NavigableSet. All methods can be implemented easily in LinkedHashSet and LinkedHashMap::keySet package java.util; public interface OrderedMap<K, V> extends Map<K, V> { // First entry or null if empty Map.Entry<K,V> firstEntry(); // Last entry or null if empty Map.Entry<K,V> lastEntry(); // Retrieve&remove first entry or null if empty Map.Entry<K,V> pollFirstEntry(); // Retrieve&remove last entry or null if empty Map.Entry<K,V> pollLastEntry(); // First key or NSEE if empty K firstKey(); // Last key or NSEE if empty K lastKey(); // Ordered keySet() OrderedSet<K> orderedKeySet(); // TBD: OrderedSet<K> descendingKeySet(); // TBD: OrderedSet<Entry<K,V>> orderedEntrySet(); } All the methods except orderedKeySet() are already present in NavigableMap, and the orderedKeySet() is just an alias for navigableKeySet(). Also, all of them can be implemented easily in LinkedHashMap. Any feedback is welcome. Thank you in advance, Tagir Valeev.

4 6

RFR [15] 8243541: (tz) Upgrade time-zone data to tzdata2020a
by Kiran Ravikumar 29 Apr '20

29 Apr '20

Hello All, Please review the patch for tzdata2020a integration into jdk. Release details can be found here: http://mm.icann.org/pipermail/tz-announce/2020-April/000058.html Webrev: http://cr.openjdk.java.net/~kravikumar/8243541/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8243541 The patch has passed all the related testing including JCK and uses vanguard format tzdata. Thanks, Kiran

4 6

RFR(T) : 8244052 : remove copying of s.h.WB$WhiteBoxPermission in test/jdk
by Igor Ignatyev 29 Apr '20

29 Apr '20

http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ > 34 lines changed: 0 ins; 11 del; 23 mod; Hi all, could you please review this trivial patch? from JBS: > JDK-8199290 made it unnecessary to explicitly pass sun.hotspot.WhiteBox$WhiteBoxPermission as an argument to ClassFileInstaller b/c the former now copies it every time it copies sun.hotspot.WhiteBox. besides removing WhiteBoxPermission from the list of ClassFileInstaller's arguments, the patch also makes sure ClassFileInstaller is run in a driver mode in all the touched tests. testing: the changed tests webrev: http://cr.openjdk.java.net/~iignatyev//8244052/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8244052 Thanks, -- Igor

3 3