Thursday, November 11, 2010

Desktop Java Apps - to bundle or not to bundle a JRE?

First - here is my definition of bundling the JRE. Shipping your application with a JRE, such that it is the one used by default from your application startup scripts, regardless of the environment on the target system. The bundled JRE is not registered with the system, so it should not affect other applications on the system.

There are probably some good reasons not to bundle a JRE. Taking a moment to ponder, I can think of at least the following:
  • Bloat
  • No automatic security updates
  • Less portable
There may be more - but I believe the pro's will outweigh them regardless, once I add some additional constraints. Specifically, I am concerned with Java on the Windows desktop. Further, I am talking about larger, high engineering effort commercial software deployed to big companies. Not a small, independent Java app deployed to individual consumers. (although there may still be cases where that simplifies things). At a minimum, I would argue for stating "Use 1.6 Update X or higher" somewhere in a README, even for a small app. I've just seen too many weird issues not to.


On to some reasons for bundling a JRE:
  • Control over major Java version (1.4,1.5, 1.6) - this is less of an issue today, since 1.5 has reached its end-of-life and 1.4 is far behind that. Thank goodness for that.
  • Control over the exact version (i.e. 1.6 Update 20) - to ensure mandatory functionality works properly
  • So the end users don't need to install something additional
  • So your program is not influenced by the system environment
  • So your program does not influence other applications in the environment 
  • Less variables for when customers report bugs
  • No automatic updates - which could break functionality
  • Less to test
See a theme? Better control. Also, better isolation from the environment and other things that can go wrong.

For instance, in the 1.5 days, I recall one release that had very misbehaved tabbing through components in a UI. In the era of Windows 7 - you need a minimum of 1.6.0 Update 18 - or you have missing icons in Open/Save File Dialogs. It is not acceptable to have a UI defect like that in a shipping app - any less, and you don't have full Windows 7 support. Except on 64-bit systems Update 18 has a bad habit of crashing the JVM a lot...so you need a more recent update. Then there's the Swing/AWT changes in Update 12 that alter behavior. Then I'm pretty sure depending on the version, applets load differently, if that's a factor (in one of our cases, integration with another process - it is).

You can avoid all that by picking a version you know works for your required situations. This means less to QA. Less potential headaches. The trade-off is losing faster security updates, increased application size (which believe it or not - still matters even in the age of 3TB hard drives), and portability. If you are in a Windows-only market, as I have seen several applications be, then portability isn't affected. Even if there are other target platforms - it's just a matter of repackaging for other platforms.

I believe there are some good reasons to bundle a JRE - on Windows, anyway.

2 comments:

  1. To Bundle to bundle is not the question (at least for me), the question is how to bundle?
    Actually, I tested some solutions but they didn't meet my requirements. I want to pack a Java application with JRE so that an end user don't have to install anything to run my app, and he can't see anything but my exe(hidden JRE inside generated executable). In dotnet technologies, I tested Xenocode and it was marvelous. But now i can't find the Xenocode Like tool. Do you have any idea where can i start? :)

    ReplyDelete
  2. In the past I have used a commercial tool, exe4j. It's been some years, but I think that will bundle a JRE inside an EXE. Currently we simply bundle a zipped up Java install and extract inside our installation dir. No environment settings configured we just point to it...

    ReplyDelete