How should I test JApplets and Applets?

Question

Been playing with Java for quite a while now, and I just started working with JApplets/Applets. The problem I'm having is actually testing them. As you all probably know, most browsers cache the files, so if you update any of your code, the JApplets/Applets don't refresh. I've read that you can change the name of the HTML file that hosts the JApplet/Applet, and thus "trick" the browser into caching a "new" program. This doesn't always seem to work unfortunately.

Another method I see quite often is using the command appletviewer in command line, but I've never been able to get this to work.

So I was wondering, how should I test my JApplets/Applets? What is the best way? How do you test your them?

Answer 1

Applet Testing

1. The appletviewer

The appletviewer is relatively easy to use. Here is the example from the applet info. page.

/* <!-- Defines the applet element used by the appletviewer. -->
<applet code='HelloWorld' width='200' height='100'></applet> */
import javax.swing.*;

/** An 'Hello World' Swing based applet.

To compile and launch:
prompt> javac HelloWorld.java
prompt> appletviewer HelloWorld.java  */
public class HelloWorld extends JApplet {

    public void init() {
        // Swing operations need to be performed on the EDT.
        // The Runnable/invokeLater() ensures that happens.
        Runnable r = new Runnable() {
            public void run() {
                // the crux of this simple applet
                getContentPane().add( new JLabel("Hello World!") );
            }
        };
        SwingUtilities.invokeAndWait(r);
    }
}

2. Appleteer

The Appleteer - applet test tool was designed by me to provide more feedback on an applet launch or the reasons for failure. Main features:

• Loads applet web pages in an applet enabled JEditorPane.
• Supports multiple applets on the same page, along with applet communication/object sharing & the 1.4+ InputStream sharing mechanism.
• Supports the applet showDocument()/showStatus methods.
• Helps avoid applet class caching.
• Allows inspection of
  1. The getAppletInfo() & getParameterInfo() defined for the applet.
  2. Parameters requested by applet code. Very handy for poorly documented applets!
• Can provide easy access to the following information.
  1. Split output and error streams,
  2. Has in-built logging, and all applet logs to the anonymous logger are added to the main log. Along with easy configuration of..
     • Log level.
     • Log history length.
  3. Applet lifecycle Throwables logged.