17 ms·

Java moved to a six-months release cycle in 2017: https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history Java 8

Java moved to a six-months release cycle in 2017: https://en.wikipedia.org/wiki/Java_version_history https://en.wikipedia.org/wiki/Java_version_history Java 8 had its end-of-life for commercial usage in january 2019. The new long term release is Java 11. Time to move on for you.

toopok4k3 7y ago
Not really. The real world seems to move much slower. I'm not sure if Android even fully supports 8 yet.
tristanperry 7y ago
Some companies spend longer than six months to discuss/agree to a 'major version upgrade' of software. Naturally the gap between (say) Java 10 and 11 is fairly small, meaning it shouldn't take many months to merely discuss an upgrade - but not all companies have got round to the regular-release way of thinking.
- Yessing 7y ago
  I thought the whole point of backward compatible versions, is that you don't discuss, you just move.
- qw 7y ago
  Java 8 was released March 18, 2014, so they had 5 years to upgrade. But I see your point about the new release schedule, where the LTS version is not supported after 6 months. I think the companies need to change their mindsets. New Java version are backwards compatible, as they introduce changes gradually. It is actually more dangerous to wait, because they risk that some features (like GC) are deprecated after 4-5 versions. By updating regularly and keeping an eye on deprecated features, they should have time to adjust
  - vbezhenar 7y ago
    I still need to pass weird flags for Tomcat to make it work under Java 9+, almost 6 years later. Modules were a mistake. If not for modules, a lot of people would have migrated to 9+.
    - ivolimmen 7y ago
      Modules where not a mistake but we will likely benefit from it in say at least 5 years. Every artifact/library you use has to be a (real) module to be able to use it's full potential.
      - jillesvangurp 7y ago
        I've yet to see a real world use that is meaningful. Mostly it just adds deployment bureaucracy for opting in to stuff that used to be there by default. I'm not seeing a huge adoption of modules outside of Java's core libraries. A good thing that came out of it was that it forced them to untangle the 2 decades old standard library. This was disruptive but it seems to have also unblocked a bit of progress and also allows the to have experimental modules in non lts releases (9,10,12,13).
    - diroussel 7y ago
      Modules were certainly the biggest upgrade barrier ever in the history of java. But the have enabled a way for the JDK to get smaller without them we would face the JDK getting bigger with each release, which is not sustainable. So on reflection I think it was a good move. Most frameworks and libraries work on modules now.
  - Tilks 7y ago
    The LTS versions are supported past 6 months. Java 11 has 2 years of public updates through AdoptOpenJDK. The next LTS (17) will no doubt have similar.
- iSnow 7y ago
  It doesn't matter so much, as Java is backwards-compatible to stone age. If the company has finally settled on a backlog, they can start with whatever LTS version is the most recent one. It's only a drawback for hired hands that may have become used to the features in v13 and then land a gig where they have to scale back to v1.6, that has to hurt.
- Tilks 7y ago
  It's not really an "update every 6 months" thing - I imagine most companies will stick to the LTS releases which are less frequent.
desdiv 7y ago
>Java 8 had its end-of-life for commercial usage in january 2019 _Oracle's_ Java 8 end-of-lifed, but many other vendors provide TLS for their respective Java implementations.
- pron 7y ago
  Just a correction: they are not separate implementations. Almost all vendors use Oracle's Java implementation -- OpenJDK. It's just that only Oracle and companies that license the source from Oracle (like Azul) can release non-GPL builds based on OpenJDK, so other vendors maintain old OpenJDK versions by doing their own backporting from the mainline, where most of the work is done by Oracle.
- jillesvangurp 7y ago
  Amazon Corretto and Azul are making decent efforts for this. You can also find openjdk 7 versions with some support still. For actively developed projects, I would recommend moving to java 11 without too much delay unless you have pressing technical or business reasons not to. If it's dead code and it is not causing issues, don't mess with it too much. The Java 8 to Java 11 upgrade is unfortunately somewhat disruptive due to the module stuff. That affects some projects that depend on JVM internals, which tends to include e.g. older versions of application servers. Upgrading those is a bigger deal usually.

toopok4k3 7y ago

Not really. The real world seems to move much slower. I'm not sure if Android even fully supports 8 yet.

tristanperry 7y ago

Some companies spend longer than six months to discuss/agree to a 'major version upgrade' of software. Naturally the gap between (say) Java 10 and 11 is fairly small, meaning it shouldn't take many months to merely discuss an upgrade - but not all companies have got round to the regular-release way of thinking.

Yessing 7y ago
I thought the whole point of backward compatible versions, is that you don't discuss, you just move.
qw 7y ago
Java 8 was released March 18, 2014, so they had 5 years to upgrade. But I see your point about the new release schedule, where the LTS version is not supported after 6 months. I think the companies need to change their mindsets. New Java version are backwards compatible, as they introduce changes gradually. It is actually more dangerous to wait, because they risk that some features (like GC) are deprecated after 4-5 versions. By updating regularly and keeping an eye on deprecated features, they should have time to adjust
- vbezhenar 7y ago
  I still need to pass weird flags for Tomcat to make it work under Java 9+, almost 6 years later. Modules were a mistake. If not for modules, a lot of people would have migrated to 9+.
  - ivolimmen 7y ago
    Modules where not a mistake but we will likely benefit from it in say at least 5 years. Every artifact/library you use has to be a (real) module to be able to use it's full potential.
    - jillesvangurp 7y ago
      I've yet to see a real world use that is meaningful. Mostly it just adds deployment bureaucracy for opting in to stuff that used to be there by default. I'm not seeing a huge adoption of modules outside of Java's core libraries. A good thing that came out of it was that it forced them to untangle the 2 decades old standard library. This was disruptive but it seems to have also unblocked a bit of progress and also allows the to have experimental modules in non lts releases (9,10,12,13).
  - diroussel 7y ago
    Modules were certainly the biggest upgrade barrier ever in the history of java. But the have enabled a way for the JDK to get smaller without them we would face the JDK getting bigger with each release, which is not sustainable. So on reflection I think it was a good move. Most frameworks and libraries work on modules now.
- Tilks 7y ago
  The LTS versions are supported past 6 months. Java 11 has 2 years of public updates through AdoptOpenJDK. The next LTS (17) will no doubt have similar.
iSnow 7y ago
It doesn't matter so much, as Java is backwards-compatible to stone age. If the company has finally settled on a backlog, they can start with whatever LTS version is the most recent one. It's only a drawback for hired hands that may have become used to the features in v13 and then land a gig where they have to scale back to v1.6, that has to hurt.
Tilks 7y ago
It's not really an "update every 6 months" thing - I imagine most companies will stick to the LTS releases which are less frequent.

desdiv 7y ago

>Java 8 had its end-of-life for commercial usage in january 2019 _Oracle's_ Java 8 end-of-lifed, but many other vendors provide TLS for their respective Java implementations.

pron 7y ago
Just a correction: they are not separate implementations. Almost all vendors use Oracle's Java implementation -- OpenJDK. It's just that only Oracle and companies that license the source from Oracle (like Azul) can release non-GPL builds based on OpenJDK, so other vendors maintain old OpenJDK versions by doing their own backporting from the mainline, where most of the work is done by Oracle.
jillesvangurp 7y ago
Amazon Corretto and Azul are making decent efforts for this. You can also find openjdk 7 versions with some support still. For actively developed projects, I would recommend moving to java 11 without too much delay unless you have pressing technical or business reasons not to. If it's dead code and it is not causing issues, don't mess with it too much. The Java 8 to Java 11 upgrade is unfortunately somewhat disruptive due to the module stuff. That affects some projects that depend on JVM internals, which tends to include e.g. older versions of application servers. Upgrading those is a bigger deal usually.