more background to List<int> specializing List<Any>

[Gavin King]

Stephen you might be right but note that "beans" as they are used
today actually are usually mutable and have identity. In UI binding
frameworks, in ORMs, etc.

As much as I appreciate little immutable objects, it's not at all
clear to me that the Java ecosystem is really set up to turn on a dime
and start using them everywhere.

If we want a way to get a cheap equals()/hashCode(), we should add an
annotation that generates equals()/hashCode(). Tying auto-generation
of equals()/hashCode() to value semantics is to my mind making
auto-generation much less useful.

On Mon, Jan 5, 2015 at 2:18 AM, Stephen Colebourne <scolebourne at joda.org> wrote:
> On 5 January 2015 at 00:44, Gavin King <gavin.king at gmail.com> wrote:
>> How strong of an objection this is depends upon how often you think
>> value objects will occur compared to primitives. That's a question
>> I've been turning over in my head the last couple of days, without
>> being able to really arrive at a firm conclusion by intuition alone.
>
> Given that Java has no convenient bean/property support but value
> types will likely provide an equals/hashCode/toString, I believe that
> they will be widely used as domain objects, even for objects way
> bigger than the size sweet-spot of value types. This opinion make me
> more concerned about how they interoperate with libraries pre-JDK
> 10/11.
>
> Stephen
> PS. On List<int> vs List<Integer> I'm sure you're right...



-- 
Gavin King
gavin.king at gmail.com
http://in.relation.to/Bloggers/Gavin
http://hibernate.org
http://seamframework.org