The Competition Won't Eat Java’s Lunch Anytime Soon
Feature-wise, Java’s evolution clearly points to a functional style. The JVM remains its strong suit, in enabling alternative JVM languages.
Join the DZone community and get the full member experience.Join For Free
In a previous post, I drew some comparisons between the evolution of computer languages and natural languages. One such is Turing completeness: native speakers express everything they want with a limited toolkit of vocabulary, sounds, and syntactic rules that must not be too hard to master. Another parallel is the slow, incremental nature of language evolution. Languages avoid breaking changes, given the billions of lines of legacy that would otherwise be rendered unreadable.
What does this mean for Java? It makes sense to stay true to its OO roots and optimize its expressive potential, rather than introduce paradigm shifts that break backward compatibility. To remain in the same language, big syntactic overhauls are unlikely. Mutability and void statements will stay part of the language, despite the growing appetite for more functional languages features. This is fine because the JVM platform can offer the best of two worlds. Interoperability of byte code allows radically different languages (Frege, Clojure) easy access to a rich and stable ecosystem. Java doesn’t have to be the golden hammer of programming.
Expressions Instead of Statements
Meanwhile, Java is not oblivious to what’s happening in competing languages on the JVM like Kotlin and Scala. Reactive and asynchronous programming models (think Akka and Coroutines) favor a functional style of coding. The traditional, imperative style to manipulate data through explicit instructions is synonymous with state change and leads to intractable side effects when done badly. Void methods that mutate the state of the instance they’re defined in (or worse, its arguments) are treated as the code smells that they are.
Java has caught up by allowing switch statements as expressions. The preference in favor of statements is clear. We may even see if-then-else blocks receiving a similar transformation. Immutability in the shape of records is another movement, great for parallel processing since it eliminates much expensive synchronization.
Contenders on the JVM can outdo Java with more powerful changes that are hard to introduce if you remain committed to backward compatibility. So, many minor irritants won’t be solved, and some beloved features can’t be introduced. The List interface will not turn immutable by default. Checked exceptions are here to stay. Java will not get Kotlin’s nullable type system. No question mark about it.
Haskell and Lisp on the JVM
Language popularity contests based solely on search engine stats are crude measurements, but it’s fair to say that the JVM competitors have yet to make a serious dent (say, more than 10% reduction) in the number of projects that still choose Java as their main language. The same JVM platform that welcomes these alternatives also remains the powerhouse that keeps Java in the saddle. Faster release cycles mean you can enjoy new features more quickly. The interval for long-time support versions may be shortened to two years. All this makes an enterprise-wide transition to Kotlin or Scala less attractive.
Alternative JVM languages suffer from a smaller pool of expertise – nice for developers, less so for their employers. Their ecosystem of dedicated tooling is often smaller and not as mature. Sure, many of these drawbacks are growing pains. Time can heal some, and the competition may eventually take a sizable bite out of Java’s popularity. If one contender gathers enough momentum, Java might be done for in the long term – I’d put my money on Kotlin though, not Scala. Even so, it would only make the JVM as a platform more appealing.
The Biggest Golden Hammer of All
Coding itself may be the biggest golden hammer of all. We are tinkering less with source code and more with configuration. Low-code and no-code platforms offer a deliberately constrained programming platform for generic business problems, as an antidote to this overload of complexity. Don’t treat them as a silver bullet or as a golden hammer, mind you.
They are suited to vanilla business problems. And if you can’t click and drag your way out of some non-trivial business logic, you can usually insert some snippets of custom code to deal with it. Written in Java, for example.
Opinions expressed by DZone contributors are their own.