I see two options proposed:
Option 1: RefObject, ValObject - classes
VM at class definition time replaces superclass of all existing classes from
Object -> RefObject
VM translates:
new Object -> treated as Object.new() { returns RefObject.new() } //
assume old code only wants references here
risk: existing getClass.getSuper() assumptions
Questions:
How would the VM translate new Object[] ?
- we might want existing code to be able to handle all subtypes of the top
type in the existing arrays
- or erased generics will break
If I wanted to instantiate a new top type which could hold either RefObject
or ValObject, how would I do that?
Object.new()? Object.newObject()
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).
Remi - L/Q signatures are orthogonal to the type hierarchy - they declare
null-free or null-tolerant
so Point.val and Point.box are both subclasses of ValObject
thanks,
Karen
> On Jan 30, 2019, at 10:21 AM, fo...@univ-mlv.fr wrote:
>
>
>
> De: "John Rose" <john.r.r...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Karen Kinnear" <karen.kinn...@oracle.com>, "valhalla-spec-experts"
> <valhalla-spec-experts@openjdk.java.net>
> Envoyé: Mercredi 30 Janvier 2019 00:29:01
> Objet: Re: Valhalla EG notes Jan 16, 2019
> On Jan 29, 2019, at 11:10 AM, Remi Forax <fo...@univ-mlv.fr
> <mailto:fo...@univ-mlv.fr>> wrote:
>
> currently the result of the expression "new Object()" is a reference type, so
> it should be a RefObject, but we have created an Object not a RefObject,
> so it's at best weird.
>
> I'd like to rationalize this in two steps.
>
> First, allow `new I(x…)` where `I` is an interface,
> to be treated as shorthand for `I.F(x…)` where
> the method `F` is somehow declared by `I` as
> its canonical factory. I'm thinking `List.of` is
> a good one. (Maybe also extend this rule to classes
> with non-public constructors.)
>
> Second, since `Object` is an honorary interface,
> change the meaning of `new Object()` to be
> `Object.newReference()` (or some such), by
> having `Object` declare `newReference` (of
> no arguments) as its canonical factory.
>
> Moving `new` statements to factories is coherent,
> also, with changing the translation strategy for Java
> to deprecate the new/init dance outside of the class
> being constructed, and eventually make it illegal in
> bytecode outside of the nest of the class being made.
> In other words, if I could go back in a time machine
> and rewrite the translation strategy, I'd insist that
> each class (or the JVM itself) would define a canonical
> factory for each constructor of that class, and require
> all other classes to allocate via the canonical factory.
> The new/init dance would be legal inside the class
> but nowhere else. That attack surface has been a
> painful one. And value types have to use factories
> from the get-go, so we've got to figure it out sooner
> or later. The name of the canonical factory can be,
> in fact, fixed as '<init>'.
>
> so new Object() <==> Object.new() and
> class Object {
> ...
> public static Object new() { return ReferenceObject.new(); }
> }
> and the translation new Object() to Object.new() has to be done by the VM
> because there is already a lot of code that do a new Object().
>
>
> — John
>
>
> I think i still prefer having interfaces Val/Ref instead of classes, these
> interfaces can be injected by the VM, at least the Ref interface can be
> injected, for the Val interface, we can requires all value types to implement
> that interface.
>
> Another question, we have two representations of a value class, the real
> value class and the nullable value class, the Q and the L classes, Point.val
> and Point.box, does Point.box a subtype of Val/ValObject ?
>
> Rémi
