What are Value Types from Project Valhalla?

Question

I've started reading about Project Valhalla and there is something I really don't understand and it's the Value Types.

This is what I understand:

1) Are objects that can't be compare it as reference?

final ValueType a = new ValueType();
final ValueType b = a;
System.out.println(a==b); returns false????

In Google AutoValue code example, it states

if(o == this){return true;}//equals method implementation what is this? I am comparing references here right?

2) According to Wikipedia, highly-efficient small 'objects' without inheritance. What do Small Objects? and Without inheritance mean?

Is this not possible using VT?

public final class ValueType extends Any //is this not possible??

3) Why are they used? Which scenario would be used and how would it be used.

4) According to Google AutoValue Library, in a nutshell, a value-typed object is an object without an identity, i.e. two value objects are considered equal if their respective internal state is equal. My question is: do they have state and should they implement equals and hashcode. What does object without an identity mean?

5) Is this assertion correct?

public static void main(final String[] args)
{
    final Test clazz = new Test();
    final AutoValue value = new AutoValue("Java Belongs to SUN");//Constructor Name
    clazz.mutate(value);
    System.out.println(value.getName()); //would print: Java Belongs to SUN??
}
private void mutate(final AutoValue value){value.setName("Java now is part of Oracle Corporation");return;}

If it is so, would JVM gain memory not tracking this Objects or Values between methods calls?

Project Valhalla is part of initial Project of Java 10 would be ready in 2018 or so.

Chapell

You've made a lot of research and asked a good question. That said, I'm not sure including that as a part of the question is a good idea since a person who can answer this question likely won't need it :) – Marla

Sounds like what c# calls a 'struct' – Score

That makes 5 questions instead of 1, and many of them are unclear, at least to me. I suspect every question you can have can be answered by reading cr.openjdk.java.net/~jrose/values/values-0.html. It has for example a whole section dedicated to use-cases, which is your third question. – Diba

Also, Google's AutoValue library has nothing to do with the upcoming value types in Java 10. It's just a code-generating annotation processor that helps you cut down the boilerplate needed when writing a value class with the current Java version. – Deshawndesi

I think a simplistic answer is to say value types are immutable types. Just like an int has no setters, you would never mutate a value type, you would create new ones with different properties. Therefore identity (as in a pointer/reference) doesn't make sense. This is common in functional programming. You might gain insight into this by looking at Clojure which, by default, leverages value/immutable types. – Halliburton

@KevinDiTraglia, it's exactly like a C/C++/C# struct or a namedtuple in Python or a case class in Scala. There are subtle proposed performance benefits. Hard to evaluate without a prototype to benchmark. – Chow

Answer 1

Your final assertion is correct. The ValueType variables are entirely copied when passing them as a parameter to a function, rather than typically just getting a copy of the reference to an object. This allows you to treat a small object as if it were a value type like int or boolean.

Score

Answer 2

1) Under Project Valhalla, two ValueTypes would be compared by fields directly, even for == checks, much like primitive types. With Google's AutoValue types, you would never use == directly, because that would still be an identity check.

2) Small Objects means that this should be used for objects that only have a few fields, as the whole content of the object is going to be copied repeatedly. Large objects would be better served with passes by reference.

Without Inheritance means that you won't be able to use polymorphism for Value Type objects. Because Value Types are meant to be stored directly, like primitive values, they don't include any class information, so the JVM must always be able to infer what the object is from the program itself, instead of from any information on the object. For example, an Integer field could be a Value Type member, while a Number field would have to still be by reference.

3) They are used to avoid the dereference penalty normally required for accessing an object's members. For example, with a List of Points, each Point is actually a reference to the x and y values in memory, so iterating over the list will involve many dereferences. If the Points were stored directly in the list, this would be avoided.

4) Object Without an Identity means that all that matters about the object is its value. Just as an int valued 1 should be the same as all other ints valued 1, and all Strings "hello world" are equal to all other Strings "hello world", whether or not they are actually the same object. By contrast, two ArrayLists that are both empty, while at the time equal, have identity, because they are mutable, and adding an element to one list must be distinct from adding an element to the other list.

5) Under Project Valhalla, the AutoValue, if it is a Value Object, would be immutable, so there would be no setName method to call. It would be similar to how you can never mutate 1 into 2, you instead modify where a 1 is located so that a 2 is there instead.

Source: http://cr.openjdk.java.net/~jrose/values/values-0.html

Galahad

Answer 3

The other answers are fine, but there is one other perspective about the core point of value objects: they give you stack semantics.

Meaning: before project Valhalla, you either have primitive "objects" and reference objects. The first ones can exist on the stack, but real objects only live on the heap.

Value objects will change that. You can have "real" objects - but their data only resides on the stack. This means that you do not have a reference (and therefore cost for de-referencing) anything - just like primitive types, the value is directly placed on the stack. But now that value can be more than just a single int, long, ... - you can have a real, "complex" object - but all its data is directly there on the stack.

And because of that, you can nicely do a == b now - because now you are no longer comparing references that point to the heap - but a and b directly have their corresponding values.

Ecclesiastical

Does this also mean that the value object won't become garbage for GC to collect and will be immediately freed (since it was allocated on stack)? – Studley

@GurwinderSingh That sounds reasonable, so I am in agreement. But more of "yes, sounds good", than true in depth knowledge ;-) – Ecclesiastical

Answer 4

UPDATE 2019/2020, Build 14-valhalla+4-55 (2019/8/30)

Inline Class is the new name of "Value Type". According to current project state Inline Classes don't support inheritance but are able to extend interfaces. Following statement is legal:

public inline class MyInlineClass extends SomeJavaInterface {}

They do have equals, hashcode (and toString) methods. "==" operation and equals (default implementation) are same for simple case, where only Inline Classes and primitive fields are involved. But it is not true in general.

It becomes messy, if you add a classic Java Object (including String and Array) as a field inside of Inline Class. In this case "==" operation most probably won't work as expected anymore and you have to fallback to classic custom equal implementation.

Inline objects are immutable and don't support clone (clone makes no sense).

---

A possible usecase for Inline Classes would be complex numbers or matrix algebra, which is essential for neural networks algorithms of artificial intelligence systems.

Yates

its not inline anymore, its value – Casiecasilda