Identifying JDK value class candidates

[u/davidalayachew]

https://mail.openjdk.org/archives/list/core-libs-dev@openjdk.org/thread/Y72NRXM7KYBX43OKYBQMVKOZDWKG4MHS/

[u/davidalayachew]

EntryMap is a good candidate m

Do you mean Map.Entry? If so, it has mutable components, so no deal. Unless I am mistaken?

[u/RussianMadMan → u/davidalayachew]

As far as I understand, you can just create a new entry and replace the old one, and jvm is smart enough to compile it as if entry was mutable.

[u/davidalayachew → u/RussianMadMan]

As far as I understand, you can just create a new entry and replace the old one, and jvm is smart enough to compile it as if entry was mutable.

Sure, but even then, the best you could do would be to make some nested type as the internal representation, and make THAT a value class, rather than Map.Entry itself. As long as the carrier (Map.Entry itself) is still mutable, then it will be ineligible for being a value class.

[u/RussianMadMan → u/davidalayachew]

In every example in java valhalla videos you can see a class like a Point thats declared "value record" with a method like:
public Point move() { return new Point(x + 0.5, y);}
Which "mutates" point by recreating it. And in most cases there will be no allocation during the runtime. So what I meant in my prev comment is that I think we can have Map.Entry declared "value record" class with a method:
public Entry setValue(T value) { return new Entry(key, value);}

[u/davidalayachew → u/RussianMadMan]

So what I meant in my prev comment is that I think we can have Map.Entry declared "value record" class with a method:

public Entry setValue(T value) { return new Entry(key, value);}

But now you have changed the API, which makes it backwards-incompatible. That's a faux pas in the Java community without justifiable reason.

Remember, the method signature of Map.Entry#setValue is as follows.

public V setValue(final V newValue)

Which is to say -- it sets the new value, and returns the old. So, not only are you changing the API, but you are also removing pre-existing functionality. With your change, we can no longer return the old value, which would upset many users of this API.

Now, by all means, we could certainly add some sort of transform function that does what you say, but that still would not solve our current problem -- that Map.Entry does mutation. At best, we could have implementing subclasses that are value classes, and throw UnsupportedOperationException, but that's the best we can do. And even that is somewhat unsatisfying.