This FAQ attempts to answer the following questions. Feel free to add more content as you see fit.
Where do I start? Show me the basics.
I'm unclear about the details of the APPLET tag.
This page tells you all about the applet tag, applet parameters and just about everything else you need to know. The Java Plugin Guide (for Java 1.4 - for Java 5) also has lots of useful information on the subject. Version conflicts when dealing with the EMBED and OBJECT tags are addressed here.
Further deployment options (JNLP and the deployJava script) are discussed here.
Recent version of the Java Plugin (in Java 6) allow the look of the startup image to be modified, and introduced many new capabilities and improved matters in general; check out the changes in general and read this for details of the APPLET tag in particular.
My applet works fine if I run it locally, but not if it's served from a web server. What gives?
A symptom of this problem might be a message "applet not initialized" at the bottom status bar of the browser window. Make sure you haven't put any required class files into the WEB-INF directory - web servers will not serve any files out of that directory. Move the class files to a publicly accessible directory - the most convenient would be the directory where the HTML file with the applet tag is in.
How can an applet access files inside the jar file the applet is stored in?
You can access files inside a jar file through an InputStream, which is returned by several methods in the Class and ClassLoader classes. This article in the Java documentation has all the details. Refer to the "Resource Names" section on how to specify the file name.
How can an applet load an image?
One way to do this is described here. The most basic approach would be:
Image img = getImage("http://www.myschool.edu/anImage.gif");
Image img = getImage(getCodeBase(), "anImage.gif");
Mozilla.org has a test page, where you can test whether your browser supports LiveConnect.
This page by Sun has examples of the newer <EMBED> and <OBJECT> tags in addition to <APPLET>.
What are the differences between the Sun JVM and the Microsoft JVM?
This article describes what you need to keep in mind when moving applets between the Sun and Microsoft JVMs. (Note that the Microsoft JVM has been obsolete for a very long time, and should not be used for anything at this point.)
How can an applet access a web site that's protected by basic authentication?
If the applet uses URLConnection or one of its subclasses, the following code will enable this:
String authorization = Base64Coder.encode(username + ":" + password); connection.setRequestProperty("Authorization", "Basic " + authorization);
Alternatively, you can use the HttpClient package which is more feature-rich than [Http]URLConnection, and also handles NTLM authentication in addition to basic and digest.
How can an applet connect to a database?
Accessing a DB from an applet is not fundamentally different than connecting from any other piece of Java code. The one important restriction is that applets can only make network connections to the host where they originate (i.e., where the web server is located). If the DB is not located on that machine, the applet will either have to be signed (which gets around the host restriction; the details are described above), or the applet needs to route the DB calls through a DB proxy on the web server host, which takes the DB calls, transmits them to the proper DB host, and then sends the results from the DB server back to the applet.
Note that it is considered bad design to mix DB access code with presentation code (which is what applets are). Consider a design where the applet accesses a servlet, which in turn accesses the DB. That also gets around the host restriction. A further benefit is heigthened security, because the client can no longer send SQL statements directly to the database, thus making the DB access harder to tamper with.
One solution for proxying a DB is RmiJdbc. It uses RMI, which does not work well with the age-old MS JVM, if you are stuck with that (and, of course, RMI is sort of obsolete in general - an HTTP/REST solution might be better suited).
How can an applet upload a file to a server?
If the file to be uploaded is on the local file system, the applet will need to be signed or the local policy needs to allow applets access to the filesystem, because otherwise applets can not access the file (for details see HowCanAnAppletReadFilesOnTheLocalFileSystem).
A number of libraries that help with file uploads over various protocols are listed in the FileUpload page.
How can an applet communicate with a servlet?
Some classes to look at on the applet side are URL (particularly its getContent method) for simple access, and URLConnection and HttpURLConnection if you need more control over the connection.
It is possible to transfer Java objects through serialization. A simple example is at http://www.frank-buss.de/echoservlet/. Note that there may be problems getting this to work reliably if the client and server JVMs run different versions of Java.
An introduction on how to use RMI in applets via HTTP tunneling can be found in this article.
How can applets communicate with each other?
This article over at JavaWorld outlines some of the methods you can use.
How can an applet connect to a server through a proxy?
This article describes how to use the Java Plugin control panel to configure the various proxy options.
The Java documentation also has a section describing how to configure the properties governing proxy connections programmatically (for FTP, HTTP and SOCKS connections).
How can I run an applet as an application, and vice-versa?
While it's easy to add a main method to an applet, and add the applet panel to a Frame, and thus make it runnable and displayable as an application, this is not generally sufficient. The reason is that browsers provide some extra infrastucture for applets to use. To help with this, Jef Poskanzer has written a very useful adapter class called MainFrame which helps provide this infrastructure.
There's also the reverse functionality available in the ApplicationApplet class, which lets you run an application as an applet.
How can I protect the code of an applet from being decompiled?
Fundamentally, this is not possible. To run the applet, the code needs to be in the client JVM, where a technically sophisticated user can always recover it. It can be made progressively harder by employing a variety of techniques, as suggested in this thread :
Note that all but the first item on this list require the use of a ClassLoader. Applets can only use ClassLoaders if they are signed, or a policy file on the local machine allows them to do this. (See HowCanAnAppletReadFilesOnTheLocalFileSystem for details.)
If you can require the user to be online, it may be feasible to have the applet call a servlet, and have crucial code execute on the server, and then send the results back to the applet.
How can I deploy an applet that uses native libraries?
For starters, the applet needs to be signed (see HowCanAnAppletReadFilesOnTheLocalFileSystem for details). All the gory details of how to load the native libraries needed by the applet can be handled by a helper class like the JNLPAppletLauncher. (Although that page is JOGL-centric, that class can be used for other libraries as well.) Note that you'll have to include several libraries (for Windows, Linux, OS X etc.) if you still want cross-platform compatibility.