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.
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".
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.
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.
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.
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.
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.)
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.
There are barely any breaking changes, I could still run a graphical application written by a prof in early 2000s, served on his website as a jar. No other language comes remotely as close to this level of stability.
As for the changes in 8->9, there was a stagnation period in the last year of Sun, and many people overfitted their libs to 8, by e.g. making use of internal APIs made accessible through reflection. This was never a good idea, and all that is happening now is that you have to explicitly state at invocation what kinds of non-future-proof modules you make use of, so that you are made aware of what could potentially change, plus it disincentivizes libraries from accessing these non-public APIs.
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.
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.
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.
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.
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.
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.
User-mode implementations are very easy to get wrong (you might accidentally call a blocking operation where you shouldn’t), and have indecipherable stack traces. How is Loom’s API bad? It literally reuses basically everything you know about Threads, seamlessly.
Also, Java has the luxury that almost no code makes use of FFI, so their impact is minimal.
Interesting point regarding scheduler and the interruptibility of FFI calls. Just thinking about it I don't see how this can be addressed. So definitely interested in learning here: what is the remedy to your criticism here beyond "document behavior"?
Does it? Preemptability is pretty robustly solved in Go. While it's sometimes less efficient than I'd like, it's a far cry from the initial draft of virtual threads in java where a misplaced "synchronized" could sneakily starve entire executors. Even with CGo pinning (which, as you indicate, is rare due to the bulk of pure-Go libraries) I'm having trouble thinking of reasonable situations where full starvation or deadlock occurs rather than (admittedly unpleasant!) latency and queueing.
That said, Loom is quite new and deliberately iterative in approach, and the Java core folks are quite skilled, so I do expect to see substantial improvements in behavior and issue-detection tooling here over the coming years.
> I'd consider all three implementations of the approach to be dead on arrival
I'd argue that eventlet/greenlet failed for different reasons than the concurrency model or starvation risk (the monkeypatching approach just can't sustainably work in an ecosystem as big and native-code-dependent as Python's), hence Python's falling back to traditional async/await cooperative concurrency.
The Rust folks are struggling with the same choices here as well, further constrained by their requirements of a GC-less runtime with near-zero-overhead C FFI, which precludes them from using Go's approach. There was some great discussion of that here: https://news.ycombinator.com/item?id=39242962
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.