3 ms·

Reportedly, not much "big new stuff" got into this release (maybe next time), but it's an LTS so it's not the best time for that anyway.

rickette 5y ago
Most products/projects I know are on Java 11 LTS and will probably upgrade to this release. Between 11 and 17 there's quite some new stuff.
tikkabhuna 5y ago
Can't remember where I heard it, but the thought was that "big stuff" was skipped in case it created bugs that then had to be maintained for the entire LTS support period.
- carimura 5y ago
  See my parallel comment on this philosophy. Also, it's likely we'll never see "really big stuff" in a single release as the 6-month cadence has made possible incremental changes to a larger vision. Case in point, see Project Amber [1]. [1] https://inside.java/tag/amber https://inside.java/tag/amber
gavinray 5y ago
A ton of huge stuff was in JDK 16 though, and seems most companies won't upgrade until LTS releases, so folks should be looking at JDK 17 as JDK 12-17 if they're in a corporate environment. Records, multiline strings, pattern matching for instanceof, handling nulls in pattern matching/switch, sealed classes/interfaces, probably other things I'm forgetting. I had never written Java before until recently, and thank god for JDK16 features. Only thing that made it slightly tolerable.
carimura 5y ago
The teams working on the JDK think about their work in 6-month release cycles, not LTS cycles. What's ready to go in when the train leaves the station, goes in, what's not, waits another 6 months. And this applies across the board for incremental changes coming from Amber, Loom, Valhalla, Panama, etc. The danger of thinking in LTS cycles is a feeling that a feature needs to be rushed to make it in, which might jeopardize the production-ready quality on Day 1 of GA. It's very important to us that the ecosystem can trust every release, in production, right out of the gate.
thinkharderdev 5y ago
The new FFM API looks really cool. Still incubating but having better native interop I think could really be a big win. Most developers will never touch that stuff but having the ability to manage native, off-heap memory and safely(ish) make native calls will be great.
- twic 5y ago
  I wrote an app which used JNI to call into C++ code. I ended up refactoring it to spawn subprocesses written in C++, and communicate with them via RPC. Not because JNI was difficult, but because errors in the C++ can take down the whole app otherwise. All the performance and ergonomics improvements in the world wouldn't persuade me to give up that safety barrier. Unless i rewrite the native parts in Rust, of course :).

rickette 5y ago

Most products/projects I know are on Java 11 LTS and will probably upgrade to this release. Between 11 and 17 there's quite some new stuff.

tikkabhuna 5y ago

Can't remember where I heard it, but the thought was that "big stuff" was skipped in case it created bugs that then had to be maintained for the entire LTS support period.

carimura 5y ago
See my parallel comment on this philosophy. Also, it's likely we'll never see "really big stuff" in a single release as the 6-month cadence has made possible incremental changes to a larger vision. Case in point, see Project Amber [1]. [1] https://inside.java/tag/amber https://inside.java/tag/amber

gavinray 5y ago

A ton of huge stuff was in JDK 16 though, and seems most companies won't upgrade until LTS releases, so folks should be looking at JDK 17 as JDK 12-17 if they're in a corporate environment. Records, multiline strings, pattern matching for instanceof, handling nulls in pattern matching/switch, sealed classes/interfaces, probably other things I'm forgetting. I had never written Java before until recently, and thank god for JDK16 features. Only thing that made it slightly tolerable.

carimura 5y ago

The teams working on the JDK think about their work in 6-month release cycles, not LTS cycles. What's ready to go in when the train leaves the station, goes in, what's not, waits another 6 months. And this applies across the board for incremental changes coming from Amber, Loom, Valhalla, Panama, etc. The danger of thinking in LTS cycles is a feeling that a feature needs to be rushed to make it in, which might jeopardize the production-ready quality on Day 1 of GA. It's very important to us that the ecosystem can trust every release, in production, right out of the gate.

thinkharderdev 5y ago

The new FFM API looks really cool. Still incubating but having better native interop I think could really be a big win. Most developers will never touch that stuff but having the ability to manage native, off-heap memory and safely(ish) make native calls will be great.

twic 5y ago
I wrote an app which used JNI to call into C++ code. I ended up refactoring it to spawn subprocesses written in C++, and communicate with them via RPC. Not because JNI was difficult, but because errors in the C++ can take down the whole app otherwise. All the performance and ergonomics improvements in the world wouldn't persuade me to give up that safety barrier. Unless i rewrite the native parts in Rust, of course :).