7 ms·

On its own, the features specifically for Java 17 aren't obviously that compelling, but the important thing is that Java 17 is an LTS, the last one of which was

On its own, the features specifically for Java 17 aren't obviously that compelling, but the important thing is that Java 17 is an LTS, the last one of which was Java 11, 3 years ago. Since many organizations, including mine, stick to LTS releases, that means a lot of developers will get a big change in what they can do sometime in the next few months as they upgrade to the LTS. Among other things, this means that we can begin to use records, pattern matching for instanceof, the shenendoah GC, and more. Links to JEPs for the other releases. http://openjdk.java.net/projects/jdk/16/ http://openjdk.java.net/projects/jdk/16/ http://openjdk.java.net/projects/jdk/15/ http://openjdk.java.net/projects/jdk/15/ http://openjdk.java.net/projects/jdk/14/ http://openjdk.java.net/projects/jdk/14/ http://openjdk.java.net/projects/jdk/13/ http://openjdk.java.net/projects/jdk/13/ http://openjdk.java.net/projects/jdk/12/ http://openjdk.java.net/projects/jdk/12/

mreinhold 5y ago
Comprehensive list of all JEPs integrated since JDK 11: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11 https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11
- mabbo 5y ago
  > Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.
  - hashmash 5y ago
    I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.
    - cupofjoakim 5y ago
      I work as a systems developer for a bank and records is an easy replacement for a very popular dependency called lombok. Now, records doesn't necessarily do everything that lombok does, but for us it replaces what we actually need. One less dependency and I'm a happy camper.
      - renw0rp 5y ago
        I think it's worth highlighting that while Lombok is a dependency it is only a compile time dependency (it's not part of the output JAR).
        kjeetgill 5y ago
        You say only, but I find that to be much more fussy.
        jsight 5y ago
        Exactly, I hate dealing with Lombok projects for that reason. I'd rather the cruft than the compiler add-on.
        oauea 5y ago
        Do you not just use maven? Any of the major IDEs will automatically configure annotation processors for you when they're configured in your pom. Similar for gradle.
        jsight 5y ago
        Its been a while since I have had to deal with one, but at the time the IDE didn't handle it well at all. I think it was because I was missing the Lombok plugin. TBH, it was a lot of trouble so that someone could avoid generating a couple of getters and setters, and could use a annotation to setup the logger. I realize that there are more features available than that, but the ones that I've seen often used it in such mundane and boring ways that the setup wasn't worth the hassle for me. But I guess we all get annoyed with minor hassles in different ways. I got annoyed with the hassle of setting up an IDE, they got annoyed with getters and setters more. :)
  - foolfoolz 5y ago
    a lot of these were the killer feature of scala that separated it from other languages
- mopierotti 5y ago
  Here's another similar summary, but with code examples and categories. https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-16/ https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
- suyash 5y ago
  if you're coming from Java 8, here is a comprehensive list of new features since then https://ondro.inginea.eu/index.php/new-features-in-java-versions-since-java-8/ https://ondro.inginea.eu/index.php/new-features-in-java-vers...
shellac 5y ago
> the important thing is that Java 17 is an LTS That's not _strictly_ true. Java 17 is a release of the reference implementation, but there are a number of distributions from a variety of vendors. Oracle are going to provide long term support for their distribution, and it sounds like many will follow their lead. (If you are going to provide LTS it would be a little perverse to be out of sync with other providers of the same software) So, for all practical purposes, it is an LTS. But check with your vendor.
- dtech 5y ago
  This is a bit pedantic. All relevant JDK distributors follow Oracle's LTS versioning scheme.
- stingraycharles 5y ago
  I just checked but Oracle, OpenJDK, Azul, and Amazon are all going to consider 17 an LTS. So it seems like a reasonable assumption.
- jlengrand 5y ago
  Do you know of any vendor for which 17 isn't considered an LTS? Genuinely curious
  - brunoborges 5y ago
    Ubuntu's, Alpine's, Debian's, and any Linux distribution that builds and ships OpenJDK from the source (except Red Hat's, of course). Yes, these are "distributions" (binaries) of OpenJDK that do not provide any sort of support, and clearly no LTS flag to them.
    - tcmart14 5y ago
      Yes and no. Debian's repos provide binaries for multiple version though. Since 11 has been about, Debian testing has always had OpenJDK11 and then of course binaries for newer versions. So they do ship the LTS, you just need to specify the version number, openjdk-11-jdk. They don't tag it as LTS in the package name, but someone who is using java professionally probably knows openjdk-11 is the LTS implementation.
cmckn 5y ago
This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.
- pgwhalen 5y ago
  You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.
  - cmckn 5y ago
    “Some” as in dozens (for my apps, at least). It’s a solution, but not a great one. The projects I depend on will have to remove such usages eventually to avoid awful UX (and avoid punching holes in encapsulation).
    - pgwhalen 5y ago
      > The projects I depend on will have to remove such usages eventually to avoid awful UX This seems like exactly the intended effect to me.
    - samus 5y ago
      For server application, this is a one-time administration effort. If you are concerned about `--illegal-access=allow`: yes, you should strive to get rid of it before security auditors blow an artery because of it. Desktop applications are usually not delivered as bare JARs, but with wrapper binaries or scripts, where such flags are supposed to go.
- ragnese 5y ago
  I must have missed this topic. What are these encapsulation loopholes that are being closed?
  - jmiserez 5y ago
macspoofing 5y ago
>the last one of which was Java 11, 3 years ago. Extended support still behind Java 8 =) I suspect Java 8 will be with us for a long long time.
Zardoz84 5y ago
Laughs because we just change to Java 8.
shepherdjerred 5y ago
There are so many good features from the last LTS (11) to now. Some of my favorite languages are Swift and TypeScript because of how natural the syntax feels. Java is finally getting close to that level of flexibility with JDK 17.
gunnarmorling 5y ago
I've compiled a Twitter thread with some of the key features new since Java 11 over the last few days: https://twitter.com/gunnarmorling/status/1434443970411704324 https://twitter.com/gunnarmorling/status/1434443970411704324. Also includes some links to related blog posts. Perhaps interesting for some to get a quick overview what you'll get with 17 when coming from 11.
- aembleton 5y ago
  Here's the Thread Reader link: https://threadreaderapp.com/thread/1434443970411704324.html https://threadreaderapp.com/thread/1434443970411704324.html
excerionsforte 5y ago
You also get better NullPointerException messages, which to me have been super helpful during development. https://openjdk.java.net/jeps/358 https://openjdk.java.net/jeps/358

mreinhold 5y ago

Comprehensive list of all JEPs integrated since JDK 11: https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11 https://openjdk.java.net/projects/jdk/17/jeps-since-jdk-11

mabbo 5y ago
> Language > Pattern Matching for instanceof (16) > Records (16) > Restore Always-Strict Floating-Point Semantics (17) > Sealed Classes (17) > Switch Expressions (14) > Text Blocks (15) This is what excites me. Records, switch expressions and sealed classes are all excellent and even better together. Along with pattern matching switch statements, Java is finally losing a lot of cruft people complain about.
- hashmash 5y ago
  I'm trying to find a good use case for records, but the best I can come up with is using it for composite hashmap keys. I suppose when combined with sealed classes and pattern matching features at some point it might be more useful, but what is the main use for records right now? Given that they're immutable and have no convenient way to be copied when modified, I find them quite tedious to use.
  - cupofjoakim 5y ago
    I work as a systems developer for a bank and records is an easy replacement for a very popular dependency called lombok. Now, records doesn't necessarily do everything that lombok does, but for us it replaces what we actually need. One less dependency and I'm a happy camper.
    - renw0rp 5y ago
      I think it's worth highlighting that while Lombok is a dependency it is only a compile time dependency (it's not part of the output JAR).
      - kjeetgill 5y ago
        You say only, but I find that to be much more fussy.
        jsight 5y ago
        Exactly, I hate dealing with Lombok projects for that reason. I'd rather the cruft than the compiler add-on.
        oauea 5y ago
        Do you not just use maven? Any of the major IDEs will automatically configure annotation processors for you when they're configured in your pom. Similar for gradle.
        jsight 5y ago
        Its been a while since I have had to deal with one, but at the time the IDE didn't handle it well at all. I think it was because I was missing the Lombok plugin. TBH, it was a lot of trouble so that someone could avoid generating a couple of getters and setters, and could use a annotation to setup the logger. I realize that there are more features available than that, but the ones that I've seen often used it in such mundane and boring ways that the setup wasn't worth the hassle for me. But I guess we all get annoyed with minor hassles in different ways. I got annoyed with the hassle of setting up an IDE, they got annoyed with getters and setters more. :)
- foolfoolz 5y ago
  a lot of these were the killer feature of scala that separated it from other languages
mopierotti 5y ago
Here's another similar summary, but with code examples and categories. https://advancedweb.hu/a-categorized-list-of-all-java-and-jvm-features-since-jdk-8-to-16/ https://advancedweb.hu/a-categorized-list-of-all-java-and-jv...
suyash 5y ago
if you're coming from Java 8, here is a comprehensive list of new features since then https://ondro.inginea.eu/index.php/new-features-in-java-versions-since-java-8/ https://ondro.inginea.eu/index.php/new-features-in-java-vers...

shellac 5y ago

> the important thing is that Java 17 is an LTS That's not _strictly_ true. Java 17 is a release of the reference implementation, but there are a number of distributions from a variety of vendors. Oracle are going to provide long term support for their distribution, and it sounds like many will follow their lead. (If you are going to provide LTS it would be a little perverse to be out of sync with other providers of the same software) So, for all practical purposes, it is an LTS. But check with your vendor.

dtech 5y ago
This is a bit pedantic. All relevant JDK distributors follow Oracle's LTS versioning scheme.
stingraycharles 5y ago
I just checked but Oracle, OpenJDK, Azul, and Amazon are all going to consider 17 an LTS. So it seems like a reasonable assumption.
jlengrand 5y ago
Do you know of any vendor for which 17 isn't considered an LTS? Genuinely curious
- brunoborges 5y ago
  Ubuntu's, Alpine's, Debian's, and any Linux distribution that builds and ships OpenJDK from the source (except Red Hat's, of course). Yes, these are "distributions" (binaries) of OpenJDK that do not provide any sort of support, and clearly no LTS flag to them.
  - tcmart14 5y ago
    Yes and no. Debian's repos provide binaries for multiple version though. Since 11 has been about, Debian testing has always had OpenJDK11 and then of course binaries for newer versions. So they do ship the LTS, you just need to specify the version number, openjdk-11-jdk. They don't tag it as LTS in the package name, but someone who is using java professionally probably knows openjdk-11 is the LTS implementation.

cmckn 5y ago

This also brings some big gotchas, such as the closing of encapsulation loopholes. Unsafe code and various hacks calling into the JDK will break a lot of programs; so you might be stuck on 11 if you use HBase, Spark, etc.

pgwhalen 5y ago
You won’t be stuck, you just need to add some command line flags when running your application, as a way of acknowledging these packages are breaking encapsulation.
- cmckn 5y ago
  “Some” as in dozens (for my apps, at least). It’s a solution, but not a great one. The projects I depend on will have to remove such usages eventually to avoid awful UX (and avoid punching holes in encapsulation).
  - pgwhalen 5y ago
    > The projects I depend on will have to remove such usages eventually to avoid awful UX This seems like exactly the intended effect to me.
  - samus 5y ago
    For server application, this is a one-time administration effort. If you are concerned about `--illegal-access=allow`: yes, you should strive to get rid of it before security auditors blow an artery because of it. Desktop applications are usually not delivered as bare JARs, but with wrapper binaries or scripts, where such flags are supposed to go.
ragnese 5y ago
I must have missed this topic. What are these encapsulation loopholes that are being closed?
- jmiserez 5y ago

macspoofing 5y ago

>the last one of which was Java 11, 3 years ago. Extended support still behind Java 8 =) I suspect Java 8 will be with us for a long long time.

Zardoz84 5y ago

Laughs because we just change to Java 8.

shepherdjerred 5y ago

There are so many good features from the last LTS (11) to now. Some of my favorite languages are Swift and TypeScript because of how natural the syntax feels. Java is finally getting close to that level of flexibility with JDK 17.

gunnarmorling 5y ago

I've compiled a Twitter thread with some of the key features new since Java 11 over the last few days: https://twitter.com/gunnarmorling/status/1434443970411704324 https://twitter.com/gunnarmorling/status/1434443970411704324. Also includes some links to related blog posts. Perhaps interesting for some to get a quick overview what you'll get with 17 when coming from 11.

aembleton 5y ago
Here's the Thread Reader link: https://threadreaderapp.com/thread/1434443970411704324.html https://threadreaderapp.com/thread/1434443970411704324.html

excerionsforte 5y ago

You also get better NullPointerException messages, which to me have been super helpful during development. https://openjdk.java.net/jeps/358 https://openjdk.java.net/jeps/358