For information on running applets in JBuilder, see also:
"Running Java programs"
"Runtime" topic in the "Release Notes" (Help|Release Notes)
For additional information on applets, see also:
"Tutorial: Building an applet" in the Quick Start
The Java tutorial on "Writing Applets" at http://www.java.sun.com/docs/books/tutorial/applet/index.html
Sun's web site at http://www.javasoft.com/applets/index.html
The Java FAQ at http://www.afu.com/javafaq.html
Charlie Calvert's home page at http://homepages.borland.com/ccalvert/JavaCourse/index.htm
When the browser encounters a web page with an applet, it starts the JVM and provides it with the information located in the APPLET
tag. The class loader inside the JVM looks to see what classes are needed for the applet. As part of the class loading process, the class files are run through a verifier which makes sure they are valid class files and not malevolent code. Once verified, the applet runs. This is, of course, a simplified view of the process.
This delivery mechanism is the primary value of applets. However, there are some issues unique to applet development that need to be addressed to ensure successful implementation.
APPLET
tag in the HTML file. The tag attributes tell it what class to run, which (if any) archives it should search for classes, and the location of these archives and/or classes.
Unlike Java applications, which use an environment variable called CLASSPATH
to search for classes, applets use only the CODEBASE
attribute in the APPLET
tag to specify where to look for classes needed by the applet.
The key to running an applet is its ability to find the classes it needs.
APPLET
tag that uses the most common attributes.
<APPLET CODEBASE = "." ARCHIVE = "test.jar" CODE = "test.Applet1.class" NAME = "TestApplet" WIDTH = 400 HEIGHT = 300 VSPACE = 0 HSPACE = 0 > <PARAM NAME = "param1" VALUE = "xyz"> </APPLET>
APPLET
tag. Notice that some items are required.
Item | Description |
---|---|
CODEBASE (optional/required) |
Allows you to specify a different location for your classes or archive files than the location of the HTML file containing the APPLET tag. This path is relative to the location of the HTML file and is often limited to subdirectories of the location of the HTML file.
For example, if the applet classes are stored in a A value of "." specifies the same directory as the HTML file running the applet.
|
ARCHIVE (optional/required) |
Used to identify one or more archive files (ZIP, JAR, or CAB) that contain the classes needed for the applet. Archive files must be placed in the directory specified by CODEBASE . You can have multiple archive files and list them with commas: ARCHIVE="archive1.jar, archive2.jar" .
|
CODE (required) |
The fully qualified name of the applet class that contains the init() method. For example, if the class Applet1.class is part of a package called test , then CODE would be CODE="test.Applet1.class" .
|
NAME (optional) |
A string that describes your applet. This string shows up in the status bar of the browser. |
WIDTH /HEIGHT (required) |
Defines the size in pixels allocated to the applet in the browser. This information is also passed to the applet's layout manager. |
HSPACE /VSPACE (optional) |
Represents the horizontal or vertical padding in pixels around the applet. This is useful if you have text on the web page that wraps around the applet or if you have more than one applet in the page. |
PARAM (optional) |
Allows you to specify parameters that can be read by the APPLET tag. These are similar to the argument list used by main() in applications.
Parameters have two parts, |
APPLET
tag are due to the following errors:
If you receive an error message that says there's no </APPLET>
tag on the HTML page, check if there is a closing tag.
The case is extremely important. Typically, class names use mixed case, and directories and archives are all lowercase. The class, archive, and directory names in the APPLET
tag must exactly match the case of those on the web server. If the case is not exactly the same, you'll see "can't find xyz.class" errors.
If your class is in package foo.bar.baz
, any directories created to support that class must be created with and referenced in lowercase.
Moving files between Windows 95/98 and Windows NT and the Internet introduces increased chances for case-sensitivity errors.
Once you've posted your files to the Web, check to make sure that files, directories, and archives have the same uppercase and lowercase values as your local machine. Also, if you have archived all your class files, make sure that the archiving tool has preserved the case.
CODE
attribute
You need to use the fully qualified name because that is the actual name of the class. If the class name is Applet1.class
and is in package test
, then you must reference it correctly in the CODE
attribute as test.Applet1.class
.
CODEBASE
value
The CODEBASE
value is not a URL or some other type of reference. In the simple applet example we gave, CODEBASE = "."
was used. This specifies that files needed by the applet will be found in either the same directory as the HTML file, or, if no archive is specified, the files will be found in package appropriate subdirectories relative to the one containing the HTML file.
ARCHIVE
attribute
If your applet is deployed in one or more JAR or ZIP files, you must add the ARCHIVE
attribute to the HTML file.
CODE
, CODEBASE
, ARCHIVE
, NAME
, and so on.
NoClassDefFoundError
on some class in the java.*
packages because the ClassLoader determined it needed a Java class or method that the browser JDK does not support.
JDK 1.2 and 1.3 are still not fully supported in all browsers. While it is true that recent versions of the browsers support Java, you should know what specific version of Java is supported in the browsers that will run your applet. This is important so you can do whatever is necessary to create a match between the version of the JDK used in your applet and the JDK supported by the browsers. Browsers that do support JDK 1.1 are Netscape 4.06+ and Internet Explorer 4.01+. JDK version support may vary by platform.
To find out what JDK version the browser supports, check the Java Console in the browser or check the browser's web site.
To open the Java Console:
The JavaTM Plug-in from Sun easily solves the problem of JDK mismatch by permanently downloading the same version of the JDK to all the end-users' machines.
Initially you have to get your clients to install a minimum version of a browser. If they already have their favorite browser installed, you will need to convince them that any inconvenience caused by getting updates is offset by the value of your applet. Each browser upgrade requires downloading the browser update and/or installing a patch.
One difference among browsers is in their implementation of the Security Manager and security levels. What is allowed in one browser at "medium" security may not be allowed in the other. Adjustment of security is done on the client side, and each browser does it differently. For example, the mechanism for relaxing some security for an applet is signing. Signing an applet and getting the browser to accept that signature allows you more flexibility in your applet. The mechanism for this is built into Java with the Javakey utility. Unfortunately, browsers aren't required to use thisf mechanism. In fact, some use their own proprietary mechanisms for signing which only work in their browser.
Another difference is that individual browser manufacturers make some adjustments to core Java functionality, including leaving some of it out. This can result in unexpected behavior at runtime. For example, you could have paint calls that do not happen, leaving the applet in an odd state, or even invisible. You can try to find a way to code around specific cases, but it is not always possible.
Also, there are often variations in Java support on different platforms from within the same browser. For example, a multi-threaded applet may run on one platform, but because of problems in the threading model on a different platform, threads may run sequentially on a different platform. Often, browsers are not updated across platforms at the same time, and a browser update for a less popular platform may be released later.
These differences increase the amount of time you have to spend testing and debugging in a particular browser.
Most of the browser issues mentioned above can be solved by using the Java Plug-in, found at http://java.sun.com/products/plugin/. This plug-in provides up-to-date JDK archives, which is most beneficial if your applet uses Swing (JFC).
You do have to modify your HTML files for the applet to use the plug-in. Sun provides a utility that does the conversion quickly and easily.
Using the Java Plug-in is the only way to get the same JDK into the different browsers. You also typically get a JDK that is more current than the browser's JDK. There are some extensions that browser manufacturers have added that may not work the same with the plug-in.
From the end-user perspective, the first time they encounter a Java Plug-in enabled page, they will be prompted to install the plug-in. Once the plug-in is installed, the client machine will have an official VM from Sun and the latest JDK (including Swing) installed locally. This will only be used in "plug-in" aware pages, but it does cut down on the overhead of delivering the latest JDK technology to the browser.
You can avoid many problems by writing applets using the same JDK that the browsers support. JBuilder Professional and Enterprise allows you to switch the JDK version you are using for development. Although JBuilder Foundation does not support JDK switching, you can edit the current JDK. See Tools|Configure JDKs and "Setting project properties."
Writing your applets using JDK 1.1.x and earlier limits you to the functionality (and bugs) of these versions. Also, most development tools generate 1.1.x or higher code. JBuilder, for example, has many tools that generate 1.1.x or higher code which you cannot use for your applets. However, JBuilder does provide a feature that allows you to edit or switch your JDK version. See "Setting project properties."
JDK 1.02 has the best support in the browsers, but it also has different mechanisms for events than JDK 1.1.x. Most browsers now support JDK 1.1.5 but not Swing components, which were introduced in JDK 1.1.7. If you do write your applets in newer JDK versions, use only AWT components and do not use any of the newer features, such as Swing components.
The biggest disadvantage to using JDK 1.1.x and earlier versions is that all the improvements are in later versions, so you'll eventually have to migrate and port the old code. Another disadvantage is that some browser versions that are JDK 1.1.x-compliant have more problems with JDK 1.02 code.
swingall.jar
which contains those files.
CLASSPATH
-based searches, so if you store the large archives that your applet uses locally, your client won't have to download them. This is usually only possible in an intranet environment or in Internet situations where you have a controlled client set (such as in a subscription-based service). This does, however, make future code updates more difficult.
Make your users use only one browser to minimize the need for special code and maintenance. This is usually only possible in intranet situations controlled by IS policy.
A common problem with a deployed applet is placing files in the wrong location (for example, "class XYZ cannot be found"). Everything is relative to the HTML file that launches the applet. Without a CLASSPATH
to help find applet classes, the applet relies on the CODEBASE
and CODE
attributes in the HTML file to locate the classes it needs to run. Therefore, before beginning deployment, it is important to have the files in the correct location.
You'll find the deployment process easier if you make your project working environment reflect the reality of a deployed applet, bringing your development a little closer to instant deployment. This means that your HTML file needs to be moved (a simple rename will do it) to the directory above your class hierarchy (where your compiled files go). Once you have your applet built and running in this situation, you can archive everything into one JAR or ZIP file. Then, test your applet outside JBuilder in the browsers.
You should always use packages to organize similar classes when coding in Java. This makes them easier to find and makes deployment much simpler. Packages also help avoid conflicts with class names, because the package name is added before the class name in Java.
Know the browsers on which your applet will run. If you are using current tools like JBuilder, you are likely to be generating JDK 1.1.x or later code and will need the latest browser(s) to run your applets. Make sure you provide the latest patch or plug-in to match the browser's JDK version with the applet's. See Java Plug-in found at http://java.sun.com/products/plugin/.
Remember that Java is case-sensitive. Check that all case in class, package, archive, and directory names in the APPLET
tag exactly match the names on the server.
Archives simplify deployment, because you only have to upload the HTML file and your archive file(s). They also speed up the downloading process to the client; one compressed file is downloaded rather than each individual, uncompressed class file. Always check the directory structure and the case of file names in the archive file for accuracy.
JBuilder Professional and Enterprise have an Archive Builder that can create the ZIP and JAR archive files for you. You can also create JAR files by manually using the jar tool provided in the JDK. There are a number of ZIP tools that create ZIP files, but be sure to use a version that accepts long file names.
CAB files can only be used by Internet Explorer. Tools for creating them are available from Microsoft.
Unless you are writing something that uses only core Java classes, you have to deploy all of the class files needed by your applet to the Web. Of course, you still need to deploy everything to the right location. See "Basic deployment" for more information.
It is not sufficient to test the applet locally. You must also test it in multiple browsers after deploying it to the server. This is critical to ensure that all the classes you need for the applet are deployed properly to the server and that the APPLET
tag and server deployment match.
Security is advantageous for the developer because without it many end users would not allow applets to run at all. However, it also has several disadvantages for the developer, especially if the developer is unaware of the restrictions when the project is started. Many activities that you take for granted in an application will be denied in an applet.
Understanding these limitations before writing your applets can save time and money. Applets, like any tool, accomplish certain tasks very well. But, trying to use an applet in the wrong context only leads to problems.
You can't read files, check for their existence, write files, rename files, and so on. You wouldn't, for example, try to gather information from the user and save it.
This makes it difficult to provide data from a database that lives on a different machine than the web server.
There are other activities taken for granted by application developers, such as running local system programs to save time, which are not allowed in applets. Any good Java book will list the restrictions placed on applets.
If you find that you are trying to bypass the Security Manager at any point in your planning or development, consider using an application instead. Sun has done a very good job of defining their security model and identifying the key bits of information, or data types, on which entire sets of functionality depend. As a result, it is very difficult to trick the security model.
This may allow you to relax some of the restrictions placed by the Security Manager. It has a few disadvantages, one of which is that there is no standard signing mechanism that works in all browsers. Check the web site for your particular browser for more information on signing applet archive files.
The browsers have settings that can be used to adjust the security model. These settings range from very simple choices between "high", "medium" and "low" to fairly flexible schemes. Unfortunately, these settings are global for all applets. While the user may trust your applet not to do harm under relaxed security, it is often difficult to convince them to do so for all applets that they may encounter.
For example, if you simply need to write back to the server, design your applet to talk to a CGI script or write server-side Java applications that your applet talks to. This server-side code doesn't have the limitations of the applet and can be fairly powerful. Both server-side Java applications and CGI scripts require access to the physical server or a very flexible and understanding ISP (Internet Service Provider). These are solutions that are better suited to an intranet.
Gathering data from forms on the Web and collecting that data is probably better suited for CGI or DHTML. Complex operations, such as using databases, require additional software on the server like Data Gateway. It's a more complex solution, but without it, "normal" database actions, such as posting new data, are not possible in applets.
The advantages of Java applications, full access to the Java language and no security issues, may far outweigh the benefits of applets in some situations.
With applets, all referenced classes have to be sent across the Net to the client machine. If the third-party library has a large interwoven architecture, it can substantially increase the applet's file size. You should also be aware of the redistribution license for the library. Some libraries require you to redistribute the library in its entirety (not just the pieces you use).
Remember: The larger the applet, the longer it takes to download and run.
However, it does not give you accurate runtime behavior for applets. To properly test an applet, you need to test it with the applet deployed to the web server in its actual running environment. This is the only way to make sure all the classes the applet needs are available on the server running it.
When you run your applet in a browser, the applet needs to have enough information inside the APPLET
tag of the HTML file to allow the applet loader to find all the classes, images, and other assorted files your applet needs. This environment is the entire "real world" of your applet and is the only place the applet gets the information it needs for finding the files.
For the first tests of your deployed applet, consider using the JDK appletviewer test "browser." This command-line tool included in the JDK provides useful displays of error messages and stack traces. As demonstrated in the following steps, remove the CLASSPATH
in the testing session.
Check the following:
APPLET
tag contains the ARCHIVE
attribute with the archive file name(s) if the applet is deployed to a JAR or ZIP file.
Deployment is covered in depth in "Deploying Java programs" in the JBuilder Professional and Enterprise documentation.
CLASSPATH
you may have set for that session.
appletviewer knows were to find the core Java files.
/jbuilder/jdk/bin/appletviewer TestApplet.html
If this is the first time you've run appletviewer, you'll get a license agreement screen. Click Yes.
If all is well, you will see your applet running in appletviewer. If not, look in appletviewer's console to read the error messages.
APPLET
tag and server deployment match.
Here are a few tips for testing in the browser:
"Solving Common Applet Problems" in the Java Tutorial, "Writing Applets"
There are several things you can do to make deployment easier:
For details on deployment, see "Deploying Java programs" in the JBuilder Professional and Enterprise documentation.