Fwd: Proposal for generics over primitives needs a rethink

[Gavin King]

Hi, I read with interest the document here:

    http://cr.openjdk.java.net/~briangoetz/valhalla/specialization.html

I'm rather concerned with this proposal, which introduces additional
irregularities and complications into the type system of Java, instead
of attacking the underlying cause of the irregularity, which is that
there is no root type abstracting over primitives and reference types.

In my opinion, this proposal should not be implemented as written,
since it adds additional complexity to an area of the language
(variance/wildcards) which is already too complex, and is already an
area which many professional Java developers don't completely
understand. The proposal as it exists today runs a serious risk of
making Java worse.

What this proposal does is introduce parametric polymorphism over
primitive types, while leaving it impossible to abstract over
primitives and reference types with subtype polymorphism. Thus, at the
intersection of the two systems of abstraction, namely, *variance*, we
get the broken behavior that a List<int> isn't a List<?>.

The proposal also ties itself in knots trying to explain which
operations are and are not sound for a type variable of form "any T",
as a list of special casey restrictions, all the while pretending that
these restrictions can't possibly be represented within the type
system itself.

Finally, worst of all, the proposal fails to separate a description of
the type system being proposed from a bunch of details about how that
type system could hypothetically be implemented in today's JVM.

I therefore suggest a different, simpler, and much more natural
starting point for this work: stop pretending that there is no type
Any. If we accept that there is a type Any, from which Object, int,
float, and friends all descend, then:

- it's clear at the declaration site what is the difference between
"interface X<T extends Any>" and "interface X<T extends Object>", and
it is crystal clear what are the operations that are legal for a T in
either case, and
- it's clear at the use site what is the difference between the
instantiations List<? extends Any> and List<? extends Object>, and we
obtain the correct subtyping relationships that List<int> and List<?
extends Object> are both subtypes of List<? extends Any>.

Furthermore, the notion of parametric abstraction over primitive types
falls out naturally without the need to introduce new primitive
constructs and syntax ("any T") into the language.

Then, finally, working from this simpler, more elegant, more correct
model, we can ask ourselves how it's possible to implement this type
system (either at the compiler level, or, much preferably via
enhancements to the VM itself). This is instead of starting from a
convenient implementation and then working backwards to obtain a
broken type system, which seems to be what has happened with the
current proposal.

I readily expect objections that this might break existing code. I
therefore humbly request that such objection should come with
example code written in Java 8 which would be broken by the
introduction of an Any type. I can't think of any, but surely I could be
missing something. (I am aware of one case which might require
some finessing, but I can think of at least two solutions which would
likely work.)

Thanks,
Gavin


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