Valhalla EG notes Jan 16, 2019
brian.goetz at oracle.com
Wed Jan 30 16:01:24 UTC 2019
> Option 2: RefObject, ValObject - interfaces
> VM at class definition adds RefObject to all existing classes
> value classes required to declare ValObject as superinterface
> ackwardness: VM needs special behaviors for Object.wait, Object.notify - if dynamically a ValObject, throw IMSE
> instead of having that obvious from the implementation in a superclass.
> Are there other concerns here?
> This seems cleaner to me - especially since I also believe that synchronization on ValObjects will also require
> special handling - which will be vm implementations rather than visible in java sources (exact plan is TBD).
As I said to Remi, let’s be crystal clear that this seems cleaner _only to VM implementors_. To everyone else, it’s less clean, less powerful, less educational, and more complicated (“why can’t I implement both RefObject and ValObject?”)
If we bash our heads against the former for a while and give up, that’s OK; we can’t solve all the problems all the time. But let’s be clear what we’re doing, and why.
Theres’s also a middle ground: ValObject is a class, and RefObject is an interface. While this may appear stupid, it reclaims more than half of what we lose by making both interfaces — because it gives us a place to put privileged, final, value-specific behaviors. And values are going to need more of them than references will.
More information about the valhalla-spec-observers