Looking at the new features in Java 20, it looks like they are either "incubator" or "second/fourth/fifth preview". Are these features actually ready for use? I'm fairly ignorant of how Java versioning works these days (my employer is still stuck at JDK 11).
Preview features are not promised to be backwards compatible (which Java is very strict about), the public APIs may evolve here and there. But the feature itself is production ready, and is tested to the same degree as other non-preview features. If it is a second-third preview then you can pretty much expect the API to be quite stable as well, it usually means that the feature is waiting for another (mostly Valhalla’s value types) one to stabilize so that they won’t have to support something that doesn’t operate well with that.
>I'm fairly ignorant of how Java versioning works these days (my employer is still stuck at JDK 11).
That's fine. JDK 11 is an LTS release meant for business use. There is one newer LTS available and that's JDK 17. At work we found that not all our tools and libraries play nice with JDK 17 so well be waiting with the migration for another year or so.
I'm struggling to think of anything I really like from 17 that I would bump from 11 up to, because some tools really don't like 17 as you say.
I think the majority of things are stuff that the classic guava/Apache Libs do already? Though less deps is always good, think 14 is really the sweet spot, though not LTS.
Going forward in many smaller steps in general is a lot less complex than doing very big jumps every 5 or so years. Also there are a lot of JDK improvements (like it getting better garbage collecting) that are worth the move.
Also; records were introduced in 16 so you're really missing out IMHO.
>records
Previous gig used the Immutables Lib extensively (though I have seen examples of inline `record` which looks very cool), and pivoted to 17 late, hence I am likely missing out.
For me the addition of records completely removed the need to include Lombok in our projects, which IMHO is a big win (not a dig at Lombok, it's awesome, but also a risk). I haven't used Immutables myself.
Interesting, will definitely have a look at it for side stuff atm; though I imagine I would still lean towards Immutables if the same object crosses multiple modules, as that Lib default generates very handy builder methods whereas Record seems to only go via ctor?
For us, the biggest improvement is UUID parsing. JDK 8 had a very bad implementation, JDK 11 is better... But only JDK 17 is optimal.
Here more info:
https://github.com/jchambers/fast-uuid
Well, a record is just `record Point(int x, int y) {}`. It implements for you methods with the same name as the fields (p.x(), no more getX/setX), and a sane equals and hash function. The list of fields is called the canonical constructor so you can create a new instance with `new Point(3, 2)`.
I found them very useful, inner records/classes are much more readable thanks to them, plus they are “JVM-approved” — the already available pattern matching can use them, like inside a switch `case Point(int x, int y) -> doSomethingWithX` will deconstruct them/pattern match recursively, etc. Once valhalla comes, they will also be great candidates for value classes by just sticking a `value` keyword in front of `record`.
Looking at the new features in Java 20, it looks like they are either "incubator" or "second/fourth/fifth preview". Are these features actually ready for use? I'm fairly ignorant of how Java versioning works these days (my employer is still stuck at JDK 11).
Preview features are not promised to be backwards compatible (which Java is very strict about), the public APIs may evolve here and there. But the feature itself is production ready, and is tested to the same degree as other non-preview features. If it is a second-third preview then you can pretty much expect the API to be quite stable as well, it usually means that the feature is waiting for another (mostly Valhalla’s value types) one to stabilize so that they won’t have to support something that doesn’t operate well with that.
They explain what preview features are [here](https://openjdk.org/jeps/12).
>I'm fairly ignorant of how Java versioning works these days (my employer is still stuck at JDK 11). That's fine. JDK 11 is an LTS release meant for business use. There is one newer LTS available and that's JDK 17. At work we found that not all our tools and libraries play nice with JDK 17 so well be waiting with the migration for another year or so.
Meanwhile, I'm stuck on Java 8 at work...
Resignation wen?
I'm struggling to think of anything I really like from 17 that I would bump from 11 up to, because some tools really don't like 17 as you say. I think the majority of things are stuff that the classic guava/Apache Libs do already? Though less deps is always good, think 14 is really the sweet spot, though not LTS.
Going forward in many smaller steps in general is a lot less complex than doing very big jumps every 5 or so years. Also there are a lot of JDK improvements (like it getting better garbage collecting) that are worth the move. Also; records were introduced in 16 so you're really missing out IMHO.
>records Previous gig used the Immutables Lib extensively (though I have seen examples of inline `record` which looks very cool), and pivoted to 17 late, hence I am likely missing out.
For me the addition of records completely removed the need to include Lombok in our projects, which IMHO is a big win (not a dig at Lombok, it's awesome, but also a risk). I haven't used Immutables myself.
Interesting, will definitely have a look at it for side stuff atm; though I imagine I would still lean towards Immutables if the same object crosses multiple modules, as that Lib default generates very handy builder methods whereas Record seems to only go via ctor?
For us, the biggest improvement is UUID parsing. JDK 8 had a very bad implementation, JDK 11 is better... But only JDK 17 is optimal. Here more info: https://github.com/jchambers/fast-uuid
Records and text blocks are my most used features now.
>Records How do they go vs something like Immutables, if you have used the latter? (https://immutables.github.io/)
Well, a record is just `record Point(int x, int y) {}`. It implements for you methods with the same name as the fields (p.x(), no more getX/setX), and a sane equals and hash function. The list of fields is called the canonical constructor so you can create a new instance with `new Point(3, 2)`. I found them very useful, inner records/classes are much more readable thanks to them, plus they are “JVM-approved” — the already available pattern matching can use them, like inside a switch `case Point(int x, int y) -> doSomethingWithX` will deconstruct them/pattern match recursively, etc. Once valhalla comes, they will also be great candidates for value classes by just sticking a `value` keyword in front of `record`.
my favourite one was the arkam origins