That makes sense (and it's consistent with my layman's interpretation that List<T> as a value-based is weird). In this particular case, I believe Stuart does want to make explicit claims for immutability and serializability.
In the case of the empty methods, I don't see why a strong claim about identity can't be made. The same claim exists today in Collections.empty*. As a user of the API, the more clarity/guarantees I can get, the better I feel about using the method. If I know a method is garbage-free, for example, I will use it, but if I don't have that guarantee, I might as well do my own "static final List EMPTY = ...". Thanks Moh >-----Original Message----- >From: Brian Goetz [mailto:brian.go...@oracle.com] >Sent: Tuesday, December 01, 2015 10:03 PM >To: Stuart Marks; Rezaei, Mohammad A. [Tech] >Cc: 'core-libs-dev' >Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation (JDK- >8139232) > >Value-based is a property of types, not of instances. > >For disclaimers regarding the result of factory methods, it seems >clearer to go to the traditional "make no assumptions about the type, >mutability, serializability, or identity..." sort of language. > > > >On 11/25/2015 7:37 PM, Stuart Marks wrote: >> I think the main point of including the "value-based" admonition is to >> warn developers not to depend on identity semantics of these things. >> This should help preserve flexibility when/if we decide to convert >> them to value types in the future. It might be that there's no >> advantage in doing so, in which case we presumably won't do it. :-) >> >> I'm somewhat distant from the current state of the value types work, >> but I can imagine that it would provide some advantage even for the >> empty List. Clearly the overall heap savings wouldn't be large, since >> as you point out, there's only ever a single instance. But if it were >> a value type, it could live entirely on the stack, avoiding a memory >> dereference, a cache miss, etc. >> >> s'marks >> >> On 11/24/15 7:52 PM, Rezaei, Mohammad A. wrote: >>> Value based things make a lot of sense for types that don't belong to >>> well established reference hierarchies. I can even see great uses for >>> a value based List implementation, so long as it's preferentially >>> referenced as the exact type (e.g. private ValueBasedList someList = >>> ...) and rarely cast to the interface type (List). >>> >>> But I've been scratching my head about the empty collections (of()) >>> and I can't figure out why value based would be a good idea. >>> Currently, there is only one instance in the entire VM, so it's >>> unlikely to get any memory benefits. The most likely use for the >>> return value is either a variable/member of type List or something >>> that can hold a List (like a Map<K, List>), which will likely cause >>> an immediate boxing. In some cases this can be elided (lots of >>> inlining and optimization), but that's the less likely case. >>> >>> What's the rationale for the value based spec for the empty >>> implementations? >>> >>> Thanks >>> Moh >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] >>>> On Behalf >>>> Of John Rose >>>> Sent: Tuesday, November 24, 2015 9:08 PM >>>> To: Stuart Marks >>>> Cc: core-libs-dev >>>> Subject: Re: RFR(m): JEP 269 initial API and skeleton implementation >>>> (JDK- >>>> 8139232) >>>> >>>> On Nov 23, 2015, at 10:26 PM, Stuart Marks <stuart.ma...@oracle.com> >>>> wrote: >>>>> >>>>> Please review these API and implementation changes that comprise >>>>> the first >>>> integration of JEP 269. I intend to push this under the "initial API >>>> and >>>> skeleton implementation" subtask, JDK-8139232. >>>> >>>> Please strengthen the specification to assert that the new >>>> immutables are in >>>> fact value-based. >>>> >>>> http://docs.oracle.com/javase/8/docs/api/java/lang/doc- >files/ValueBased.html >>>> >>>> <http://docs.oracle.com/javase/8/docs/api/java/lang/doc- >files/ValueBased.html> >>>> >>>> >>>> This will prevent people from relying on their identity (acmp) and >>>> synchronization (monitorenter). >>>> It will allow optimizations more freedom to use flatter storage >>>> formats and to >>>> reuse list values. >>>> >>>> If we don't do this now, then we will not be able to retroactively >>>> make or >>>> enforce the claim, >>>> and the optimizations will be impossible. >>>> >>>> — John
