Applet : Java Glossary

a partial Java application program designed to run inside the womb of a web browser, with help from some predefined support classes. Everything I say here about Applets also applies to JApplets since JApplet is a subclass of Applet.

Applet Difficulties

java.applet.Applets must run inside a web browser (or AppletViewer). You can also run them in Java Web Start to avoid the peculiarities of individual browsers. You cannot run them from the java.exe command line, unless you add some code to make them into a hybrid. 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.

Applets are harder to write than applications. I would recommend that beginners start with applications. With Applets you have the following complications:

1. Your entire logic must fit in the straight jacket of four methods init(), start(), stop() and destroy().
2. Unsigned (ordinary) Applets are restricted in hundreds of not-well-documented ways. They are not even allowed to read files.
3. An Applet must run inside a browser. This adds an extra level of complication and uncertainty as different browsers have different bugs.
4. Unless you spin off a separate Thread, an Applet has no mechanism to do any calculation that takes more than a fraction of a second. All Applets on a page used to run no the same thread. Now they each get their own thread.

The easiest way to write an Applet is to start with a working one, perhaps one of mine. Write it as a hybrid and debug it as an application. Once you have it working as an application, test it as an Applet in a browser. If you have an IDE (Integrated Development Environment) like Intellij Idea, you can run it in the IDE as an Applet as an intermediate phase between testing as an application and as an Applet in a browser.

Unsigned 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. Unsigned 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 at all. They can’t load classes, read files, or have socket communications with any webserver but mom, the server they were loaded from. Applets can send/receive email to/from a different host, but only via the home host.
• I have discovered by experiment that when an Applet runs locally, it is only allowed to read files in the same directory or in a subdirectory of that directory. It can’t read files in the parents or sibling directories, just child/grandchild directories. Oddly, it does not matter where the jar itself is, but where the web page is that has the <APPLET tag. The files the Applet reads have to be downstream of that page. You will notice multiple snippet subdirectories all over my website. This is because Applets could not get at a central snippet directory. The place where I put the code snippets for a given webpage has to be in a branch off the directory containing the web page. My only other alternative would be to always put the code snippets in the same directory as the web page. I am not sure if the same restriction applies to Applets run on a webserver.
• I have discovered by experiment that when an Applet runs from a website, it is only allowed to read files in the same directory as the web page or in a subdirectory of that directory, (downstream from the webpage). It can’t read files in the parents or sibling directories, just child/grandchild directories. It does not matter where the jar is, just the web page and the files that you try to read. This means unsigned Applets usually end up bundling everything they need to read as resources in the jar.
• I have not experimented with https:. Please let me know if you can use https in an unsigned Applet and if you can mix http: to fetch the Applet jar and http: to fetch the data.
• 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 (Uniform Resource Locators).
• Use System.setOut or System.setErr to redirect the console.
• Look at the restricted system properties, or get an enumeration of all the system properties. See Wassup. Don’t use Color.getColor. getColor which interrogates the system properties.
• Monitor mouse motion.
• Print in Java version 1.1, though you can in JDK (Java Development Kit) 1,2+. The user has to ok the printing though.
• Send email to a server other than the one it was loaded from.
• Talk to a serial port.
• Talk to a parallel port.
• Change thread priority, even lower it.
• Read or write the clipboard. However, users can manually cut/paste your AWT (Advanced Windowing Toolkit) components without security clearance. The restriction is on programmatic control of the clipboard. Swing components have no cut/paste ability at all.
• Install software.
• Execute any native code. If you use native JNI (Java Native Interface) code, things get really complicated vis a vis security and signed Applets with native code. You are better off to use Java Web Start.
  Java Web Start
  JNI
• Exec external programs.
• Issue an RMI (Remote Method Invocation) 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 (Application Programming Interface).
• Use the Preferences API to store or look at configuration information in the registry.
• You can use  Properties.load so long as you read the resource with  MyClass.class. getResourceAsStream rather than getResource.

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

Now that IE (Internet Explorer) has dropped its own version of Java, it is reasonable to ask your clients to upgrade to the latest Oracle 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.

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 (Local Area Network) 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

• When you use a browser to host your Applets, the JVM (Java Virtual Machine) is started once, when you run your first Applet. All Applets run in the same JVM. In some older systems, they even share the same Thread. You must be careful in your Applet not to hog the CPU (Central Processing Unit), otherwise you will throttle other Applets. This loading strategy is why the first Applet takes longer to start. In contrast, when you run applications, each get their own logically distinct JVM, but they share DLLs (Dynamic Link Libraries) (in Windows).
• 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 instead.
• 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.
• AppletContext.getApplets () does not work properly when you have 12+ instances of Applet on the page. See Inter-Applet Communication for more details.

Windows and Variable Resolution

Windows has a feature whereby the user can increase the size of the default system font. Let’s say you increase it to 125%. Now, when you use an Applet in Internet Explorer, IE will give you Applet region to paint 25% bigger than you asked for on your <APPLET tag. Windows/IE is inviting you as an Applet programmer to use a 25% bigger font inside your Applet and to magnify your images by 25% to make them easier for the user to see. If you ignore the extra space, your Applet will appear with small fonts, small icons and a big wide empty border.

HTML (Hypertext Markup Language) to Invoke an Applet

Usually HTML tags are in lower case, but I often show them in this document all upper case to help distinguish them from Java source code.

Here is tip to find the optimal size parameters. Run the Applet as an application. Drag the frame to the optimum size. Use PaintShop Pro to capture a screen snapshot of the frame, excluding the menu bar. Then look in the lower right corner of the PSP window (or use Mioplanet Pixel Ruler) 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. It is safest to stop and restart the browser for each test.

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. I often start different a different browser for each test to get a clean start, e.g. Opera, Firefox, SeaMonkey,, IE.

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

HTML4 (Hypertext Markup Language v 4) <APPLET Tags

<!-- simple parameter -->
<param name="favouriteColour" value="orange">

<!-- note you CANNOT say, as any sane person would expect: -->
<param favouriteColour="orange">

Here is an example of minimalist markup.

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

Make sure you get your <s s ‘s ’s 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>

<APPLET, from a CSS point of view, is just another tag. In your CSS style sheet, you can apply properties to it, adjust the margin spacing, put borders around it… In your HTML markup you can give it a class or id. Unfortunately Chrome and Firefox have a common bug and don’t display a border around Applets even when you ask them to. Opera and IE work properly.

HTML4 <OBJECT> and <EMBED>

In theory, <APPLET has been deprecated and you should use the more generic, verbose, error-prone <OBJECT tag. In HTML5 (Hypertext Markup Language v 5) <APPLET no longer works, but thankfully HTML5 uses a greatly simplified <OBJECT syntax. This is what you should be using for all new work.

HTML4 <OBJECT has some minor 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. See the HTML spec for details.

Starting with JDK 1.4.2, you can arranged that jars be cached at the client site using the EMBED tag cache_archive parameter.

That was the polite version, but here is what I really think of <OBJECT> and <OBJECT> tags. Anti-Java, rather corrupt people launched a successful attempt to derail Java by somehow convincing some weak minded folk at the W3C to deprecate the <APPLET tags. Browser makers have all sensibly resisted this foul play and all continue to support <APPLET. The replacement is an utterly preposterous and verbose scheme using <OBJECT> and <OBJECT> tags that works in different ways in different browsers. The scheme is beyond ridiculous. It is so baroque, you can’t even hand code it. You have to use an automated tool C:\Program Files\java\jre1.8.0_131\jre\lib\ext\htmlconverter.jar to convert <APPLET tags into pages and pages of gobbledegook. Don’t use them! If you ignore my advice, you might as well add to the flakiness by using the Java Deployment Toolkit to generate the tags with JavaScript.

Tell the W3C (World Wide Web Consortium) and Microsoft to shove their <OBJECT> and <EMBED> and lunatic classids to a foul-smelling place. Please, do not use these tags!

It is possible to interleave Microsoft and Mozilla markup cleverly so that each ignore’s the other’s markup.

HTML 5 no longer supports APPLET. There are five standards.

1. APPLET, now deprecated'
2. Microsoft OBJECT classid=gibberish
3. Mozilla EMBED type="application/x-java-applet;version=1.8.0"
4. HTML 5 OBJECT. Simplified. The browser automatically figures out the plug-in needed from the MIME (Multipurpose Internet Mail Extensions) type.
5. HTML 5 EMBED alias for OBJECT.

OBJECT is a meaningless keyword. It is like calling it THING. It should have been called PLUGIN.

Many websites tell you to use non-conforming parameters with OBJECT in HTML5. Check with the spec to see which ones are still supported. Some have been converted to PARAMs. One of the strange features of HTML5 OBJECT is you must specify the jar twice.

You can use a simple  Jump to Java Button to handle a missing JRE (Java Runtime Environment).

HTML5 <OBJECT>

HTML5 <OBJECT is much more reasonable than its predecessors, but has fewer features. Here is an example of how you invoke an Applet.

It is almost the same as the old <APPLET tag with the addition of MIME type type="application/x-java-applet" and a redundant reference to the jar. data="canadiantax.jar".

Applet ⇒ application: Hybrid Switch Hitter

Application ⇒ Applet

What if you already have an application? How do 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:

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

Your Applet does not get to see the web page. It goes straight to the browser for rendering. Because this feature can be so easily abused to wallpaper the user’s screen with popups, it is now often blocked.

Inter-Applet Communication

Communication between Applets running on the same page, it turns out, is much simpler than you might imagine. First, there is one instance of your Applet class running per APPLET tag on a web page running, with a common static region. 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 inter-Applet communications. Your only problem is finding the other Applet objects on your page to talk to. There are two mechanisms for that:

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

In 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.

The following SSCCE demonstrates the problem with getApplets().

I have reported it to Oracle. I doubt they will fix the problem, but they might add a warning to the AppletContex.getApplets () method.

Some have chastised me that this is not a bug. If you read the documentation like lawyer, this behaviour is considered within spec. I respond, it violates the principle of least astonishment. The actual behaviour is highly unexpected and should be documented.

Applet Classpath

Applets without jars 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. Normally you use your website in backwards order so that mindprod.com ⇒ com.mindprod
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.

I advice you to ignore the classpath and put all the classes you need into the jar. With a jar, the classpath is ignored. That way the code will work the same on your machine as an your customer’s machines.

Applet vs 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.
• People run your Applet code as a side effect of viewing a web page. They are much more willing to do that than download and install your code.
• The user automatically gets the latest version of the software.
• There is nothing to install.

• To do anything interesting, you must use signed Applets. There are many different signing schemes to support. Signing is complicated.
• Applets must coexist with a browser. There is less RAM (Random Access Memory) available to work.
• Applets must coexist 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.
• Web Start 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.

Applet vs Servlet

The current fashion is to use Servlets exclusively for all web based applications. I think this is idiotic. It has made data entry even more primitive than it was on the keypunch. The advantages of using Applets over Servlets are:

• With Applets, the user can find out about keying errors right away, not with cryptic messages that appear only after you hit submit and wait several seconds.
• With Applets, data entry can be much more sophisticated, with keystroke validation, code lookup, pattern validation, bounds checking, mandatory field validation, prompting, help etc.
• With Applets, data communications can go on in the background and can be cached or procrastinated giving the illusion of instant response.
• With Applets, you don’t have to fill in a giant form only to discover the server won’t accept it.
• With Applets, you can run your applications on a cheap vanilla HTML server. You don’t need a complex, expensive to maintain, Servlet womb.
• With Applets, you don’t have to resort to dog’s breakfast kludges like Ajax to provide even tiny bits of client side intelligence.
• With Applets, you have sufficient local intelligence to send much terser binary compressed messages back and forth with the server. You can also exchange serialised Object trees.

• With Applets, a recent Java must be properly installed at the client. This is more difficult to arrange than you might imagine especially with the FUD (Fear Uncertainty and Doubt) from Oracle’s competitors spreading misinformation about the danger of using Java when actually it is the safest language going.
• With Applets, you can’t use low cost web designers to help create your applications. With Servlets and a framework markup language the designers don’t have to write Java code, just HTML, peppered with a bit of gibberish.
• With Applets that connect with a database, you need a mixture of client size and server side code. This requires two sets of skills, and keeping server and client size code in sync.
• Applets that do almost anything interesting have to be digitally signed. This is an annoyance to users and frightens them off.

Applet vs WebStart

The advantage of using an Applet over Java Webstart are:

• Once Java is loaded it will render immediately. It will render inline on your webpage. I use Applets to display prices on this website in the user’s local currency. There my be dozens of tiny Applets on a single page. Java Web Start apps take an inordinately long time to launch. One reason is they always launch a private copy of java.exe for each app.
• Applets just run. You don’t need to persuade the user to click something, or give permission. They are embedded in ordinary HTML pages.

• The app does not run inside the browser. The browser cannot interfere. If you test with one browser, your app will work with them all. Applets can be a pain, working in one browser but not another.
• The app does not get downloaded each time, only when it has changed.
• The user can run your app even when disconnected from the Internet.

Splash Logo

In Java version 1.5 or later there is a splash logo that comes up as your Applet loads. It sort of a radiant Sun-like image. You can modify that with a magic <param tag that provides an alternate scalable image.

Applet Sound

Applet.audioClip can play *.au, *.aiff, *.wav and *.midi files. Old Javas supported only *.au 8 bit, μlaw, 8000 Hz (Hertz), one-channel.

Runtime Parameters

You can control the browser’s JVM runtime parameters (see java.exe) that control stack and heap sizes etc. from the Java Control Panel. click Start ⇒ Control Panel ⇒ Java ⇒ Java ⇒ Java Applet Settings ⇒ View. Add the required parameters in the 4th column, next to the JVM. It does not look like it is editable, but it is.

Learning More