Applets:
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 files on the client. This is allowed because they aren't being downloaded and executed simultaneously. However the user must have the a Java VM(Virtual Machine) on their system(currently) to execute your application, the compiled bytecodes to be exact, and your application can not be 'embedded' into a HTML page like an applet can.
Applets:Applets have the following execution path:
The applet itself is a Panel(Container) and has access to most of the AWT. But applets generally are graphical, thus they're not good replacements for CGIs. And unlike CGIs which run on the server'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. i.e More than 8 megs RAM, 486 or greater(386 dies a horrible death) and a 28.8k > connection.
Applets in this case use Java and the AWT as a weak-multimedia scripting language, rather than as a general purpose one, such as C.
A Sample Applet: Boss Dartboard(from Dilbert)
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:
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++.
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. It still lacks many features to make it usuable in developing mainstream applications. Thus, I would not use the AWT in applications(not applets) for commercial purposes, because it is deficient in too many areas.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 protocols, etc.But it does have threading and networking which is lagging is 99% of languages and GUI libraries.
Q: Isn't true portability really a pipe dream?
A: Yes. We are more likely to have Japanese software factories than true cross platform apps. Why? Why do you use Un*x vs. the Mac? Because you like teletype? No. Unix provides features not found or badly implemented on other OSes.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 the lack availability of good tools(see Digital Focus for a list of tools) and some basic functionality such as printing classes, 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: 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, Oracle, IBM, SGI, Symantec, Natural Intelligence, etc. 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. See AppletGen for an applet generator and check out Symantec's Cafe. There are more listed at the Java Developer Site.Q: The future of Java and the AWT?
A: I've chosen Java as the language I prefer to use. Even though I know C++ a bit better. I've decided to formally ditch the AWT. So from now on, I will no longer use the AWT in stand-alone programs, unless something drastic occurs, like a restructuring of it. Originally, during the move from alpha3 to pre-beta, the AWT look like it was heading towards the "right direction". Classes were added to make it usuable for stand-alone apps, but alas nothing further was done and we get a GUI lib only suitable for applets, presumably because Sun thought most of the interest was there.