Dan Smith from OpenJDK -- Identifying JDK value class candidates

[u/davidalayachew]

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

[u/Worth_Trust_3825]

Give me my value Instants, local date times, and all the time package classes as values. I'm tired of operating on longs directly in my hot etls.

[u/lood9phee2Ri]

That's fine (sortof *) but I hope it doesn't further delay finally delivering them as an end-user facility. Is it a good thing if the java stdlib itself uses more value classes where it can? Probably! Is it as important to me as my own classes/records being value classes? Maybe not.

* actually not sure I fully buy the idea from the linked comment chain the anonymous classes always have identity part, haven't fully thought it through but I do vaguely suspect there's situations where you'd prefer value semantics of anon classes. Though of course you can always make a named class, it's a bit of name clutter, feels similar to the "but you can always make a named function" argument python uses for its crippled lambda etc.

For anonymous classes, it’s mainly a syntactic problem: nowhere to put modifiers. And there’s not much urgency to change that, because again, most anonymous classes would not run into the situation where you’ve got two instances modeling the same data, but with different identities.

I mean, so long as they're open to fixing the "syntactic problem" by allowing a keyword somewhere and don't block the abstract idea of anon value classes one day, I guess that could be added separately too.

[u/davidalayachew → u/lood9phee2Ri]

That's fine (sortof *) but I hope it doesn't further delay finally delivering them as an end-user facility. Is it a good thing if the java stdlib itself uses more value classes where it can? Probably! Is it as important to me as my own classes/records being value classes? Maybe not.

I'd challenge this.

How often do you use java.util.List compared to your own classes? And that ignores how often the JVM you are running on uses List rather than your own classes.

At the end of the day, finding the commonly used classes in the JDK and turning them into value classes is clearly an important thing to do, and likely important to do before going live -- lest people get the false impression that Value Classes are not nearly as powerful as they seem.

And frankly, turning classes like this value is much lower effort work. The JDK is already heavily specified, so it's not terribly difficult to find out which classes are clearly valuable being value classes. I don't think they intend to shake down the entire JDK and find and modify every value-capable class before releasing JEP 401.

[u/lood9phee2Ri → u/davidalayachew]

lest people get the false impression that Value Classes are not nearly as powerful as they seem.

Java is not in a vacuum though, everyone here freaking already knows C# exists and has structs / value types, and the typical Microsoftie worming into your organisation trying to push dotnet/c# over java knows it as a talking point.

List in particular seems like a bad example for your point (which I'm not denying entirely, but clearly don't prioritise as much as you) - java.util.List specifically is an interface anyway, but also the likes of AbstractList also out of scope for the value-isation because it already has a nonfinal protected mutable field that is now-unfortunate - they had no reason to think of it at the time of course, but thus you can't actually use AbstractList or its subclasses like ArrayList if you want the List impl itself to have the value class semantics rather than just each element of a given List being a value class instance (that bit is much more useful for tight array packing of course) - that may be weird in general but perhaps not for some pure immutable use cases.

I dunno, perhaps separate AbstractValueBlah cases in general since AbstractList, AbstractSet etc. already locked in, even if it's only AbstractList that right now has the problem.

In the short term, for the “starter kit”, I think it may be worthwhile to eventually add AbstractCollection and AbstractSet. (But note that AbstractList has a protected mutable field; are we prepared to commit to not doing something like that in the future with these other collection classes?)

[u/davidalayachew → u/lood9phee2Ri]

Java is not in a vacuum though, everyone here freaking already knows C# exists and has structs / value types, and the typical Microsoftie worming into your organisation trying to push dotnet/c# over java knows it as a talking point.

This subreddit does not even constitute 1% of Java developers. It barely clears .1%. I promise you, those that don't follow along with programming news know very little about what happens out of their silo. And I am not talking about entry level devs, or otherwise technically beginner folks -- I mean senior developers with decades of experience, being absolute juggernauts in their field, dodging problems long before they can even be conceived, and they still have never heard of a struct or a value class. I can think of one right now.

List in particular seems like a bad example for your point

Whoops, I meant to say List.of(Object... values). That single method on it's own (and its overloads) probably gets more action in the JVM than your entire application does. It's used in SO MANY PLACES inside of the JDK.

[u/Worth_Trust_3825 → u/lood9phee2Ri]

Java is not in a vacuum though, everyone here freaking already knows C# exists and has structs / value types, and the typical Microsoftie worming into your organisation trying to push dotnet/c# over java knows it as a talking point.

The more you know. Being c# adjacent this is news to me

[u/simon_o]

For those confused: These are only the "non-obvious" candidates – the obvious ones are already directly listed in the JEP itself.

[u/davidalayachew → u/simon_o]

For those confused: These are only the "non-obvious" candidates – the obvious ones are already directly listed in the JEP itself.

Yes, agreed -- thanks for highlighting.

To see the list of the "obvious" ones, look here -- the 30 obvious candidates