November 2017 - core-libs-dev

Is Collections.sort(List) still stable (java 8, 9..)?
by Piotr Findeisen 16 Nov '17

16 Nov '17

Hi, I just realised the Collections.sort(List) method ceased to be stable as of Java 8 (sort of). Although the method's documentation still promises stable sort, the implementation delegates to List.sort(Comparator) and that interface method bears no constraint that an implementation must sort stable. Is "stable" missing from List.sort's documentation? Or, instead, should it be now no longer promised by Collections.sort? (oh, no!) Or, what am i missing? Best regards, Piotr

2 3

JDK-8190919 :StaX buffers do not really close underlying buffers
by Srividya Shamaiah 16 Nov '17

16 Nov '17

Hello, Am not sure to which mailing-list, I can send issues related to xml-jaxp. I found couple of xml-jaxp issues discussed in this mailing-list. Hence, am sending to this group. Please let me know the correct mailing-list if this is not the right one. I had a brief analysis on the subject issue and identified that the StaX buffers were not closed as the close method implemented for XMLStreamWriter in XMLStreamWriterImpl.java does not call the close on the underlying writer and instead calls only flush() on the writer. Interestingly the close call was in fact coded but commented out. We looked into the history of XMLStreamWriterImpl.java and found that the same code exists from Java 6 GA or even before. Hence, we could not find the bug which really introduced/commented out the close call. I tested with close uncommented and it resolve the issue. I did not run the jtreg and other tests as I could see that the bug is already assigned to Joe Wang. @Joe, please let me know whether you will continue with the analysis or you want me to do other tests and contribute the patch. With Thanks and Regards, Srividya S

3 2

JDK-8067661: transferTo proposal for Appendable
by Patrick Reinhart 15 Nov '17

15 Nov '17

Hi Chris & Pavel, Based on the transferTo Method on the InputStream I would propose to introduce a default method on the Readable interface. In that way the method can be used for all existing implementations of Readable and still be implemented in a special way by a individual implementer. /** * Reads all characters from this readable and writes the characters to * the given appendable in the order that they are read. On return, this * readable will be at end its data. * <p> * This method may block indefinitely reading from the readable, or * writing to the appendable. The behavior for the case where the readable * and/or appendable is <i>asynchronously closed</i>, or the thread * interrupted during the transfer, is highly readable and appendable * specific, and therefore not specified. * <p> * If an I/O error occurs reading from the readable or writing to the * appendable, then it may do so after some characters have been read or * written. Consequently the readable may not be at end of its data and * one, or both participants may be in an inconsistent state. It is strongly * recommended that both readable and appendable be promptly closed * if needed and an I/O error occurs. * * @param out the appendable, non-null * @return the number of characters transferred * @throws IOException if an I/O error occurs when reading or writing * @throws NullPointerException if {@code out} is {@code null} * * @since 1.9 */ default long transferTo(Appendable out) throws IOException { .... } -Patrick

5 26

RFR 8187742 Minimal set of bootstrap methods for dynamic constants
by Paul Sandoz 15 Nov '17

15 Nov '17

Hi, Please review the patch that adds a minimal set of bootstrap methods can be be used for producing dynamic constants: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webr… <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8187742-condy-bootstraps/webr…> The aim is to provide a small but common set of BSMs that are likely useful with ldc or as BSM arguments, filling in the gaps for constants that cannot be currently represented, such as null, primitive classes and VarHandles. It’s possible to get more sophisticated regarding say factories but that is something to consider later on. This patch is based off the minimal dynamic constant support (still in review): http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.ht… <http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-October/049603.ht…> Paul.

6 23

Review request: JDK-8157246 MHs.arrayLength, arrayElementGetter/Setter, arrayConstructor need to specify invocation-time behavior
by mandy chung 15 Nov '17

15 Nov '17

http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8157246/webrev.00/index.ht… This fixes the spec of MethodHandles::arrayLength, arrayConstructor, arrayElementGetter/Setter to specify the behavior if the returned method handle is invoked with null array or invalid index; same runtime exception thrown by the bytecode behavior. MethodHandle::asSpreader spec is also clarified to throw NPE and IAE except when it spreads with no argument and the returned method handle accepts a zero-length array or null array. Thanks Mandy

3 6

RFR 8190974 Parallel stream execution within a custom ForkJoinPool should obey the parallelism
by Paul Sandoz 15 Nov '17

15 Nov '17

Hi, Please review this patch to ensure that a parallel stream obeys the parallelism of a custom fork join pool when it is executed within that pool: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-poo… <http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8190974-par-stream-custom-poo…> Streams currently do not support capabilities to control the level of parallelism and therefore resources utilised (tricky API design problem to get right). At the moment the trick is to run stream executions within a custom pool, however the number of fork join tasks created will be in proportion to the parallelism of the common pool thus the execution will be over-provisioned. This can be especially noticeable on large machines with many cores. Paul.

4 7

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map
by Funda Secgin 14 Nov '17

14 Nov '17

-- Fs

1 0

RFR: 8184777: Factor out species generation logic from BoundMethodHandle
by Claes Redestad 14 Nov '17

14 Nov '17

Hi, this patch factors out the BoundMethodHandle species data class generation to a new ClassSpecializer facility. While currently semantically neutral, this will make it possible to reuse the facility in other places. Webrev: http://cr.openjdk.java.net/~redestad/8184777/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8184777 Performance wise this adds a very small (~20k bytecode) amount of work to the initialization costs of BMHs, which we expect will be more than repaid as we apply the ClassSpecializer elsewhere. Thanks! /Claes

3 6

Require some insight regarding Objects & Json
by Prakhar Makhija 13 Nov '17

13 Nov '17

Hi, *Scenario* Having 1.5 million json files of same structure (same keys). Each file is of around 64 KB, which makes a total of 1 GB. Created a class MyDummyJsonClass, having the attribute names same as the keys in those json files. Reading the json files, loading them into MyDummyJsonClass, using ObjectMapper. *Doubt 1* Will the objects occupy the same amount of space in Java's Memory, as they were occupying earlier as flat files? *Doubt 2* Does Java convert Objects to Enumerations at Runtime? What I mean to ask is, does it enumerate the attribute names while creating objects, in order to save the memory? Because the Class is just a blueprint, and we create objects out of it over and over again. *Example* class MyDummyJsonClass { private Object meaningfulNameOfAttributeOne; private String meaningfulNameOfAttributeTwo; private Integer meaningfulNameOfAttributeThree; private Float meaningfulNameOfAttributeFour; private Double meaningfulNameOfAttributeFive; private Long meaningfulNameOfAttributeSix; private Byte meaningfulNameOfAttributeSeven; private Boolean meaningfulNameOfAttributeEight; private Character meaningfulNameOfAttributeNine; private Short meaningfulNameOfAttributeTen; // Contructors // Getters & Setters } Here the field meaningfulNameOfAttributeOne is of 28 characters, and Java uses Unicode, so internally just this attribute name will it be occupying 56 bytes of memory in every Object we create? Or is meaningfulNameOfAttributeOne mapped to enum value 1, and will occupy maybe just 1 byte, depending upon the number of fields? If less than or equal to 256 fields in the class, allocate 1 byte enum, else 2 bytes enum. And some kind of Interceptor decides, to give it logical attribute name mapping?

2 2

RFR: 8189953: FileHandler constructor throws NoSuchFileException with absolute path
by Daniel Fuchs 09 Nov '17

09 Nov '17

Hi, Please find below a patch for: 8189953: FileHandler constructor throws NoSuchFileException with absolute path https://bugs.openjdk.java.net/browse/JDK-8189953 webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8189953/webrev.00/ This is a windows only bug. The issue is caused by a change that happen somewhen between 8 and 9, where new File(new File("C:"),"Workspace") was fixed to return "C:Workspace" and not "C:\\Workspace". This uncovered a bug in the FileHandler::generate algorithm. The FileHandler::generate algorithm could arguably be improved by being entirely rewritten but I choose to keep the changes as minimal as I could. best regards, -- daniel

3 5