Static fields in specialized classes

[Stephen Colebourne]

On 15 October 2014 16:25, Brian Goetz <brian.goetz at oracle.com> wrote:
> What you should have done even in Java 5 was
> <T> void process(Foo<T>) { ... }

Thats an argument to get developers to type more code for no actual
benefit (in Java 5 to 8). Not very appealing.

> So if you want to write methods that are generic across all
> Foo<T> instantiations, just do:
> <any T> void process(Foo<T> foo) { ... }
> and you're fine.

Not quite. It is not possible to write code in Java 8 that still works
in Java 10. While a private closed code base can potentially make the
change you propose when migrating to 10, an open source library can't.
As an open source author, I need the code I publish to be equally
usable across multiple Java versions. I can't write <any T> today, so
it won't work as desired in 10. The "refactor and you're fine"
argument doesn't work here.

(Conceptually, "any T" is a new supertype of Object and primitive,
which is an understandable design choice, but of little use to running
code both pre and post 10)

> Where this
> falls down is in representation of things like arrays; you want
> ArrayList<int> to be backed by an int[], not an Integer[].  You may be able
> to make boxing faster (and we should!), but when the data hits the heap,
> erasure won't cut it.

We obviously want int[] or value[] not Object[]. What I was suggesting
is that if an int[] is accessed via a dumb Object[] reflection routine
then boxing occurs. If accessed via a smart, specialism aware
reflection routine, then the int[] is visible. Think of it as a
variation of boxing that applies to arrays instead of single objects.

> Avoiding special-casing
> of primitives is part of the design goal here, by unifying all primitives in
> the greater family of "values".

I'm glad to hear that, but I'm not yet seeing it. In fact I'm seeing
the opposite, because that sentence implies unifying primitives and
values, rather than unifying primitives and objects. Perhaps this is
an understanding issue. Perhaps it is an early stage issue.

But my "I want a pony" requirement is still for int and value to "just
be" a kind of Object
(difficulty noted, and where Object is no longer a synonym for reference type).

Stephen