This relies on the existence of a 'release' file in the top-level of the unpacked JVM. If no 'release' file exists (or it can't be read) then we fall back to the old behavior which is to assume that an unpacked JVM meets the app's version requirements. This also assumes that the java_version_regex configured for the app is capable of parsing the version string in the release file. The release file appears to contain a string that matches the system property 'java.version', so if you are doing version shenanigans and using 'java.runtime.version', you need to do one of two things: 1. Make sure your regexp can handle missing bits and that the lack of said bits doesn't hose your version checks. For example, if you need 1.8.0_42-b15 and your version regexp turns that into 108004215, but the release file just contains 1.8.0_42 which your version regexp turns into 108004200, then you're going to have a problem. But if your minimum version is some previous patch release (say 1.8.0_25-b32) and the custom JVM you ship is 1.8.0_42, then you'll be OK because 108004200 > 108002532. 2. Create your own 'release' file in your custom packaged JVM (or modify the existing one) which contains a line with the following syntax: JAVA_VERSION="VVV" where VVV is the full version string that your regexp expects. It will be extracted and parsed with your regexp, and everything will be peachy.
What is it?
Getdown (yes, it's the funky stuff) aims to provide a system for downloading and installing a collection of files on a user's machine and upgrading those files as needed. Though just any collection of files would do, Getdown is mainly intended for the distribution and maintenance of the collection of files that make up a Java application.
It was designed as a replacement for Java Web Start due to limitations in Java Web Start's architecture which are outlined in the rationale section.
How do I use it?
A tutorial and more detailed specification are available from the Documentation page. Questions can be posted to the OOO Libs Google group.
How does it work?
The main design and operation of Getdown is detailed on the design page. You can also browse the javadoc documentation and source code if you're interested in implementation details.
Where can I see it in action?
Getdown was originally written by developers at OOO for the deployment of their Java-based massively multiplayer games. Try out any of the following games to see it in action:
- Puzzle Pirates - OOO
- Bang! Howdy - OOO
- Spiral Knights - OOO
- Tribal Trouble 2 - Oddlabs
Getdown is implemented in Java, but certainly can be used to deploy non-Java-based applications. Doing so would be a little crazy since you may have to install a JVM on the user's machine (if they don't already have one installed), which is a ~7MB download. This isn't so bad if you're already installing a Java application and must have a JVM, but it's a little crazy if the JVM is only used for your installer. It is probably possible to compile Getdown with GCJ, which would make Getdown a viable choice for non-Java applications.
Obtaining Getdown
The latest version of Getdown can be obtained thusly:
- Download the pre-built jar file from Maven Central: getdown-1.4.jar
- Obtain the jar artifact via Maven with the following identifier:
com.threerings:getdown:1.4. - Check out the code and build it yourself.
You can also:
- View the javadoc documentation online.
- Browse the source code online.
Building
Getdown is built with Maven in the standard ways. Invoke the following commands, for fun and profit:
% mvn compile # builds the classes
% mvn test # builds and runs the unit tests
% mvn package # builds and creates jar file
% mvn install # builds, jars and installs in your local Maven repository
Discussion
Feel free to pop over to the OOO Libs Google Group to ask questions and get (and give) answers.