Fwd: Proposal for generics over primitives needs a rethink

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