Java 9 Programming By Example

It is like going through a path in a forest. You can focus on the gravel of the road but it is pointless. Instead, you can enjoy the view, the trees, the birds, and the environment around you, which is more enjoyable. This book is similar as I won't be focusing only on the language. From time to time, I will cover topics that are close to the road and will give you some overview and directions on where you can go further after you finish this book. I will not only teach you the language but also talk a bit about algorithms, object-oriented programming principles, tools that surround Java development, and how professionals work. This will be mixed with the coding examples that we will follow. Lastly, the final chapter will be fully devoted to the topic, what to learn next and how to go further to become a professional Java developer.

By the time this book gets into print, Java will have completed 22 years. http://www.oracle.com/technetwork/java/javase/overview/javahistory-index-198355.html. The language has changed a lot during this period and got better. The real question to ask is not how long has it been here, but rather how long will it stay? Is it still worth learning this language? There are numerous new languages that have been developed since Java was born (http://blog.takipi.com/java-vs-net-vs-python-vs-ruby-vs-node-js-who-reigns-the-job-market/). These languages are more modern and have functional programming features, which, by the way, Java has also had since version 8. Many say that Java is the past—the future is Scala, Swift, Go, Kotlin, JavaScript, and so on. You can add many other languages to this list, and for each, you can find a blog article that celebrates the burial of Java. There are two answers to this concern-one is a pragmatic business approach, the other is more engineering:

To understand and learn the basic operation of JVM is almost as important as the language itself. Java is a compiled and interpreted language. It is a special beast that forges the best of both worlds. Before Java, there were interpreted and compiled languages.

Interpreted languages are read from the source code by the interpreter and then the interpreter executes the code. In each of these languages, there is some preliminary lexical and syntax analysis step; however, after that, the interpreter, which, as a program itself, is executed by the processor and the interpreter continuously, interprets the program code to know what to do. Compiled languages are different. In such a case, the source code is compiled to binary (.exe file on Windows platforms), which the operating system loads and the processor directly executes. Compiled programs usually run faster, but there is usually a slower compilation phase that may make the development slower, and the execution environment is not so flexible. Java combined the two approaches.

To execute a Java program, the Java source code has to be compiled to the JVM byte code (.class file), which is loaded by JVM and is interpreted or compiled. Hmm... is it interpreted or compiled? The thing that came with Java is the Just in Time (JIT) compiler. This makes the phase of the compilation that is calculation-intensive and the compilation for compiled languages relatively slow. JVM first starts to interpret the Java byte code and, while doing that, it keeps track of execution statistics. When it gathers enough statistics about code executions, it compiles to native code (for example, x86 code on an Intel/AMD platform) for direct execution of the parts of code that are executed frequently and keeps interpreting the code fragments that are rarely used. After all, why waste expensive CPU time to compile some code that is hardly ever used? (For example, code that reads configuration during startup and does not execute again unless the application server is restarted.) Compilation to the byte code is fast and code generation is done only for the segments that pay off.

It is also interesting that JIT uses the statistics of the code execution to optimize the code. If, for example, it sees that some conditional branch is executed in 99% of the cases and the other branch is executed only in 1%, then it will generate native code that runs fast, thus favoring the frequent branch. If the behavior of that part of the program changes by time and the statistic shows that the ratios changed, the JIT automatically recompiles the byte code from time to time. This is all automatic and behind the scenes.

In addition to the automatic compilation, there is also an extremely important feature of JVM-it manages the memory for the Java program. The execution environment of modern languages do that and Java was the first mainstream language that had an automatic garbage collection (GC). Before Java, I was programming in C for 20 years and it was a great pain to keep track of all memory allocation and not to forget to release the memory when the program no longer needed it. Forgetting memory allocation at a single point in the code and the long running program was eating up all memory slowly. Such problems practically ceased to exist in Java. There is a price that we have to pay for it—GC needs processor capacity and some extra memory, but that is something we are not short of in most of the enterprise applications. Some special programs, like real-time embedded systems that control the brakes of a heavy-duty lorry may not have that luxury. Those are still programmed in assembly or C. For the rest of us, we have Java, and though it may seem strange for many professionals, even almost-real-time programs, such as high-frequency trading applications, are written in Java.

These applications connect through the network to the stock exchange and they sell and buy stocks responding to market change in milliseconds. Java is capable of doing that. The runtime environment of Java that you will need to execute a compiled Java code, which also includes the JVM itself, contains code that lets Java programs access the network, files on disks, and other resources. To do this, the runtime contains high-level classes that the code can instantiate, execute, and which do the low-level jobs. You will also do this. It means that the actual Java code does not need to handle IP packets, TCP connections, or even HTTP handling when it wants to use or provide a REST service in some microservices architecture. It is already implemented in the runtime libraries, and all the application programmer has to do is to include the classes in the code and use the APIs they provide on an abstraction level that matches the program. When you program in Java, you can focus on the actual problem you want to solve, which is the business code and not the low-level system code. If it is not in the standard library, you will find it in some product in some external library, and it is also very probable that you will find an open source solution for the problem.

This is also a strong point of Java. There is a vast number of open source libraries available for all the different purposes. If you cannot find a library fitting your problem if you start to code some low-level code, then probably you are doing something wrong. There are topics in this book that are important, such as class loaders or reflection, not because you have to use them every day but rather because they are used by frameworks, and knowing them helps understand how these frameworks work. If you cannot solve your problem without using reflection or writing your own class loader or program multithread directly, then you probably chose the wrong framework. There is almost certainly a good one: Apache project, Google, and many other important players in the software industry publish their Java libraries as open source.

This is also true for multithread programming. Java is a multithread programming environment from the very beginning. The JVM and the runtime supports programs that execute the code. The execution runs parallel on multiple threads. There are runtime language constructs that support parallel executing programs starting at the very low level to high abstraction. Multithread code utilizes the multicore processors, which are more effective. These processors are more and more common. 20 years ago, only high-end servers had multiple processors and only Digital Alpha processors had 64-bit architecture and CPU clock above 100 MHz. 10 years ago, multiprocessor structure was common on the server side, and about 5 years ago, multicore processors were on some desktops and on notebooks. Today, even mobile phones have them. When Java was started in 1995, the geniuses who created it had seen this future.

They envisioned Java to be a write once, run anywhere language. At that time, the first target for the language was applet running in the browser. Today, many think (and I also share this opinion) that applets were a wrong target, or at least things were not done in the right way. As for now, you will meet applets on the Internet less frequently than Flash applications or dinosaurs.

However, at the same time, the Java interpreter was also executing server and client applications without any browser; furthermore, as the language and the executing environment developed, these application areas became more and more relevant. Today, the main use of Java is enterprise computing and mobile applications mainly for the Android platform; for the future, the use of the environment is growing in embedded systems as the Internet of things (IoT) comes more and more into picture.

To develop, compile, and execute Java programs, you will need the Java execution environment. As the operating systems that we usually use for software development do not contain the language preinstalled, you will have to download it. Although, there is multiple implementation of the language, I recommend that you download the official version of the software from Oracle. The official site for java is http://java.com and this is the site from where the latest release of the language can be downloaded. At the time of writing this book, the 9th version of Java is not yet released. An early pre-release version is accessible via http://jdk9.java.net/download. Later the release versions will also be available from here.

What you can download from here is a so called early access version of the code that is available only to experiment with it, and no professionals should use it for real professional purposes

On the page, you have to click on the radio button to accept the license. After that, you can click on the link that directly starts the download of the installation kit. The license is a special early access license version that you, as a professional, should carefully read, understand, and accept only if you are agreeable with the terms.

There is a separate installation kit for Windows 32 and 64 bit systems, Mac OS X, Linux 32 and 64 bit versions, Linux for ARM processor, Solaris for SPARC processor systems, and Solaris x86 versions. As it is not likely that you will use Solaris, I will detail the installation procedure only for Windows, Linux, and Mac OS X. In later chapters, the samples will always be Mac OS X, but since Java is a write once, run anywhere language, there is no difference after the installation. The directory separator may be slanted differently, the classpath separator character is a semicolon on Windows instead of a colon, and the look and feel of the Terminal or command application is also different. However, where it is important, I will try not to forget to mention it.

To confuse you, the Java download for each of these operating system versions lists a link for the JRE and one for the JDK. JRE stands for Java Runtime Environment and it contains all the tools and executables that are needed to run Java programs. JDK is the Java Development Kit that contains all the tools and executables that are needed to develop Java programs including the execution of the Java program. In other words, JDK contains its own JRE. For now, all you need to do is download the JDK.

There is one important point of the installation that is the same on each of the three operating systems that you have to be prepared for before the installation: to install Java, you should have administrative privileges.

Installation on Windows

The installation process on Windows starts by double clicking on the downloaded file. It will start the installer that will present you a welcome screen.

Pressing the Next button we get a window where you can select the parts you want to install. Let's leave here the default selection, which means that we install all the downloaded parts of Java and press the button Next. The following window is where we can select the destination folder for the installation.

As for now we do not change the directory selected by the installer. Press Next. Later, when you become a professional Java developer, you may decide to install Java to a different location but then you will already have to know what you are doing.

You may need to click the Next button a few times and then the installer finishes. Provide the administrative password when asked and voila! Java is installed. This is really the very usual Windows installation process.

The last step is to set the environment variable JAVA_HOME. To do that in Windows we have to open the control center and select the Edit environment variables for your account menu.

This will open a new window that we should use to create a new environment variable for the current user.

The name of the new variable has to be JAVA_HOME and the value should point to the installation directory of the JDK.

This value on most of the systems is C:Program FilesJavajdk-9. This is used by many Java programs and tools to locate the Java runtime.

Installation on MAC OS X

In this section, we will take look at how to install Java step-by-step on an OS X platform. I will describe the installation process for the released version available at the time of writing this book. As for now, the Java 9 early access version is a bit tricky to install. It is probable that version Java 9 will have similar or the same install steps as Java 8 update 92 has.

The OS X version of Java comes in the form of a .dmg file. This is a packaging format of OS X. To open it, simply double click on the file in the Download folder where the browser saves it and the operating system will mount the file as a read-only disk image.

There is only one file on this disk: the installation image. Double click on the file name or icon in the Finder application and the installation process will start.

The first screen opening is a welcome screen. Click Continue and you will see the Summary page that displays what will be installed.

It is not a surprise that you will see a standard Java installation. This time, the button is called Install. Click on it and you will see the following:

This is the time when you have to provide the login parameters for the administrative user—a username and password. When provided, installation starts and, in a few seconds, you will see a Summary page.

Click Close and you are ready. You have Java installed on your Mac. Optionally, you can dismount the installation disk and, sometime later, you can also delete the .dmg file. You will not need that, and in case you do, you can download it any time from Oracle.

The last thing is to check whether the installation was okay. Proof of the pudding is eating it. Start a Terminal window and type java -version at the prompt and Java will tell you the version installed.

On the next screenshot you can see the output on my workstation and also the Mac OS commands that are handy to switch between the different versions of Java:

On the screenshot, you can see that I have installed the Java JDK 1.8u92 version and, at the same time, I also have a Java 9 early release installation, which I will use to test the new features of Java for this book.

Installation on Linux

There are several ways to install Java on Linux, depending on its flavor. Here, I will describe an installation method that works more or less the same way on all flavors. The one I used is Debian.

First step is the same as in any other operating system: download the installation kit. In the case of Linux, you should select a package that has a tar.gz ending. This is a compressed archive format. You should also carefully select the package that matches the processor in your machine and the 32/64 bit version of the operating system. After the package is downloaded, you have to switch to root mode, issuing the su command. This the first command you can see on the screenshot that shows the installation commands.

The tar command uncompressed the archive into a subfolder. In Debian, this subfolder has to be moved to /opt/jdk and the mv command is used for this purpose. The two update-alternatives command is Debian-specific. These tell the operating system to use this newly installed Java in case there is already an older Java installed. The Debian I was using to test and demonstrate the installation process on a virtual machine came with a 7 year old version of Java.

The final step of the installation is the same as any other operating system: checking that the installation was successful in issuing the java -version command. In the case of Linux, this is even more important because the installation process does not check that the downloaded version matches the operating system and the processor architecture.

~$ /usr/libexec/java_home -V
Matching Java Virtual Machines (10):
    9, x86_64:    "Java SE 9-ea"    /Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home
    1.8.0_92, x86_64:    "Java SE 8"    /Library/Java/JavaVirtualMachines/jdk1.8.0_92.jdk/Contents/Home
    1.7.0_60, x86_64:    "Java SE 7"    /Library/Java/JavaVirtualMachines/jdk1.7.0_60.jdk/Contents/Home
/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home

export JAVA_HOME=$(/usr/libexec/java_home)

export JAVA_HOME=$(/usr/libexec/java_home -v 1.8)

export JAVA_HOME=$(/usr/libexec/java_home -v 9)

Now that we have spent a lot of time installing Java, it is time to get the fingers burnt a bit. As we are using Java 9, there is a new tool that helps developers to play around with the language. This is a Read-Eval-Print-Loop (REPL) tool that many language toolsets contain and there were also implementations from Java, but version 9 is the first that contains this feature off the shelf.

REPL is a tool that has interactive prompt and language commands that can be directly entered without editing some standalone file. The entered commands are executed directly and then the loop starts again, waiting for the user to type in the next command. This is a very effective tool to try out some language constructs without the delay of editing, compiling, and loading. The steps are automatically and transparently done by the REPL tool.

The REPL tool in Java 9 is called jshell. To start it, just type its name. If it is not on the PATH, then type the full path to jshell that comes installed with Java 9, as shown in the following example:

$ jshell
|  Welcome to JShell -- Version 9-ea
|  For an introduction type: /help intro
jshell> 

The jshell starts up in an interactive way and the prompt it displays is jshell> to help you recognize that jshell is running and what you type is read by the program and not the operating system shell. As this is the first time you will start jshell, it tells you to type /help intro. Let's do it. It will print out a short text about what jshell is, as shown in the following code:

jshell> /help intro
|  
|  intro
|  
|  The jshell tool allows you to execute Java code, getting immediate results.
|  You can enter a Java definition (variable, method, class, etc), like:  int x = 8
|  or a Java expression, like:  x + x
|  or a Java statement or import.
|  These little chunks of Java code are called 'snippets'.
|  
|  There are also jshell commands that allow you to understand and
|  control what you are doing, like:  /list
|  
|  For a list of commands: /help

Okay, so we can type Java snippets and /list, but that is only one example of the available commands. We can hope for more information by typing /help, as shown in the following code:

jshell> /help
|  Type a Java language expression, statement, or declaration.
|  Or type one of the following commands:
|     /list [<name or id>|-all|-start]                             -- list the source you have typed
|     /edit <name or id>                                           -- edit a source entry referenced by name or id
|     /drop <name or id>                                           -- delete a source entry referenced by name or id
|     /save [-all|-history|-start] <file>                          -- Save snippet source to a file.
...

What you get is a long list of commands. Most of it is not presented here to save paper and your attention. We will use many of these commands on our journey through the next few pages. Let's start with a small Java snippet that is the ageless Hello World example:

jshell> System.out.println("Hello World!")
Hello World!

This is the shortest ever Hello World program in Java. Till Java 9, if you wanted to do nothing more than print out Hello World!, you had to create a program file. It had to contain the source code of a class including the public static main method, which contained the one line we had to type in with Java 9 jshell. It was cumbersome just for a simple printout of sample code. Now it is much easier and jshell is also lenient, forgiving us the missing semicolon at the end of the line.

The next thing we should try is declaring a variable, as follows:

jshell> int a = 13
a ==> 13
jshell> 

We declared a variable, named a, and assigned the value to it-13. The type of the variable is int, which is an abbreviation for integer types in Java. Now we have this variable already in our snippet, so we can print it out if we want to as shown:

jshell> System.out.println(a)
13

It is time to write something more complex into jshell than a one liner.

jshell> void main(String[] args){
   ...>  System.out.println("Hello World")
   ...> }
|  Error:
|  ';' expected
|   System.out.println("Hello World")
|                             

The jshell recognizes that this is not a one-liner and that it cannot process what we typed so far, when we press Enter at the end of the first line, and it signals that it expects more characters from us, so it displays ...> as a continuation prompt. We type in the commands that make up the whole hello world main method, but this time jshell does not let us miss the semicolon. That is allowed only in the case of one-line snippets. As jshell is interactive, it is easy to correct the mistake; press the up arrow key a few times to get back the previous lines and, this time, add the semicolon at the end of the second line:

jshell> void main(String[] args){
   ...>  System.out.println("Hello World");
   ...> }
|  created method main(String[])

This method was created for us as a snippet and now we can call it:

jshell> main(null)
Hello World

And it works. You can list all the snippets that were created, as follows:

jshell> /list
   1 : System.out.println("Hello World!")
   2 : int a = 13;
   3 : System.out.println(a)
   4 : void main(String[] args){
               System.out.println("Hello World");
              }

And, as we want to go on writing a full Java version of hello world, we can save our work from jshell to a file, as follows:

jshell> /save HelloWorld.java

Finally, we exited from jshell by typing /exit. As you get back to the system prompt, type cat HelloWorld.java (or type HelloWorld.java on Windows) to see the content of the file. It is as follows:

$ cat HelloWorld.java
System.out.println("Hello World!")
int a = 13;
System.out.println(a)
void main(String[] args){
        System.out.println("Hello World");
       }

The file contains all the snippets that we typed in one after the other. If you think that you have messed up the shell with lots of variables and code snippets that you do not need anymore, you can issue the /reset command:

jshell> /reset
|  Resetting state.

After this command, the jshell is as clean as when it was started earlier

jshell> /list

jshell>

Listing just does not produce anything as we deleted it all. Fortunately, we saved the state of jshell to a file and we can also load the content of the file issuing the /open command:

jshell> /open HelloWorld.java
Hello World!
13

It loads the line from the file and executes it just as the characters were typed into the Command Prompt.

You may recall that the /list command printed a number in front of each snippet. We can use it to edit the snippets individually. To do so, issue the /edit command followed by the number of the snippet:

jshell> /edit 1

You may recall that the first command we entered was the System.out.println system call that prints out the argument to the console. When you press Enter after the /edit 1 command, you do not get the prompt back. Instead, jshell opens a separate graphical editor that contains the snippet to edit as shown in the following image:

Edit the text in the box so that it will look like this:

printf("Hello World!")

Click on Accept and then Exit. When you click on Accept, the Terminal will execute the snippet and display the following result:

Hello World!

The method that we used, printf, stands for formatted printing. This may be well known from many other languages. It was first introduced by the C language and though cryptic, the name survived. This is also part of the standard Java class, PrintStream, just like println. In case of println, we had to write System.out in front of the method name. In case of printf, we did not. Why?

The reason is that jshell defines a few snippets that are automatically loaded when jshell starts or resets. You can see these if you issue the /list command with the -start option, as follows:

jshell> /list -start

  s1 : import java.util.*;
  s2 : import java.io.*;
  s3 : import java.math.*;
  s4 : import java.net.*;
  s5 : import java.util.concurrent.*;
  s6 : import java.util.prefs.*;
  s7 : import java.util.regex.*;
  s8 : void printf(String format, Object... args) { System.out.printf(format, args); }

These predefined snippets help the use of jshell. Most of the users will import these classes, and to ease the print to screen, it defines a method snippet that happens to have the name, printf, which is also the name of a method in the PrintStream class.

If you want to list all the snippets you entered as well as the predefined snippets and also those that contained some error and thus were not executed, you can use the -all option to the /list command, as follows:

jshell> /list -all

...
  s7 : import java.util.regex.*;
...
   1 : System.out.println("Hello World!")
...
  e1 : System.out.println("Hello World!")
       int a = 14;
   5 : System.out.println("Hello World!");
...

Some of the lines were deleted from the actual output for brevity. The lines that are preloaded are numbered with the s prefix. The snippets that contain an error have a number prefixed with e.

If you want to execute some of the snippets again, you only have to type /n where n is the number of the snippet, as follows:

jshell> /1
System.out.println("Hello World!")
Hello World!

You cannot re-execute the preloaded snippets or snippets that contained errors. There is no need for any of those anyway. Preloaded snippets declare some imports and define a snippet method; erroneous snippets do not execute because they are, well...erroneous.

You need not rely on the number of jshell when you want to re-execute a snippet. When you already have a lot of snippets in your jshell session, listing them all would be too cumbersome; there is a shortcut to re-execute the last n-th snippet. You have to write /-n. Here, n is the number of the snippet counting from the last one. So, if you want to execute the very last snippet, then you have to write /-1. If you want to execute the one before the last one, you have to write /-2. Note that if you already typed /-1, then the last one is the re-execution of the last snippet and snippet number -2 will become number -3.

Listing all the snippets can also be avoided in other ways. When you are interested only in certain types of snippets, you can have special commands.

If we want to see only the variables that we defined in the snippets, then we can issue the /vars command, as follows:

jshell> /vars
|    int a = 13

If we want to see only the classes, the command/types will do that:

jshell> class s {}
|  created class s

jshell> /types
|    class s

Here, we just created an empty class and then we listed it.

To list the methods that were defined in the snippets, the /methods command can be issued:

jshell> /methods
|    printf (String,Object...)void
|    main (String[])void

You can see in the output that there are only two methods, which are as follows:

If you want to see everything you typed, you have to issue the /history command for all the snippets and commands that you typed. (I will not copy the output here; I do not want to shame myself. You should try yourself and see your own history.)

Recall that we can delete all the snippets issuing the /reset command. You can also delete snippets individually. To do so, you should issue the /drop n command, where n is the snipped number:

jshell> /drop 1
|  This command does not accept the snippet '1' : System.out.println("Hello World!")
|  See /types, /methods, /vars, or /list

Oops! Something went wrong. There is nothing defined when snippet number 1 was executed and the /drop command actually drops the defined variable, type, or method. There is nothing to be dropped in the first snippet. But, if we reissue the /list command, we will get the following results:

jshell> /list

   1 : System.out.println("Hello World!")
   2 : int a = 13;
   3 : System.out.println(a)
   4 : void main(String[] args){
               System.out.println("Hello World");
              }

We can see that we can drop the second or the fourth snippet, too:

jshell> /drop 2
|  dropped variable a

jshell> /drop 4
|  dropped method main(String[])

When we were editing the snippets, jshell opened a separate graphical editor. It may happen that you are running jshell using ssh on a remote server and where it is not possible to open a separate window. You can set the editor using the /set command. This command can set quite a few configuration options of the jshell. To set the editor to use the ubiquitous vi, issue the following command:

jshell> /set editor "vi"
|  Editor set to: vi

After this, jshell will open the snipped-in vi in the same Terminal window where you issue the /edit command.

It is not only the editor that you can set. You can set the startup file, and the way jshell prints the feedback to the console after a command was executed.

If you set the startup file, then the commands listed in the startup file will be executed instead of the built-in commands of jshell after the /reset command. This also means that you will not be able to use the classes directly that are imported by default and you will not have the printf method snippet, unless your own startup file contains the imports and the definition of the snippet.

Create the sample.startup file with the following content:

void println(String message) { System.out.println(message); }

Starting up a new jshell and executing it is done as follows:

jshell> /set start sample.startup

jshell> /reset
|  Resetting state.

jshell> println("wuff")
wuff

jshell> printf("This won't work...")
|  Error:
|  cannot find symbol
|    symbol:   method printf(java.lang.String)
|  printf("This won't work...")
|  ^----^

The println method is defined but the printf method, which was defined in the default startup, is not.

The feedback defines the prompt jshell prints and then waits for the input, the prompt for the continuation lines, and the message details after each command. There are predefined modes, which are as follows:

Normal is selected by default. If you issue /set feedback silent, then prompt becomes -> and jshell will not print details about the commands. The /set feedback concise code prints a bit more information and /set feedback verbose prints verbose information about the commands executed:

jshell> /set feedback verbose
|  Feedback mode: verbose

jshell> int z = 13
z ==> 13
|  modified variable z : int
|    update overwrote variable z : int

You can also define your own modes, giving a name to the new mode using the /set mode xyz command where xyz is the name of the new mode. After this, you can set prompt, truncation, and format for the mode. When the format is defined, you can use it the same way as the built-in modes.

Last, but not least, the most important command of jshell is /exit. This will just terminate the program and you will return to the operating system shell prompt.

Now, let's edit the HelloWorld.java file to create our first Java program. To do so, you can use vi, notepad, Emacs, or whatever is available on your machine and fits you. Later on, we will use some integrated development environment (IDE), NetBeans, Eclipse, or IntelliJ; however, for now, a simple text editor is enough.

Edit the file so that the content will be as follows:

public class HelloWorld { 
  public static void main(String[] args){ 
        System.out.println("Hello World"); 
       } 
  }

To compile the source code to byte code, which is executable by JVM, we have to use the Java compiler named javac:

javac HelloWorld.java

This generates the java.class file in the current directory. This is a compiled code that can be executed as follows:

$ java HelloWorld
Hello World

With this one, you have created and executed your first full Java program. You may still wonder what we were doing. How and why, I will explain it; but first, I wanted you to have a feeling that it works.

The file we edited contained only the snippet and we deleted most of the lines, except the declaration of the main method and we inserted the declaration of the class around it.

In Java, you cannot have standalone methods or functions, like in many other languages. Every method belongs to some class and every class should be declared in a separate file (well, almost, but for now, let's skip the exceptions). The name of the file has to be the same as the name of the class. The compiler requires this for public classes. Even for non-public classes we usually follow this convention. If you renamed the file from HelloWorld.java to Hello.java, the compiler will display an error when you try to compile the file with the new name.

$ mv HelloWorld.java Hello.java
~/Dropbox/java_9-by_Example$ javac Hello.java
Hello.java:2: error: class HelloWorld is public, should be declared in a file named HelloWorld.java
public class HelloWorld {
       ^
1 error

So, let's move it back to the original name: mv Hello.java HelloWorld.java.

The declaration of the class starts with the keyword class, then the name of the class, an opening curly brace, and lasts until the matching closing brace. Everything in between belongs to the class.

For now, let's skip why I wrote public in front of the class and focus on the main method in it. The method does not return any value, therefore; the return value of it is void. The argument, named args, is a string array. When JVM starts the main method, it passes the command-line arguments to the program in this array. However, this time we do not use it. The main method contains the line that prints out Hello World. Now, let's examine this line a bit more.

In other languages, printing something to the console requires only a print statement or a very similar command. I remember that some BASIC interpreters even allowed us to type ? instead of print because printing to the screen was so common. This has changed a lot during the last 40 years. We use graphical screens, Internet, and many other input and output channels. These days, it is not very common to write to the console.

Usually, in professional large-scale enterprise applications, there is not even a single line that does that. Instead, we will direct the text to log files, send messages to message queues, and send requests and reply with responses over TCP/IP protocol. As this is so infrequently used, there is no reason to create a shortcut for the purpose in the language. After the first few programs, when you get acquainted with the debugger and logging possibilities, you will not print anything directly to the console yourself.

Still, Java has features that let you send text directly to the standard output of a process the good old way, as it was invented originally for UNIX. This is implemented in a Java way where everything has to be an object or class. To get access to the system output, there is a class named System and it, among other things, has the following three variables:

To refer to the output stream variable, because it is not in our class but in System, we will have to specify the class name so we will refer to it as System.out in our program. The type of this variable is PrintStream, which is also a class. Class and type are synonyms in Java. Every object that is of type PrintStream has a method named println that accepts a String. If the actual print stream is the standard output, and we are executing our Java code from the command line, then the string is sent to the console.

The method is named main and this is a special name in Java programs. When we start a Java program from the command line, JVM invokes the method named main from the class that we specify on the command line. It can do that because we declared this method public so that anyone can see and invoke it. If it was private, it would be seen and callable only from within the same class, or classes, that are defined in the same source file.

The method is also declared as static, which means that it can be invoked without an actual instance of the class that contains the methods. Using static methods is usually seen as not a good practice these days, unless they are implementing functions that cannot really ever be related to an instance, or have different implementations such as the functions in the java.lang.Math class; but, somewhere, the code execution has to start and the Java runtime will not usually create instances of classes for us automatically.

To start the code, the command line should be as follows:

java -cp . HelloWorld

The -cp option stands for classpath. The classpath is a fairly complex idea for java but, for now, let's make it simple and say that it is a list of directories and JAR files that contain our classes. The list separator for the classpath is : (colon) on UNIX-like systems and ; (semicolon) on Windows. In our case, the classpath is the actual directory, as that is the place where the Java compiler created HelloWorld.class. If we do not specify classpath on the command line, Java will use the current directory as a default. That is the reason our program was working without the -cp option in the first place.

Both java and javac handle many options. To get a list of the options type javac -help or java -help. We use the IDE to edit the code and, many times, to compile, build, and run it during development. The environment in this case sets the reasonable parameters. For production we use build tools that also support the configuration of the environment. Because of this, we rarely meet these command line options. Nevertheless, professionals have to understand their meanings at least and know where to learn their actual use in case it is needed.

$ javap HelloWorld.class
Compiled from "HelloWorld.java"
public class HelloWorld {
  public HelloWorld();
  public static void main(java.lang.String[]);
}

$ javap -c HelloWorld.class
Compiled from "HelloWorld.java"
public class HelloWorld {
  public HelloWorld();
    Code:
       0: aload_0
       1: invokespecial #1                  // Method java/lang/Object."<init>":()V
       4: return
  public static void main(java.lang.String[]);
    Code:
       0: getstatic     #2                  // Field java/lang/System.out:Ljava/io/PrintStream;
       3: ldc           #3                  // String hali
       5: invokevirtual #4                  // Method java/io/PrintStream.println:(Ljava/lang/String;)V
       8: return
}

When you deliver a Java application, usually the code is packaged into JAR, WAR, EAR, or some other packaged format. We learn something again that seems to be obscure at first sight, but in reality, this is not that complex. They are all ZIP files. You can open any of these files using WinZip or some other zip manager that you have a license for. The extra requirement is that, for example, in the case of a JAR file, the archive should contain a directory named META-INF and inside it a file named MANIFEST.MF. This file is a text file and contains meta information in the format, which is as follows:

Manifest-Version: 1.0 
Created-By: 9-ea (Oracle Corporation)

There can be a lot of other information in the file, but this is the minimum that the Java provided tool jar puts there if we package our class file into a jar issuing the following command:

         jar -cf hello.jar HelloWorld.class

The -c option tells the JAR archiver to create a new JAR file and the option f is used to specify the name of the new archive. The one we specified here is hello.jar and the file added to it is the class file.

The packaged JAR file can also be used to start the Java application. Java can read directly from JAR archives and load classes from there. The only requirement is that they are on the classpath.

Check that the JAR file was created using ls hello.jar and remove the rm HelloWorld.class class file just to ensure that when we issue the command line, the code is executed from the JAR file and not the class.

$ java -cp hello.jar HelloWorld
Hello World

To see the content of the JAR file, however, it is recommended that you use the JAR tool and not WinZip even though that may be cozier. Real professionals use the Java tools to handle Java files.

$ jar -tf hello.jar 
META-INF/ 
META-INF/MANIFEST.MF 
HelloWorld.class

The Java toolset that comes with the JDK supports the execution and management of running Java applications as well. To have some program that we can manage while executing, we will need a code that runs not only for a few milliseconds but, while it runs, it also prints something to the console. Let's create a new program called HelloWorldLoop.java with the following content:

public class HelloWorldLoop { 
  public static void main(String[] args){ 
       for( ;; ){ 
         System.out.println("Hello World"); 
         } 
       } 
  }

The program contains a for loop. Loops allow repeated execution of a code block, and we will discuss them in Chapter 2, The First Real Java Program - Sorting Names. The loop we created here is a special one that never terminates but repeats the printing method call, printing Hello World until we kill the program by pressing Ctrl + c or issuing a kill command on Linux or on OSX, or terminate the program in the task manager under Windows.

Compile and start it in one window and open another Terminal window to manage the application.

The first command that we should get familiar with is jps. http://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html It lists the Java processes that run on the machine, which are as follows:

$ jps 
21873 sun.tools.jps.Jps 
21871 HelloWorldLoop

You can see that there are two processes—one is the program we execute and the other is the jps program itself. Not surprisingly, the jps tool is also written in Java. You can also pass options to jps, which are documented on the web.

There are many other tools and we will examine one of them, which is a very powerful and easy-to-use tool—Java VisualVM.

VisualVM is a command-line graphical tool that connects to the running Java process and displays the different performance parameters. To start the VisualVM tool, you will issue the jvisualvm command without any parameters. Soon, a window will appear with an exploring tree on the left-hand side and a welcome pane on the right. The left side shows all the running Java processes under the branch named Local. If you double click on HelloWorldLoop, it will open the details of the process on the right pane. On the header tabs, you can select Overview, Monitor, Threads, Sampler, and Profiler. The first three tabs are the most important and give you a good view of what is happening in JVM regarding the number of threads, CPU usage, memory consumption, and so on.

Integrated development environments are outstanding tools that help the development by offloading the mechanical tasks from the developer's shoulders. They recognize many of the programming errors as we type the code, help us find the needed library methods, display the documentation of the libraries, and provide extra tools for style checking, debugging, and so on.

In this section, we will look at some IDEs and how to leverage the functions they provide.

To get an IDE, you will have to download and install it. It does not come with the Java development tools because they are not part of the language environment. But, don't worry. They can be downloaded free of charge and are easy to install. They may be more complex to start up than a notepad editor, but even after a few hours of work, they will pay back the time you devote to learning them. After all, it is not without reason that no developer is coding Java in notepad or vi.

The three topmost IDEs are NetBeans, Eclipse, and IntelliJ. All are available in community versions, which means that you need not pay for them. IntelliJ has a full version that you can also buy. The community edition will be usable for learning the language. In case you do not like IntelliJ, you can use Eclipse or NetBeans. These are all free of charge. Personally, I use the IntelliJ community edition for most of my projects and the screen samples that show an IDE in this book will feature this IDE. But, it does not necessarily mean that you have to stick to this IDE.

To download the IDE of your choice, you can visit either one of the following websites:

IDE services

Integrated development environments provide us with services. The most basic service is that you can edit files with them, but they also help build the code, find bugs, run the code, deploy to the application server in development mode, debug, and so on. In the following sections, we will look at these features. I will not give an exact and precise introduction on how to use one or the other IDE. A book like this is not a good medium for such a tutorial.

IDEs differ on menu placement, keyboard shortcuts, and they may even change as newer versions are released. It is best to look at the actual IDE tutorial video or online help. Their features, on the other hand, are very similar. IntelliJ has the video documentation at https://www.jetbrains.com/idea/documentation/.

IDE screen structure

The different IDEs look similar, and have the same screen structure more or less. In the following screenshot, you can see an IntelliJ IDE:

On the left side, you can see the file structure of a Java project. A Java project typically contains many files in different directories which we will discuss in the next chapter. The simple HelloWorld application contains a pom.xml project description file. This file is needed for the Maven build tool, which is also a topic for the next chapter. For now, you should only know that it is a file that describes the project structure for maven. The IDE also keeps track of some administrative data for itself. It is stored in HelloWorld.iml. The main program file is stored in the src/main/java directory and named HelloWorld.java.

On the right side, you can see the files. In the screenshot, we have only one file opened. In case there is more than one file opened, then there are tabs-one for each file. Now, the active file is HelloWorld.java that can be edited in the source code editor.

Editing files

When editing, you can type in characters or delete characters, words, and lines, but this is something that all editors can do. IDEs offer extra. IDEs analyze the source code and format it, which, in turn, automatically indents the lines. It also continuously compiles the code in the background while you edit it and if there is some syntax error, then it underlines it with a red waiving line. When you fix the error, the red underlining disappears.

The editor also automatically gives suggestions for further characters as you type. You can ignore the window that pops up and continue typing. However, many times, it is easier to stop after a character and use the up and down arrows to select the word that needs finishing before pressing Enter: the word will be inserted into the source code automatically.

In the screenshot, you can see that I wrote System.o and the editor immediately suggested that I wanted to write out. The other alternatives are the other static fields and methods that are in the class System and which contain the letter o.

The IDE editor gives you hints not only when it can type for you, but also when it cannot type instead of you. In the screenshot, the IDE tells you to type some expression as argument to the println()method that is boolean, char, int, and so on. The IDE has absolutely no idea what to type there. You have to construct the expression. Still, it can tell you that it needs to be of a certain type.

It is not only the built-in types that the editor knows. The editor integrated with the JDK continuously scans the source files and knows what classes, methods, and fields are there in the source code which are usable at the place of editing.

This knowledge is also heavily used when you want to rename a method or variable. The old method was to rename the field or method in the source file and then do an exhaustive search for all references to the variable. Using the IDE, the mechanical work is done by it. It knows all the uses of a field or method and automatically replaces the old identifier with the new one. It also recognizes whether a local variable happens to have the same name as the one that we rename, and the IDE only renames those occurrences that are really referring to the one we are renaming.

You can usually do more than just renaming. There are more or less mechanical tasks that programmers call refactoring. These are supported by the IDEs using some keyboard shortcut and context sensitive menu in the editor—right click on the mouse and click Menu.

The IDE also helps you to read the documentation of the libraries and source code as shown in the following image:

Libraries provide Javadoc documentation for the public methods and you should also write Javadoc for your own method. Javadoc documentation is extracted from special comments in the source code and we will learn how to create those in Chapter 4, Mastermind - Creating a Game. These are located in comments in front of the actual method head. As creating compiled documentation is part of the compilation flow, the IDE also knows the documentation and it displays as a hovering box over the method names, class names, or whatever element you want to use in the source file when you position the cursor on the element.

Managing projects

On the left side of the IDE window, you can see the directory structure of the project. The IDE knows the different types of files and shows them in a way that is meaningful from the programming point of view. For example, it does not display Main.java as a filename. Instead, it displays Main and an icon that signals that Main is a class. It can also be an interface still in a file named Main.java but, in that case, the icon will show that this is an interface. This is again done by the IDE continuously scanning and compiling the code.

The files are structured into subdirectories when we develop a Java code. These subdirectories follow the packaging structure of the code. Many times, in Java, we use compound and long package names, and displaying it as a deep and nested directory structure will not be so easy to handle.

Note

Packages are used to group the source files. The source files for classes that are related in some way should go into one package. We will discuss the notion of packages and how to use them in the next chapter

The IDE is capable of showing the package structure instead of the nested directories for those directories of the project that contain source files.

When you move a class or an interface from one package to another, it happens in a similar way as renaming or other refactoring. All references to the class or interface in the source files get renamed to the new package. If a file contains an import statement referring to the class, the name of the class in the statement is corrected. To move a class, you can open the package and use the good old drag and drop.

Package hierarchy is not the only hierarchy displayed in the IDE. The classes are in packages but, at the same time, there is an inheritance hierarchy. Classes may implement interfaces and can extend other classes. The Java IDEs help us by showing type hierarchies where you can navigate across a graphical interface along the inheritance relations.

There is another hierarchy that IDEs can show to help us with development: method call hierarchy. After analyzing the code, the IDE can show us the graph displaying the relations between the methods: which method calls which other methods. Sometimes, this call graph is also important in showing the dependencies of methods on each other.

Build the code and run it

The IDEs usually compile the code for analysis to help us spot syntax errors or undefined classes and methods on the fly. This compilation is usually partial, covering a part of the code, and as it runs all the time, the source code changes and is never actually complete. To create the deployable file, that is, the final deliverable code of the project, a separate build process has to be started. Most of the IDEs have some built-in tool for that, but it's not recommended to use these except for the smallest projects. Professional development projects use Ant, Maven, or Gradle instead. Here is an example of Maven.

The IDEs are prepared to use such an external tool, and they can help us in starting them. This way, the build process can run on the developer machine without starting a new shell window. IDEs can also import the settings from the configuration file of these external build tools to recognize the project structure, where source files are, and what to compile to support the error checking while editing.

The building process usually contains the execution of certain checks on the code. A bunch of the Java source file may compile smoothly and the code may still contain a lot of bugs and may be written in bad style, which will make the project becomes unmaintainable in the long run. To avoid such problems, we will use unit tests and static code analysis tools. These do not guarantee error free code but the chances are much better.

IDEs have plugins to run the static code analysis tools as well as unit tests. Being integrated into the IDE has a huge advantage. When there is any problem identified by the analysis tool, or by some unit tests, the IDE provides an error message that also functions like a link on a web page. If you click on the message, usually blue and underlined, exactly like on a web page, the editor opens the problematic file and places the cursor where the issue is.

Debugging Java

Developing code needs debugging. Java has very good facilities to debug code during development. JVM supports debuggers via the Java Platform Debugger Architecture. This lets you execute code in debug mode and JVM will accept external debugger tools to attach to it via a network, or it will try to attach to a debugger depending on command-line options. JDK contains a client, the jdb tool, which contains a debugger; however, it is so cumbersome to use when compared to the graphical client built into the IDEs that I have never heard of anyone using it for real work.

To start a Java program in debug mode so that JVM will accept a debugger client to attach the options to it, execute the following command:

-Xagentlib:jdwp=transport=dt_socket,server=y,suspend=y,address=7896

The Xagentlib option instructs the Java runtime to load the jdwp agent. The part of the option that follows -Xagentlib:jdwp= is interpreted by the debugger agent. These options are as follows:

• transport: This should specify which transport to use. It can be a shared memory (dt_shmem) socket or a TCP/IP socket transport but, in practice, you will always use the latter. This is specified in the preceding dt_socket sample.
• server: This specifies if the debugged JVM starts in server mode or client mode. When you start the JVM in server mode, it starts to listen on a socket and accepts the debugger to connect to it. If it is started in client mode, then it tries to connect a debugger that is supposed to be started in server mode, listening on a port. The value of the option is y meaning server mode or n meaning nonserver, a.k.a. client mode.
• suspend: This can also be y or n. If JVM is started in suspend mode, it will not start the Java code until a debugger is attached to it. If it is started with suspend=n, then the JVM starts and when a debugger attaches, it stops as soon as a breakpoint is reached. If you start a standalone Java application, you will usually start the debugging with suspend=y, which is the default. If you want to debug an application in an application server or servlet-container environment, then it is better to start with suspend=n; otherwise, the server does not start until the debugger attaches to it. Starting the Java process in suspend=y mode in case servlet application is only useful when you want to debug the servlet static initializer code, which is executed when the server is starting up. Without suspend mode, you will be required to attach the debugger very fast. It is better that JVM just waits for you in that situation.
• address: This should specify the address that JVM communicates with. If the JVM started in client mode, then it will start to connect to this address. If the JVM runs in server mode, then it will accept connections from the debugger on that address. The address may specify only the port. In this case, the IP address is that of the local machine.

The other options the debugger agent may handle are for special cases. For the topics covered in this book, the preceding options are enough.

The following screenshot shows a typical debugging session where we debug the simplest program in IntelliJ IDE:

When you start a program from the IDE in debug mode, all these options are automatically set for you. You can set breakpoint just by clicking on the source code in the editor. You can have a separate form to add, remove, and edit breakpoints. Breakpoints can be attached to specific lines or specific events, like when an exception is thrown. Breakpoints attached to a specific line can also have conditions that tell the debugger to stop the execution of the code only when the condition is true; for example, if a variable has some predefined value.

In this chapter we were introduced to each other with Java. We do not know too much from each other but we got acquainted. We have installed the Java environment: Java, JDK and integrated development environment. We have written a small program and had a brief look at what can be done using the development tools. This is far from mastery but even the longest journey starts with a first step, which is sometimes the hardest to make. We have done it in our Java journey. We started rolling and for the enthusiasts that we are, nothing can stop us walking all the way long.