Java Glossary : Applet

Last updated 2004-06-30 by Roedy Green ©1996-2004 Canadian Mind Products

Java definitions: 0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

You are here : home : Java Glossary : A words : Applet.

Applet

a partial Java application program designed to run inside the womb of a web browser, with help from some predefined support classes.

Applets must run inside a web browser (or AppletViewer). You cannot run them from the java.exe command line. To spawn a web browser from within an application to get it to display an Applet, see the tips under HTML rendering. Applets are typically automatically downloaded over the web freshly every time they are executed. They can also be run from local hard disk. In contrast, applications cannot be run inside a browser, though it is possible to make a dual mode program that can run either as an Applet or application. Applets run on the client's machine. In contrast, servlets run on the host webserver.

Applet Restrictions

To make Applets very safe to run, even when they were composed by teens with the morals or skill of Beavis and Butthead, Applets are severely restricted. Applets (without special permission to bypass security) are not permitted to:

• talk to any server but the one you were loaded from. No talking to strangers. If they were loaded from a local disk, they can't talk to any webserver. Applets could send/receive email to/from a different host, but only via the home host.
• read or write local files on the client machine. They are not even allowed to look in a directory or test for the existence of a file. You can however read a file (resource) embedded in the jar with Class.getResource or Class.getResourceAsStream. It can also read from the server via a URL. Even when your Applet is loaded from hard disk, it still may not do file I/O even via file: urls.
• look at the restricted system properties, or get an enumeration of all the system properties. See Wassup.
• monitor mouse motion.
• print.
• send email.
• talk to a serial port.
• talk to a parallel port.
• change thread priority.
• read or write the clipboard. However, users can manually cut/paste your components without security clearance. The restriction is on programmatic control of the clipboard.
• install software.
• execute any native code. If you use native code,
  JNI
  Things get really complicated vis a vis security with native code.
• exec external programs.
• issue an RMI call to a remote object running on a different server than the Applet's.
• Determine the structure of an object (fields, methods, values, etc.) using the Reflection API.
• Use the Preferences API to store or look at configuration information in the registry.

If your Applet needs to do any of the above things, it must be signed.

Now that IE has dropped Java, it is reasonable to ask your clients to upgrade to the latest Java, understanding that some will not. For them, you must develop or at least test on earlier versions. Don't just assume that just because you did not use any new features that you are home free.

Standalone Java applications are not so limited. Exactly what the limitations are is controlled by the security manager in the browser. If the user installs an alternate security class, the Applet may have more powers. The security restrictions are controlled entirely by the browser. There is nothing to stop you from writing a non-conforming browser that has quite different security restrictions for Applets. However, in practice, you write code to sign your jars and bypass each of the five different security schemes used in browsers.

Signed Applets

Programmers bitterly complain about these restrictions. The restrictions protect the end user from malicious web Applets they might encounter on the web. Without such protection, vicious Applets could destroy the user's hard disk, print reams of paper, phone out on a spare serial port and rack up long distance bills, go sniffing on the LAN for the company books... You don't want to give those powers to psychotic strangers -- those same people who stay up late at night writing viruses.

Applet Gotchas

• Don't try to make Applets work on your website with naked class files. Always bundle everything, classes, gifs, configuration scripts etc. up into a jar. This bypasses many classpath headaches, and it downloads faster. Further, the chances are much better your Applet will work first time on the website once you get it working locally out of a jar.
• Applets are a pain in the behind. If you possibly can, use Java Web Start intead.
• Don't try to use any of the Applet methods in your constructor such as getCodeBase. They depend on a private field called appletStub that does not get initialised until just before your init method is called. You will get NullPointerExceptions if you fail to heed this advice.
• Unsigned Applets are extremely restricted in what they can do. Carefully review the list above. In particular, Applets cannot write to the local hard disk or talk to a server other than the one they were loaded from.

HTML to Invoke an Applet

I find it wise to sandwich the <applet ...> ... </applet> tags in <p> tags like this:

<p>
<applet
code= "MyClass.class"
width= "230"
height= "240"
archive= "Everything.jar,Sub/MoreStuff.zip"
codebase= "http://mydomain.com/"
vspace= "10"
hspace= "10"
align= "left"
alt= "You need Java to run this Applet"
name= "receiver"
mayscript
>
<param name= "favouriteColour" value= "orange" >
<img src= "images/NoJava4U.jpg" >
You need Java to run this Applet.
</applet>
<p>

that stray-looking > is not a mistake. It has to be there to close the opening <applet tag This way the Applet has lots of room to display. If you leave them, out your Applet may be rendered off the right edge of the screen, where you probably won't see it.

Here is tip to find the optimal size parameters. Run the Applet as an application. Drag the frame to the optimum size. Use Paint Shop Pro to capture a screen snapshot of the frame, excluding the menu bar. Then look in the lower right corner of the PSP window to discover the size for the <applet height and width tags. Then measure including the menu bar to discover the size for the Frame.setSize( width, height ) when running as an application. It will need about 24 pixels extra height. This trick saves a lot of guesswork and experimentation to home in on the optimal values.

When debugging Applets, remember to click Shift-Reload in your browser, not just plain Reload to attempt re-running with your new version. Shift-Reload supposedly flushes the cache of class files. This usually does not work. You have to exit the browser and restart. It is a good idea to put something unique in every incarnation of your code so you can tell if you are running the old or new code. I do it by flipping a background colour or setting a micro version number.

You can go crazy debugging Applets because the browser sometimes caches old copies of jars, classes, html ... It is best to start each test with at least a fresh loading of your browser, preferably with all its caches deleted using a bat file before each test.

It is best to debug as an application, then at the last minute convert to an Applet.

Applet Tags

Applets are invoked to run in browsers by the <Applet...> tag. Applets won't work if you load them directly with your browser as if they were web pages! The HTML commands for firing up an Applet are exceedingly picky. It matters whether you have .class or not. I suggest you look at the files that come with the Conversion Amanuensis to see how to run an Applet/Application with/without jars, locally, on a web site, with various browsers and run times. Here is the basic structure:

HTML Tag	Comments
<Applet
code= "MyClass.class"	The name of the class file for the Applet. Make sure the case and name exactly match the name of the *.java file, *.class file, and class name. For a class in a package this would have dots in it, e.g. com.mindprod.mypackage.Myclass.class , but it would not have any directory qualification. You are not allowed to specify an absolute URL or absolute fully qualified hard disk filename. Strange as it sounds, you must specify the trailing .class, though some browsers let you get away without it. All the Sun tutorials do it with the .class.
width= "330"	width of entire Applet display in pixels. There is nothing the Applet can do itself to change this. If you needed variable size you would have to resort to JavaScript or a server-side technology to generate HTML pages with the appropriate size.
height= "240"	height of entire Applet display in pixels. There is nothing the Applet can do itself to change this.
archive= "Everything.jar,Sub/MoreStuff.zip"	Resource file, classes etc. Your ARCHIVE parameter must have a list of the absolute or relative jar files, separated by commas (no spaces). (Watch out! The ARCHIVE tag in <OBJECT is space-separated!) If you have too little or too much qualification, or if you fail to use the file naming conventions of your server, you will be in trouble. You are probably best to use absolute urls or fully qualified hard disk file names. Whether the archive is supposed to be relative to the current HTML directory, the CODEBASE, or all elements of the classpath is unclear. The forms of archive I use most are archive="myapp.jar" archive="../myapp.jar" and archive="somedir/myapp.jar"
codebase= "http://mydomain.com/"	I suspect CODEBASE is simply broken in the current implementations. Theoretically it is the absolute or relative URL/directory where class files are, like a one-element classpath. Normally the class files are in the same directory as the html, so you don't need it. In practice, I have found your CODEBASE parameter must have an absolute http:// -style reference to the base directory where the code is stored. The codebase is only needed when your code resides somewhere other than where the html page was loaded from. For a local hard disk, the only thing I could get to work on NT with all browsers and Appletviewers is leaving the CODEBASE out entirely which causes the CODEBASE to default to the same directory as where the enclosing HTML page was loaded from. You may find for your platform you have to code it something like this: file:///C|//MyDir/ or C:\MyDir\. I also further suspect that some browsers will take the a relative CODEBASE as relative to each element of the CLASSPATH, not relative to the current HTML directory. If the user of the signed Applet is behind a firewall, for some strange reason, if he invokes the Applet using the IP rather than the DNS name of the website in the codebase e.g CODEBASE= "http://24.87.56.253/" instead of CODEBASE= "mindprod.com" , all works. Otherwise you get a trustProxy Property error message.
vspace= "10"	pixel width of border above and below the Applet
hspace= "10"	pixel width of border left and right of the Applet
align= "left"	how this Applet aligns, treated like a image
alt= "You need Java to run this Applet"	what to display if no Java interpreter available. Normally this would be the same text that appears just before the </applet> tag. This optional attribute specifies any text that should be displayed if the browser understands the APPLET tag but can't run Java applets.
name= "receiver"	Name for this Applet so that other Applets can communicate with it. Other Applets would do a Applet Applet.getAppletContext().getApplet( "receiver" ) to get a handle on this Applet. You don't need this parameter if you use Applet Enumeration Applet.getAppletContext(). getApplets() which gets you a list of all the Applets running on the page (including yourself).
mayscript	Lets Applet read/write cookies and peek at the page it is embedded in.
>	All that stuff above has to be inside the <Applet ... >, but the params may not be.
<param name= "favouriteColour" value= "orange" >	The param statements are Java's ode to verbosity. They pass information to the Applet. There can be as many param statements as you like. Beware of params with decimal points. <param name= "cost" value="10.00" > When your Applet runs in Europe, it will be expecting a comma instead unless you take special precautions. Param values cannot contain embedded " or newline characters. If you need them, you must use java.net. URLEncoder to encode the string, then manually include it as the param value, then use java.net. URLDecoder inside the Applet to make sense of the parameter. URLEncoder encodes space as + and special characters as %xx hex, so you can do the encoding in your head once you see a few examples. The catch is, once you hook up URLDecoder to a param, you can't use that param anymore for plain text, at least not completely transparently. Alternatively, you could experiment with encoding the parameters using HTML entities such as &quot; or &#nn
<img src= "images/NoJava4U.jpg" >	image to display if no Java interpreter available.
You need Java to run this Applet	Text that will display on a really stupid browser that has no idea what an Applet tag is.
</Applet>	and finally the ending tag for the

A minimal Applet invocation might look like this:

<applet code="MyApplet.class" width="330" height="240">
</applet>

Make sure you get your < 's and > 's in the right places.

A more typical Applet invocation might look like this:

<applet
archive="../mypackage.jar"
code="com.mindprod.mypackage.MyClass.class"
width="565" height="46"
alt="Java needed to display this Applet.">
<param name="flavour" value="strawberry">
Java needed to display this Applet.
</applet>

To run Applets in Internet Explorer 5.5 or Netscape 4.79 with the Java 1.3 Plugin, you need a hideously complicated syntax using nested <OBJECT> and <EMBED> tags. The best way to generate them is to use the HTML converter program on your simple <APPLET tags. You don't need them to run with the Plug-in 1.4 in Netscape 6.0, Opera 7.21 or IE 6.0.

In theory <APPLET has been deprecated and you should use the more generic, verbose, error-prone <OBJECT tag. <OBJECT has some nice features, like a standby message and a way of providing alternate implementations if the user's browser does not support Java. It can work with serialised Applets. It works for languages and plug-ins other than Java. However, <OBJECT is still not as widely supported as <APPLET , so it is probably wiser to stick with <APPLET for now. See the HTML spec for details.

Switch Hitter

By adding the following method to your Applet, you can allow it be run either as an Applet or as an application. If your Applet were called MyApplet, here is the code to add to the MyApplet class to make it also into an application:
view
Your Applet can get hold of the parameters in the HTML.
That code is quite crude. It will not do such things as:

• Simulate the getParameter method to get at the Applet parameters.
• Adjust the co-ordinate system so part of the Applet is not hidden under the Frame menu bar. Layout managers deal with this automtically, but if you do absolute positioning, you have to compensate manually..

The easiest way to deal with these problems is to use two Applet constructors, one the usual default constructor and one that passes the param information in. Inside you can keep track of which mode you are running in with a boolean you set in the constructor. getParameter( "favouriteColour" ) will return the String "orange" . When you write an Applet often you will override some of the following methods: init(), start() , stop() , destroy() and paint(Graphics g).

There is equivalent code for JApplet.

Switch Hitter: Application to Applet

What if you already have an application? how to you allow it to run also as an Applet? An Applet is just a Panel with init, start, stop and destroy methods. Write an Applet shell that does a this.add to add your application into the Applet in its init method, just as you would any other Panel.

Transparency

Though it is possible to create transparent and translucent components using colours with the alpha channel ( the fourth number in new Color ( red, green, blue, alpha )) set to something other than 0xff, I have found no way to make the Applet or JApplet itself transparent. You could pass the colour of the web page's background in as an Applet param or have JavaScript communicate that information to Java. This would only give true transparency only when the browser were using a plain untextured background.

Loading A Web Page

Often you want to display some other web page. You can trick the browser into doing that for you with:

this.getAppletContext().showDocument( url, window );

Your Applet does not get to see the web page. It goes straight to the browser for rendering.

InterApplet Communication

Communication between Applets running on the same page, it turns out, is much simpler than you might imagine. First, there is only one program per web page running. In fact there is only one program per browser running. Applets are just a bunch of ordinary objects. Applets from the same class share the same static variables! Objects can call each other's methods. They are all in the same address space. There is thus almost zero problem with interApplet communications. Your only problem is finding the other Applet objects on your page to talk to. There are two mechanisms for that,

1. Applet Applet.getAppletContext().getApplet( "receiver" )
   that accesses another Applet uniquely identified via a name you assign in the HTML <applet name= tag.
2. Applet Enumeration Applet.getAppletContext().getApplets()
   that gets you a list of all the Applets, of any class, not just yours, running on the page (including yourself).

An Applet propagates information around by putting it in static variables, or by passing parameters to the methods of other objects to get them to do something with the information. There is only one thread, not one per Applet. You can't just deposit information and expect the other Applets to notice the change.

The browser may decide to kill (forget) Applets not on the current page, and then again it may not. Presumably, if you held onto a reference to offscreen Applets in your onscreen Applet, or in a common doubly linked object, those offscreen objects would have to stay alive.

Applet Classpath

Applets use the ordinary local classpath. This can cause trouble since the developer's classpath and the end user's classpath won't usually match. There are two sorts of trouble that ensue:

1. If you have any classes not in a package, these non-uniquely named classes could conflict with ones on the end-user's local hard disk. To avoid this problem, put any classes ever used by Applets in some globally uniquely named package, e.g. com.mindprod.business
2. You, as developer, may forget to include a necessary class in your jar, usually from some peripheral package. It will work fine on your machine, but will fail on the customer's machine. On your machine, the JVM finds the missing class via the classpath. On the end user's machine that search fails.
3. You as developer may test an Applet jar, yet actually may be using some fresher classes on your local hard disk. You inadvertently ship stale code.

On the other paw, the Applet classpath can work in the developer's favour. If an Applet requires a huge support class library, he can ask the user to download and install it on his local hard disk and point the classpath to it (or put it in the ext directory). Then the class library will be immediately available every time the Applet runs.

Applet or Application

When you are starting a project, which should it be, an Applet or application or both? The advantages of using an Applet are:

• You can get the browser to render HTML for you.
• You can direct the browser to fetch and display material off the web.
• The user automatically gets the latest version of the software.
• There is nothing to install.

The disadvantages of using an Applet are:

• To do anything interesting, you must use signed Applets. There are many different signing schemes to support. Signing is complicated.
• Applets must co-exist with a browser. There is less RAM available to work.
• Applets must co-exist with a variety of browsers and their variety of bugs and lack of support. IE supports only Java 1.14 with no RMI, Swing, Collections etc. It is almost impossible to write code that dodges all the bugs in all the browsers.
• Applets must be loaded over the Internet afresh each time. This can be time consuming for fat ones. Modern browsers now cache Applets, so this is no longer a disadvantage.
• WebStart is designed to distribute and update applications, not Applets.
• To start an Applet, you must first start a browser.
• You can't use native code compilers on Applets, only applications. This means your speed will be limited to the JVM supported by the browser.
• You may not be able to force the user to update the browser to something recent.

There is a third possibility that has some of the advantage of both Applet and application called Java Web Start.

documentation on Applet : available:

• on the web at java.Sun.com
• on J: in the JDK 1.4.2_04: J:\j2sdk1.4.2_04\docs\api\java\applet\Applet.html
• on J: in the JDK 1.5 beta: J:\Program Files\Java\j2sdk1.5.0\docs\api\java\applet\Applet.html

aglet ¤ application ¤ AWT ¤ caching ¤ Canvas ¤ destroy ¤ init ¤ initialisation ¤ JApplet ¤ main ¤ servlet ¤ signed Applet ¤ start ¤ stop ¤ Sun's Applet Tutorial ¤ Swing ¤ tame Applet ¤ wild Applet ¤ window differences

home	Canadian Mind Products
	mindprod.com IP:[24.87.56.253]
	Your IP:[80.134.30.163]
	You are visitor number 7703.
	Please send errors, omissions and suggestions
	to improve this page to Roedy Green.
	You can get a fresh copy of this page from:	or possibly from your local J: drive mirror:
	http://mindprod.com/jgloss/applet.html	J:\mindprod\jgloss\applet.html