Java Web Start - Example Applications and Applets
This page offers examples of apps. launched using web start which either use JNLP API services, web start trimmings (menus, icons, splash screens..) or show interesting or little known aspects of web start.
Examples apps. launched using web start
These are mostly standard Java applications and applets that use web start for their deployment/launch, though some of the more recent examples use web start API services, in place of the usual J2SE methods of (e.g.) getting files.
Some of the examples using AWT are compatible with Java 1.1, but JWS was a separate download for some time. Since the most common 'Java' 1.1 VM was the MSVM - which did not ever come with web start - these examples start with a minimum Java of 1.2.
Application - JTest application/applet
Java 1.2+
A little known fact, is that web start can be used to launch both applications and applets. Here is an example of a simple little application/applet that provides the names and values of some common Java properties, as well as indicating that a variety of them are Not Accessible in this sandboxed test.
Another important aspect of applet deployment is also demonstrated in
this example. The applet appears as a free floating entity, there is no
'web page' involved, even though we need to specify a documentbase
attribute within the applet-desc element!
The applet is loaded by the applet viewer, the only reason we need
to specify a documentbase, is to allow the applet to return
sensible values for the Applet.getDocumentBase() method.
Application - The Giffer
Java 1.4.2+
'The Giffer' is a small application for creating animated GIF's.
Library
The Giffer is perhaps more accurately described as a GUI'd front end
for the Animated GIF decoder/encoder library by Kevin Weiner.
The launch file(s)* simply call that library as a <component-desc />.
This offers a significant advantage in that the single component descriptor can not only be called by a number of different forms of the one application*, but can also be used as the back end of other applications & potentially applications that do not even reside on this domain.
So, for example, if another developer feels they can make a better front end for the libray, they simply need to call the common library from their own JNLP - they are spared the deployment overhead of the extra library, and even better, the end user is spared downloading the common library more than once! So if the user wishes to try both my application, as well as your variant that uses the common library, they will download one each of your code, my code, and the library code (once, prompted by whichever code calls it first). Neat!
Memory allocation
* While animated GIF's are designed/best suited for low color, slow frame animations as you might often see on 'any old web page', it is also possible to create some much more interesting animations. The author was first using the software to create Time Lapse Animations.
The TLA's consist of runs of still images that ranged from 200-600 in a single run - many more frames than your average animated GIF. The images were resized from the original resolutions of around 2200 pixels wide, down to 640x480, but still quite large for an animated GIF, and they retained the 'full' 256 colors available in this format.
The animated GIF produced under these conditions would typically be 45-60 Megabytes in size. And no, you will not commonly see GIF's of that size on 'any old web page'!
To avoid OutOfMemoryErrors while producing such
images, it is necessary to offer a form of The Giffer that runs
with extra memory assigned, and that is why there are is the second
form of the launch file, giffer0512.jnlp. It requests extra memory
from within the j2se element.
<j2se version="1.4.2+" initial-heap-size="64m" max-heap-size="512m" />
Note that you might also generate the JNLP file using a servlet or some other active means, thereby offering the end user the option to request as much memory as their system can offer, or that they would be willing to devote to the application.
Application - 'Knock Knock' server/client example
Java 1.4+
This example should be familiar to anyone who has done the Reading from and Writing to a Socket section of the Java Tutorial, as it is simply a GUI wrapper around the server/client code used.
What makes this example interesting, is the security environment in which it operates. The launch files request no extended permissions, and the code itself is not digitally signed, yet the client can connect to the server via sockets on the local machine, after the user is prompted to allow the action. Related files (an html file for the applet, the source..) can be found in the test/kk/ directory.
It has been suggested that the prompting behaviour was introduced in Java 1.6. These launch files request 1.5 and 1.6 specifically, to allow testing.
Instructions
Much the same instructions as for the command line based example. The changes in the GUI'd version can be summed up by the following.
Launch the server by launching the kkserver.jnlp.
Once it is on-screen, select a port number from the combo box
on the top right of the GUI (or skip this step and accept
the default port number of 4447).
Activate the Start Server button.
Activate the Launch Client button.
Note this example is single threaded - each server
will accept just one client.
Once the client is on-screen.
Select the port number that matches the server port number,
from the combo box on the top right of the GUI
(or skip this step if you accepted the default
port number above)
Activate the Start Client button.
'Follow the prompts' for allowing connection, dismissing info.
messages etc., and the initial 'Knock Knock' JOptionPane
input prompt will appear from the client, requesting a reply to
the message from the server.
This example was announced on the threads - Desktop app. coms. via sockets - test on comp.lang.java.programmer, as well as 'Report Back' web start launch - test on Sun's Deploying - Java Web Start & JNLP forum - to a disinterested audience. Further test results for this example, especially from boxes with an active firewall, would be most welcome.
