Using the Java 9 compiler and runtime

Let's get started with the first step--compiling and running an old code base using the Java 9 compiler and runtime. It'll be great if things work as-is. If changes are required, we'd like to make as few of them as possible.

First, make sure you are using Java 9 using the following command. If you have a different version, you'll need to switch, as covered in Chapter 2, Creating Your First Java Module:

$ java --version  

From the project folder, create a new out directory for our compiled classes and run the following Java compiler command to compile all the .java files:

$ mkdir out
$ javac -cp lib/commons-collections4-4.1.jar  -d out $(find . -name 
'*.java')

In the preceding javac command, we are adding the commons collections JAR file to the classpath using the -cp option, specifying the output directory for the compiled classes using the -d option and then specifying all the .java files in the following directories recursively using $(find . -name '*.java').

The compilation step should go through fine without any errors. Great! Let's try to run it:

$ java -cp out:lib/commons-collections4-4.1.jar  
com.packt.sortstrings.app.App

In the preceding java command, we are specifying two paths in the classpath -cp option--the out directory that contains the compiled classes and the common collections JAR file. Following that is the fully qualified class name of the class with the main method.

Notice that we are still using classpath and not the concept of module path. Java 9 still works with classpath, and with the same -cp option as did the previous Java versions. More on that shortly.

Running the command should result in success, with the prompt being displayed as expected. And there you have it! A Java 8 application has compiled and executed using Java 9, and not a single line of code needed to be changed! As much as I'd love to tell you that all legacy code will work just as easily as this, it is unfortunately not true. There are some cases that need more effort. However, the good thing is that in the majority of the cases, this process should be this effortless. We'll look at some of the cases where you might run into problems, and how to address them in the next section. But first, knowing what we now know about Java 9, isn't it surprising that everything worked well? If you think about it, both the compilation and execution should have failed! Why? Here are a couple of reasons:

  • We learned that Java 9 is moving to a module system and that everything, be it the application code or the platform, should be in a module! Our Java 8 code is obviously not in a predefined module. That's fine in Java 8, but shouldn't that have caused an error in Java 9?
  • Notice that App.java is using the Java logging API. We've learned in Chapter 4Introducing the Modular JDK that the logging APIs have been bundled into a separate platform module called java.logging . And all code that accesses any module that's not java.base should require it explicitly. That's clearly not happening in the code here, because this is Java 8 code, and there's no module-info.java module definition to begin with.

This begs the question--how did compiling and executing this code in Java 9 still work? It all works thanks to some special features introduced in the language to support this very process--executing legacy code in Java 9. The specific feature that's working for us here is called the unnamed module.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.32.67