Java 17 / JDK 17: General Availability • Hacker News Board

Re: Java 17 / JDK 17: General Availability

#21

Post by gavinray » Tue, Sep 14, 2021, 2:53 PM UTC

gjsman-1000 wrote: post #3

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.

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.

Re: Java 17 / JDK 17: General Availability

#22

Post by hocuspocus » Tue, Sep 14, 2021, 2:54 PM UTC

codetrotter wrote: post #16

bcrosby95 wrote: post #11

Earlier quoted context omitted.

They have a 6 month release cadence.

2021.0, 2021.5, 2022.0, … :^)

They tried for a short while (I think Java 10 was supposed to be 18.3) but stuck to incrementing major versions after all.

Re: Java 17 / JDK 17: General Availability

#23

Post by avodonosov » Tue, Sep 14, 2021, 2:54 PM UTC

I am skeptical about the "strong encapsulation" and in general, of all cases whey people tell me about something: "you don't need it, it's better for you to do it other way".

Usually I know better what I need. There were cases when I needed to access the internals, e.g. fixing a prod issue.

A quote from Thinking Forth comes to mind:

> The newest traditional languages (such as Modula 2) bend over backwards to ensure that modules hide internal routines and data structures from other modules. The goal is to achieve module independence (a minimum coupling). The fear seems to be that modules strive to attack each other like alien antibodies. Or else, that evil bands of marauding modules are out to clobber the precious family data structures.

> This is not what we’re concerned about. The purpose of hiding information, as we mean it, is simply to minimize the effects of a possible design-change by localizing things that might change within each component.

Re: Java 17 / JDK 17: General Availability

#24

Post by shadycuz » Tue, Sep 14, 2021, 2:54 PM UTC

jsiepkes wrote: post #8

shadycuz wrote: post #4

If only I could understand the difference between java 1.8, 8 and 18.

Starting from 1.6 they only showed the minor version number. So 1.6 = Java 6, 1.8 = Java 8, etc. I always assumed this was because .net (arguably it's main competitor) was churning fast through version numbers and they "wanted to keep up".

Ahh so 17, is 1.17?

I swear I googled this like 2 months ago and the first 2 or 3 links weren't helpful so I gave up. Thanks!

Re: Java 17 / JDK 17: General Availability

#25

Post by zokier » Tue, Sep 14, 2021, 2:54 PM UTC

deepsun wrote: post #7

Are they going to introduce zero-cost structs? Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer).

> Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer).

That is not correct. Trivial counterexample:

https://play.rust-lang.org/?version=stable&mode=debug&editio...

prints

    4
    8

i.e. Option is 4 bytes larger than plain T

Re: Java 17 / JDK 17: General Availability

#26

Post by hyperpape » Tue, Sep 14, 2021, 2:54 PM UTC

geophile wrote: post #18

vips7L wrote: post #12

Earlier quoted context omitted.

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

I haven't been following it incredibly closely, but I have checked in from time to time. It's a hard problem, but there's a lot of real progress (https://github.com/openjdk/valhalla-docs/blob/main/site/desi...).

I'd wager that it will ship by the next LTS, in 2024.

Re: Java 17 / JDK 17: General Availability

#27

Post by zokier » Tue, Sep 14, 2021, 2:55 PM UTC

geophile wrote: post #18

vips7L wrote: post #12

Earlier quoted context omitted.

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

> This is such an important thing to add to Java, and it seems to be perpetually off the stove, not even on the back burner.

Valhalla is being actively worked on, I'm not sure what you are implying here.

Re: Java 17 / JDK 17: General Availability

#28

Post by pjmlp » Tue, Sep 14, 2021, 2:57 PM UTC

ducktective wrote: post #13

Any news on JavaFX? I know it's developed independently but is it an even option beside Qt, Electron, etc..?

Yes, now Gluon is driving it.

https://openjfx.io/

Re: Java 17 / JDK 17: General Availability

#29

Post by CodeIsTheEnd » Tue, Sep 14, 2021, 2:57 PM UTC

deepsun wrote: post #7

Are they going to introduce zero-cost structs? Kinda like Rust guarantees that Option has the same size as T (aka free like in free beer).

A clarification: Rust only makes this guarantee for certain types[1] which you would expect to be represented by a simple pointer under the hood (e.g., Box, &T, function pointers) and for other types which can never be all 0.

Making this optimization for something like Option is, naturally, impossible.

(I assume you are aware of this and were implicitly referring to this optimization.)

[1]: https://doc.rust-lang.org/std/option/#representation

Re: Java 17 / JDK 17: General Availability

#30

Post by pjmlp » Tue, Sep 14, 2021, 2:58 PM UTC

geophile wrote: post #18

vips7L wrote: post #12

Earlier quoted context omitted.

Primitive classes are being worked on in Project Valhalla.

I think this statement has been true since about 2014. Structs are nice, as they allow for control over locality, to a degree that is simply not possible in Java currently. But there is a second effect, which is possibly more important: If I can move gigabytes of my data into arrays of structs, then 1) I greatly reduce memory requirements (far fewer pointers), and 2) I greatly reduce the amount of work that GC has to…

Because they don't want to do a Python move, and those compiled JARs from 2000 should keep working as much as possible on a Valhala aware JVM.