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. >>> >>>
