Discover your dream Career
For Recruiters

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: sbutcher@efinancialcareers.com 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

author-card-avatar
AUTHORSarah Butcher Global Editor
  • Ja
    James McGill
    25 October 2021

    The deprecation of URLClassloader was devastating for a whole lot of systems. There are critical systems all over the world that can't migrate to jdk 9+ because they absolutely depend on dynamic claasloader construction, and even if you can find people who know how to fix that, you can't afford us, and it's still an introduction of substantial risk. It was a terrible decision and it caught a whole lot of people completely off guard, even people who follow the JDK development process closely.

  • Bh
    Bhanu
    23 October 2021

    True.. all the companies I know are using Java8 not even Java11. But Java still rules the backend for many enterprise companies

  • MO
    MOCKBA
    23 October 2021

    Write once, run anywhere... unfortunately not anymore. What benefits Java has after? It you want to play with modern technologies, then Java is the worst choice.

  • cr
    crab
    22 October 2021

    > "There are quite a few breaking changes in Java 17," says one senior developer. "It's non-trivial to upgrade existing applications."

    Such as? The only significant breaking change I'm aware of going from 11 to 17 is the strong encapsulation of JDK internals. That change has been made pretty effortless thanks to the warning messages that proceeded the change, and it was a change that needed to happen anyways.

    There was a Netflix blog recently about how simple it actually is to go 8 -> 9 -> 11 -> 16/17. If Netfix can show how they moved their sprawling codebase from 2011 into the present in 1 blog post, you can probably migrate yours as well.

    Modern Java is an exciting, powerful language, and upgrading has never been easier. These articles seem like they're designed to give middle management some hackneyed talking points so that they can avoid addressing tech debt a bit longer.

  • Bo
    Bob
    22 October 2021

    Java is strictly for the back office and has been for years. Legacy code only.

Sign up to our Newsletter!

Get advice to help you manage and drive your career.

Boost your career

Find thousands of job opportunities by signing up to eFinancialCareers today.
Recommended Jobs

Sign up to our Newsletter!

Get advice to help you manage and drive your career.