Java Desktop Applications
Let me explain a few things that will prepare you to run a Java Desktop Application,
and other Java Applications as well. If you do not get this right the application
won’t run.
Bytecode example that looks very similar to assembly language.
[code language=”java”]
iconst_2
istore_1
iload_1
sipush 1000
if_icmpge 44
iconst_2
istore_2
iload_2
iload_1
if_icmpge 31
iload_1
iload_2
irem
ifne 25
goto 38
iinc 2, 1
goto 11
getstatic #84; // Field java/lang/System.out:Ljava/io/PrintStream;
iload_1
invokevirtual #85; // Method java/io/PrintStream.println:(I)V
iinc 1, 1
goto 2
return
[/code]
Java runs in a virtual machine, meaning this VM (java.exe or javaw.exe) interprets Java bytecode. For the VM to be able to interpret the bytecode it needs to be started up and given the name of an executable Java class. An executable Java class is one with a “public static void main(String args[])” method. Also any supporting classes must be on the classpath. The Java VM first loads the class with the main method and then begins loading all other classes needed for the application to run.
Objects, Classes and the classpath variable.
This is Java’s world. Its a world with a classpath full of Java classes. Classes are in programming terms types of Objects. You may have heard of OOP (Object Oriented Programming). Java is based on languages such as SmallTalk and C++ when it comes to OOP with some variants of its own. Prior to objects or OOP program code was grouped into files called libraries. Data was grouped into records. OOP combines this and logically groups program logic and data into
units called objects.
So what is a classpath? Its extremely similar to the DOS or Unix system PATH variable in function. The path variable reduces the number of locations that your operating system will have to search to find commands that you enter at the command line. If you didn’t have this it might take many minutes just to find the command to run because its looking over the entire hard drive for the command. The classpath is a system variable. There are other system variables related to Java as well such as JAVA_HOME and CATALINA_HOME and others. I won’t talk about those in this article however. The classpath provides a set of locations on the hard drive where the Java VM should look for classes when loading them (loading up and running your java application). This is very handy for the VM because it doesn’t have to search the entire hard drive for classes but only say 5 to 10 percent of it or much less. Also this eliminates situations where you have multiple versions of classes in different locations causing class version conflicts.
The classpath may be set at the DOS command line or Unix command line. It may be set on Windows in the System Properties Advanced Settings as a permanent setting. On Unix it may be set in .bashrc file for the user. And when executing the VM, a command called ‘java’ on linux and ‘java.exe’ on windows, you may specify classpath options as well. This classpath is very important because if you do not get it right your application will fail to startup. There is more to learn about the classpath that I tell you about here, such as inclusion of current folder ‘.’ for example.
[java]
import java.awt.*;
import javax.swing.*;
public class DisplayGraphics extends JPanel{
public void paint(Graphics g) {
g.drawString(“Hello”,40,40);
setBackground(Color.WHITE);
g.fillRect(130, 30,100, 80);
g.drawOval(30,130,50, 60);
setForeground(Color.RED);
g.fillOval(130,130,50, 60);
g.drawArc(30, 200, 40,50,90,60);
g.fillArc(30, 130, 40,50,180,40);
}
public static void main(String[] args) {
DisplayGraphics displayGraphics =new DisplayGraphics();
JFrame f=new JFrame();
f.add(displayGraphics);
f.setSize(400,400);
//f.setLayout(null);
f.setVisible(true);
}
}
[/java]
Once the classpath issues are resolved all that one need do to start a Java application is something like ‘java AClassName’ or ‘java.exe AClassName’. If this does not work for you then you have a classpath problem or have not used the proper class name which may need to be the fully qualified name. For example ‘java apackage.AClassName’ Java classes are categorized in packages most of the time, which have names. These names correspond to folder names on the system. If indeed there were a package named apackage then it would be in a folder ‘\apackage’ or ‘/apackage’ depending on your system. Remember “\” on windows and “/” on Unix in file paths.
You may also start up Java Applications from within an IDE such as Eclipse by merely clicking on the class and selecting Run from a menu. Another method would be to run a Java application that has been packaged in an executable Jar file. These files are named with ‘.jar’ at the end. On a properly installed Java Runtime Environment or JRE or Java Development Kit JDK or SDK, one can place the jar on his desktop and merely click it to run it as he would any GUI app by clicking an Icon. At the command line you may use a command like ‘java -jar somejavaapplication.jar’ or java.exe on windows. On linux follow this with the & symbol to run it in the background so that the console is freed up for other things. On windows you may use ‘javaw.exe’ to do the same thing.
I talk in the Java console applications article more about anything to do with Java from the console or command line. I wanted to mention it here to give the reader a good foundation for the understanding on how to startup Java GUI applications. The easiest way to run a java application is from the jar file by clicking it from the desktop or by adding the jar file to the start menu so that it may be started as any normal GUI application. You may need to add a shortcut on the desktop to the jar file instead of copying the jar file. In more complex applications the jar has to be executed from the installation folder, or using a windows shortcut or unix symbolic link. You may also alternatively navigate in the system folder explorer and click on the executable jar file to run it.
A note to programmers about how this executable jar file works. First you must make up a manifest file that has one entry which describes which class should be the ‘main class’. When building this jar file you need to specify the manifest file name in the command. Just unpack ‘unjar’ any executable jar file to see how this is setup. Simply edit the manifest file to view the syntax. On my java projects there may be many class files with main methods. I do this for several reasons. Many of the main methods are for “boot strap” testing. Meaning I am simply using it to run and test and debug the class itself without starting up and loading the rest of the project. In other cases I have multiple apps within one project. It would be a simple thing to make a menu app for starting up any of them. In those cases the only main method that is needed is the one in the MenuApp and it would be the main class in the jar.
Once you learn to run Java GUI Application the fun begins. You will find them to be as nice as any GUI application if they are properly designed and made. Java GUI’s can be made from several libraries and each give them a slightly different look and feel. The standard libraries that come with Sun’s and now (Oracle’s) Java is made with AWT(Abstract Windowing Toolkit) or Swing which is based on AWT. AWT came first, then Swing. Usually in today’s Java world any application from Sun’s Java would be a Swing application. Swing itself comes with 4 main ‘look and feels’. First there is the Java default Swing Look and Feel. Next the Windows Look and Feel. Then there is the Metal Look and Feel which resembles Unix like GUI’s. And there is Motif which resembles Mac GUI’s. And custom Look and Feel’s can be made as well. So don’t be surprised if you start up different Java apps and they look slightly different. This was done so that users on different system could set a look and feel that more closely resembles their own native system’s GUI.
IBM has a GUI library (libraries are also know as API or application programmer interface) called SWT (Standard Widget Toolkit). If you are familiar with Eclipse IDE I believe that it is made using SWT and not Sun’s Swing. And finally there is OpenGL which is for high end graphics mostly in Game, Simulator or CAD type applications. OpenGL may have its own widgets and look and feel I assume.
If you have installed Sun’s Java SDK (JDK) Development Kit (IBM has a development kit and now there is Open JDK yet another one.), you will find demonstration applications for probably both AWT and Swing GUI. These are fairly impressive so have a look. Find and download some Java apps and try running them. A good place to look would be www.sourceforge.net. Source Forge is a web site which is dedicated to helping assist and coordinate the collaborative efforts of programmers from around the world on creating free software. (This opens up a whole other can of worms as in “why would anyone want to work for free on software”, which I will not go into here.) Just know that the software is free, so download and enjoy. Many of the tools I use as a programmer are projects that are hosted at sourceforge. Sourceforge is not the only open source host on the internet. When I get time later in another article I’ll be glad to list some others, and they host Java Projects as well. In conclusion I say “search and enjoy”.
Well one last note. To run Java apps from the command line you may need to add the Java distribution binaries to the System path variable. This is slightly different on each system and I won’t explain this here. Simply search the web and you find many examples and explanations. If I explain more it will be in the article about Java console applications.
