Using the variable instantiation to define if is primitive type (Bucket 3) or value type (Bucket 2)

[Anderson Vasconcelos Pires]

Hi guys,

I am very excited about Valhalla and what it will do for Java. I was
wondering if the language proposals could be simplified a little bit
without affecting performance.

Please let me (maybe the community) know if the proposal below could be
applied or not.

>From the new proposal that separates the user type in 3 Buckets (1, 2, 3),
I believe the Primitive.ref (Bucket 3) and value class (Bucket 2) are
equivalent, right?

If so, I was wondering if we could have just one class declaration and
distinguish the variable from how it is created.

The runtime variable would be a value object if we use the new keyword to
instantiate the variable, if not would be primitive value. I think it makes
a little bit of sense since the new is used to create an object today,
right?

See the example below:

[primitive or value] class Point {
    int x;
    int y;
}

Point p1 = Point(1, 1); // primitive value   - p1 is value of Point. Could
be defined at compile time as new Point() in the actual proposal;
Point p2 = new Point(1, 1); // value object - p2 instance of Point.ref.
Could be defined at compile time as new Point.ref();

Assuming the Point.ref is a subtype of Point, I believe this could be
possible, right? If necessary, the right type could be defined at compile
time in some cases.

I do not know if it would have extra cost. I hope not.

private Point getPoint(boolean reference) {
     if (reference)
          return new Point(1, 1);
      else
          return Point(1, 1);
}

Point p1 = getPoint(true); // p1 runtime is a value object -> Point.ref

The array would be like below.

Point[] ps1 = Point[10];  // assert ps1[0].x == 0
Point[] ps2 = new Point[10]; // assert ps2[0] == null

In this way primitive variables could be null. I don't think this is a
problem since the wrapper class looks like it will continue to be nullable.
For another point of view, the builtin primitives cannot be null. An
Advantage is that it would not be necessary to include T.ref at the return
of Map.get.

One doubt is about another [primitive or value] class that has [primitive
or value] members like shown below.

[primitive or value] class Rectangle {
    Point low;
    Point high;
}

Maybe it would be a problem because the object size could not be defined
previously. But we may assume in this case the size of primitive value.
This way, Rectangle would be flat.

Thanks for your time and please let me know your thoughts about this
proposal.

Anderson.