Tuesday, 22 September 2009

Options for deploying desktop software in Java

Like my yesterday I'm going to copy & paste an answer from Stack Overflow.

Java software can be release in a number of ways depending on the target market.

The simplest for the developer (but hardest for the end user) is to just release a jar file (or set of Jar files). On many systems the JAR will be "double-click-able", and so act as an executable. But if the end user does not have Java installed it will not work.
Good if you control the target environment. Also good if you want to target Windows, Mac and Linux all at once. Any platform with Java can run it, including platforms you had not considered.
Bad if you are targeting normal users. It can not do "install tasks", set up anything in the start menu or associate itself with a file type.

Java Web Start is my preference in most cases. It gives a Java based installer and can set up the start menu, associate file types and all that goodness. But does bring up a security box on install.
Good for most cases. You have just the one link for all OSes.
Bad if you suspect the user does not have a JRE installed or you don't want the end user to be aware that the application is written in Java.

You could release a zip file with the Jars in and a .bat file and a .sh file to get the going.
Good for administrators, developers and command line applications.
Bad for end users who don't really know what a bat and shell script are and would have no idea what to do if the script was broken for their system.

A thin .exe wrapper round the Jar file. This gives the impression to the end user that the application is native. They normally come with...

A Java aware installer. This is a native installer (so different installers for Windows, Mac & Linux). This will be able to detect if the target machine has Java installed and if not be able to kick off the installation of the JRE. It will also be able to do all the fun post-install stuff such as setting file associations and add items to the start menu.
Good for most cases.
Bad if you are targeting multiply platforms as you will need to maintain an installer for each platform. Also bad if one of the target platforms does not have a Java aware installer (you will then need to use of of the other methods above for that one platform).

Native EXE. Using a Java-to-native compiler (Jet or GCJ) you create a native executable.
Good if you really don't want people to know you are using Java.
Bad as people think that this will magically make the application faster when it will not.

Monday, 21 September 2009

Randomly Ordered JUnit Tests

Could not be arsed to work for a bit, so got sucked into Stack Overview for a bit.
Never a good thing. Anyway one question was about how to run JUnit tests in a random order. So I sat down and looked over the APIs and gave it a bash:

import java.util.Collections;
import java.util.List;

import org.junit.runners.BlockJUnit4ClassRunner;
import org.junit.runners.model.FrameworkMethod;
import org.junit.runners.model.InitializationError;

/** Runs JUnit tests in a random order.
*
* @author mlk
*
*/
public class RandomBlockJUnit4ClassRunner extends BlockJUnit4ClassRunner {
   public RandomBlockJUnit4ClassRunner(Class klass)
      throws InitializationError {
      super(klass);
   }

   /** {@inheritDoc} */
   protected java.util.List computeTestMethods() {
      List methods = super.computeTestMethods();
      Collections.shuffle(methods);
      return methods;
   }

}

Annotate any class you want the unit tests to run in a random order with "@RunWith(RandomBlockJUnit4ClassRunner.class)" and hey presto randomly ordered unit tests. (Note: This required JUnit 4.5 or above).
Now JUnit does have a Sortable interface, but I've no idea how to actually ruddy use it. :'(