The fate of int, int.ref, and Integer

[Brian Goetz]

> I approve of the idea of writing int.java etc. files in order to add 
> methods to `int`, and add interfaces to `int.ref`. It is fine if these 
> files are essentially "fake" (they don't actually bring the primitives 
> into existence as other classes do). I think attempts to try to make 
> them look "real" would mean letting them do things other inline types 
> can't and it definitely wouldn't seem worth it to me.

Not to mention this circularity:

     native inline class int implements BlahBlah {
         int theValue;  <-- oops
     }

So to the extent these are written as .java files, some fakery is 
inevitable.

> I also approve of giving the new `int` class everything it needs so 
> that the `Integer` class becomes obsolete; that is, there would no 
> longer be any good reason to use it except when forced by legacy code. 
> (Of course, anything that wants to depend on identity or locking of 
> such an object I will just declare to be legacy code, so it works!) 
> Really though, don't bring `getInteger` over when you do.
>
> However, I am highly skeptical of attempts to do anything else beyond 
> that. I've seen, at least, the allusions to some kind of aliasing 
> between `int.ref` and `Integer`. That seems unnecessary to me, and 
> more to the point, I feel that it can only make things more confusing 
> to users; that in fact it will cause a large share of all the 
> confusion they do feel. So wait, what IS the wrapper class then? What 
> IS this reference projection then? I see no benefit to blurring that 
> line, at this point.
>
> Reactions?

I certainly understand your gut sense that trying to retcon Integer to 
be something it was never meant to be will likely have some unexpected 
consequences.  But, its not like the alternative is great either.

Suppose we have `native inline class int { ... }`.  So it gets a 
reference projection, `int.ref`, and a inline widening conversion from 
`int` to `int.ref`.  And also, it already has a boxing conversion (with 
the same semantics, and applicable in exactly the same places) to 
`Integer`.  Now what happens when someone does:

     Object o = i;

There are gazillions of lines of code that hard-code the assumption that 
this results in `Integer`.  Every client of reflection is rife with this 
assumption.  So we're probably going to conclude that the boxing 
conversion has to win over the widening conversion.  And now every use 
of primitives -- the most important inline types -- will be saddled with 
accidental identity when they box.  Which means that none of the boxing 
cases we have now -- part of the motivation for doing Valhalla in the 
first place -- will ever get better.

OK, that's existing code.  What about new code?  It gets worse! Some 
libraries might use `List<int.ref>` (because they're better boxes), and 
others might use `List<Integer>`.  And they won't interop.  And this 
problem won't ever go away.

The move of saying `Integer` *is* `int.ref` makes these problems go 
away.  This seems too good to pass up preemptively.