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