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

[Brian Goetz]

BTW, if anyone wants a hard problem to think about that we've not yet 
tackled, I encourage someone to explore how we're going to migrate 
existing j.u.Optional to be a value type -- without breaking existing 
source or binaries.  (Hint: exploiting the L/Q duality gets you partway 
there.)

On 1/4/2015 7:57 PM, Gavin King wrote:
> Right, so this is the biggest objection to the idea of implementing
> Any at the VM level: it would let you avoid boxing for the built-in
> primitives, which is big win, obviously, but not for arbitrary value
> types, which would still need boxing.
>
> 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.
> Looking at Java as it exists today, it might be that Optional is the
> one thing that really tips the balance. But on the other hand, it's
> hard to say what people are going to do with Java once value types
> exist; perhaps value types will eventually become the default choice
> for most user-written classes!
>
> The other thing floating around in the back of my mind is that even if
> a VM-level Any isn't that useful for *Java*, it would still surely be
> extremely useful for other JVM languages. I can imagine that folks
> running dynamic langs on the JVM would just *love* to be able to use
> an array of type Any[], and have that efficiently store numeric values
> without boxing. The "specialization" approach doesn't seem like it
> would help them as much. (This is speculation on my part; I've not
> tried to compile dynamically-typed code for the JVM myself.)
>
>
> On Mon, Jan 5, 2015 at 12:00 AM, Stephen Colebourne
> <scolebourne at joda.org> wrote:
>> The specialization document include the phrase "If we were concerned
>> only about primitive instantiations, we could consider some sort of
>> "tagged fixnum" approach. However, this approach essentially reverts
>> to boxing for arbitrary value types, so it does not get us to our
>> goal."
>
> --
> Gavin King
> gavin at ceylon-lang.org
> http://profiles.google.com/gavin.king
> http://ceylon-lang.org
> http://hibernate.org
> http://seamframework.org
>