generic specialization design discussion

[John Rose]

> ...
> - use via the Object type or an interface (they are indirect)
> - signature compatibility with existing APIs (Optional, LDT)
> - atomic updates (volatile variables)
> - forced nullability of null-hostile classes (ZDV?)
> - permission to load the class later (breaking bootstrap cycles)
> - option to translate recursive value types (requires an indirection)
> - fine control over object layout (when you prefer sharing to flattening)
> - fine control over object API (when you prefer heap buffering to scalarization)

BTW, one reason I like "indirect" is that it is a relatively
unused term in the JVMS, and so can be used to indicate
the new distinction between new flat/scalar and old
"just a pointer", a distinction which gives rise to so many
subtle effects, such as those I just listed.

Using the old words "reference" and "value" for this runs
up against previous existing uses of those words in the JVMS.

Brian and I toyed briefly with the idea of promoting the word
"pointer" (from its mysterious source in NPE) to document the
new distinction, and also the term "address" or "machine address".
"Indirection" won out, for me at least, because it is less concrete.

I also prefer term "indirection" because of its fame as a problem
solver.  It is proverbial that you can solve any problem by adding
another indirection.  (What kind of problem?  See list above!)

https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering

So, in our world, the technical term "indirection" can mean
"What we've always done in the JVM to solve various problems
by adding abstraction to variables."   In contrast to inlining,
which is "What we now do in the JVM to solve other various
problems by breaking abstraction in other variables."

For the JVM an "indirect" variable will be a pointer, a machine
address.  (But perhaps a compressed one!)  The JVM will hide
the details, but the abstraction will be available to solve
those problems which require "another indirection".