RFR: JDK-8134373: explore potential uses of convenience factories within the JDK

[Stuart Marks]

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 <patrick at 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.redestad at 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.
>>>>
>>>>