"Model 2" prototype status

[Martijn Verburg]

Hi all,

As an aside - to get some of the in depth background behind this proposal
(and alternatives) then I highly recommend going to the JVM (language)
summit (http://openjdk.java.net/projects/mlvm/jvmlangsummit/). It's almost
impossible to write up all of thought processes etc (would take volumes and
1000's of hours) on this list as much as Brian et al would like to, much
easier to get the info in person with the higher bandwidth so to speak.

Cheers,
Martijn

On 4 August 2015 at 17:07, Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>
>