Why develop on JVM?

With so many programming languages and platform options available today, why would you consider developing and deploying your next project on JVM? After all, Java, the language that JVM was originally built for, has been declared obsolete (and, ridiculously, even dead) by fans of different languages more times over the years than anyone cares to remember.

Yet, while many other programming languages have come in and gone out of the spotlight, Java has always managed to return to impressive spots, either near or lately even on top of the list of the most used languages in the world.

Let's look at some of the most important reasons why the JVM platform is so strong:

• It keeps up with the modern times by adapting to market changes
• The Java Class Library, the built-in library of classes, is very strong
• It has an unmatched ecosystem

JVM adapts to market changes

When Java first appeared in the mid-1990s, computers had CPUs with only a single core and didn't have gigabytes of memory, as memory chips used to be prohibitively expensive. Java is one of those languages that kept up with modern developments: when multicore CPUs appeared, Java was soon able to support those additional cores when running code in multiple threads. But it did not stop there. In each newer version, it added new classes that made working with concurrency easier. This trend still continues.

When the functional programming paradigm became popular, Java received built-in support for lambdas and streams in the core language. While Java was quite late to get this support, compared to other popular languages, Java's implementation was better than many others. This was because it offered built-in support for multithreading almost for free.

Adapting to market changes also means that sometimes things have to go. Back when Java was introduced, running Java code directly in the browser was a big thing. These mini applications were called applets and required a custom browser plugin for each browser and system. Of course, we now know that the market has chosen the JavaScript language as the standard language to create interactive websites, and Oracle recently deprecated the applet standard.

Java Class Library

For each edition of Java (more on available editions later in this chapter), it has been decided which classes are guaranteed to be available in a JVM implementation of a specific version. The Java Class Library for Java SE 8 is a very large collection of classes, and every JVM runtime installation that adheres to the Java SE 8 platform standard must implement those classes, regardless of the vendor of the JVM implementation.

Classes in this library provide functionalities such as writing or reading from the console window, performing file I/O, and communicating with TCP servers. Also, there are many classes available to start and manage operating system threads. More fundamentally, it contains classes that define data structures, such as lists and maps (called dictionaries in some other languages), among many others. In the next chapter, we will thoroughly look at the classes in the Java Class Library.

The Java Class Library is an important reason why language designers love targeting JVM. Using the data structures defined in the Java Class Library, they are able to focus more on the language design and less on building a full runtime library from scratch. Building a fully tested, multiplatform runtime system library comparable to the Java Class Library is a huge undertaking.

Ecosystem

A built-in class library can obviously not cover all the use cases of a programmer. If something is missing, you can turn to libraries and tools built by other companies, groups, and individuals to save time. Because Java has been so successful for many years, its ecosystem is unmatched. It will be hard to find a platform with proven high-quality tools, libraries, toolkits, and framework choices that are better than the ones available in JVM.

With so many add-on libraries available, Java hardly ever pushes the developer in a certain direction. As an example of how rich the ecosystem is, let's look at the main options JVM developers typically have when creating a web application:

• Build a web application that runs inside a JVM application server
• To quickly have results, a general high-level web framework can be used
• For more control, the application can be built with a microservice framework

Scenario 1 – Using a JVM application server

Developers could take the enterprise route and install a JVM-based application server, either a free open source one or a paid proprietary one, that will run the application along with web applications simultaneously, if desired. The server will handle configuration issues and manage database connections.

There are simple application servers available that just contain enough built-in APIs to run basic web applications. But there are also full blown Oracle-certified application servers that have a magnitude of built-in and standardized APIs, including APIs to access databases, generate or consume XML or JSON documents, communicate with other web services via the SOAP or REST standards, provide web security, send or receive messages from legacy computer systems, and many others.

The two most important frameworks for enterprise development are the following:

• Oracle's Java Enterprise Edition (Java EE) platform, covered later in this book
• The Spring Framework ecosystem (including Spring Boot)

Many applications use both these technologies together.

Some of the popular application servers are the following:

• Apache Tomcat (for basic web applications)
• Apache TomEE
• Red Hat WildFly
• Oracle GlassFish
• Red Hat JBoss Enterprise Application Platform
• Oracle WebLogic

The first four are open source and the last two proprietary.

Scenario 2 – Using a general high-level web application framework

The second possibility would be to use a complete web application framework. These frameworks usually offer higher-level APIs than enterprise frameworks and offer built-in model-view-controller (MVC) solutions that have the capability to enhance a developer's productivity significantly.

Frameworks such as these usually dictate or steer the developer in a certain direction as they have built-in support for only a few hardcoded libraries/toolkits. Often, plugins are supported to add support to other choices, however. By giving up some freedom, quick development cycles can be achieved. Some frameworks require that the application is run inside a JVM application server, while other frameworks provide their own HTTP server.

Apache Struts used to be very popular in this category, but nowadays, the Play framework is probably the most popular choice.

Scenario 3 – Using a microservice framework

A different choice could be to create the application using the modern microservice framework. Frameworks such as these have a built-in HTTP server to run your application, but they do not provide any other tools or libraries out of the box. In this scenario, it's easier to mix and match other libraries and toolkits that you want to use yourself.

Commonly, the application will be separated into multiple standalone web services to follow the modern microservice architecture, but this is not a strict requirement of these frameworks.

Vert.x and Spark Java (not to be used with the Apache Spark big data platform) are the most commonly used microservice frameworks.