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.”

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 improve pattern matching, switching between expressions and the creation of immutable data classes. Most importantly, it also holds the promise of long-term support. Оne senior developer commented:

“Teams who have been using Java 11, will now likely plan to move to Java 17.”

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. The JPMorgan coder says:

“We’re on Java 8 and have little reason to upgrade as we mainly use Scala and Kotlin.  Java 17 does offer some interesting language features, although Kotlin is still considered to be a better language than Java by many.

Another senior developer also comments:

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

Java has become the language of the 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. One developer added:

“There are quite a few breaking changes in Java 17, 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.