Fwd: Fwd: Proposal for generics over primitives needs a rethink

[Gavin King]

On Mon, Jan 5, 2015 at 12:06 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>
> On 01/05/2015 02:54 AM, Gavin King wrote:

>> I'm not seeing this. By nature it's impossible to switch over the
>> primitive types with instanceof or whatever, so I'm having a really
>> hard time visualizing what kind of Java code would break.
>>
>> Examples?
>
>
> switch(type.getName()) { ...

So you mean the introduction of Any could break code that uses
reflection? I mean, sure, I suppose, in principle, but I guess I just
don't see this as really a big deal. What would happen in practice is
that attempting to use a newly-written class *that uses Any* with an
older reflection-based library that hasn't been updated yet would
cause an error from the library. But except in very extreme cases,
programs that used to work will keep working, since they don't use
Any, right?


> yes, but you don't need Any to do primitive type specialization,
> you just need Any as a bound of a type parameter that's
> the whole point of the discussion now ?

What I'm saying is that: whatever the implementation, specialization,
or something else. There should be a type List<? extends Any> that is
a supertype of both List<int> and List<java.lang.Object>. *How* that
is achieved (via boxing, or via a tagged union) is of much less
importance to me.


> Yes, it makes the VM more powerful, I think we can all agree with that.
> The problem is that its a pervasive change that as far as I know
> nobody has even tried.

So we know it's really really hard even though nobody has actually
tried to do it? Hrm, trying to keep my skepticism in check here ;-)


> I will be very happy to see Redhat to found a project like this,
> taking the source of hotspot and trying to add Any.

Stef and I will chat to the guys working on Open JDK and ask them what
they think.


> About the separation of behaviors, it's exactly like saying,
> if I use a JVM but only with primitive types, no objects,
> I will not pay the price of having to deal with objects.
> That's not true, the VM will still prepare internal data structures
> to be able to crawle the stack during a GC even if a GC
> will never occur in that case.

Sure, but I don't think that's where most of the cost of having
objects comes from. If I write a program that never actually allocates
any objects, it will run much faster than one which allocates millions
of objects ;-)


> Having all values stored as Any require the VM to check the runtime type of
> all operands
> for each operation, this is what CPython does, but not what more advanced
> dynamic language runtimes do.
> They do optimistic speculative type analysis, i.e. generate a code by
> examples for ints
> and de-optimise if a type is a String and then re-generate a new code.
>
> So sure Any will help, but not as much as you think.

OK, that's interesting.


>> Couldn't we just say that a byte[] actually isn't an Any[]? I mean,
>> that's actually *correct*. Why double down on stupid?
>
>
> how to implement ArrayList in that case ?
>
> class ArrayList<T extends Any> {
>   T[] array;   // <-- this is an array of Any !
> }

Ah, yes, so indeed this motivates the idea that ArrayList<Any> is not
a concrete instantiation. And that's precisely why you prefer
ArrayList<any T>.

OK, that's very interesting. I had not picked up on this one.

I'll reflect on this some more, but indeed I see how this could be the
killer argument against the "tagged union" approach to Any.

Thanks.

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