Hacker News Reader

Comment by geophile | Hacker News Reader

Are they ever going to release value types?

Adding values is a huge task because they are a big change at the VM, language, and library level. You can read about some of the latest plans in draft form at https://mail.openjdk.java.net/pipermail/valhalla-spec-expert....

Rest assured progress is being made.

Sounds like we won't have them in the next LTS, so probably another 5 years at least.

Next lts is 14 which is due in a year as I understand the new release schedule.

No, the next scheduled LTS will be 17. The idea is that 1 release every 3 years will be an LTS release.

I’m not sure what would happen if values landed in 18, it might be an important enough change for people to want break the LTS cadence.

The worst thing Oracle can do is deliver a bad feature. Java Gererics turn 15 this year. It's better to delay such a radical change than being stuck with it for the next few decades. Oracle is no hurry to do that. Maybe they get it together in time for the next LTS release (Java 14).

You can play with them today.

https://jdk.java.net/valhalla/

The engineering problem is that they want to keep old jars running on a world of value types.

I get Java needs it because some uses need the performance gain in terms of less ram and less pointer interdirection. I'm glad library authors of like servers or caches will be able to improve performance without weird things like unsafe byte buffers and native memory leaks.

I suspect I won't ever use value types in my code though unless it's drop in to refactor from AnyVal=>AnyRef (or w/e the java equiv is).

* Does accepting a value type parameter accept it by value or by ref? * How does this play with GC? Can I get dangling ref with value type? * How does value types play with inheritance e.g. will it be like c# and struct and they will be boxed any time treated as ref? * How safe will it be to convert a class from being value type based to Object (w/e AnyRef equiv is). Will I need to inspect all methods that deal it now?

This can probably just be resolved with a style guide like c++ can be mostly sane if you're starting a new project today with an aggressive style guide, but I just appreciated not think about this and just count on escape analysis + gc + hotspot tricks like monomorphize code paths with some counters to be good enough.

I share your frustration but this new GC should drastically reduce the issues with creating tons of garbage. There's still the infamous "allocation wall" but value types wouldn't solve that either. But they would make it a lot better

GC is only part of the issue. Value types allow much finer control over locality, something completely lacking in Java now. And without that, you give up a lot of performance.

For example: https://rcoh.me/posts/cache-oblivious-datastructures/

Yeah that was supposed to be in 12 wasn't it? Everyone is waiting for that, it will obsolete Lombok.

No feature is meant to be in a release. A feature will be done when it’s done, though features may be split so that some functionality can land earlier.

Data classes will reduce the need for Lombok/immutables. Less so for value types.

Still heavily a work in progress based on the in-flight commits getting sent to valhalla-dev@

Reply on news.ycombinator.com