The JVM is a Multiparadigm Platform: Use this to Improve your Programming

Java is an imperative language: Java programs tell the JVM what to do and when to do it. But computing is all about building abstractions. Java is touted as an object-oriented language: The abstractions of Java are objects, methods, and message passing via method call. Over the years people have built larger and larger systems using objects, methods, updatable state, explicit iteration, and the cracks have appeared. Many are “papered over” using high quality testing, but still programmers end up “hacking” to get round various problems.

With the arrival of Java 8, Java underwent an extremely revolutionary change, it introduced method references, lambda expressions, default methods on interfaces, higher order functions, implicit iteration, and various other things. Java 8 introduced a very different way of thinking about the implementation of algorithms.

Imperative and declarative thinking are very different ways of expressing algorithms. During the 1980s and 1990s these mindsets were seen as being distinct and irreconcilable: We had the object-oriented versus functional programming war. Smalltalk and C++ were the champions of object-orientation, and Haskell the champion of functional. Later, C++ stopped being an object-oriented language and marketed itself as a multiparadigm language; Java took over as the champion of object-oriented. With Java 8, though, Java has become multiparadigm.

Back in the early 1990s, the JVM was constructed as the way of making Java portable — we can gloss over the history of Project Green and the Oak programming language. Initially, this was for making Web browser plugins, but rapidly moved to creating server-side systems. Java compiles to
hardware independent JVM bytecode, and an interpreter executes the bytecode. Just-in-time (JIT) compilers enable the whole interpretation model to execute much faster without changing the computational model of the JVM.

As the JVM became the hugely popular platform it is, other languages were created that made use of the bytecode as a target platform: Groovy, JRuby, and Clojure are dynamic languages using the JVM for execution; Scala, Ceylon, and Kotlin are static languages. Scala, in particular, showed in the late 2000s that object-orientation and functional programming can be integrated into a single, multiparadigm language. While Clojure is a functional language, Groovy and JRuby were multiparadigm from the outset. Kotlin is taking the lessons of Java, Scala, Groovy, etc. to create languages for the 2010s and 2020s on the JVM.

To use the JVM to best effect, we should choose the right programming language for the problem. This doesn’t necessarily mean one language for the whole problem: We can use different languages for different bits — all because of the JVM. So, Java or Kotlin for the bits that are best expressed as static code, Clojure or Groovy for the bits that are best handled by dynamic code. Trying to write dynamic code in Java is a pain so use the right tool for the job given that all the programming languages can interoperate on the JVM.