What Are Objects

Java is an object-oriented programming language. But what are objects? An object is a self-contained entity which has its own private collection of properties (ie. data) and methods (ie. operations) that encapsulate functionality into a reusable and dynamically loaded structure. After a class definition has been created as a prototype, it can be used as a template for creating new classes that add functionality. Objects are programing units of a particular class. Dynamic loading implies that applications can request new objects of a particular class to be supplied on an 'as needed' basis. Objects provide the extremely useful benefit of reusable code that minimizes development time.

The Basic Structure of an Application

A Java application resembles programs in most compiled languages. Code in object format resides on the user's machine and is executed by a run-time interpreter that normally has to be user installed

Previously you wrote a simple 'hello world!' application to test the development environment. Now comes the explanation of the basic structure of Java applications using it as an example. Applications are stand alone and are invoked (or executed) by using a Java interpreter.

The first two lines is a comment on the application's function. Comments are not required but are extremely useful as documentation within the source. Other notes and doc files may get lost but these stay right where they are most useful. A long comment starts with a /* or /** and ends with a */ Short one line comments begin with // and end with the <return>.

The third line starts with the reserved word public. This indicates that objects outside the object can invoke (or use) it. The reserved word class indicates that we are building a new object with the name that follows. HelloWorldApp is the object name (your choice) and is case sensitive. Java 'style' is to capitalize the first letter of each word only. The line concludes with an opening curly bracket that marks the start of the object definition.

Line five is an invocation of an initialization method (or procedure in older languages). static indicates that it calls the class and not an 'instance' of the class. The concept of 'instance' will be discussed later in the tutorials. The method's name is main and the reserved word void indicates that no result is returned back. Main has arguments (aka parameters) in round brackets. String args[] indicates that any command line values given are being passed to main as an array of String type in the variable args. The line finishes with an opening bracket for the main() method.

Line nine invokes the println() method of the system.out object. What is to be printed is passed in the argument as a string parameter. Note that each Java statement concludes with a semicolon.

Finally closing curly brackets are used for the main and for the object definition.

The Basic Structure of an Applet

A Java applet produces object code which can be interpreted within the user's browser. This means that naive users do not have to fuss with program installation. Applets also provide security by restricting local user resource access. Applets can be useful, user friendly programs as demoed by ChemJava or a lot of fun as seen on Jigzone.

Here is the explanation of the basic structure of a Java applet using the applet that you wrote to test your working environment. Applets are placed in XHTML documents and are invoked (or executed) from within a Java aware browser such as FireFox, Opera or MSIE.

Line three uses the reserved word import which indicates that objects from the external classes Graphics and Applet are going to be used. Line four uses the reserved word extends to indicate that the class being created is a subclass of the Applet class. This demonstrates how Java code is easily reused and extended.
Note: The JApplet class is used instead of Applet whenever Swing GUI objects are used.

Line six starts the override (change) of the java.applet.Applet class init() method. Line eleven invokes the resize() method of the Applet object and sets the window dimensions. Note the all important statement ending semicolon.

Line 12 is another method override declaration. This time it is the paint() method of the Applet object. It is being passed an object of the Graphics class called g. Line 14 tells the Graphics object g to invoke its method drawString() using the string "Hello World! and position it at point (50,25) in the previously assigned window. A later tutorial gives details on graphics programming within applets.

Viewinging Applets in XHTML Docs

Applets are intended to be viewed from within XHTML documents. In XHTML the applet or object element is placed where desired in the body element of the document. The applet element has been deprecated and may only be used in Transitional documents. To use a Strict doctype you must convert any applet element to an object element. An applet skeleton is as follows:

<applet code="HelloWorld.class" codebase="javaProj/"
height="70" width="300">Browser does not allow Java!</applet>

code points to the applet class file. codebase points to the class directory. Be sure to explicitly point at the codebase. To start at the root directory use file:///C:/. Anything else will fail in FireFox! height and width are also required parameters and cannot be moved into style rules. Nested param element(s) are optional and can be used to feed data to the applet from the XHTML document. Always include a message for non-java browsers between the applet element tags. The resulting applet displays as:

The equivalent object element skeleton syntax is:

<object classid="java:HelloWorld.class" codebase="JavaProj/"
height="70" width="300">Browser does not allow Java in object elements!</object>

And it would appear as:

Browser does not support Java in object element!

Note 1: Remember that filenames are case sensitive in Java. Some browsers may allow helloworld.class but Opera obeys the rule! Always test any applet on as many browsers as you can.

Note 2: Although styling attributes such as align, hspace and vspace are mentioned in many texts, they are archaic and should be replaced by CSS style rules. And of course all XHTML documents should have a doctype and validate to current w3.org recommendations.

Life Cycle of an Applet

Each Java applet goes through a sequence of stages. They are created (initialized), displayed (painted), paused while off screen (stopped,started) and finally removed (destroyed) when over.

Initialization occurs when the applet is first loaded. Tasks performed here are creating objects,setting initial state, loading images, fonts, etc. and setting parameters. The method used is init()

Display is how things are drawn on screen whether it is text, graphics or background. Redisplay occurs many time through the life of an applet. The method used is paint().

Stopping occurs when one leaves a page that contains a running applet. Threads normally continue running but can be manually stopped. The method used is stop().

Starting occurs after initialization and after stops occur. Tasks include starting threads, sending messages to helper objects, or to tell the applet to start running. The method used is start().

Destruction cleans up an applet before the browser exits. Tasks include thread stopping. Normally the method destroy() is not overridden.

Cautions About Applet Use

The greatest problem with using applets is the nonstandard way browsers cope with them. Some browsers support Java natively (ie. self contained). However this leads to version compatibility issues. Other browsers allow applets to be passed through to the Java engine of the viewer's operating system. But this requires that the viewer download and install Java. Are your website visitors this sophisticated? And finally there are ancient browsers like MSIE6 which really makes you jump through the hoops to hook up an installed Java environment. Most browsers also open a box that will overwrite any text that the box is scrolled to (ie a hign z-index value). At this point JavaScript looks like a more consistent method of utility delivery!

For security purposes, Java applets allow NO access to user resources! Local files can not be accessed. Printers can't be used. Only the current website server can be communicated with. If your project can live with those restrictions then an applet may be more appropriate than an application.