IBM absorbs Red Hat’s Java division + merges, hyperscale AI deals… and other all‑things‑corporate - JVM Weekly vol. 137
This week’s edition dives into corporate news - far cheerier than that ominous thumbnail suggests, but the image was simply too good to pass up 😇
This issue is sponsored by Bufstream - an innovative Kafka alternative focusing on Protobuf schema validation at the broker level. They invite you to a free workshop on July 10 (TODAY!) to learn more about this technology.
At the beginning of 2025 it was announced that Red Hat’s entire middleware/Java team would be moved into IBM Data Security, IAM & Runtimes, creating a single product line for cloud (and AI 😅), a natural step after IBM’s US $34 billion acquisition of Red Hat in 2019, which had left the company with two separate JDK/JVM divisions. Both brands stress that the goal is not re‑branding but concentrating talent and budget on a single roadmap for JDK LTS, WildFly/Liberty, and Quarkus without breaking upstream licenses.
Sounds scary, but IBM’s Java roots run deep - from the classic J9 VM of the 1990s, through co‑founding Eclipse in 2004, to donating OpenJ9 to the Eclipse Foundation in 2017. Also in 2017 WebSphere Liberty went open source as Open Liberty, adopting an “OSS‑first” model and regularly adding support for newer Java versions (most recently Java 17). For IBM, bringing in Red Hat’s team means enhancing Open Liberty with the WildFly and Quarkus engineers’ expertise and testing both on OpenJ9 and HotSpot.
Red Hat became a Java heavyweight when it bought JBoss in 2006 and launched IcedTea in 2007 (a patch set that let Fedora build a 100 % open OpenJDK). It has since developed WildFly (the community Java EE server that acts as a proving ground for commercial JBoss EAP) and unveiled Quarkus in 2019. In parallel, the company maintains its own OpenJDK builds for RHEL and Windows and is among the largest upstream contributors.
Red Hat’s blog stresses that “nothing disappears, it only grows,” and the news even reached Forbes, which spoke of a “middleware powerhouse.” Developer comments voiced fears that WildFly might be retired in favor of Liberty, but engineers on both sides have largely reassured the community: EAP customers have long contracts, and Liberty serves a different market segment. In practice, the roadmap calls for common cloud‑native APIs, unified CVE/patch releases, and a coordinated quarterly release train. IBM pledges to maintain parallel HotSpot (OpenJDK 23 LTS) and OpenJ9 builds, a shared cert kit for Liberty/WildFly/Quarkus, and full sources on GitHub.
What about other projects? The answer is the Commonhaus Foundation, founded 9 April 2024 as a vendor‑neutral non‑profit by Erin Schnabel , Cesar Saavedra , and Ken Finnigan (all from the JBoss/Red Hat circle). Its goal was (and remains) to provide mature libraries and frameworks with “succession plans,” light oversight, and fiscal support. On day one it accepted Hibernate, Jackson, OpenRewrite, JBang, JReleaser, and Morphia. Since then Red Hat has moved its middleware projects there: Quarkus (August 2024), Debezium (November 2024), WildFly (30 April 2025), Narayana (June 2025), and Weld is onboarding.
For the community this means faster patches and a coherent LTS policy; for companies—one invoice for all runtimes. And for us? This autumn we’ll see the first joint beta of EAP 8 + Liberty 25.0 - then we’ll learn whether “merge” truly means “synergy.”
You probably know nature abhors a vacuum - when one Linux vendor stops building OpenJDK, another must start.
On 1 July Canonical announced its own Canonical Builds of OpenJDK, covering versions 8, 11, 17, and 21 with at least 12 years of security support under Ubuntu Pro - Java 8 is supported until 2034(!), eight years longer than Red Hat and four longer than Azul Zulu.
For containers Canonical introduced ultra‑light “Chiseled Ubuntu OpenJRE” images for 8, 17, and 21 - which due to initial data are about 50 % smaller than Temurin and covered by the same 12‑year support. A new Spring‑focused “devpack” and broader Java‑on‑Ubuntu Pro support accompany the move. Clearly the target is companies seeking long‑lived, certified JDK binaries.
The new packages land in the repos right after upstream releases, are fully TCK‑compliant, and Canonical promises wide architecture support (x86‑64, ARM64, s390x, RISC‑V, ppc64el) plus faster JVM startup via CRaC. Not bad for a first outing—Ubuntu is becoming a peer alternative to Red Hat builds, Temurin, or Azul.
Now for a change of scene: On 30 June Meta announced that it is joining the Kotlin Foundation board as the first “gold” partner beside JetBrains and Google. This didn’t come out of nowhere: Meta, Google, JetBrains, and Uber have joined forces in recent years to help companies migrate huge codebases from Java to Kotlin, and in the past three years Meta engineers have rewritten tens of millions of lines. Their enterprise Java‑to‑Kotlin Working Group inside the foundation maintains a shared “recipe for migration” (rules, checklists, configs) so any company can reproduce the pipeline and safely refactor hundreds of thousands of files. Meta has open‑sourced Kotlinator—a tool that mass‑converts files, polishes them for idiomatic style and null‑safety, and builds deterministically with Buck2, a fast Rust‑based build engine.
If you’re curious what such migrations look like at scale, Ty Smith conference talk should soon appear on the Kotlin YouTube channel. Can’t wait, it was that good 😁.
What does the rest of the world gain? “Gold” status pumps Meta’s people and cash into Kotlin Grants, student KMP contests, and work on the K2 compiler’s performance and monorepo tooling - requests library authors have had for months.
According to the foundation, this is only the first step toward broader openness - Block is already joining as “silver,” and rumor has it more hyperscalers are waiting. For developers this means faster patches, better IDE insights, and unified governance; for Meta, a vote in shaping Kotlin and Compose Multiplatform roadmaps. If Kotlinator lands on public SDKMAN! in 2026, it will be the biggest win yet for those still migrating from Java.
Staying with Big Tech: I recently mentioned Swift investing in Java‑compatibility tools, and on 25 June the Swift Core Team announced an Android Workgroup to make Android an officially supported Swift platform, with its own CI, full JNI bridge, and removal of all “out‑of‑tree” patches. The group plans to adapt Foundation and Dispatch to Android idioms, define minimum API levels and debugger tools, and hold open bi‑weekly meetings for interested developers. A public roadmap is already on GitHub, and early members include Saleem Abdulrasool and Marc Prud’hommeaux—signaling tight cooperation with the open‑source community.
To the Kotlin crowd, this looks like KMP in reverse: for years Kotlin Multiplatform let you share business logic between Android and iOS, and now Swift wants to offer a mirror path the other way. Swift forums ask openly whether the project is “heading toward KMP,” but voices in both ecosystems speak of healthy competition, not threat—no one expects Kotlin to be displaced, yet everyone hopes for two‑way Java interop (like the swift‑java project) and mutual innovation. If the Android Workgroup delivers official binaries and Gradle templates, writing shared logic in Swift with Compose UI (or SwiftUI with Kotlin/Native) could become reality, pushing JetBrains and Google to polish KMP even faster and accelerating toolchain maturity on both sides.
We’ve shown corporations in a rather positive light...
...so time for a reality check - welcome to the courtroom for an intriguing case.
On 18 June 2025 the U.S. Trademark Trial and Appeal Board rejected the fraud claim filed by Deno in its bid to cancel the “JavaScript” trademark, ruling that Oracle’s 2019 renewal evidence (a Node.js site screenshot) doesn’t meet the fraud threshold. Deno won’t amend that part, avoiding delay, and will focus on two key grounds—genericness and abandonment, i.e. arguing that “JavaScript” is the common name of the language and Oracle hasn’t used it in a product sense for years. Oracle has until 7 August 2025 for a point‑by‑point response; discovery starts 6 September, finally moving the dispute from procedural games to substance.
The fight began in November 2024, when Ryan Dahl (creator of Node.js and Deno) petitioned the USPTO to cancel the mark, alleging genericization and abandonment and claiming Oracle misled the office. In February 2025 Oracle tried to cut the fraud thread with a partial motion to dismiss—a move many developers saw as stalling. Support for #FreeJavaScript keeps growing: over 19.5 k signatures, and tech outlets from Slashdot to InfoWorld recall that Oracle never helped develop the language. If Deno wins - or Oracle yields - the name “JavaScript” returns to the public domain, the ecosystem loses the ™ symbol and potential license landmines, and conferences, publishers, and even ECMA‑262 itself see a historic shift.
One last Oracle item: as part of Project Stargate (building the world’s largest AI infrastructure in the U.S.), the company signed a historic deal with OpenAI on 3 July. OpenAI secured 4.5 GW of compute in Oracle data centers for 15 years—worth roughly US $30 billion annually from FY2028 onward, shooting Oracle’s stock to record highs.
For OpenAI this diversifies dependence on Microsoft—Azure, Google TPU, and CoreWeave are still in play, but the Oracle deal guarantees scaling for future GPT generations without compute or power bottlenecks. Oracle gains a flagship generative‑AI customer and proof its rapidly expanding data‑center network can price‑compete with AWS and Azure.
So we witness the race to build U.S. “gigawatt campuses,” soaring demand for GB200 chips, and yet another hyperscaler sprint - already prompting regulators to ask about grid capacity and potential energy subsidies.
BTW: we’ll return to power and sustainability next week - JobRunr just released v8 with a very interesting feature on that front. More coverage soon.
BTW 2: I know - Jakarta EE 11 also shipped, and for many that’s “corporate tech” too. But that’s for next week.
Excellent issue once again. I've always believed that WildFly is a horrible name. A WildFly isn't something you adopt -- it's something you swat. Even their logo looks like a bug, and why would you want to associate your software with that image? Probably the second worst name ever, after Cockroach DB, whose emails I delete unopened.
I had no idea Oracle is being awful about JavaScript, too. Thanks for the reminder about that company cartoon. Amazing how much it still seems to apply even after all these years.