more background to List<int> specializing List<Any>

[Stephen Colebourne]

On 5 January 2015 at 03:00, Brian Goetz <brian.goetz at oracle.com> wrote:
>> - that there is too much concern on memory/performance and not enough
>> on developer productivity - Java isn't C
> We care a lot about developer productivity -- remember Java 8?  But we also
> have to pay attention to performance too.  You might not care (and that's
> great for you if you can avoid caring), but not all users have that luxury.
> And developers spent ridiculous energy working around boxing / objects.
>
> Value types are not an end unto themselves; they power features that offer
> productivity and performance both -- alternate numerics, tuples, faster
> iterators, etc.  (It's too bad they weren't around for JSR-310, as you went
> to great effort to ensure that date-times behaved like values, but you still
> had to pay the boxing cost anyway.)
>
> Value types are also a huge boon for non-Java languages, who have to
> represent other-language primitives in Java, such as numerics that don't
> quite line up with Java's eight primitives.
>
> So, I think what you're saying is there isn't as much for *you* in this
> release as there was in other releases.  And that's OK.  We have a diverse
> base of users, and we have to serve them all.  Value types are a
> foundational tool that will make a huge difference for a significant
> category of users.

I actually like the potential benefits of value types. And I
definitely care about performance to a degree. But if performance is
key to a system it probably shouldn't be in Java, and value types
aren't going to give anywhere near the amount of control necessary to
perform the range of optimisations at the CPU level that true memory
control can achieve. (That LocalDate is an object not a value is pain
that will definitely cause me issues this year, so I do "get" the
potential upsides here)

But for every upside of value types there is also a downside. Its a
trade off, and I'm not comfortable with the balance right now.
Function types (in JDK 8) were dropped to make lambdas palatable, IMO
something key needs to change in order for value types to be
palatable.

> I think the better way to look at it is not going from "eight special cases
> to infinitely many", but going from "one general case and eight special
> cases to two general cases."

Right now we have a world 99% of objects. A single unified approach to
coding. Sure there are 8 special cases, but that is very managable and
all the tricks and issues around them are very well known. In most
cases they cause no issues - complaints about them are more grumbles
than real pain. In that world Object is the top type - sure it might
not be in technical terms, but it is in practical terms. With value
types, that Object is not the top type becomes in-your-face visible,
something that IMO effectively changes the meaning of Object (in
practical terms), and means code written today won't have the same
semantic meaning wrt top type in JDK 10/11.

Thus, in the world being outlined the entire coding world is
bifurcated. Two general cases look to be worse than one general case
plus 8 special cases. No piece of code can ignore value types because
value types will be everywhere. As I've said before, what I want is
"faster objects", not "user-defined primitives".

Stephen