Fwd: Proposal for generics over primitives needs a rethink

[Brian Goetz]

>> For the record, the reason we rejected a unified 'Any' type is: it is a
>> fiction.
>
> So this sentence has been bothering me for a day or so

Sure, I can unpack this a bit.

Not all fictions are harmful.  Many features are mere sugar, and sugar 
is tasty when used judiciously.  Enums, constructor chaining, and 
checked exceptions are good examples; they get sugared away by the 
compiler.  And they are good fictions!  There's a perfectly reasonable 
and performant way to represent them in bytecode, so the language-level 
abstraction maps cleanly to existing (but different, and -- critically 
-- simpler) VM abstractions, and the user doesn't notice or care. 
(Check out my recent Devoxx keynote, where I referred to these 
positively as "language fictions".)  And yes, generics are a fiction 
too.  There's more diverse opinion on whether they are a good fiction or 
not; erased generics do map *mostly* cleanly to the VM (bridge methods 
excepted) and they perform well, but people do find erasure to be pretty 
unnatural, and when they find out they've been "fooled" in this way, 
sometimes they get pretty upset.

On the other hand, an Any relative to to today's JVM would be a harmful 
fiction, because it *seems* so natural, and yet, our tools for 
representing it in bytecode would have serious impedence mismatches with 
user expectations.  This is bait-and-switch for users, and a lifetime of 
pain for implementors.  (I had more to say about this topic at my JVMLS 
keynote from this year; video is online.)

> It's quite possible, of course, that you've already invested a lot of
> time into making Any work, and found that it doesn't work because of
> certain obscure, highly technical points that I have not yet stumbled
> upon.

Yeah, I think is pretty close to right (except for the assumption that 
the only reason we'd reject it is some obscure technical point you've 
not yet thought of -- we reject all sorts of things that are technical 
feasible, for reasons of compatibility, consistency, maintainability, 
philosophy, resource availability, priority, security, or just plain 
"not good enough", and even if the reasons were perfectly transparent, 
you still might not agree with them.)

But, yes, we've explored it in substantial depth, and we still don't see 
a feasible and acceptable path.  (And we probably will continue to think 
about it; sometimes your first ten ideas are wrong but that doesn't stop 
you from continuing to try.)

> But if that's the case, then neither the design document for
> specialization, nor your above email, hints at what these issues might
> be. At the very least they should be highlighted in the paper so that
> the Java community understands what they are.

Sure, in a perfect world, our brains would be available on the internet 
for direct neural queries, and all curiosities could be satisfied (or 
maybe not.)  In the world we've got, we try our best to balance moving 
things forward with providing after-the-fact explanations of our thought 
processes and what we've explored.  But this is not always possible in 
the detail, time-frame, or angle of view that everyone with a question 
would like.  That may suck, but we need to focus our energy primarily on 
the search for the right answers.