Java is notorious for being very verbose. While over the years there have been updates made to the language to improve the situation a bit, many other languages require the writing of less code for the same end result.

Let'€™s look at a simple example.

A standard mutable object often looks like this in Java:

    class Person {
      private String name;
      public Person(String name) {
        this.name = name;
      }
      public String getName() {
        return name;
      }
      public void setName(String name) {
        this.name = name;
      }
    }

In Kotlin, the following line of code does the same (and more):

    data class Person(val name: String)

No, this is not a joke. Kotlin automatically implements the same methods as shown in the Java example when compiling this code. In fact, it adds even more commonly used methods than shown here in the Java example. In Chapter 4, Java Programming, we will discuss those additional methods for Java as well.

While Java recently received some serious functional-programming-like features in version 8, at its core, it is still a statically typed imperative language. Not all developers prefer this programming style. Programmers coming from Python or Ruby may cringe when they have to write code for a fully typed language. This can be a valid reason for teams to adopt a different language than Java for JVM development.

Also, some problems can be solved much more elegantly when using a dynamic programming language, while for projects that require complex concurrency situations, a functional programming style is often more suitable. Finally, some libraries and frameworks simply feel more natural when used with certain languages.

Java Class Library is an extensive library, but sometimes, it simply misses certain classes or it shows that it was introduced more than two decades ago. While missing functionality, in most cases, can be solved by adding free and open source add-on libraries from the JVM ecosystem, it can both be convenient and a time-saving option if you use a language that has built-in solutions for these problems.

A good example of missing functionality in Java SE version 8's Java Class Library is that it currently has no built-in support for the very commonly used JSON standard. Popular add-on libraries that provide JSON support include Jackson and Google's GSON. Also, modern versions of the Java EE platform provide APIs for JSON support classes. Some languages covered in this book have built-in support for JSON.

Another issue is that some popular classes from Java Class Library require a lot of boilerplate code to use them effectively. Languages, such as Groovy, add wrappers to many popular Java Class Library classes that make these APIs much easier to use.

When combining multiple languages, the build script has to be adapted, and this can lead to complex situations. For example, if a Java project uses a class compiled in Groovy, the order of the compilation is important. First, the Groovy class will have to be compiled, then the Java code. If that Groovy code uses custom classes from the Java project, then it gets even more complex.

A solution could be to divide the code into multiple subprojects and list the resulting libraries as a requirement of the main project in the build tool.

Some languages offer another solution: they provide their own custom classes to call the language's source code from Java (or any other JVM language). The source code is then dynamically compiled to the Java bytecode on the fly as these classes load the code. Other languages implement an official standard to embed script languages in Java code. We will take a brief look at this in the appendix when we discuss Oracle's JavaScript interpreter, called Nashorn.

This is somewhat related to building complications. Many alternative JVM languages require their own support libraries to be bundled with the compiled program. These libraries often define data structures that are unique to the language and internal support methods that the language's compiled Java bytecode calls.

This is usually not a problem, but things can get problematic if one of the project's dependencies (or one of the project's dependencies' dependencies...) is compiled in the same language but of a different version. Things can get messy when a different version of the same runtime library is required by multiple libraries of the same project and can result in confusing error messages when compiling or running the project.

This situation is called dependency hell and is not really specific to the usage of multiple languages in a single project, but it is something every developer should be aware of. Developers that want to mix languages should also be aware of the fact that sometimes language runtime libraries increase the final size significantly and that some runtime libraries also bundle their own dependencies; this increases the risk of dependency-hell-like problems. Often, dependencies are documented in the language's documentation or website.