"Model 2" prototype status

[Brian Goetz]

Much of this has been covered already in the "Why not 'just' add an Any 
type?" discussion (see the archives), so I'll try to avoid repeating 
those points.  The short answer is "yes, we've thought about this quite 
a bit, and we feel the result would only be superficially satisfying." 
(And I regret to say, I won't be able to continue this discussion 
further; extended discussions on "why not take a completely different 
direction" -- especially when that direction is one we've already 
considered -- are just too much of a distraction, so please, hold your 
responses.)

> Simple question... I can't help to think ( although I may be incorrect )
> that a massive amount of this issue goes away ( for new programs ) with
> a unified object/valueType hierarchy and availability of autoboxing
> tweaks.

It depends on your goal, of course.  If the goal is simply to let you 
type List<int> instead of List<Integer> (saving four keystrokes), then 
it would be trivial to simply interpret List<int> as the boxed 
List<Integer>.  But that doesn't meet our goals, which is enabling 
generics to play nicely with values without giving up the key 
performance benefits of values -- density (no header or other memory 
overhead) and flatness (no indirection or pointers.)  Any solution that 
relies on autoboxing fails to meet these goals.

As a simple summary of goal, if ArrayList<int> is not backed by a real 
int[], then we've failed.

When you say "a massive amount of this issue goes away", what I think 
you actually mean is it "recedes from where I can see it."  But that 
doesn't make it go away.  (There can be in pushing the complexity where 
the user doesn't have to see it, if the problem is just being kicked 
down the road, you're not necessarily doing anyone a favor.)

Autoboxing simply kicks the problem down the road.  I think its fair to 
say that, if the performance of boxing didn't suck so badly, we wouldn't 
be bothering with this in the first place -- people would be happy 
enough to just write ArrayList<Integer>.  (The next obvious question is 
"Well, why not just fix that?"  And the answer should be equally obvious 
-- if we had an easy fix for this, we would have done it years ago.)

Your "for new programs" observation is too important to be limited to a 
parenthetical.  If we were building a new language from scratch, we 
would surely make different decisions.  And its worth spending some time 
asking ourselves what the ideal might be in that situation, but we can't 
let ourselves be too drawn into the fantasy that we have a clean sheet 
of paper to work with.  Migration compatibility (not just for 
implementations of generic classes, but also for their clients and 
subclasses) is absolutely critical -- and it's going to cause warts. 
(Its OK to regret said warts, or wonder whether a different set of warts 
would be more palatable -- but not really reasonable to conclude that 
"warts -> someone made a mistake".)

 > 2. Value type hierarchy base object appearing to the compiler has
 > Object.
 >
 > Some popular languages seem to have success with this approach.  And at
 > least on the surface it seems to solve nullability and and host of other
 > API issues that have been discussed.

Other languages and platforms have attempted to unify objects and 
primitives -- with varying degrees of failure and success.  Paul 
Philips' talks circa 2013 -- at JVMLS and Scala PNW -- highlight the 
challenges of trying to unify references and primitives on the JVM while 
retaining any sort of compatibility.  The poor performance of Scala 
streams over "primitives" (see Aggelos Biboudis' paper on this) proceeds 
mostly from this attempt to unify; the result is that they can't prevent 
the boxing, and performance suffers.  .NET took the path of unifying 
structs and objects (but regrettably, allowed their structs to be 
mutable.)  This has been partially successful but also less than 
perfect; we've tried to learn what we can from their experience.

Our thinking continues to be: primitives/values and references are 
different, and papering over the differences with superficial remedies 
ultimately causes more trouble than its worth.

> More out of curiosity than anything else, is there anything inherently
> wrong/broken with the above approach?

There's nothing inherently wrong with the concept; it has pros/cons like 
anything else.  What is inherently wrong is the assumption that it is 
somehow any simpler or less work.

HTH,
-Brian