4 ms·

Are they ever going to release value types?

by geophile 8y ago

MrBuddyCasino 8y ago
Yeah that was supposed to be in 12 wasn't it? Everyone is waiting for that, it will obsolete Lombok.
- debug-desperado 8y ago
  Data classes will reduce the need for Lombok/immutables. Less so for value types.
- aardvark179 8y ago
  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.
aardvark179 8y ago
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-experts/2019-March/000897.html https://mail.openjdk.java.net/pipermail/valhalla-spec-expert.... Rest assured progress is being made.
- vbezhenar 8y ago
  Sounds like we won't have them in the next LTS, so probably another 5 years at least.
  - chvid 8y ago
    Next lts is 14 which is due in a year as I understand the new release schedule.
    - aardvark179 8y ago
      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.
samus 8y ago
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).
plandis 8y ago
Still heavily a work in progress based on the in-flight commits getting sent to valhalla-dev@
pjmlp 8y ago
You can play with them today. https://jdk.java.net/valhalla/ https://jdk.java.net/valhalla/ The engineering problem is that they want to keep old jars running on a world of value types.
spricket 8y ago
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
- geophile 8y ago
  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/ https://rcoh.me/posts/cache-oblivious-datastructures/
potatosareok 8y ago
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.

Are they ever going to release value types?

MrBuddyCasino 8y ago

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

debug-desperado 8y ago
Data classes will reduce the need for Lombok/immutables. Less so for value types.
aardvark179 8y ago
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.

aardvark179 8y ago

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-experts/2019-March/000897.html https://mail.openjdk.java.net/pipermail/valhalla-spec-expert.... Rest assured progress is being made.

vbezhenar 8y ago
Sounds like we won't have them in the next LTS, so probably another 5 years at least.
- chvid 8y ago
  Next lts is 14 which is due in a year as I understand the new release schedule.
  - aardvark179 8y ago
    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.

samus 8y ago

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).

plandis 8y ago

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

pjmlp 8y ago

You can play with them today. https://jdk.java.net/valhalla/ https://jdk.java.net/valhalla/ The engineering problem is that they want to keep old jars running on a world of value types.

spricket 8y ago

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

geophile 8y ago
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/ https://rcoh.me/posts/cache-oblivious-datastructures/

potatosareok 8y ago

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.