Contents:
When releasing a software product, it is important to package it so that it is simple for users to install and to run. To this end, Sun Microsystems has created Java Web Start (JAWS) to simplify the deployment of Java programs. Thus, you are required to to package your final project using JAWS so that you can easily share your final project with the world (or at least with the 6.170 staff).
One of the problems with Java is that it is difficult for the average person to run a Java desktop application because that requires downloading and installing the Java Runtime Environment (JRE). Even after the JRE is installed, executing a Java program may require setting the classpath and including native libraries. Obviously, these are not tasks that an average user will be able to do.
One solution [for Windows] is to fork over $200 to buy a static compiler like Excelsior Jet that will convert your .jar into a Windows C executable (.exe) file that people can just double-click on and run like any other Windows application. Obviously, this is a little expensive (though there is one major success story about a free static compiler), and it only solves the problem for one platform.
A cheaper, platform-independent solution is JAWS. Basically, anyone who has JAWS installed can install a JAWS application by clicking on a hyperlink in a web browser to "download" it. When clicked, JAWS downloads the application to the client's machine so that he need not be online to run it in the future. However, if the client is online when he subsequently launches the application, JAWS will ping the web site from which it was downloaded to see if there have been any updates to the application since it was downloaded. If there are, it silently gets them from the web site, so you can be sure that your client is always running the latest version of your software. Thus, all a user needs to do is click on a hyperlink in a web browser then hit OK in a few dialog boxes to get your application up and running.
The JAWS developer site is pretty thorough about how to get your application working with JAWS. The basic idea is that you upload your jarfile, and any jarfiles on which it depends, to a web site. In that directory, you also create an XML descriptor of your application that identifies which jars it uses. This file is called a JNLP file. The next step is to create a web page that has a hyperlink to your JNLP file, so you might include the following in a web page about your final project:
<a href="final-project.jnlp">Download Final Project!</a>
When the user clicks on this hyperlink, the web browser should know to associate the JNLP file extension with JAWS, so it will start JAWS and have it parse the JNLP file. Then JAWS will look at the file to figure out which jarfiles it needs to download, it downloads them, and then launches your application locally on the client's machine.
Thus, you do not need to modify your Java code to make your application work with JAWS. Your only responsibility is to create the JNLP file and a web page that links to it. However, if your application requires special permissions, such as writing files on the client's machine or using native libraries, then you may have to address some of the issues in the JAWS Gotchas section below.
JDIC is a third-party Java library which renders HTML. If you look under the Demos section on the JDIC web site, then you will see a hyperlink labeled Browser that you can click on to run the demo. Clicking on this link should launch JAWS, and then the demo. Launching your final project from a web page should be just as easy for your users.
One of the tricky parts about using JAWS to deploy Java software is that you probably need to sign your jars. When you sign a jar, JAWS asks the user if he or she trusts your digital signature before running the code. If the user trusts you, then your application can do things like read and write files on the user's disk. If you do not sign your code, then you will get a SecurityException when your application tries to do such naughty things. Because your final project will likely persist data by writing files to the user's machine, you must sign your code if you want your users to have the full functionality of your application. Also, every time you rebuild your jar, you have to re-sign your code, so you should write a script or an Ant task to automate the code signing process; otherwise, it's pretty tedious to do it yourself every time you make a change to your jar.
Also, if you are hosting your project on the Web from Athena,
then you need to add a file called .htaccess.mit
in the same directory as your JNLP file.
The contents of the file should be:
AddType application/x-java-jnlp-file .jnlp AddType application/x-java-archive-diff .jardiff
This tells the web server to serve .jnlp and
.jardiff files as their own special MIME types instead of
plaintext files. If you are running your own Apache web server, then
you should call this file .htaccess or just add these
lines directly into your httpd.conf file. If you run
into other problems with Java Web Start, then also take a look at The
Unofficial Java Web Start/JNLP FAQ, as it has a lot of solutions
to problems that other developers have run into.
Finally, let it be known that JAWS is not a perfect solution in that not every user has it. Some browsers/operating systems come with it pre-installed, in which case it should be simple for your users to get your JAWSified application. However, other users may not be as fortunate, so you may want to provide a link where users can download JAWS before getting your application. Generally, users hate downloading things, but JAWS simplifies this process greatly since the user does not need to download something to a temp directory and then run an installation wizard or anything like that. For the user with JAWS installed, installing your application is just one click in a web browser — this is much easier than trying to explain to your users how they need to get the JRE and then add java.exe to their %PATH%.
Note that you need to sign your JAR files to get JAWS working for 6.170. Please refer to the section about signing JAR files.
Jar files are a way of collecting all parts of your application together in one place. jar files are useful because they can store all of the source code, compiled code, and associated data files (such as images or sounds) in one centralized archive, which can then be easily distributed.
To learn more about jar files, review the jar tool manual from Sun.
As a quick reference, here are a few sample uses of the jar command:
To create gizmo.jar from classes in packages gizmo and ball:
jar cvf gizmo.jar gizmo ball
To create antichess.jar from classes in package antichess:
jar cvf antichess.jar antichess
To list the contents of the jar file, use:
jar tf gizmo.jar
To create a runnable gizmo.jar:
jar cvfm gizmo.jar JarMainManifest gizmo ball
In the example above, the file JarMainManifest should contain a single line which names the entry point:
Main-Class: gizmo.StartGizmoball
For Antichess, the entry point would be:
Main-Class: antichess.Antichess
To run the application using the jar file, use:
java -jar gizmo.jar java -jar antichess.jar
Important: Note that, when using the -jar option to run an application, the CLASSPATH variable and the -cp command line switch are ignored. Therefore, to include another jar in an application stored in a runnable jar, you will have to extract the .class files from the other jar, and include them in your own. You can extract a jar file into the current directory this way:
jar xvf /mit/6.170/lib/gb-lib.jar
Using Ant can simplify and automate the creation of jar files. Given the complexity and maintenance issues involved with merging the physics class files in with the gizmoball application, we recommend the use of Ant to automate the process.
You will need to sign your jar files when using JAWS to deploy java software (especially if you want your application to do things like read and write files on the user's disk). A tutorial for learning how to sign jar files can be found here.
The product of your final project is likely to have a few thousand lines of code. You might find the following tools handy in performing common tasks on large project:
The final project is going to require group coordination, so you may find the following tools helpful in managing your project.
System.out.println statements when trying to debug their
code. Over time, these statements get commented in, commented out,
deleted, rewritten, etc. This adds up to a lot of wasted time. Using
a tool for logging messages, such as Log4j, can help stop the
println madness.
Throughout the development of your project, your application will likely have some bugs. Once a bug is discovered, it is important to make a record of it in some way and then update the record when it is fixed. The overhead that comes with setting up one of these tools may be overkill for your project; however, whatever system you use for tracking bugs should probably imitate that of a full-fledged bug tracking system.