Simplifying reified generics with partial specialization

[Ron Pressler]

You would still get a compile-time error if you try to add a String to an
ArrayList<int>, just as you'd get one for ArrayList<Integer> today. As for
runtime behavior -- there's nothing surprising here. ArrayList wouldn't
change behavior because ArrayList<int> doesn't extend ArrayList, and
List<Integer> might well throw a CCE at runtime even today -- after all,
that's what you'd get when using Collections.checkedList today. Any code
that takes a List<Integer> today might get a checked list and get a CCE if
it tries to do something crazy with it. Code that for whatever reason takes
ArrayList<Integer> simply won't be able to take an ArrayList<int> (just as
it can't take a specialized Trove class today), but that's what you'd also
get with Brian's proposal.

Ron Pressler
paralleluniverse.co
@puniverseco <https://twitter.com/puniverseco> on Twitter

On Mon, Jan 5, 2015 at 7:47 PM, Simon Ochsenreither <simon at ochsenreither.de>
wrote:

> As to your other example, you'd get a ClassCastException/ArrayStoreException
>> because the storage is still specialized. This behavior is specifically
>> allowed by the List interface contract.
>>
>
> a) That contract comes from pre-Generics ages.
> b) One of the goals of Generics was to move errors from runtime to compile
> time. This would reverse the success of it (success in the sense of "I
> haven't seen a ClassCastException coming from the collection API for a long
> time"). I think it's fair to say that pretty much no codebase in the wild
> today would be prepared to handle such CCEs.
> c) What about all the APIs out there, which are defined more strictly?
>