Home > Java Terminologies > Java Terminologies

Java Terminologies


Few terminologies to be familiar with, before getting started with Java:


Java Platform:

The Java platform from Sun allows developing and running programs written in the Java programming language. The platform is not specific to any one processor or operating system, but rather an execution engine called virtual machine and a compiler with a set of standard libraries that are implemented for various hardware and operating systems so that Java programs can run identically on all of them.

The Java Platform consists of several programs, each of which provides a distinct portion of its overall capabilities. For example, the Java compiler converts Java source code into Java byte-code, an intermediate language to be executed by the virtual machine (JVM) and it is provided as part of the Java Development Kit (JDK). The Java Runtime Environment (JRE), complementing the JVM with a just-in-time (JIT) compiler, converts intermediate byte-code into native machine code on the fly. Also supplied are extensive libraries, pre-compiled in which are several other components, some available only in certain versions.

The essential components in the platform are the Java language compiler, the libraries, java language itself (Java API) and the runtime environment in which Java intermediate byte-code “executes” according to the rules laid out in the virtual machine specification. 

  Java Platform


The heart of the Java Platform is the concept of a “virtual machine” that executes Java byte-code. This byte-code is the same no matter what hardware or operating system the program is running under. The use of byte-code as an intermediate language permits Java programs to run on any platform that has a virtual machine available. Although Java programs are platform independent, the code of the Java Virtual Machine (JVM) that execute these programs is not so every supported operating platform has its own JVM.

The JVM is a crucial component of the Java Platform. It is a platform-independent execution environment that converts Java byte-code into machine language and executes it. Most programming languages compile source code directly into machine code that is designed to run on a specific microprocessor architecture or operating system, such as Windows or UNIX.

The JVM is an instance of the JRE (Java Runtime Environment) and comes into action when a Java program is executed. JVM can be obtained with JRE / JDK distribution.

Few functionalities of JVM are:-

  • Loading of class files (compiled java source code).
  • Verification of class files i.e., Class files should contain valid byte-code.
  • Interpretation of byte code and then run the program. 



Just-In-Time compiler exists within the Java Virtual Machine or JVM. The JIT compiler translates the Java byte-code into native processor instructions at run-time and caches the native code in memory during execution.

The use of a JIT compiler means that Java applications, after a short delay during loading and once they have “warmed up”, tend to run about as fast as native programs. Since JRE version 1.2, Sun’s JVM implementation has included a just-in-time compiler instead of an interpreter.

JIT is the part of the JVM that is used to speed up the execution time. JIT compiles parts of the byte code that have similar functionality at the same time, and hence reduces the amount of time needed for compilation.



Java Runtime Environment contains JVM, class libraries, and other supporting files. It does not contain any development tools such as compiler, debugger, etc. JVM runs the program, and it uses the class libraries, and other supporting files provided in JRE. JRE is enough if the intention is only to run a java program but not to write / compile own programs.

Sun distributes the JRE separately, or as part of J2EE, J2SE, and J2ME.



The Java Development Kit(JDK) is bundle of software that can be used to develop Java based software. Typically, each JDK contains documentation, examples, installation instructions, class libraries and packages, one (or more) JRE’s along with the various development tools like the Java source compilers, bundling and deployment tools, debuggers, development libraries, etc. 


Difference between JRE and JDKjrevsjdk.jpg 

The JRE and JDK are the actual files that are downloaded and installed on a computer in order to run or develop java programs, respectively.



Java Platform Standard Edition (JavaSE) is equivalent to JDK. It was called as JDK earlier and some people continue to call it so. When people say JDK1.6, it means version JavaSE SDK 1.6.0. At java.sun.com, you can download the JavaSE SDK and/or the JavaSE JRE (which is the runtime only).

JavaSE consists of a virtual machine (JVM) as part of a JRE which must be used to run Java programs and a set of libraries or “packages” (JDK) needed to use file systems, networks, graphical interfaces, and so on.


Sun Quotes:

Java Platform, Standard Edition (Java SE) lets you develop and deploy Java applications on desktops and servers, as well as today’s demanding Embedded and Real-Time environments.


Java SE was known as Java 2 Platform Standard Edition or J2SE from version 1.2 until version 1.5. The “SE” is used to distinguish the base platform from Java EE (Java Enterprise Edition)and Java ME (Java Mobile Edition). The “2” was originally intended to emphasize the major changes introduced in version 1.2, but was removed in version 1.6.

The naming convention has been changed several times over the Java version history. Starting with J2SE 1.4 (Merlin) to J2SE 5.0 (Tiger) to Java SE 6 (Mustang).

Difference between JRE and JavaSE JRE vs JavaSE



The Javadoc tool provided by Sun is used to produce documentation for an application or program.


Jar Files:

A Jar (Java Archive) file is used to group together related class files into a single file for more compact storage, distribution, and transmission. Its much like a zip file with .jar extension.


Path and Classpath:

Two system / user environment variables will affect how your Java programs run. The directions given here apply equally to UNIX/Linux and Windows. Many users confuse the PATH and the CLASSPATH environment variables. Please note that these are not the same thing, although their structures are similar. They are two separate environment variables with separate functions.

In PATH Environment variable, you need to specify the location of the executables such as .bat,.exe(Executable files that Operating System Uses).

In CLASSPATH environment, you need to specify the location of the .class files (jar, zip files etc, within which will be the .class files) .


Do we have a choice of not setting PATH / CLASSPATH ?

For running a java application, you need to set PATH alone. For versions above JDK 1.5, JAVA_HOME itself is enough. No need to set CLASSPATH.


Why to set PATH?

Java programs can be run even without setting the PATH variable, but for that, the program needs to be executed inside the (installed location)\bin folder because java.exe, javac.exe etc are available only inside this folder.

If PATH variable is set, we can access .java.exe, javac.exe etc., (all the .exe’s which are required to compile/run java program) from any where in the computer i.e., c:, d:, e: etc. It will be available throughout all drives. So java programs can be run from any where in the computer.


why to set CLASSPATH?

For running java programs, there’s no need to set CLASSPATH. Given a jar file, we might need the classes/interfaces in the jar file to be accesible from any location from the computer. To access those class files from the jars / zips, we set the CLASSPATH variable. 

Ex:- Many Java-related tools are distributed as Jar files such as ANT, and it can be set in CLASSPATH to be used wherever required, as D:\Technical Software\apache-ant-1.6.5\lib\ant.jar

For further details about Path and Classpath, please see the descriptions in the following two sections.


Path Variable:

The PATH environment variable determines where your system will look for executable programs when they are named on the command line, except if the relative path of the program is specifically specified on the command line (ex:-C:\Java\jdk1.4.0\bin\java.exe).

In Windows, the current directory is always implicitly first on the PATH. This means that if you type – java, the OS will search the current directory for an executable program called java.exe (or java.bat or java.cmd or any number of executable file types on Windows) and run it. If Windows does not find one, it will search the directories specified in the PATH environment variable in order, looking for an executable file called java.

To specify a specific Java executable that is not in the current directory, overriding the current PATH you can write its full pathname on the command line, as such:

C:\Java\jdk1.4.0\bin\java.exe program

In general, it is convenient to include jdk_home_directory\bin on your path when developing and running Java programs, where jdk_home_directory is the directory where your working JDK is installed, for instance C:\Java\jdk1.6.0.

The PATH environment variable consists of a list of directories, separated by semicolons (;). Invalid directory names are ignored. An example of a Windows path is:


To determine your current PATH in Windows, open up a command prompt and type:

echo %PATH%

There are several ways to set or modify the PATH:


1. Setting PATH through Environment Variables (Preferred Method):

Windows XP/Vista have a specific place in the GUI, rather than an autoexec.bat file, where environment variables can be set up. Right-click on the My Computer icon and select Properties, in the Advanced tab, under “Environment Variables.” 


2. Command prompt:

You can set the PATH by hand at the command-line by typing:
SET PATH=dir1;dir2;…

Alternately, you can append a directory to the front of the existing path by typing:

SET PATH=newdir;%PATH%

You can append a directory to the end of the path by typing path by typing:

SET PATH=%PATH%;newdir


3. Batch File:

A batch file is the Windows equivalent of a UNIX shell script. It contains a sequence of commands that are executed as if they were typed on the command line, with some additional support for change-able parameters. For example, a Windows batch file to set up the command environment for use with JDK 1.6 might look something like this:

SET JDK_HOME=C:\Java\jdk1.6.0\


Classpath Variable:

The CLASSPATH is simply an environment variable. Setting this variable is almost exactly the same as setting the PATH. The class path tells SDK tools and applications where to find third-party and user-defined classes — that is, classes that are not Java extensions or part of the Java platform. The class path needs to find any classes you’ve compiled with the javac compiler — its default is the current directory to conveniently enable those classes to be found.

The CLASSPATH contains directories (or JAR files), from where your java compiler/runtime will look for .class files (and some others). For example, “java Hello.class” will not work unless you set the directory (or JAR file) Hello.class, into your CLASSPATH. It is not a requirement to use a Classpath system variable.

Java SDK, the JVM and other SDK tools find classes by searching the Java platform (bootstrap) classes, any extension classes, and the class path, in that order. You only need to set the class path when you want to load a class that’s (a) not in the current directory or in any of its subdirectories, and (b) not in a location specified by the extensions mechanism.

If you are upgrading from an older version of the SDK, your startup settings may include CLASSPATH settings that are no longer needed. You should remove any settings that are not application-specific, such as classes.zip. Some third-party applications that use the Java Virtual Machine may modify your CLASSPATH environment variable to include the libaries they use. Such settings can remain.

You can change the class path by using the Java tools’ -classpath option when you invoke the JVM or other SDK tools or by using the CLASSPATH environment variable. Using the -classpath option is preferred over setting CLASSPATH environment variable because you can set it individually for each application without affecting other applications and without other applications modifying its value. Classes can be stored either in directories (folders) or in archive files. The Java platform classes are stored in rt.jar.

The CLASSPATH is a standard environment variable that consists of a list of three things:

JAR files, and
ZIP files

Each element in the list is separated by a path separator character, the same character used in the PATH variable, described above. On Windows, this character is a semicolon (;). On UNIX, the path separator character is a colon (:). To understand the CLASSPATH requires an understanding of the relationship between filesystem directories and Java packages. Java packages provide a global, top-level namespace hierarchy for Java classes. Levels in the package hierarchy are specified by the period (dot) character (‘.’). Sun recommends avoiding namespace conflicts by using the development organization’s Internet domain name segments in reverse order. Ex: com.tecnoesis.packagename

However, typing these names can be cumbersome, so often developers break this recommendation for the sake of brevity. In theory, each level in the package hierarchy maps onto a filesystem directory. So, a class with fully-qualified name ie.com.tecnoesis.spring.SpringAop implies that there is a class file called SpringAop.class in a directory called:

ie /com/tecnoesis/spring (UNIX) or
ie \com\tecnoesis\spring (Windows)

Once you understand how Java packages map to filesystem directories, it is possible to explore how the CLASSPATH works.

As noted above, there are three types of things that can be on the CLASSPATH: directories, JAR files, and ZIP files. A JAR (Java ARchive) file is simply a ZIP file with a distinguished file called the manifest in it, but for the purposes of this discussion, the difference between a JAR file and a ZIP file is irrelevant.

Each entry in the CLASSPATH represents a location from which the Java runtime will search for classes when it needs to load them. The CLASSPATH is searched in order, so in the case of multiple classes with the same fully qualified class name (that is, package + class name) on the CLASSPATH, the first one found is loaded.

JAR or ZIP archives on the CLASSPATH are searched as if they were a filesystem root. That is, ZIP and JAR files can contain directories and files just as if they were a directory themselves. When Java needs to load a class, it will search the archive file and unZIP it from the archive.

Important: If your CLASSPATH contains a directory which, in turn, contains a JAR or ZIP archive, the JAR or ZIP archive will not be automatically searched. It must be added separately to the CLASSPATH.

The runtime will iterate along the CLASSPATH looking for each class when it is needed. If the class is not found, a ClassNotFoundException is thrown by the runtime.

One important insight to glean from this is that all the files in a given package or software system do not necessarily have to be in the same place, as long as the classpath is specified correctly. So, if a JAR file containing ie/com/tecnoesis/spring/SpringAop.class is on the classpath, along with a directory containing a file structure ie/com/tecnoesis/spring/SpringSecurity.class, both classes will be found by the runtime when needed, even though they are in different places in the filesystem.



Important! Exceptions to the CLASSPATH Rules Above
In general, class loading works as specified above. However, there are a few notable exceptions:

  • Classes in the java.* packages are treated specially by different runtimes, and may not be allowed to be loaded externally.
  • Applications may define their own classloaders which ignore the CLASSPATH or load classes from a non-filesystem source such as a URL or a database.
  • The Java Extension Mechanism changes how classloading works in version 1.2 and later. It allows certain archive files to be considered part of the Java core, and therefore are automatically added to the Java classpath by the runtime.
  • Most, if not all, of the Java tools have a command-line parameter, -classpath, which allows the user to set the classpath for a single tool invocation, overriding whatever is stored in an environment variable.



1. Setting CLASSPATH through command prompt:

Suppose we have a package called org.mypackage containing the classes:

HelloWorld (main class)

and the files defining this package are stored physically under the directory D:\myprogram.
The file structure will look like this:

      —> org\ 
            —> mypackage\
                     —> HelloWorld.class      
                     —> SupportClass.class  
                     —> UtilClass.class 
When we invoke Java, we specify the name of the application to run: org.mypackage.HelloWorld. However we must also tell Java where to look for the files and directories defining our package. So to launch the program, we use the following command:

java -classpath D:\myprogram org.mypackage.HelloWorld

where :
-classpath    D:\myprogram set the path to the packages used in the program
org.mypackage.HelloWorld  is the name of the main class

Note that if we ran Java in D:\myprogram\ then we would not need to specify the classpath since Java implicitly looks in the current working directory for files containing classes.


2. Setting the CLASSPATH through an environment variable:

The Environment variable named CLASSPATH may be alternatively used to set the Classpath. For the above example, we could also use on Windows :

set CLASSPATH=D:\myprogram
java org.mypackage.HelloWorld

or through windows GUI.


3. Setting the CLASSPATH of a Jar file:

Now, suppose the program uses a supporting library enclosed in a Jar file called supportLib.jar, physically in the directory D:\myprogram\lib\.

The corresponding physical file structure is :

      —> lib\
            —> supportLib.jar
                      —> org\
                            —> mypackage\
                                     —> HelloWorld.class
                                     —> SupportClass.class
                                     —> UtilClass.class

We should use the following command-line option:

java -classpath D:\myprogram;D:\myprogram\lib\supportLib.jar org.mypackage.HelloWorld

or alternatively:

set CLASSPATH=D:\myprogram;D:\myprogram\lib\supportLib.jar
java org.mypackage.HelloWorld

If you are using classes that are contained inside a .jar file, you will need to specify the full path and name of this file in the CLASSPATH, rather than just the name of the directory it is contained within.


4. Setting the CLASSPATH in a Manifest file:

Suppose that our program has been enclosed in a Jar file called helloWorld.jar, put directly in the D:\myprogram directory. We have the following file structure:

      —> helloWorld.jar
      ———–> lib\ 
                    —> supportLib.jar

The manifest file defined in this Jar file has this definition:

Main-Class: org.mypackage.HelloWorld
Class-Path: lib/supportLib.jar

Note: It’s important that the manifest file ends with either a new line or carriage return.

Also, note that the classpath string in this case describes the location of the supportLib.jar file relative to the location of the helloWorld.jar file, and not as an absolute file path (as it might be when setting the -classpath parameter on the command line, for example). Thus, the actual locations of the jar file and its support library are irrelevant so long as the relative directory structure between the two is preserved.

To launch the program, we can use the following command:

java -jar D:\myprogram\helloWorld.jar

It is not necessary to define the Main class at launch, the Classpath to the program classes, and the support library classes, because they are already defined in the manifest file.

The syntax for specifying multiple library JAR files in the manifest file is to separate the entries with a space:

Class-Path: lib/supportLib.jar lib/supportLib2.jar


Java Platform, Enterprise Edition is a related specification which includes all of the classes in Java SE, plus a number which are more useful to programs which run on servers as opposed to workstations.



Java Platform, Micro Edition is a related specification intended to provide a certified collection of Java APIs for the development of software for small, resource-constrained devices such as cell phones, PDAs and set-top boxes.





Note: Refer to other posts in Java category for further knowledge.



  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: