Introduction to JVM Languages

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.

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.

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:

With its focus on performance, JVM is a very popular choice for web applications. When built correctly, applications can scale really well, if needed across many different servers.

JVM is a well-understood platform, meaning that it is predictable. Plus, it provides many tools to debug and profile problematic applications. Because of its open nature, monitoring of JVM internals is also possible. For web applications that have to serve thousands of users concurrently, this is an important advantage.

JVM already plays a huge role in the cloud. Popular examples of companies that use JVM for core parts of their cloud-based services include Twitter (famously using Scala), Amazon, Spotify, and Netflix. The actual list is much larger.

Big data is a hot topic. When data is regarded too big for traditional databases to be analyzed, one can set up multiple clusters of servers for processing such data. Analyzing data in this context can, for example, refer to searching for something specific, looking for patterns, and calculating statistics.

This data could be obtained from the data collected from web servers (for example, logged visitors' clicks), the output obtained from external sensors at a manufacturer's plant, legacy servers that have been producing log files for many years, and so forth. Data sizes can vary wildly as well, but often, they take up multiple terabytes in total.

Two popular technologies in the big data arena are the following:

Both Hadoop and Spark are for the most part written in Java. While both offer interfaces to a lot of programming languages and platforms, it will not be a surprise that JVM is one among them.

The functional programming paradigm focuses on creating code that would run safely on multiple CPU cores, so languages that are fully specialized in this style, such as Scala or Clojure, are appropriate candidates to be used with either Spark or Hadoop.

Portable devices that feature Internet connectivity are very common these days. Since Java was created with the idea of running on embedded devices from the beginning, JVM is, yet again, at an advantage here.

For memory-constrained systems, Oracle offers the Java ME Embedded platform. It is meant for commercial IoT devices that do not require a standard graphical or console-based user interface.

For devices that can spare more memory, the Java SE Embedded edition is available. The Java SE Embedded version is very close to the Java SE discussed in this book. When running a full Linux environment, it can be used to provide desktop GUIs for full user interaction.

Both Java ME Embedded and Java SE Embedded platforms can access the general-purpose input/output (GPIO) pins on the Raspberry Pi, which means that sensors and other peripherals connected to these ports can be accessed by Java code.

That the Java Virtual Machine is a virtual machine is a rather obvious observation, but it should be kept in mind. One of the consequences is that you are, in theory, writing applications for a type of machine that differs from the machine you are developing or running your applications on.

It generally does not matter whether the code runs on a 32-bit or 64-bit version of the Java Runtime Environment (JRE). The latter will probably make more memory available to the application than the 32-bit version, but the running program will not care about this difference as long as it doesn't make native operating system calls or require gigabytes of memory.

Finally, it should be noted that each application that runs on JVM loads its own instance of JVM on system memory. This means when you run multiple Java applications at the same time, they will all have their own copy of JVM at their disposal; this also means different applications can use different versions of JVM if required for whatever reason. For security reasons, it is not suggested that you have different versions of the JDK or JRE on one system; it's usually better to have only the latest supported versions installed.

Although not dictated anywhere, all popular JVM implementations are not just simple interpreters; they feature complex JIT compilers along with their interpreters.

When you launch a Java application, JVM is launched and initialized first. Once this is done, it immediately starts interpreting and running the Java bytecode. If the interpreter believes it makes sense, it will compile sections of the programs and load libraries to native executable code in memory and start executing that version of the code instead of the interpreted Java bytecode version. This often results in code that could be executed much faster.

Whether the code is compiled or interpreted depends on many things. If a routine is called often, it becomes a probable candidate for the JIT compiler to compile it to the native code.

JVM has a few so-called built-in primitive datatypes. This is the main reason why Java is not considered a pure OOP language. Variables of these types are not objects and always have a value:

Note that not all JVM languages support the creation of variables of primitive types and follow this modern assumption: everything takes the object approach. We will see that this is usually not a problem as the Java Class Library has wrapper objects that wrap primitive types, and most languages, including Java, automatically use these wrappers when required. This process is called auto-boxing.

Functions and variables are always declared inside a class. Even the application entry function that is called upon a program launch, called the main() function, is a function that is located inside a class.

JVM only supports the single-inheritance model. Classes always inherit from one class at the maximum. This is not a big loss. As we will see in the next chapter, a structure called an interface comes to the rescue. An interface is basically a list of function prototypes (only the definition of functions, without code) and constants. Classes that implement an interface are required by the compiler to have implementations for those functions. Classes can implement as many interfaces as they want, but they must provide implementations for each method of all the implemented interfaces.

JVM classes are usually grouped in packages. In the next chapter, we will see how classes are organized.

Like most modern programming languages, JVM does not work with direct memory pointers to objects; it uses reference types. A reference type variable either points to a specific instance of a class or it points to nothing.

If a reference type points to an object, it can be used to call the object's methods or access public attributes.

If a reference type points to nothing, it is called a null reference. When calling methods or reading attributes using a null reference, an error will be generated at runtime. We will see that some languages covered in this book came up with solutions to this common problem.

    Product p = new Product();
    p.setName("Box of biscuits");

    p = null;
    p.setName("This line will produce an error at run-time");

JVM does not require the programmer to manually allocate and release blocks of memory when creating or disposing of objects. The programmer can generally concentrate on just creating objects when he or she needs them.

A process known as the GC halts the application at certain intervals and scans the memory for objects that are no longer in scope (not reachable by any other object loaded at that point). It will remove those objects that can safely be deleted from the memory and reclaim the freed space.

This process used to cause very serious performance issues in the past, but the algorithm has improved much over the years. Also, if an application needs it, system administrators can configure many parameters of the GC to better control it.

The developer should always keep the high-level concept of the GC algorithm in mind. If you keep creating tons of objects and always keep them in the scope (meaning making it in such a way that all those objects can be reached, for example, by storing them in a list that the application can access), then out of the memory, errors are very likely to occur sooner or later.

Example

Let's assume you have developed an e-commerce application for an online store. Also, let's assume that each logged-in user has their own ShoppingBasket instance that holds the products that they add to their basket.

Say, a user has logged in today and is planning to buy a soap bar and a delicious pack of cookies. For this user, the application will create two Product instances, one for each chosen product, and add them to the products list of ShoppingBasket:

Just before visiting the checkout page, the user sees that Amazon offers the same cookies at a much better price and decides to remove the cookies from the basket. Technically, the application would remove the Product instance from the list of products. But from there on, the product instance representing Chocolate cookies is an orphan object. As there is no reference to it, it cannot be reached by the application:

After a while, JVM's GC kicks in and sees the Chocolate cookies object instance. It determines that the object cannot be reached in any way by the application anymore and therefore decides to remove it. The memory the object was using up will now be released:

There are several tricks to tame GC. One well-known trick when an application needs to work with lots of similar objects is to put these objects in a pool (list of objects). When an application needs an object, it simply gets one from the pool and modifies the object according to its needs. When it has finished and doesn't need the object anymore, it will put it back in the pool. Since these objects are always in the scope (when not used, in the pool, which the application can access), GC will not try to dispose of these objects.

The maintainers of JVM and Java Class Library understand the needs of business developers. The code that is written today should ideally run tomorrow. JVM offers reasonable backward compatibility. Developers familiar with Python 2 and 3 will know that this is not a given in the industry.

Newer JVM versions can run applications that were compiled for older JVM versions, as long as the application's code does not use APIs or technologies that were removed from the JVM version that is running the application. Here's an example: libraries compiled for Java 6 can still be loaded and used in projects that run on a Java 8 JVM instance. But this is not the case the other way around; applications running on a Java 6 JVM instance cannot load classes compiled for later versions.

Of course, like every other platform or language, the JDK and Java Class Library maintainers have to deprecate classes and whole technologies from time to time. While there are issues, backward compatibility on JVM is generally better than many other platforms and languages. Also, APIs are generally only removed if proper and well-documented alternatives exist.

Back when projects were simpler, simple batch or operating system shell script files used to automate the compiling and packaging process. As projects became more complex, it became harder to define these scripts. For different operating systems, completely different scripts had to be written.

Soon, the first set of dedicated Java build tools appeared. These worked with XML build files. More or less, cross-platform compatible scripts could be written this way. At first, long and cumbersome scripts had to be written; later, tools worked with the convention over configuration paradigm. When using the conventions suggested by the tool, much less code has to be written; however, if your situation is different from the default behavior, it can take a lot of effort to let the tools do what you want or need. Newer tools ditch XML files and provide script languages to automate the building.

Some of the features that many of those tools offer are as follows:

The JDK does not offer a build tool itself, but it will be hard to find projects that do not at least use one of the following open source build automation tools:

JVM programmers that use a popular IDE do not have to worry too much about build automation tools. This is because all IDEs can generate build scripts themselves. If you want more control, you can start writing your own scripts manually and let the IDE use that script to compile, test, and run your project.

This is the most important edition. When people mention the term "Java," they usually refer to this edition. This book concentrates solely on the Java SE platform.

This edition is meant to run on desktop machines and servers, and as we will see later, an embedded version is also available and bundled with Raspberry Pi's Linux distribution. Java SE comes with the complete Java Class Library. It includes the classic Swing GUI Toolkit; most versions also contain the modern JavaFX GUI toolkit.

Java SE is mostly meant to create standalone consoles, desktop GUIs, or headless applications; alternatively, it is used to create external libraries.

Java EE builds upon Java SE; therefore, it requires that Java SE is installed. It adds lots of APIs in a lot of categories. Java EE applications usually run inside JVM application servers. This book does not cover Java EE in depth but will mention it from time to time. This is because it is a very important addition to the Java platform, especially for business developers.

It is not possible to download a Java EE standalone edition from the Oracle website; instead, you will have to download a full application server that is compatible with the Java EE platform version you want to use. Some IDEs bundle the Java EE application server as well; we will cover this in the next chapter.

The Java EE standard only describes the APIs that must be available, but it does not dictate the implementation. It's up to the Java EE-compatible application servers to come up with actual implementations that adhere to these standards.

Before the days of iOS and Android, Java ME happened to be an important platform for feature phones and early smartphones for games and some basic applications. iOS and Android both never supported Java ME applications, so nowadays it does not play a major role anymore.

It featured a subset of the Java Class Library and offered some additional APIs to work with mobile devices. Java ME got a second life as Java ME Embedded, which can be used for commercial IoT devices.

Since Java is a language that is originally designed to run on JVM, why would anyone choose another language for JVM development?

There are several reasons why a developer would do this:

    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;
      }
    }

    data class Person(val name: String)

Many languages offer good interoperability with Java, and therefore, with other JVM languages as well. Languages do this if they use standard Java Class Library classes, where possible, for their data structures and compile methods in a similar way as Java would have done.

It's not uncommon to have certain classes compiled in a different language in a Java project. One should be aware of the various issues, though:

It is quite a common approach to test Java code with unit tests written in a different language. As we have seen earlier in this chapter, the code in other languages can be much more compact than the same code in Java, which is ideal for writing small, concrete, and readable unit tests.

Since the language's runtime library will only be used while running the unit tests, the language's runtime library itself will only be used while executing the tests and it will not have to be bundled with the compiled main project.