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.

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.

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.

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.

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.

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:

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.