Apple has transitioned its hardware products to the AArch64 processor architecture and is phasing out support for x64. Oracle engineers will thus stop maintaining the macOS/x64 port as of JDK 27. Maintaining the port is a significant burden.
↫ JEP 541: Deprecate the macOS/x64 Port for Removal
The port won’t yet be removed, but will be in a future release. Considering the number of Intel Macs that must surely still be in use today, this does seem a little premature to me.
Counterpoint: how many new/fully up to date Java/jvm programs are being made that could justify keeping the build alive. The current Java versions will continue to run for a good while yet so itll likely be a long time before you find yourself in a situation where you cant run a version of a java program you need, at that point it would likely be nice to invest in newer hardware but if you cant then Linux is always there. It does suck to have to ditch a system for no great reasons but the wheels of time do turn for every bit of hardware
Not only this, current LTS JDK25 (w/ Apple x86 support) will be supported until 2030/31. That is still a long time.
Shugo,
That’s the critical question.
Back when Oracle acquired Sun and Java, they killed backwards compatibility creating serious compatibility and support issues. A lot of specialty IOT hardware, dell dracs, and other things became inaccessible if you upgraded java, and yet new hardware/software was inaccessible if you didn’t. I was working for an HVAC company at the time and they faced the exact same issue: Oracle updates broke critical infrastructure and we had no choice but to tell customers NOT to upgrade because of oracle breaking compatibility. These were solid enterprise use cases, so it’s rather surprising that oracle would jam a wrench into the works because the lesson that many of us took away from that is that java under Oracle isn’t suitable for enterprise. I for one have avoided it ever since because I never want to be bitten by this again and frankly I’d advice mac users affected by this to do the same.
This iż a non issue and anyone who think IA being affected are welcome to step up and maintain the port…
.wojtek
Do you remember when Sun’s slogan for Java was “write once, run anywhere?” Oracle’s fragmented roadmap for Java stabs right into the heart of the write once run anywhere philosophy. I’m not saying you are wrong, but now that you’re arguing developers need to maintain different versions targeting different platforms, this is rather detrimental to Java’s core strengths. IMHO this compatibility was one of the biggest selling points for Java and without it Java becomes far less special.
Yes, that slogan is true. But also true is the fact that they never promised eternal compatibility.
While there is a high chance if Java1.0 Java app *could* run in newer JVM it’s not given. And you still be able to run Java 20-something for a long time still…
Even Linux removes support for older architectures ♂️
.wojtek,
I don’t expect eternal compatibility, however the fact remains x86 macs are still officially supported, only under a different & incompatible version of java. In a real sense this is reneging on the promise of the same code running everywhere. To be fair, I don’t know that Oracle ever promoted Sun’s “write once” mantra themselves, it’s just a disappointing regression from Sun’s vision for Java.
@Alfman,
here, I don’t follow: JDK25 LTS will be fully supported til 2031, thats another 5 years. Those Macs will be dead by then,
Further, there is little reason to upgrade your JDK unless you want to use new language features. You can always just provide your preferred JDK as a blob/folder beside your applications or nowadays even compile to Native.
Yes, the removal (or privatisation) of classes was annoying. I maintain https://github.com/manticore-projects/webswing and getting this from JDK11 to JDK25 was serious work. But at the same time, I feel like Oracle did a great job overall in keeping Java relevant and they managed a good balance between backward compatibility and modernization. (And I am not fan of Oracle at all at all.)
Andreas Reichel,
It depends if your software updates to the latest JDK. But can I ask where you got 2031? Oracle’s download page shows updates ending in 2028 in about two years under existing licensing terms. Production use of updates beyond that are expressly prohibited without acquiring a fee based license.
oracle.com/java/technologies/downloads/
I think it’s $180/yr for the runtime and $1200/yr for developer tools. I don’t know if you factored this in?
Yes, but this assumes the java code is yours to do with as you please. For us this wasn’t the case, I didn’t have the source code to fix anything that broke. We did try getting different java versions working but it created a support nightmare. Keep in mind the java software was associated with physical machines and getting vendors to replace them was both expensive and labor intensive.
It’s likely that at least some projects are going to leave the x86 LTS version out to hang even if for no other reason than they can’t justify buying subscriptions from oracle just to be able to support the older machines. Or maybe you’re fortunate enough to have source code to do something about it (it sounds like this is the case for you).
Well that’s fair enough. To be clear none of this is my battle anymore, since I’ve been avoiding Java and don’t care to return.
@Alfman
Temurin: https://adoptium.net/support/
@Alfman:
Liberica offers Commercial Support until March 2034 according to https://bell-sw.com/support/#pricing
And they state, that Oracle Commercial Support ends Sep 2033 (though I really don’t care about Oracle, as long as certified JDKs are available — I do trust BellSoft way more than Oracle.)
@Alfman,
Pardon my curiosity (and feel welcome to ignore my question when this goes to deep): Can you elaborate please?
1) Why update the JDK at all (when the Java Software did not change)
2) Why not just provide the JDK as self contained folder and set JAVA_HOME accordingly?
I may be too ignorant, but the only ever showstopper I have been facing was about GLIBC incompatibilities (JDK depending on newer GLIBC than ancient Linux box provided) and tampering with the Graphics Stack (Jetbrains JDK).
I also never understood why anyone would use the Oracle JDK (or anything Oracle, its not a trustworthy supplier in my opinion).
Andreas Reichel,
Well, the company was a reseller and installer, not a publisher. Also customers bought the HVAC units over time, meaning an installation might comprise of dozens of units manufactured in different years. These are very expensive commercial systems and it’s not necessarily viable to ditch them over software JVM compatibility issues. So mixed environments were kind of unavoidable in the wild. Under Sun’s management compatibility was solid, upgrades just worked. It was only after oracle took over that things started breaking. Technically you’d be right that customer could split the system across different versions of the software, but that was a hard sell because it created extra work and expenses to deploy & maintain infrastructure across multiple versions.
This compatibility problem wasn’t isolated to this vendor, the oracle breakages also affected other unrelated java software and it soured me on oracle.
I agree, but bear in mind this was decades ago – a lot of customers didn’t come knocking on Oracle’s door, rather Oracle absorbed them by taking over Sun. It wasn’t just java, but mysql, openoffice, etc. Over time the community would seek to fork these into projects into non-oracle forks like mariadb and libreoffice which I still use regularly. Thankfully FOSS saved the day.
Andreas Reichel,
Oh I see, you weren’t talking about oracle. I haven’t heard about Liberca before. Honestly I’m unlikely to target Java, but it’s good to know there are different options.
Thank you for the insight and your time, Alfman.
Oracle are evil and or hopeless….
They ruined the Java promise of “Write once run anywhere”.
I don’t really know any details but my understanding is Java has a Virtual Machine and Java applications are written as Java Byte Code. As an example, I don’t understand how Java Byte Code draws an icon on the JVM “screen”/window. I would hope that is clearly specified by the Java Virtual Machine specification……
I understand with the advances in technology, the JVM specification from 1996 might not be able to fully utilise modern hardware.
Oracle should have released “Java 2” with a JVM 2 specification, clearly stating that “Java 2” apps would not work on the original Java JVM.
Instead Oracle has created confusion where newer Java Apps may not work on some JVMs.
“The port won’t yet be removed, but will be in a future release. Considering the number of Intel Macs that must surely still be in use today, this does seem a little premature to me.”
Are you really sure about that, kind makes sense IMHO. Looking at the data. From the name JDK 27, it’s probably set to be released sometime next year. Given that all intel Macs from before 2020 already is off MacOS support and Intel Macs been discontinued since 2023. And that Apple reportedly are to quit support for intel Macs in the 27 release. That would in best case give a few months with a supported MacOS for JDK 27 if any.
And the regardless of os support, the Intel Macs will be 4+ years old then. And there will hardly bee any in use with enterprise customers, you know, the customer actually generating income for Oracle. For the rest, they run an os out of support, they probably be quite fine with JDK 26 with support for several years.
JDK25 is the LTS. JDK26/27 are more like test balloons for interested developers — “Beta” would be a more traditional naming convention. JDK25 gets commercial support at least until 2031, those Macs will be long dead by then.
There is not one single software outside depending on JDK26+ and I would wonder if any software depends JDK25. The last relevant feature redefined was FFM (stable since JDK24).