6 ms·

It's kind of startling to see how many places still use Java 8, estimated at ~1/3 of projects according to a survey i just googled. And something like half that

It's kind of startling to see how many places still use Java 8, estimated at ~1/3 of projects according to a survey i just googled. And something like half that still use java 11.

BroomOfSYS 3y ago
Unbelievable! It is a strong signal that people don’t care and technical leadership is bad. Always the nonsense excuses of having to work on a “legacy” codebase for more than ten years with a team of 3 developers and 4 analysts.
MBCook 3y ago
8 reached EOL in the last year or two. I think 11 is still under LTS. Part of the problem is the changes made between 8 and 17 could be incredibly disruptive depending on your libraries. If they had stuck to not using sun.* stuff you were pretty safe, but a few very popular things did. Then somewhere in there a lot of the common server stuff moved from javax.* over to jakarta.*. Both were needed and very good, but could turn into dependency nightmares. So depending on your app/stack it wasn’t an easy transition. 17 is fantastic though, especially coming from 8. I’m excited about what’s already in 21 (latest LTS) and coming in the next LTS after that.
- agurk 3y ago
  > 8 reached EOL in the last year or two Java 8 is still under Extended Support until 2030 (and indefinite sustaining support). Java 11 left Premier Support September 2023. "Java SE 8 has gone through the End of Public Updates process for legacy releases. Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com". https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa...
  - Nullabillity 3y ago
    Oracle JDK support is not the same as OpenJDK support (for both better and worse).
  - MBCook 3y ago
    Oh that’s right. My company didn’t want to pay the insane Oracle fees to keep getting support. I think it wasn’t even a discussion once the saw the number, but that’s basically a rumor. So we have to stick to OpenJDK which means 8 doesn’t receive security updates and is untenable.
    - kaba0 3y ago
      Seems like willful incompetence on the company’s part. Just for note, JDK 8 came from the same time as Windows XP. Sure, the attack surface is different, but if they have no plans on moving forward and doesn’t even want to pay for support, then frankly fck them. Then they just surprise pikachu when a bunch of their user data leaks.
      - Nullabillity 3y ago
        Err, what? Windows XP was EOLed a month before JDK 8 was released.
      - MBCook 3y ago
        That seems oddly hostile. We moved to the latest LTS. Continuing to use an old version with no security updates would be moronic. Of course we didn’t do that. All I was saying was sticking with 8 wasn’t tenable for financial reasons.
adra 3y ago
I'm dragging my new company's codebases from 8 to 17 from soup to nuts. It's not always just about the language update, but all the old legacy crust that accumulated since java 8 that prevented anyone else to do it. My PRs are terrible and necessary.
elric 3y ago
Wait until you hear about COBOL still being used. Snark aside, the problem with Java in the enterprise is that Oracle provides support for mind-bogglingly ancient versions (if you're willing to pay them). This disincentivizes companies from upgrading, ends up frustrating their developers, and has probably contributed to the negative reputation that Java has in some corner of the net. I get that tracking the current version isn't feasible for most companies, especially if software isn't their core business. The Java folks do their best to make upgrades painless, but the longer you wait, the more painful it gets.
fngjdflmdflg 3y ago
Wasn't the whole point of Java never releasing a 2.0 that there would never be breaking changes? Seems like something went very very wrong with Java if the state they are in is that the language refuses to make breaking changes and the developers refuse to take up the supposedly non breaking updates due to breaking changes based on the comments I'm seeing here. So the language never improves as much as it can and the developers never update anyway making the whole point of non-breaking changes moot.
- chungy 3y ago
  Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.
  - cempaka 3y ago
    I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had this issue.)
    - chungy 3y ago
      That's probably another factor, and these two aren't the only ones.
    - vips7L 3y ago
      I haven’t ever seen this mentioned. The real culprit was libraries that go into jdk internals when they shouldn’t have so end user applications couldn’t upgrade until those libraries upgraded.
  - 3y ago
Nullabillity 3y ago
In practice, Java is the language of legacy and Android. Java 8 keeps working, while "modern" Java keeps chasing mistakes like green threads. If anything, I'm more baffled by 9+ having a non-neglegible market share at all.
- citrin_ru 3y ago
  > Java keeps chasing mistakes like green threads If by green threads you mean virtual threads in JDK 21 could you please elaborate why they are a mistake? I'm not a Java developer but from what I see new concurrency model allows to write much more efficient network software - OS threads are expensive (in terms of RAM/CPU) and to handle many thousands of network connections (C10k problem) you have to either throw a lot of hardware or use NIO (New/Non-blocking I/O) which is hard to code. One of reasons why Go become popular - gorutines look like normal threads (relatively easy to code) but more efficient.
  - Nullabillity 3y ago
    There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc). Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity. Go shares most of those downsides, but as a greenfield project (..heh) there's at least the expectation that all libraries play nice with their scheduler. They also try to hide FFI starvation by effectively running each FFI call in a dedicated OS thread[0]. There's also gevent/greenlet, which tries to bolt "colourless" M:N scheduling onto Python. It hasn't exactly taken the Python world by storm either, despite being far older than their native asyncio support. Overall, I'd consider all three implementations of the approach to be dead on arrival. [0]: See https://stackoverflow.com/a/28356944 https://stackoverflow.com/a/28356944, it's a bit obfuscated but the overall effect is the same
    - jen20 3y ago
      If you consider Go to be "dead on arrival", I don't know what world you're living in.

It's kind of startling to see how many places still use Java 8, estimated at ~1/3 of projects according to a survey i just googled. And something like half that still use java 11.

BroomOfSYS 3y ago

Unbelievable! It is a strong signal that people don’t care and technical leadership is bad. Always the nonsense excuses of having to work on a “legacy” codebase for more than ten years with a team of 3 developers and 4 analysts.

MBCook 3y ago

8 reached EOL in the last year or two. I think 11 is still under LTS. Part of the problem is the changes made between 8 and 17 could be incredibly disruptive depending on your libraries. If they had stuck to not using sun.* stuff you were pretty safe, but a few very popular things did. Then somewhere in there a lot of the common server stuff moved from javax.* over to jakarta.*. Both were needed and very good, but could turn into dependency nightmares. So depending on your app/stack it wasn’t an easy transition. 17 is fantastic though, especially coming from 8. I’m excited about what’s already in 21 (latest LTS) and coming in the next LTS after that.

agurk 3y ago
> 8 reached EOL in the last year or two Java 8 is still under Extended Support until 2030 (and indefinite sustaining support). Java 11 left Premier Support September 2023. "Java SE 8 has gone through the End of Public Updates process for legacy releases. Oracle will continue to provide free public updates and auto updates of Java SE 8 indefinitely for Personal, Development and other Users via java.com". https://www.oracle.com/java/technologies/java-se-support-roadmap.html https://www.oracle.com/java/technologies/java-se-support-roa...
- Nullabillity 3y ago
  Oracle JDK support is not the same as OpenJDK support (for both better and worse).
- MBCook 3y ago
  Oh that’s right. My company didn’t want to pay the insane Oracle fees to keep getting support. I think it wasn’t even a discussion once the saw the number, but that’s basically a rumor. So we have to stick to OpenJDK which means 8 doesn’t receive security updates and is untenable.
  - kaba0 3y ago
    Seems like willful incompetence on the company’s part. Just for note, JDK 8 came from the same time as Windows XP. Sure, the attack surface is different, but if they have no plans on moving forward and doesn’t even want to pay for support, then frankly fck them. Then they just surprise pikachu when a bunch of their user data leaks.
    - Nullabillity 3y ago
      Err, what? Windows XP was EOLed a month before JDK 8 was released.
    - MBCook 3y ago
      That seems oddly hostile. We moved to the latest LTS. Continuing to use an old version with no security updates would be moronic. Of course we didn’t do that. All I was saying was sticking with 8 wasn’t tenable for financial reasons.

adra 3y ago

I'm dragging my new company's codebases from 8 to 17 from soup to nuts. It's not always just about the language update, but all the old legacy crust that accumulated since java 8 that prevented anyone else to do it. My PRs are terrible and necessary.

elric 3y ago

Wait until you hear about COBOL still being used. Snark aside, the problem with Java in the enterprise is that Oracle provides support for mind-bogglingly ancient versions (if you're willing to pay them). This disincentivizes companies from upgrading, ends up frustrating their developers, and has probably contributed to the negative reputation that Java has in some corner of the net. I get that tracking the current version isn't feasible for most companies, especially if software isn't their core business. The Java folks do their best to make upgrades painless, but the longer you wait, the more painful it gets.

fngjdflmdflg 3y ago

Wasn't the whole point of Java never releasing a 2.0 that there would never be breaking changes? Seems like something went very very wrong with Java if the state they are in is that the language refuses to make breaking changes and the developers refuse to take up the supposedly non breaking updates due to breaking changes based on the comments I'm seeing here. So the language never improves as much as it can and the developers never update anyway making the whole point of non-breaking changes moot.

chungy 3y ago
Java 8 allows access to unsafe methods, which despite being meant for internal JDK use only, have been widely used in external projects. Newer Java versions do not permit the use of unsafe except for the JDK itself. It wasn't ever part of the public API that's promised to never break, and JDK developers were annoyed that it being used meant Java got perceived as unstable, and it's gone in more recent versions.
- cempaka 3y ago
  I thought the issue was not Unsafe methods (which are only just now starting to be marked for removal) but rather various bytecode weaving libraries like javassist. As the JDKs progressively enforce bytecode verification more strictly these libraries sometimes run afoul of the new restrictions. (I speak from a little experience here, managed a somewhat involved upgrade path from 7 to 8 way back in the day which had this issue.)
  - chungy 3y ago
    That's probably another factor, and these two aren't the only ones.
  - vips7L 3y ago
    I haven’t ever seen this mentioned. The real culprit was libraries that go into jdk internals when they shouldn’t have so end user applications couldn’t upgrade until those libraries upgraded.
- 3y ago

Nullabillity 3y ago

In practice, Java is the language of legacy and Android. Java 8 keeps working, while "modern" Java keeps chasing mistakes like green threads. If anything, I'm more baffled by 9+ having a non-neglegible market share at all.

citrin_ru 3y ago
> Java keeps chasing mistakes like green threads If by green threads you mean virtual threads in JDK 21 could you please elaborate why they are a mistake? I'm not a Java developer but from what I see new concurrency model allows to write much more efficient network software - OS threads are expensive (in terms of RAM/CPU) and to handle many thousands of network connections (C10k problem) you have to either throw a lot of hardware or use NIO (New/Non-blocking I/O) which is hard to code. One of reasons why Go become popular - gorutines look like normal threads (relatively easy to code) but more efficient.
- Nullabillity 3y ago
  There were already "user-mode" implementations of asynchronicity on the JVM for years (like Monix, cats-effect, Pekko (fka Akka), etc). Loom has a worse API, is hidden from the user (what's preemptible and what will cause OS thread starvation? who knows!), and effectively ends up infecting the whole JVM with its complexity. Go shares most of those downsides, but as a greenfield project (..heh) there's at least the expectation that all libraries play nice with their scheduler. They also try to hide FFI starvation by effectively running each FFI call in a dedicated OS thread[0]. There's also gevent/greenlet, which tries to bolt "colourless" M:N scheduling onto Python. It hasn't exactly taken the Python world by storm either, despite being far older than their native asyncio support. Overall, I'd consider all three implementations of the approach to be dead on arrival. [0]: See https://stackoverflow.com/a/28356944 https://stackoverflow.com/a/28356944, it's a bit obfuscated but the overall effect is the same
  - jen20 3y ago
    If you consider Go to be "dead on arrival", I don't know what world you're living in.