"Model 2" prototype status
brian.goetz at oracle.com
Tue Aug 4 16:07:33 UTC 2015
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
> 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
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
> 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.
More information about the valhalla-dev