Proposal for Decimal64 and Decimal128 value-based classes

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Wed Mar 31 15:01:31 UTC 2021


On 31/03/2021 15:23, Douglas Surber wrote:
> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

There is a catch here.

While in principle, we can add these as value-based classes, and migrate 
to Valhalla later, there is a biggie difference between doing it 
before/after.

When it comes to "migrated" primitive classes, there is a choice in how 
to interpret the "old" utterances of the class name. Let's say that 
class Foo is migrated to be a primitive class; does that mean that all 
uses of Foo in existing program will automatically get flattening? Or 
will references to Foo be interpreted in a conservative fashion, so  as 
to allow the same operations as before? One important difference in 
semantics is assignment to `null` which is prohibited under flattened 
semantics, but allowed under "indirect" (or by reference, if you will) 
semantics.

In other words, under the current plan, if Decimal128 is added now and 
migrated later, utterances of Decimal128 will behave like they used to 
pre-Valhalla, and, to take advantage of flattening you would need to 
opt-in with some keyword (e.g. Decimal128.val).

To me this is kind of a strong argument against going with these classes 
now (as much as I understand how useful they'd be even w/o Valhalla) - 
and preserving the "good" name (Decimal128) for the flattened case seems 
worth, IMHO, waiting few more cycles.

Maurizio



More information about the core-libs-dev mailing list