Hi all,
Unfortunately I don't have time to work on any of this at the moment, because of
JavaOne preparation, and JavaOne next week.
Jonathan, thanks for pushing forward with this. I'm glad that others have picked
it up.
Patrick, thanks for posting the changeset on Jonathan's behalf. This is very
helpful.
A few comments regarding issues raised up-thread.
Regarding the (non)singleton-ness of the empty collections, this is covered by
https://bugs.openjdk.java.net/browse/JDK-8156079
consider making empty instances singletons
It wasn't a design decision to make them not singletons. The spec requirement is
only that the returned instance satisfy the requirements of the interfaces it
implements (e.g., List) and nothing more. Certainly there is no spec requirement
regarding object identity.
Making the empty collections singletons is the "obvious" thing to do, but it's
often the case that the "obvious" thing isn't the right thing. That said, it may
still be the right thing to make them singletons. Given the proposed extension
to the JDK 9 schedule, it might be possible to change this in JDK 9.
Note that List.of() should be functionally equivalent to Collections.emptyList()
-- and correspondingly for Set and Map -- but they do differ. In particular,
they have different serialization formats.
Also on this topic, please note comments that Daniel Fuchs and I have added to
https://bugs.openjdk.java.net/browse/JDK-8134373
regarding serialization compatibility. Reviewers should take care that updating
code to use these new collection factories doesn't change any serialization
formats. Unfortunately I am not confident that we have sufficient tests for
serialization compatibility.
s'marks
On 9/15/16 7:02 AM, Jonathan Bluett-Duncan wrote:
Wow, lots of discussion went on since I was busy doing other stuff!
Thanks Patrick for doing the work of creating a new webrev for me. Really
appreciated!
Pavel already mentioned it, but I think List.of instead of
Collections.emptyList in ZoneOffsetTransition is the right thing to do for
visual and behavioural consistency. If it turns out that we need to revert
to Collections.empty* and Collections.unmodifiable* for e.g.
serializability or class loading concerns, then I'd be happy to revert both
of the lines I touched. Otherwise I believe that List.of should be used
consistently.
I think Stuart made List.of() non-singleton because there wasn't any
evidence that it made List.of() more memory- or time-intensive than
Collections.emptyList(), but I might be wrong on this. I'm sure he can
explain more or correct me in this case.
Kind regards,
Jonathan
On 15 September 2016 at 13:33, Patrick Reinhart <patr...@reini.net> wrote:
Hello together,
I tried to process all suggested change input into the following new
webrev:
http://cr.openjdk.java.net/~reinhapa/reviews/8134373/webrev.01
Give me feedback if something is missing/wrong
-Patrick
On 2016-09-15 13:48, Pavel Rappo wrote:
Daniel, Claes,
List.of() and Collections.emptyList() are not the same. The behaviours are
different. Moreover, immutable static factory methods return instances
which are
value-based. I believe it also means we are not tied with unconditional
instantiation, and in case of empty collections/maps could probably
return the
same object every time.
We should ask Stuart why it has been done like that in the first place.
Maybe
out of concern people might synchronize of those objects? I don't know.
Let's
say for now it's an implementation-specific detail.
On 15 Sep 2016, at 12:35, Claes Redestad <claes.redes...@oracle.com>
wrote:
+1
I don't mind List.of() aesthetically, but there are places where
startup/footprint is important where Collections.emptyList()
is simply superior, e.g., constituting permanent data structures
such as the module graph during early bootstrap.
