Once you have learned how to program games in Java, you will want to be able to deploy them on different types of deployment frameworks. This article will cover browser applets, executable JARs, and Java Web Start. It is excerpted from the book Advanced Java Game Programming written by David Wallace Croft (Apress, 2004; ISBN 1590591232).
Deployment Frameworks - Signing Applets (Page 3 of 9 )
You can make the applet security restrictions go away by digitally signing your applet. Digitally signing your applets permits the framework to authenticate that the applet was created by you—the developer—and not by someone posing as you. It also allows the framework to verify that someone else has not modified it since you created it. Once authenticated, the applet framework, such as a browser or the Java Plug-in, then prompts the user for permission to run the applet without any limiting security restrictions.
If the user grants this permission, the signed applet is said to be trusted. Unsigned applets, then, are run in untrusted mode. I find this confusing as the only applets I trust are the unsigned applets running within the restrictions of the security sandbox. When you consider that the authentication safeguard is not foolproof, granting an applet complete access to your machine seems foolhardy.
But do not let me discourage you from signing your applets. You might be discouraged instead by the fact that support for digitally signed applets varies from browser to browser and sometimes requires a browser-specific signing process. Additionally, you might need to pay a few hundred dollars to a trusted certificate authority so that you can be positively identified. Finally, you might want to consider the reaction of your more paranoid and privacy-conscious users when they are prompted to decide whether to give your game applet complete control of their home or workplace computers.
For more information on signed applets, please see the Java Plug-in Developer Guide for J2SE 1.4.3
One of the main advantages of applet distribution is that the latest version of your code is downloaded every time users play the game. On the other hand, one of the main disadvantages of applet distribution is that your code is downloaded every time users play the game. What you need, then, is for browsers to cache the applet and only download your code again when a new version is available. Although browsers have always been able to cache web pages and images between browser sessions, this has not been the case for applets. When the user would close the browser window, the browser would discard the applet download, most likely for security reasons.
In the past I have written custom code to implement applet caching. This involved digitally signing the applet and intimate knowledge of the different security policies of the major web browsers. Nowadays, however, custom code is no longer necessary as the Java Plug-in supports applet caching. I cannot vouch for the effectiveness of this feature as I have not used it but the documentation describes it. If your applets are fat and your users are using slow Internet connections or you just want to save on bandwidth-distribution costs, the applet caching mechanism of the Java Plug-in is definitely worth investigating.
Deploying as an Executable JAR
Besides applet distribution, you can also use JAR files as self-contained executables. The user simply copies the JAR file to the desktop or a directory on the hard drive and it is ready to run. If the executable is a Swing application, the user double-clicks the JAR and it launches the program in a new window. If the executable is a command-line application, the user enters the java command with the -jar option.
Double-clicking or using the command-line -jar option to launch the game is much easier on the player than specifying the classpath and class name with the full package-name prefix on the command line. Contrast the two preceding java commands, one that uses the -jar option and the other that does not.
public static void main ( String [ ] args )
When players launch an executable JAR file, the java command framework looks for a static main() method within a designated class and calls it. This causes your game to start running. In this sense the main() method can be considered a lifecycle method. I realize that I am stretching this a bit.
Making the Manifest
A JAR file often contains many classes, and more than one of these classes could have a main() method. To distinguish which class should have its main() method launched, the java command looks for a Main-Class entry in the manifest file.
The preceding code is a line in a manifest file, possibly the only line. It is written in the standard name-value pair format commonly used in property files before XML came about. You separate the class name value from the property name by a colon and a space.
CAUTION Keep in mind that only one space can follow the colon. If you put two spaces before the class name, it simply does not work.
jar -cvfm collection.jar manifest.txt .
Your JAR file normally includes a blank manifest file automatically as META-INF/MANIFEST.MF when you use the jar command. To include a non-empty manifest file that contains your Main-Class entry, you need to use the -m option to the jar command. In the above example, the jar command is instructed to include the text file manifest.txt. When manifest.txt is included, it is automatically named MANIFEST.MF and stored in the META-INF directory within the archive.
In an Ant build file, you use the manifest attribute to specify the path to the manifest file to include.
Securing the Insecure
Executable JAR files generally run on the client platform with unrestricted access to sensitive resources such as the hard drive and Internet connections by default. This can make some knowledgeable users leery of playing games distributed as executable JARs, especially when they do not know the distributor well. Such users would generally prefer to play games that are automatically restricted to a security sandbox such as those distributed as a browser applet or as a Java Web Start application.
java -Djava.security.manager -jar collection.jar
You can specify the security manager to use when you run JAR files using the java command property java.security.manager. In the preceding command-line example, no value for this property is given so the restrictions that would be imposed upon an unsigned applet running in a browser are enforced upon the executable JAR. If you use this property, you should be safe. Keep in mind that the game might throw some SecurityExceptions and fail to run properly if it was not designed to run within a security sandbox.
This article is excerpted from Advanced Java Game Programming by David Wallace Croft (Apress, 2004; ISBN 1590591232). Check it out at your favorite bookstore today. Buy this book now.