JEP 401: Primitive Objects (Preview)

[Suminda Sirinath Salpitikorala Dharmasena]

Hello,

Few things to note:

   - Instead of a class being a primitive or a reference object *at the
   point of declaration* can it be made such that the object instance is a
   primitive or a reference object *at the point of instantiation*. So at
   declaration an object can be used either as a primitive or reference. At
   instantiation if it is primitive it loses identity. Also it has the ability
   to have different functionality based on what it is.


   // Class has different templates
   class A {} // Common parts
   class A.val extends A {} // val specific parts
   class A.ref extends A {} // ref specific parts
   class B {} // can be used as a ref or val

   // Method/Constructor has different templates
   class C {
      C(...) {} // can be used as a ref or val
      C.val() {}
      C.ref() {}
      void f() {} // can be used as a ref or val
      void m.val() {}
      void m.ref() {}
      void g.ref() {} // Only in refs
      void h.val() {} // Only in vals
   }

If there reference to the self type it will become ref automatically.


   - With *arrays *there should be a *choice to make them primitive or
   reference objects* at *the point of instantiation*. Otherwise accessing
   an array will always need an indirection. Also cannot be flattened into the
   object containing the arrays when it makes sense to do so. This provides
   better
      - performance and
      - control over memory layout

Better control over memory layout would give dividends for better
serialisation, communication and foreign memory access when there are *multiple
levels of nested* intertwined objects and arrays with one containing the
other.


Suminda