Valhalla EG notes Jan 16, 2019

Karen Kinnear karen.kinnear at
Wed Jan 30 15:46:52 UTC 2019

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 { returns } // assume old code only wants references here
   risk: existing getClass.getSuper() assumptions

   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.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 are both subclasses of ValObject


> On Jan 30, 2019, at 10:21 AM, forax at wrote:
> De: "John Rose" <john.r.rose at>
> À: "Remi Forax" <forax at>
> Cc: "Karen Kinnear" <karen.kinnear at>, "valhalla-spec-experts" <valhalla-spec-experts at>
> 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 <forax at <mailto:forax at>> 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() <==> and
> class Object {
>   ...
>   public static Object new() { return; }
> }
> and the translation new Object() to 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, does a subtype of Val/ValObject ?
> Rémi

More information about the valhalla-spec-observers mailing list