6 ms·

Java 14 GA

152 points by koozz 7y ago

commandlinefan 7y ago
Wow, I'm still using JDK 1.8. I thought I was way behind until I looked up the release schedule: apparently they're pushing out two (major) releases a year now.
- chungy 7y ago
  Yep, the new rapid-release schedule. Java 8 (grandfathered) and 11 are the current LTS branches, both of which cease getting any kind of support (read: security fixes) in 2024. Java 17 will be the next LTS.
  - snazz 7y ago
    It seems to be a trend in software that has existed for a while to exponentially increase version numbers (see also: Firefox).
    - chrisseaton 7y ago
      Exponential would be if they kept getting quicker. They've only gotten quicker once.
    - the8472 7y ago
      It's a quite linear growth, not exponential
      - snazz 7y ago
        But the first few numbers went by much more slowly, right?
    - rmrfrmrf 7y ago
      I assumed that this was due to more products dropping vanity versioning in favor of semantic versioning. Is that not what's happening here?
- TravelPiglet 7y ago
  Well, Java 8 was released 6 years ago and is basically EOL now. We migrated to Java 11 during the fall and finally most third party libraries we use seems to work fully in Java 11.
  - vbezhenar 7y ago
    Azul will provide free OpenJDK builds for Java 8 until March 2026. It's not EOL.
    - topspin 7y ago
      Amazon provides Corretto 8 maintenance until 2023 as well. It's been a drop in replacement for everything I've needed. 11 is the correct go-to version now. The small but high value language improvements definitely make it worthwhile.
- p2detar 7y ago
  Yeah, although depending on what you’re working on, you’d probably be interested mainly in the LTS releases. We’re bundling an OpenJDK 11 with our product and while I’ll definitely play around with v14, I think we’ll only upgrade once v17 LTS is out.
  - vbezhenar 7y ago
    Why would you want to use OpenJDK 11 instead of 13/14? I'm using 8 because it's the latest version working with Windows XP, but other than that, I don't understand why would anyone avoid latest stable version.
    - enitihas 7y ago
      OpenJDK 11 is a LTS release, 13/14 are not.
      - vbezhenar 7y ago
        That's not really an answer. I understand that some people want to freeze in time and having problems jumping from 11 to 17 version, but I don't understand why do they want that. Is there any compatibility issues preventing use of Java 13, for example? I understand that migration path for Java 9 was not very clear because of modules, but that's not the case for Java 11.
        ww520 7y ago
        LTS version is like a checkpoint. Its support will be long term, i.e. security patches will be released on them. The versions in between don't get support.
        StreamBright 7y ago
        I guess you do not work in an enterprise environment. There are many reasons to use LTS releases, stability and security comes to my mind first. 3rd party requirements are also important in this topic.
        7y ago
- pjmlp 7y ago
  Well, you are still up to date in what concerns Android Java, in fact more than what Android Java supports. https://developer.android.com/studio/preview/features?hl=ru#j8-desugar https://developer.android.com/studio/preview/features?hl=ru#...
- DannyB2 7y ago
  If you upgrade, jump directly to Java 11. That may or may not be easy. But it was easy for me. After that there was no effort to upgrade to all subsequent versions, to this point.
  - jghn 7y ago
    If one is using OpenJDK is there any reason not to track the versions > 11 as they come out, short of the usual reticence to upgrading?
    - DannyB2 7y ago
      Each upgrade after 11 has had good reasons to upgrade. More and more Java source language features that make your life easier by small incremental bits in each upgrade.
- pron 7y ago
  They're not major releases; in fact, the last major Java release ever was 9. The way releases used to work for the past ten years or so was that after a major release, every couple of months there would be a bugfix/security patch, and every six months (for a year or more) there would be a feature release (that used to be called "limited update") with major new features (new GCs, new monitoring mechanisms etc.) but without spec changes to the language and libraries. This meant that all the changes that required changing the spec had to wait for the major release. This had several bad implications. Most if not all of the spec changes were no more disruptive than the changes in the feature releases, but they had to wait for the next major release -- a lot of changes delivered at once created an overall fairly large disruption. Also the major release had to wait for the large features, and people couldn't enjoy smaller ones. Finally, people wanted to get their changes into the next major release so they wouldn't have to wait another three years or more, so features were merged before they were fully tested, which meant that the .0 major release was noticeably less stable. So, to make the upgrade process easier and cheaper, Java got rid of the major releases, allowed making spec changes in the feature releases, and, with the major releases gone, every feature release gets a new integer name. The result is a much more gradual process. Every feature release is about as big and only slightly more disruptive than the old feature releases. The releases are now much more stable because features are merged only when they're mature enough; there's no rush because if you miss a release, there's another in six months. The ecosystem will take some years to adjust, but those who've made the transition to running in production on the current release (many still can't, as some tools haven't yet adjusted) report a smooth process.
  - derriz 7y ago
    You make it sound like the upgrading process is something to be savoured when for many it's the opposite. Upgrading a code base because of language evolution is pure cost for most people. It's a relatively risky and almost zero-reward exercise for mature applications. You've got 3rd party library/dependency drag, tooling drag (everything from IDEs to CI/CD pipelines), development effort for code changes or QA and testing resources. Your engineers have to invest time in learning about the language and library changes. Never mind that unless you do a total rewrite, you end up with an incoherent code base which mixes old and new styles. All this busy work/effort could instead be applied to adding features, eliminating bugs, improving performance, etc. - changes that end-users actually appreciate or that add business value. Java conquered the enterprise precisely because it was slow moving and stable and offered unparalleled backward compatibility. Pretty much, the very same reasons Microsoft windows conquered the business world. This is (was) Java's strength not the weakness you portray. Let's face it, at this stage Java is never going to be "cool" again the way it was in the 90s. Trying to join the "move fast and break things" school of language evolution just makes it look like a middle aged person (I'm one btw) trying to be "hip" by emulating young teenagers in dress and speech. At the same time you're alienating your existing users.
- heelix 7y ago
  Java 7, 8, and 11 are the Long Term Release (LTS) versions, that are getting patched every 90 days. Support to 2025'ish for them. With 9+, all the other versions get a 6 month life span, with new features in each and heavy deprecation/dropping of older bits with each short term cut. 9+ is fairly backward compatible with each other. 8 to 9 required a bit of finesse for things like JAXB and other things dropped from the 'core' into external libraries. At least our shop made it to JDK 11. Next LTS version is 17, which is a while out.
- animalnewbie 7y ago
  By your nomenclature this is java 1.14
koozz 7y ago
New features already discussed in https://news.ycombinator.com/item?id=22477629 https://news.ycombinator.com/item?id=22477629, but now it's GA.
whateveracct 7y ago
> Remove the Concurrent Mark Sweep (CMS) Garbage Collector pour one out for the legend
tofflos 7y ago
When are the Alpine builds getting GA status? The last release of Java to include a build for Alpine was Java 8. Ever since then the Alpine builds have been restricted to early access releases. In the meantime Microsoft has started providing officially supported Alpine builds for .NET Core.
- _old_dude_ 7y ago
  At least, Azul provides Alpine builds. Maybe other OpenJDK distribs too, i don't know ?
120bits 7y ago
I have done much Java since I moved to full time Python/Node/Go. Guess I should give a try now. The Helpful NullPointerException is certainly a exciting feature.
deleted 7y ago
[deleted]
zikani_03 7y ago
Great news, although I know it's gonna be a while before it's a smooth transition to this version - definitely going to push for atleast one of our systems. Some features we needed in this one. e.g. helpful NPE messages

152 points by koozz 7y ago

Wow, I'm still using JDK 1.8. I thought I was way behind until I looked up the release schedule: apparently they're pushing out two (major) releases a year now.

chungy 7y ago
Yep, the new rapid-release schedule. Java 8 (grandfathered) and 11 are the current LTS branches, both of which cease getting any kind of support (read: security fixes) in 2024. Java 17 will be the next LTS.
- snazz 7y ago
  It seems to be a trend in software that has existed for a while to exponentially increase version numbers (see also: Firefox).
  - chrisseaton 7y ago
    Exponential would be if they kept getting quicker. They've only gotten quicker once.
  - the8472 7y ago
    It's a quite linear growth, not exponential
    - snazz 7y ago
      But the first few numbers went by much more slowly, right?
  - rmrfrmrf 7y ago
    I assumed that this was due to more products dropping vanity versioning in favor of semantic versioning. Is that not what's happening here?
TravelPiglet 7y ago
Well, Java 8 was released 6 years ago and is basically EOL now. We migrated to Java 11 during the fall and finally most third party libraries we use seems to work fully in Java 11.
- vbezhenar 7y ago
  Azul will provide free OpenJDK builds for Java 8 until March 2026. It's not EOL.
  - topspin 7y ago
    Amazon provides Corretto 8 maintenance until 2023 as well. It's been a drop in replacement for everything I've needed. 11 is the correct go-to version now. The small but high value language improvements definitely make it worthwhile.
p2detar 7y ago
Yeah, although depending on what you’re working on, you’d probably be interested mainly in the LTS releases. We’re bundling an OpenJDK 11 with our product and while I’ll definitely play around with v14, I think we’ll only upgrade once v17 LTS is out.
- vbezhenar 7y ago
  Why would you want to use OpenJDK 11 instead of 13/14? I'm using 8 because it's the latest version working with Windows XP, but other than that, I don't understand why would anyone avoid latest stable version.
  - enitihas 7y ago
    OpenJDK 11 is a LTS release, 13/14 are not.
    - vbezhenar 7y ago
      That's not really an answer. I understand that some people want to freeze in time and having problems jumping from 11 to 17 version, but I don't understand why do they want that. Is there any compatibility issues preventing use of Java 13, for example? I understand that migration path for Java 9 was not very clear because of modules, but that's not the case for Java 11.
      - ww520 7y ago
        LTS version is like a checkpoint. Its support will be long term, i.e. security patches will be released on them. The versions in between don't get support.
      - StreamBright 7y ago
        I guess you do not work in an enterprise environment. There are many reasons to use LTS releases, stability and security comes to my mind first. 3rd party requirements are also important in this topic.
      - 7y ago
pjmlp 7y ago
Well, you are still up to date in what concerns Android Java, in fact more than what Android Java supports. https://developer.android.com/studio/preview/features?hl=ru#j8-desugar https://developer.android.com/studio/preview/features?hl=ru#...
DannyB2 7y ago
If you upgrade, jump directly to Java 11. That may or may not be easy. But it was easy for me. After that there was no effort to upgrade to all subsequent versions, to this point.
- jghn 7y ago
  If one is using OpenJDK is there any reason not to track the versions > 11 as they come out, short of the usual reticence to upgrading?
  - DannyB2 7y ago
    Each upgrade after 11 has had good reasons to upgrade. More and more Java source language features that make your life easier by small incremental bits in each upgrade.
pron 7y ago
They're not major releases; in fact, the last major Java release ever was 9. The way releases used to work for the past ten years or so was that after a major release, every couple of months there would be a bugfix/security patch, and every six months (for a year or more) there would be a feature release (that used to be called "limited update") with major new features (new GCs, new monitoring mechanisms etc.) but without spec changes to the language and libraries. This meant that all the changes that required changing the spec had to wait for the major release. This had several bad implications. Most if not all of the spec changes were no more disruptive than the changes in the feature releases, but they had to wait for the next major release -- a lot of changes delivered at once created an overall fairly large disruption. Also the major release had to wait for the large features, and people couldn't enjoy smaller ones. Finally, people wanted to get their changes into the next major release so they wouldn't have to wait another three years or more, so features were merged before they were fully tested, which meant that the .0 major release was noticeably less stable. So, to make the upgrade process easier and cheaper, Java got rid of the major releases, allowed making spec changes in the feature releases, and, with the major releases gone, every feature release gets a new integer name. The result is a much more gradual process. Every feature release is about as big and only slightly more disruptive than the old feature releases. The releases are now much more stable because features are merged only when they're mature enough; there's no rush because if you miss a release, there's another in six months. The ecosystem will take some years to adjust, but those who've made the transition to running in production on the current release (many still can't, as some tools haven't yet adjusted) report a smooth process.
- derriz 7y ago
  You make it sound like the upgrading process is something to be savoured when for many it's the opposite. Upgrading a code base because of language evolution is pure cost for most people. It's a relatively risky and almost zero-reward exercise for mature applications. You've got 3rd party library/dependency drag, tooling drag (everything from IDEs to CI/CD pipelines), development effort for code changes or QA and testing resources. Your engineers have to invest time in learning about the language and library changes. Never mind that unless you do a total rewrite, you end up with an incoherent code base which mixes old and new styles. All this busy work/effort could instead be applied to adding features, eliminating bugs, improving performance, etc. - changes that end-users actually appreciate or that add business value. Java conquered the enterprise precisely because it was slow moving and stable and offered unparalleled backward compatibility. Pretty much, the very same reasons Microsoft windows conquered the business world. This is (was) Java's strength not the weakness you portray. Let's face it, at this stage Java is never going to be "cool" again the way it was in the 90s. Trying to join the "move fast and break things" school of language evolution just makes it look like a middle aged person (I'm one btw) trying to be "hip" by emulating young teenagers in dress and speech. At the same time you're alienating your existing users.
heelix 7y ago
Java 7, 8, and 11 are the Long Term Release (LTS) versions, that are getting patched every 90 days. Support to 2025'ish for them. With 9+, all the other versions get a 6 month life span, with new features in each and heavy deprecation/dropping of older bits with each short term cut. 9+ is fairly backward compatible with each other. 8 to 9 required a bit of finesse for things like JAXB and other things dropped from the 'core' into external libraries. At least our shop made it to JDK 11. Next LTS version is 17, which is a while out.
animalnewbie 7y ago
By your nomenclature this is java 1.14

koozz 7y ago

New features already discussed in https://news.ycombinator.com/item?id=22477629 https://news.ycombinator.com/item?id=22477629, but now it's GA.

whateveracct 7y ago

> Remove the Concurrent Mark Sweep (CMS) Garbage Collector pour one out for the legend

tofflos 7y ago

When are the Alpine builds getting GA status? The last release of Java to include a build for Alpine was Java 8. Ever since then the Alpine builds have been restricted to early access releases. In the meantime Microsoft has started providing officially supported Alpine builds for .NET Core.

_old_dude_ 7y ago
At least, Azul provides Alpine builds. Maybe other OpenJDK distribs too, i don't know ?

120bits 7y ago

I have done much Java since I moved to full time Python/Node/Go. Guess I should give a try now. The Helpful NullPointerException is certainly a exciting feature.

deleted 7y ago

[deleted]

zikani_03 7y ago

Great news, although I know it's gonna be a while before it's a smooth transition to this version - definitely going to push for atleast one of our systems. Some features we needed in this one. e.g. helpful NPE messages