Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content. Where exactly were the bottlenecks in Java or top delta gains compared to Swift. The service scope looks so simple that there might be some underlying problem with the previous version, be it the code not scaling well with the irregular batch nature of traffic or custom cryptography code not taking advantage of the latest native IO constructs.
And I'm not defending Java by any means, more often than not Java is like an 80s Volvo: incredibly reliable, but you'll spend more time figuring out its strange noises than actually driving it at full speed.
> Without a deeper profiling analysis of the Java application it's hard to not consider this whole piece just advertorial content.
I'd be surprised if anything Apple wrote would satisfy you. TFA makes it clear that they first optimized the Java version as much as it could be under Java's GC, that they evaluated several languages (not just Swift) once it became clear that a rewrite was necessary, that they "benchmarked performance throughout the process of development and deployment", and they shared before/after benchmarks.
Ok, I'm pretty skeptical that they actually did optimize what they could. In fact, reading between the lines it sounds like they barely tried at all.
For example, they mention G1GC as being better than what was originally there but not good enough. Yet the problems they mention, prolonged GC pauses, indicates that G1GC was not the right collector for them. Instead, they should have been using ZGC.
The call out of G1GC as being "new" is also pretty odd as it was added to the JVM in Java 9, released in 2016. Meaning, they are talking about a 9 year old collector as if it were brand new. Did they JUST update to java 11?
And if they are complaining about startup time, then why no mention of AppCDS usage? Or more extreme, CRaC? What about doing an AOT compile with Graal?
The only mention they have is the garbage collector, which is simply just one aspect of the JVM.
And, not for nothing, the JVM has made pretty humongous strides in startup time and GC performance throughout the versions. Theres pretty large performance wins going from 11->17 and 17->21.
I'm sorry, but this really reads as Apple marketing looking for a reason to tout swift as being super great.
As someone who hasn't used Java professionally, this was helpful informed skepticism. Thanks!
> Did they JUST update to java 11?
As an LTS release with "extended" support until 2032, that certainly seems possible.
Another near-certain factor in this decision was that Apple has an extreme, trauma-born abhorrence of critical external dependencies. With "premier" support for 11 LTS having ended last fall, it makes me wonder if a primary lever for this choice was the question of whether it was better to (1) spend time evaluating whether one of Oracle's subsequent Java LTS releases would solve their performance issues, or instead (2) use that time to dogfood server-side Swift (a homegrown, "more open" language that they understand better than anyone in the world) by applying it to a real-world problem at Apple scale, with the goal of eventually replacing all of their Java-based back-ends.
Just because it’s supported (receives security updates) doesn’t mean that it isn’t still an ancient and antiquated runtime. Java 11 was released almost 8 years ago. That is thousands of commits and performance improvements behind the latest JDK24.
JDK 11 LTS is from 2018 and after that Oracle pushed two LTS releases: JDK 17 in 2021 and JDK 21 in 2023. On top of that Oracle is commited to releasing a LTS every 2 years with the next one planed for later this year.
Using an LTS doesn't mean you have to create applications on the oldest available release, it means that if you target the latest LTS release your application is going to have a predictable and supported runtime for a very long time.
If they had to start a Java 11 project in 2024 that just points to a deeper organizational problem bigger than just GC.
And I'm not defending Java by any means, more often than not Java is like an 80s Volvo: incredibly reliable, but you'll spend more time figuring out its strange noises than actually driving it at full speed.