Last Updated:

Inside the Java Language

How the Java Platform Works

 

In the Java language, as in many other programming languages, you write source code to create a program, then compile it; the compiler verifies that your code conforms to the syntax rules of the language. The Java platform adds another step to this process. After the Java code is compiled, the bytecodes are obtained. The Java Virtual Machine (JVM) then interprets these bytecodes at runtime—that is, when you run a Java program.

From a file system perspective, when you write code, you create a file with a .java extension. After compiling this file, the Java compiler creates a file with a .class extension that contains bytecodes. The JVM reads and interprets this file at runtime, and how it does this depends on the platform you are running on. To work on other platforms, you must compile your source code with libraries specific to that platform. As you can imagine, the promise of "Write Once, Run Anywhere" turns into a "Write Once, Test Anywhere" saying. There are subtle (or not-so-subtle) platform differences that can cause different execution of your code on different platforms.

Garbage collection

 

When you create Java objects, the JRE automatically allocates RAM for that object from the heap, which is a large pool of memory available on your machine. The runtime system tracks these objects for you. When your program no longer uses them, the JRE gets rid of them. You don't have to worry about it.

If you have written any programs in the C++ programming language, which is also (probably) object-oriented, you know that as a programmer you must allocate and free memory for your objects explicitly using the malloc() and free() functions. For programmers, this is an onerous task. It is also dangerous because it can lead to memory leaks in your programs. A memory leak is nothing more than your program absorbing RAM at an alarming rate that loads the CPU of the machine your program is running on. The Java platform frees you from any worries about this because it has a so-called garbage collector.

The garbage collector in Java is a background process that deals with removing unused objects instead of forcing you to do so explicitly. Computers are great for keeping track of thousands of things and for hosting resources. The Java platform allows computers to do this. It stores a reference count for each object in memory. You can manually call a garbage collector, but I've never done that throughout my career. It usually works on its own and will definitely work for each example in this tutorial.

IDE vs Command Line Tools

As we noted earlier, the Java platform comes with command-line tools that allow you to compile (javac) and run (java) Java programs. So why use an IDE like Eclipse? The reason for this is that using command line tools can be a headache for working with programs of any complexity. They are available at hand when needed, but using the IDE in most situations is a wiser decision.

The main reason for using the IDE is to manage files and paths in the IDE itself and to have wizards to help you change your runtime environments if necessary. If I want to compile a Java program using the javac command-line tool, I have to worry about setting the CLASSPATH environment variable in advance so that the JRE can find my classes, or I have to set the variable during compilation. In an IDE like Eclipse, all I have to do is tell Eclipse where to find my JRE. If my code uses classes that I haven't written, all I have to do is point Eclipse to the libraries that my code references and their location. This is much easier than using the command line to enter terribly long strings that specify classpath.

If you want or have to use command-line tools, you can find more information on how to use them on the Sun Java Web site.