Java 17 is born, but banks prefer other programming languages

Java 17 has been released into the wild. Launched last month, it includes numerous enhancements and has been described as, “the culmination of many language and platform improvements that have steadfastly been introduced with every Java release since Java 11.” 

Does this mean that banks will start using it? Probably not.

As shown by their slow uptake of Python 3, most banks are not exactly first movers when it comes to implementing new versions of popular coding languages. Java 17 may be the most up-to-date iteration of Java, but banks are predominantly stuck using the version that was launched in 2014. “The vast majority of teams in banks will be on Java 8 or Java 11,” says a senior coder at JPMorgan. They’re not alone in this: a recent study of the Java ecosystem showed that most users are similarly wedded to Java 8 and 11 and that the uptake of subsequent versions has been poor.

Java 17 is supposed to be different, though. The culmination of releases over the past five years, it’s intended to help Java to catch-up with competitors like Kotlin and Scala, and improves pattern matching, switching between expressions and the creation of immutable data classes. Most importantly, it also holds the promise of long-term support. “Teams who have been using Java 11 [the previous release with long-term support], will now likely plan to move to Java 17,” says one senior developer.

In the short term, however, moving will be a challenge. With platforms running on Java 8, banks have switched to using Kotlin and Scala instead where appropriate, and this makes a wholesale move to Java 17 undesirable and impractical. “We’re on Java 8 and have little reason to upgrade as we mainly use Scala and Kotlin,” says the JPMorgan coder.  “Java 17 does offer some interesting language features, although Kotlin is still considered to be a better language than Java by many.”

“Java isn’t used for bleeding edge things in banks anymore,” says another senior developer. “All the action is happening in Python, Scala and Kotlin, and C++ is making a comeback.” 

Java has become the language of simple, back office, and legacy applications, he adds. And the launch of Java 17 is unlikely to change that.

It doesn’t help that developers moving to Java 17 will need to familiarize themselves with all the transitional changes since Java 8, or that some of those changes could cause problems with existing systems. “There are quite a few breaking changes in Java 17,” says one senior developer. “It’s non-trivial to upgrade existing applications.”

For this reason, Java 17 is unlikely to trigger the rehabilitation of Java within banks’ coding ecosystems, even if it does dramatically improve functionality. It may be adopted eventually, but not yet. “I assume most teams will upgrade when Java 8 is end of life and no longer receiving security fixes, which will be 2025,” says the developer at JPMorgan.

Have a confidential story, tip, or comment you’d like to share?

Contact: [email protected] in the first instance. Whatsapp/Signal/Telegram also available (Telegram: @SarahButcher)

Bear with us if you leave a comment at the bottom of this article: all our comments are moderated by human beings. Sometimes these humans might be asleep, or away from their desks, so it may take a while for your comment to appear. Eventually it will – unless it’s offensive or libelous (in which case it won’t.)

Photo by Louis Tsai on Unsplash