Applications or Applets


First thing to decide is whether you want to write applets or applications. Applets require an Java-enabled browser to execute properly and usually have restrictions due to the nature of downloading code from an untrusted source. Applications on the other hand can execute by themselves without any need for a browser or appletviewer and do not have such restrictions such as not being able to write to a file on the client's side, because they aren't being downloading and executed simultaneously. However the user must have the a Java VM(Virutal Machine) on their system(currently) to execute your application and your application can not be 'embedded' into a HTML page like an applet can.

Lets start a comparison:


Applets:

Applets have the following execution path:

  1. init()
  2. start()
  3. stop()
  4. destroy()
Applets begin at init() and end at the destroy() method. You do not need to define all of these methods, in fact just init() or start() will suffice.

The applet itself is a Panel(Container) and has access to most of the AWT. But applets generally are graphically-based, thus not a good replacement for CGIs. And unlike CGIs which run on the erver's side, applets run on the client's machine(thus alleviating server-overload). Also CGIs can be written in any language and be accessible to all WWW Browsers(even Lynx). Where as applets are restricted to graphical browsers and generally require a high-bandwidth connection with lots of memory on the client's side.

Applets in this case use Java and the AWT as a weak-multimedia scripting language, rather than a general purpose one, such as C.

A Sample Applet: Boss Dartboard(from Dilbert)

To view this applet you need a Java-enabled browser

If you had sound, he'd being screaming. Here is the source

Note: One major restriction an applet has is: It can only communicate back to the host where it originated from.


Applications:

Applications have a static void main(String args[]) method. This method is where execution begins and must be defined for stand-alone applications.

Note: args[] differs from C/C++ to retain portability. i.e args[0] is not the first string on the command prompt

Applications can be either text/character or GUI-based, thus Java can be used for CGI scripts as well as developing WWW Browsers(i.e HotJava). But character-based applications are not as straightforward as they would be under C or Perl, due to the nature of portability(and abstraction from the OS) in Java.

There is no restriction in making Java platform-specific with the use of native methods. You don't even need to use the AWT to create GUI applications in the platform of your choice. As long as there is a way to link native libraries(i.e DLLs) to Java, you can create applications as you would in C++.

Some example application code from CValcarc and explanations in comments also.


[Q & A's]

Q: Why use Java and the AWT? Why not use X?
A: The AWT(and Java) is portable. But so are tcl/tk, right? And how about Python? What about Smalltalk, Eiffel, C++, etc? To put it simply: Those languages and GUI libraries for them are far from simple nor portable. And languages like tcl are far too slow to be pratical. C++ too complicated and low-level for anybody but professionals. In short, every tool and language has its own use. Java accels in true portability and simplicity. Featurewise Java matches(or beats depending whom you talk to) C++, Eiffel, Smalltalk and Objective-C. And the AWT, although young has enough functionality for small applications.

Q: Which is better applets or applications?
A: Depends :-) I prefer applications, since applets have yet to "strike a chord" with me. But due to the youth of the AWT and the fact its lacking tools and some basic functionality such as printing class, I must attempt both. For another it shouldn't be a difficult question. Do you want your "application" to run within a browser or outside of one?

Q: What is missing in the AWT?
A: Quite a bit if compared to wonderfully designed(simple and elegant) GUI libraries such as the VCL(Visual Component Library) of Delphi. The current AWT is still fairly low-level, not X calls, nor WinXX API, but lower than your average application framework. It currently does not separate interface from implementation very well, nor is there a resource format, nor true device independancy, nor printing capbility, nor a uniform help system, nor good inter-application communications protocl, etc.

But it does have threading and networking which is lagging is 99% of languages and GUI libraries.

Q: Who supports Java and the AWT?
A: Sun is the original developer of the language. Netscape adopted it back in May/95. Borland, Metrowerks, Macromind and Oracle have recently announced support for it. With support of Borland, who may or may not add "extensions"(IMHO good for the AWT), Java will take off like C++ did back 5 or so years ago. We need tools like Delphi to speed up development. Writing and re-wrting code for event handlers is more pain than necessary. Programs should generate all monotonous code for us and leave us with real programming.

Q: The future of Java and the AWT?
A: ....


[Next] [Prev] [Home]
Nelson Yu
nelson@cs.ualberta.ca
Last modified: Nov 24 1995