>> Boxes are not a good thing; they were a necessarily evil that arises from the >> fact that primitives are not objects. But they create many problems of their >> own. I don’t see how “more boxes” is the answer here. > > More boxes is a temporary answer until we have fully reified generics because > at that point we have generics over value types.
I agree that we need a plan for how to both be stable in the short term and long term. But I think “temporary” is a fantasy! Whatever we add now, is part of Java forever. So we should add the types that make sense both now and later. Boxes are a temporary crutch; if we decide to go with them, we have to be honest — it’s boxes forever, until the end of time. The V? story is a more stable long-term story. (But if you have a better one, we’re listening.). > Here we want to introduce boxes not because value type are not objects but > because value types are not nullable objects but T is a nullable object. You’re assuming the utility of V? after reification is zero, but that’s not the case. For example, suppose ArrayList is reified. Then the user gets the choice of erasure or reification by selecting ArrayList<V?> or ArrayList<V>. Erasure has a bad rap, but sometimes it is desirable. > So it's a different kind of box, for a different reason but that it should > work like a box because our users are already familiar with the box model. I think we have to stop using the word box, because it seems very difficult to have a conversation when we’re not agreeing on what “box” means.
