Posts Tagged ‘webstart’

JNLP Downloader Tool

Wednesday, March 9th, 2011

Some time ago, Rubén wrote a Java based tool to download all JNLP resources and prepare executable files to run it based on the JNLP file values.

It downloads all the resources specified by the JNLP file and save them into /libs and /natives for jar resources and nativelib resources respectively, in the second case it creates sub folders for each platform (Windows, Mac and Linux). After that, it creates one executable script file to run the application for each platform, configuring classpath and java.library.path inside it.

For example, running the tool:

 
 java -jar jnlpdownloader.jar example http://www.example.com/application.jnlp

where the JNLP contents are:

 
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+" codebase="http://www.example.com/" href="application.jnlp">
    <information>
            <title>Some Title</title>
            <vendor>Some Vendor</vendor>
            <description>Some Description</description>
    </information>
    <resources>
            <jar href="slf4j-api-1.5.8.jar" />
            <jar href="google-collections-1.0.jar" />
            <jar href="lwjgl-2.4.2.jar" />
    </resources>
    <resources os="Windows">
            <nativelib href="lwjgl-2.4.2-natives-win.jar" />
    </resources>
    <resources os="Linux">
            <nativelib href="lwjgl-2.4.2-natives-linux.jar" />
    </resources>
    <resources os="Mac">
            <nativelib href="lwjgl-2.4.2-natives-mac.jar" />
    </resources>  
    <application-desc main-class="Main" />
</jnlp>

will create the next file structure:

 
./example
./example/natives
./example/natives/Linux
./example/natives/Linux/liblwjgl.so
./example/natives/Windows
./example/natives/Windows/lwjgl.dll
./example/natives/Mac
./example/natives/Mac/liblwjgl.jnilib
./example/libs
./example/libs/google-collections-1.0.jar
./example/libs/slf4j-api-1.5.8.jar
./example/libs/lwjgl-2.4.2.jar
./example/run-windows.bat
./example/run-macosx.sh
./example/run-linux.sh

More info at the project's home page.

We used this tool mainly to take a snapshot of a deployed Java Web Start application to make it run offline, for demo purposes.

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Ways to deploy a Java Game

Wednesday, February 9th, 2011

When you develop Java games for PC, you have different ways to deploy them. We want to talk a bit about some of them.

Downloadable

The user has to download the game to run it on his machine, probably it comes with an installer to install the game before he can play it.

Pros

  • The game can be played offline when it has no online requirements.
  • User knows where the game is installed and sometimes decides where he wants to install it. They also can uninstall the game.
  • It is the only way to deploy a game in portals like Steam, Altitude Game is an example of that.

Cons

  • Users have to download a patch each time there is a new version. As a developer, you can implement something to download patches and apply them.
  • As a developer, you have to implement an installer. Also, you have to make different installers for each platform, an example of that is Revenge of the Titans (ROTT) from Puppy Games.
  • You have to create patches and deploy new files to be downloaded each time you have a new version of the game after a bug fix or new feature. Else, you force people to download large files each time you have an updated version.
  • Java Runtime Environment (JRE) must be installed or you have to embed JRE with your game. In the second case, your game file becomes bigger, for larger games that is not a problem but for small games embedded JRE could be, for example, 300% of the game size (at today, JRE weight is about 20MB). Even though there could be a JRE installed, being able to execute your program directly depends on a good configuration of the JRE within the OS. To solve that, developers usually generate a native wrapper that detects where the installed JRE is, and if it is not installed prompts the user to download one, or reports the error to the user.

Applets

Java Applets works inside the browser, as well as other web technologies like Flash and Unity. Users only have to open a page with a Java Applet inside and it is loaded by the web browser. Minecraft is an example of a successful Java Applet Game (it has other deployment options as well).

Pros

  • Users only have to follow a link to play the game. No game install is required.
  • Users are always playing the latest game version, because it is being downloaded from the server.
  • As other web technologies, you can add information or even ads to your applet page without having to put that inside the game.
  • Java Applets are as powerful as a Java Desktop application.
  • New Generation Java Applets accepts Java Networking Launching Protocol (JNLP) files (more info on next blog posts).
  • Pack200 and GZip compression support to reduce jar download sizes (only using plugin2).

Cons

  • JRE must be installed on the client machine. However, nowadays you can assume the required plugin is installed on most of the client machines.
  • You need a web server to deploy your game jars or you have to use a games portal like GameJolt or Games4j.
  • Dependning on the Java Applet technology you are using (plugin2, etc), firefox can freeze when the applet is loading, or could not work on Mac OS (more information on next blog posts).
  • As a developer, you need to sign your jars with a certificate if you want to have full access (to do extra stuff like writing a configuration file on user's home folder).
  • If you ask for full access, a security dialog box is displayed. It tends to scare users, if you have a valid certificate then it is a bit less scary.

Web Start

Java Web Start is some kind of mixing between the last two. As developer you use a JNLP file to describe which resources must be downloaded. Users only have to click on a JNLP link and then the game is opened automatically by Java Web Start.

Pros

  • Users only have to follow a link to play the game. No game install is required.
  • Automatically downloads the latest version of your game from the server each time the user wants to play a game.
  • It has a cache for downloaded resources, so if you only update one jar then it is the only one downloaded by the user's machine the next time the user opens the game.
  • As a developer you can specify to run the game offline.
  • It has a clean way to specify your game's resources using the JNLP file.
  • Pack200 and GZip compression support to reduce jar download sizes.

Cons

  • Some browsers are not configured correctly (for example, Google Chrome) and they don't open the JNLP automatically using Java Webstart, they just download the file.
  • Same thing with certificates and signing as the Java Applet.
  • As a developer you need a web server to put all your game's resources, we don't know any portal which accepts JNLP games yet.
  • Java Webstart Cache and Log files are difficult to find on user's machine.

Getdown

Getdown is a custom solution made by Three Rings in order to replace Java Web Start technology due to its limitations, as it is explained on Getdown's project Wiki. We lack experience and information about this solution, so the pros/cons section could be a bit empty.

Pros

  • Open source, that means you know what is happening, and you can collaborate, something impossible with Java Web Start.
  • Working examples of mmo games like Sprial Knights from Three Rigns and Tribal Trouble 2 from Oddlabs.

Cons

  • It is custom made. That means, as a developer you have to be aware that if something goes wrong you may have no support (note the conditional). But can't say it is really a cons because with Java Web Start you don't have any support at all from Oracle's team.

References

  1. Altitude Game - http://altitudegame.com/
  2. GameJolt - http://gamejolt.com/
  3. Games4j - http://games4j.com
  4. Getdown - http://code.google.com/p/getdown/
  5. Java Plug-In Technology - http://www.oracle.com/technetwork/java/index-jsp-141438.html
  6. Minecraft - http://www.minecraft.net/
  7. Oddlabs - http://oddlabs.com/
  8. Pack200 - http://download.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-guide/pack200.html
  9. Puppy Games - http://www.puppygames.net/
  10. Revenge of the Titans - http://www.puppygames.net/revenge-of-the-titans/
  11. Sprial Knights - http://spiralknights.com/
  12. Steam - http://store.steampowered.com/
  13. Three Rings - http://www.threerings.net
  14. LWJGL Wiki - http://www.lwjgl.org/wiki/index.php?title=General_FAQ#Distributing_LWJGL_Applications

UPDATE: added link to LWJGL wiki page about how to distribute LWJGL Java Applications (most of them applies for Java Applications in general)

VN:F [1.9.22_1171]
Rating: 5.0/5 (1 vote cast)

Signing JARs for Applet and Webstart

Sunday, February 7th, 2010

We are developing our games using Java and deploying them as Applets and Webstart applications.

By default, applications launched with Java Webstart or as an Applet run in a restricted environment. We are using some technologies which require unrestricted access like Lwjgl, Jinput and custom ClassLoaders. In order to have access to these features, every jar must be signed with a certificate.

Once the jars have been downloaded on the client machine and the signature is validated, the user is requested whether he trust or not the provider of the certificate and if he wants to accept it permanently.

In the beginning, one option is to generate a new certificate every time we sign the jars of an application but this means that although the user might have accepted a certificate permanently, he will have to accept the new one.

A better option is to generate a certificate once and use it every time we sign an application, so that whenever the user accepts our certificate permanently he won’t be bothered again.

A way to create a certificate and manually sign an application with it is explained at Sun's Java Documentation.

In our case, we are using maven as our build tool with maven-webstart-plugin to automatically sign our jars. This plugin allow us to use both options.

In order to easily choose between them, we configure the plugin using properties instead of fixed values, so we can override them with profiles. Using the default values of these properties, the plugin generates a new certificate each time.
If we want to make a public build, we activate a maven profile overriding these properties to use an existent certificate used by all of our applications.

Here are some snippets of our configuration files:

pom.xml - maven-webstart-plugin configuration

  
<configuration>
	<sign>
		<keystore>${gemserk.keystore}</keystore>
		<keypass>${gemserk.keypass}</keypass>
		<storepass>${gemserk.storepass}</storepass>
		<alias>${gemserk.alias}</alias>

		<!-- default values if gen is true -->
		<validity>3560</validity>
		<dnameCn>Gemserk</dnameCn>
		<dnameOu>Gemserk</dnameOu>
		<dnameO>Gemserk</dnameO>
		<dnameL>Montevideo</dnameL>
		<dnameSt>Montevideo</dnameSt>
		<dnameC>UY</dnameC>

		<verify>true</verify>

		<keystoreConfig>
			<delete>${gemserk.keystore.delete}</delete>
			<gen>${gemserk.keystore.gen}</gen>
		</keystoreConfig>
	</sign>
</configuration>

We use our company name as a prefix for the property keys in order to have a common scope when setting the values.

pom.xml - default values

  
<properties>
	<!-- Properties for keystore generation  -->
	<gemserk.keystore>/tmp/keystore-gemserk</gemserk.keystore>
	<gemserk.keypass>m2m2m2</gemserk.keypass>
	<gemserk.storepass>m2m2m2</gemserk.storepass>
	<gemserk.alias>gemserk.com</gemserk.alias>
	<gemserk.keystore.delete>true</gemserk.keystore.delete>
	<gemserk.keystore.gen>true</gemserk.keystore.gen>
</properties>

settings.xml - profile declaration

  
<profile>
	<id>useDeploymentCertificate</id>
	<properties>
		<gemserk.keystore>/opt/gemserk-keystore</gemserk.keystore>
		<gemserk.keypass>password</gemserk.keypass>
		<gemserk.storepass>password</gemserk.storepass>
		<gemserk.alias>gemserk.com</gemserk.alias>
		<gemserk.keystore.delete>false</gemserk.keystore.delete>
		<gemserk.keystore.gen>false</gemserk.keystore.gen>
	</properties>
</profile>

In order to build an application for deployment, you can activate this profile from the command line using:

mvn package -PuseDeploymentCertificate

If you have any questions leave a comment.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)