Simon Morris's Blog

Blame Java!

A couple of incidents have happened to me in the last few days which highlight Java's desperate plight on the desktop.

The first involved a currently existing Java desktop application, a project originally developed at another university which somehow seems to have landed on my desk. The client brought the project to us, requesting a ground up re-write. The reason was made abundantly clear in the opening paragraph of their requirements document:

"The software language must not be Java, as in previous tests this has proved to be temperamental with types of hardware and various accessories."

Note how the software wasn't to blame, nor the original programmers, nor the hardware or OS. The problem is assumed to be 'Java'!

Comments

• web-start enabled application runs without problems almost ever :)) If you create offline deployable desktop application, several bugs usually happens.

  Posted by: felipegaucho on November 08, 2006 at 03:11 AM

• Quicktime for Java perhaps? As long as you are happy to target Windows and Mac then it would seem to be a good solution - especially with H264 codecs for video, which are awesome. See http://developer.apple.com/quicktime/qtjava/ and http://www.oreilly.com/catalog/quicktimejvaadn/

  Posted by: cbarham on November 08, 2006 at 05:23 AM

• How hard is to bundle the JRE with your application? Assuming you can spare around 70Mb for it in your distribution then you won't have trouble with deployments.

  Posted by: applebanana8 on November 08, 2006 at 08:03 AM

• "spare around 70Mb for it in your distribution"

  ? u is one of these clients?

  The compressed full version JRE takes less than 16 MB

  Posted by: fcmmok on November 08, 2006 at 08:38 AM

• Yes, it seems the only solution is to ship the entire JRE with each and every application, and write some platform specific glue code - like a DOS batch file - to fire it up.

  (Which begs the question: what is the Mac equivalent of a batch/script file? Sorry, not much of a Mac-head...)

  Posted by: javakiddy on November 08, 2006 at 09:38 AM

• We're working on a Java video editing app that uses QT for Java. Although it's mostly working, it has not been much fun to work on - there are numerous problems, especially on the PC side, that have required a bunch of workarounds. It's still not 100% stable. I'd write more details if I understood everything that's happening, but we're still troubleshooting.

  Posted by: jbarnum on November 08, 2006 at 10:13 AM

• Unless you missed the boat, I don't see how you think MSFT desktop development is easier. You've obviously never experienced DLL hell when writing MSFT apps? Believe me, it is so painful to debug and it happens often...just go ask any MSFT desktop shop. Actually I've done better...here you go.

  http://en.wikipedia.org/wiki/DLL_hell

  I'm not familiar with .Net as much, nor One Touch...but before One touch(a year ago?) there was nothing like WebStart. But VB and C++ desktop development was not easy at all for large complex apps.

  Also you haven't mentioned OS, but what will you do when your client needs to be cross platform? If you don't choose Swing, are you going to charge for writing multiple apps for each OS?

  I've done and dusted a number of mission critical swing apps in my time, and havne't had any problem w/ webstart other than clearing the cache.

  Reminds me of this entry I just replied to:
  http://www.dzone.com/links/j2ee_sucks_huge_donkey_balls.html#1248076

  I'd be curious to see how experienced these developers were with Swing. Swing is not the easiest API out there as everyone says...but I don't think being a good Swing Developer is any more difficult than being a good AJAX / Javascript / DHTML / Web Developer. Developers complain b/c they can't make complicated, nice gui's right out of the box in Swing...but in my experience, the same is true w/ creating complicated nice gui's w/ all the various web technologies. However, I don't see the web developers complaining about the chore of mastering all the technologies they need for their space.

  Posted by: javaguy44 on November 08, 2006 at 10:38 AM

• Check out http://www.simplecenter.com/ and http://iondb.com/ very interesting Java media applications. Yes, Java has a very weak spot in the media dept. but for once Sun is not the main problem: its patents.
  JMF takes the idea of either using a bridge to a native codec (which you have to write) or writing a codec in Java. Thats a mistake because almost every major sound or video codec is laced with patents like arsenic! Sun would be opening itself to lawsuits from here to kingdom come. Apple, MS and Real who make media their business and have piles of patents in the field which they can use to counter attack (they also license some patents for their commercial software) can afford to build free players and API's... Sun can't and most certainly can't open source something like this.
  It gets worse... Sun can't just call a native API to perform something like this because there is no such API that works properly and consistently across platforms. So JMF is broken and unmaintained, QT which is currently one of the best options is usable for most typical use cases (but has its issues as listed above).
  If you need to support any type of file, QT is pretty much the only game in town. If you can limit your content to a particular codec (a restriction that exists in Flash) you can take one of the free codecs out there that are available in pure Java such as OGG. That could solve your problem but I never tried this myself...
  About Java deployment, I feel your pain :-( Its getting somewhat better though.

  Posted by: vprise on November 08, 2006 at 11:28 AM

• I'd really LOVE to use WebStart... but...

  The problem with saying "just use WebStart" is (a) it requires a correctly installed, correctly configured, JRE already present on all target machines, and (b) it assumes the client (the people putting their hand in their pocket and funding the application) are happy that their audience may need to download and install another large piece of software BEFORE they can download their own application.

  With native EXE files you just click to download, and click to run (the installer...) Nice and simple. There's no instructions you may-or-may-not need to follow or sites you may-or-may-not have to go off to first prior getting your actual application.

  When you're dealing with a client who's profile is so high that you could have tens of thousands of installations in the first few months of the application's life, you only need a small percentage of those to have trouble, and customer support becomes a nightmare...

  Didn't someone write a Java desktop installer which runs as a native app and installs the JRE if missing? Is this available on multiple platforms?

  Posted by: javakiddy on November 08, 2006 at 01:11 PM

• I have spent the last 7 years making desktop java applications. I bundle the VM with the application and ship it out across Solaris, Linux and Win32.
  I don't have the problems of the application not starting or it not finding third party libs. That is just bad deployment on the part of the programmers.
  And YES, you will have this problem with VB, C++ and C# if you do a poor deployment job. Simon, do you not remember the DLL hell of VB and C++ on win32???

  Posted by: brianaracnetcom on November 08, 2006 at 02:03 PM

• javakiddy: The Mac equivalent of a script file is a script file. Mac OS X ships with bash as the default shell environment. But note that Mac OS X also ships (on the DVDs) with a tool that create a .app (the Mac equivalent of a .exe) from JAR files. You just define everything you need to run a Java app (name, VM flags, application icon, classpath, etc.) and you're done.

  Posted by: gfx on November 08, 2006 at 03:01 PM

• Wow...
  So I've deployed applications in Java on Linux, Solaris and multiple flavors of Windows. Takes all of 3 minutes if you know how to build a jar file correctly. I either bundle everything in one jar OR I put the key jars in the ext folder of my JRE I'm shipping my application with OR I set the classpath.
  So where I work the VB guys have to run a bat file that PUSHES system DLL files into the system32 directory. It also has to remove all window registry settings and then reset everything. THIS IS FOR the users to be able to LOAD an EXE application file written in Visual Basic that is ON A NETWORK DRIVE.

  
  So my Java application ONLY requires a OS script to launch the correct JRE and then run the JAR with the path set up correctly.

  So if you did this in C# you would have to worry about WHICH service pack and WHICH version of .NET AND you could not run on older versions of the Windows OS. My Java application runs on Win95 all the way up to XP. Heck, it even runs on BOB if you remember that piece of innnovation from Redmond. ;-)

  Posted by: cupofjoe on November 08, 2006 at 04:36 PM

• I just wasted like 4 hours wrestling with classpath and relative pathing for files in a command line prog.... i'm hating Java right now. Too bad moving to Java 6 is still very far away for me.

  Posted by: ilazarte on November 08, 2006 at 11:11 PM

• Excelsior JET would help both runtime performance (AOT is fast right from the start) and installation experience. However for the media part that I do not know.

  Posted by: vtec on November 08, 2006 at 11:11 PM

• javakiddy, I work for an extremely high profile client as well. I manage my dev teams + global deployments to the major financial centers w/ Webstart and no issues other than clearing the cache.

  Correct me if I'm wrong, but what you are essentially doing saying I believe is putting your .exe on a webserver? And letting the user's download? If so, How do you deal w/ upgrades? And not just small ones but large ones that will require a full clean of the registry etc. beforehand??

  If your client is unhappy about downloading the JRE, that is of my belief that whoever was managing did not communicate that this would be a necessity(you say high profile client -- no steering committees? Stakeholder meetings?); nothing more. You are being hypocritical in this complaint about the JRE -- go check the friggin size of the .NET runtime...

  It seems to me though you are trashing Webstart, but at the same time haven't experienced the other side -- not very nice really. It seems like your mind is already made up though so then I wish you well in building the next MSFT? apps. But I don't think it's really fair of you to trash webstart and claim that the other side is better when you really really experienced it.

  I'm not prophetic, but in a couple of years time after what us veterans call DLL Hell, I think you will definitely have a renewed appreciation for webstart.

  ilazarte - or you talking about Webstart or Java classpath's in general? 4 hours is a long time...I don't see how it can take you so long unless you don't know how java ClassLoading works. If you want, I'll help you out. email me @ javaguy44@yahoo.com

  Posted by: javaguy44 on November 09, 2006 at 12:02 AM

• @javaguy44: how does WebStart work with desktop machines which don't yet have a JRE installed? :)

  You seem to think I have an anti-Java anti-WS attitude: nothing could be further from the truth. If you just read the blog you'll see I WANT to use Java/WS - but selling desktop Java to clients is a harder sell than selling a ".exe" . And it is probably precisely because you can't guarantee that everything you need is already present on the machine that the few really successful Java desktop apps ignore WS in favour of bundling the JRE.

  In fact the real problem is not that stuff is missing: the real problem is that one has to rely on the user to 'manually' download and install the correct JRE. There's no way of adding a native bootstrap which looks for Java and handles the download and installation automatically if necessary.

  Would I be correct in assuming that your audience (financial clients) are very much a closed environment where you can exercise a reasonable degree of say over what will be installed on each of the desktops, and there are technical staff on hand to fix any issues at each centre? I've written dekstop applications in Java for such managed environments, and they present no great problems. But I've also written apps which are downloaded by members of the public - no controlled environment, no techies to fix problems (and no way of controlling what other garbage may have screwed around with their computer in the past). Despite clear instructions to go and download a JRE from Sun's official "Get Java" page, and despite the app coming as one small Jar file with no dependencies, there's still a percentage of users who run into issues. (And that was with an installed user base of probably only a couple of hundred. The client I'm referring to may well be promoting this software to a much much larger audience! Yikes! :)

  One can always slag off a rival platform by stating extreme examples. If I don't like the size of the .Net download, I can simply not use the .Net libraries. And DLL hell can be avoided by using one's own copies of the require DLLs (although that does defeat the purpose of having shared libraries -- but then again so does bundling one's own JRE!)

  I do still intend to pitch Java as the platform for this application. We'll probably have to bundle an entire JRE with the application, probably quadrupling its footprint. I love Java, and the benefits outweigh the problems. But what I'm fearing is that Java has such a reputation for being slow and awkward to get working that the client may have an allergic reaction at the very mention of it (as clearly the first clients I mention in my blog now have!)

  Posted by: javakiddy on November 09, 2006 at 02:28 AM

• As for deployment - try wrpping your jar in a native executable wrapper:

  http://launch4j.sourceforge.net/

  As for media support - there are two paths:

  1. General solution - supporting any media:

  You will have to rely on a platform support for media and is platform (OS) specific. This means linking directly with ActiveX controls (Windows) or shared libs (Linux/Unix) via JNI native API.

  This is going to be major feat to make it consistently work over multiple platforms. Good luck.

  Links to help you get started:
  http://www.humatic.de/htools/dsj.htm

  2. End-to-end solution - you control the media type, creation to consumption.

  You could choose a Java-specific solution that supports specific media well over all platforms. QuickTime for Java from Apple and IBM's MPEG-4 for Java come to mind.
  http://developer.apple.com/quicktime/qtjava/
  http://www.alphaworks.ibm.com/tech/tk4mpeg4

  Good luck, Peter
  

  Posted by: dummy on November 09, 2006 at 02:28 AM

• @gfx: Thanks for that. I knew OSX has a BSD foundation, but I didn't know if that meant I could just run shell scripts by double clicking them. Being as Linux is my main development platform, I suspect I'll feel right at home with rattling off a quick startup script, but I'm interested in seeing how that .app solution you mention works too.

  Posted by: javakiddy on November 09, 2006 at 02:38 AM

• Posting again - this time in HTML
  As for deployment - try wrpping your jar in a native executable wrapper:
  launch4j.sourceforge.net

  As for media support - there are two paths:
  1. General solution - supporting any media:
  You will have to rely on a platform support for media and is platform (OS) specific. This means linking directly with ActiveX controls (Windows) or shared libs (Linux/Unix) via JNI native API. This is going to be major feat to make it consistently work over multiple platforms. Good luck. Links to help you get started:
  fobs.sourceforge.net/features.html
  www.humatic.de/htools/dsj.htm
  2. End-to-end solution - you control the media type, creation to consumption.
  You could choose a Java-specific solution that supports specific media well over all platforms. QuickTime for Java from Apple comes to mind.
  developer.apple.com/quicktime/qtjava/
  Good luck, Peter

  Posted by: dummy on November 09, 2006 at 02:43 AM

• @dummy: cheers! I've only minimal experience with using video within Java, so any experience/advice people wish to share is useful. I suspect I'll only need straight forward video playback, so that should simplify things. Gawd knows what I'll do if they want capture or editing! :)

  Posted by: javakiddy on November 09, 2006 at 02:44 AM

• If you only need playback capabilities, then the question comes down to: Which platform do you have to support?
  Windows only - I'd suggest calling native DirectShowAPI.
  This will give you support for any media codec installed on the system and will not requre you to deploy and additional codecs/ platform specifitc DLLs www.humatic.de/htools/dsj.htm

  Multiplatform (Linux, Windows, possibly OSX) - wrapper around FFmpeg or VideoLAN(VLC). They are both multiplatform media players.
  trac.videolan.org/jvlc
  fobs.sourceforge.net/

  Regs, Peter

  Posted by: dummy on November 09, 2006 at 03:09 AM

• Simon: Can JMF be trusted, and how flaky is its ability to work with native codecs on various OS platforms?

  The "native codec mountain" can go to Java with tools like JNIEasy, for instance LAMEOnJ (based on JNIEasy) can encode an audio stream to MP3 using the native methods of the LAME DLL.

  Posted by: jmarranz on November 09, 2006 at 03:37 AM

• javakiddy - if you put that disclaimer up in the first place, you might have saved me a lot of time in typing ;) You're right, I'm in a managed env.

  Essentially, you are trying to idiot proof a process to millions of people of which a percentage will certainly be not as tech saavy. Good effort -- If you create a cross platform idiot proof piece of kit, I'm sure you could be well minted. I think the realities of implementation would be....well all the best of luck to you.

  I don't agree w/ your extreme examples; If you write a .net app, you need the .net runtime / CLR full stop. If you write your app in .net 2.0, you will have similar problems w/ compatibility as the JRE. If you deploy the app you are talking about to the general public you will have to account for the fact half your users could have .net 1.1 and the other half have 1.0 or nothing at all. Same situation as the JRE.

  Posted by: javaguy44 on November 09, 2006 at 04:00 AM

• Great write-up Simon.

  Javakiddy is completely correct about the 'chicken and the egg' problem with Java Web Start. Launch4J sounds like a solution, I'll have to try it. If it does work, the question that begs to be asked is why isn't it or similar in the JDK? We need an exe-making installer!!! Hopefully that's what our friend Ethan Hawke will make happen.

  Posted by: commanderkeith on November 09, 2006 at 04:30 AM

• 
  I'm fighting a cold at the moment so if it seems like I'm on medication.... ;-)

  
  A JNLP file will start the download and insure you have the correct JRE and even put a link on the desktop. It does force you to have the JNLP mime type set in the browser as well as have a web site to distribute your application.

  It has been my experience that Java is EASIER to install because it doesn't require anything but a JRE and a little knowledge.

  
  If you go the EXE windows installer route you force your user to have write permissions to the registry. There are also more and more security programs that go crazy with EXE files loading or installing. JARS are just sweet and simple IMHO.

  
  The only thing that a lot of very high end shops do. I'm thinking about products like JBuilder or TogetherJ if you remember the UML tool is...
  Create a JRE for each platform and scripts and tools that leverage the user experience for that platform. Have a folder for each platform and than use Java to figure out how to install the correct version.

  
  The version of JBuilder I use allows me to create binary files for every platform I want to ship with. It has been my experience JARS are the easiest route unless your dealing with someone who isn't computer savy and over the age of 40. ;-)

  Kind regards,

  Posted by: cupofjoe on November 09, 2006 at 06:18 AM

• @cupofjo - You kind of missed the point - Java Web Start and the JRE do not come with Windows so clicking a JNLP file without a JRE will not do anything but pop an 'Open With..." dialog or maybe a text editor!And as said by Simon the JAR file extension is always taken by WinZip & friends so JARS are not feasible.

  Posted by: commanderkeith on November 09, 2006 at 07:17 AM

• commanderkeith - the jre was installed on my dell i bought a few months ago.

  goin back to the chicken and egg...w/ the windows + .net route, you still can't be sure which version of .net or if they have it at all.

  Posted by: javaguy44 on November 09, 2006 at 08:03 AM

• While they do exist, there is hardly anything from sun yet:
  GUI BINDING FRAMEWORK, Again GUI BINDING FRAMEWORK. (sits back waiting for 295)

  Posted by: coding on November 09, 2006 at 08:07 AM

• @javaguy44: yes, but in all fairness you can avoid using stuff like .Net and work with the older, more established, libraries. It's a bit of an apples/oranges situation -- worried that one can't guarantee the latest APIs are installed, versus worried that one cannot guarantee any APIs are installed!

  Posted by: javakiddy on November 09, 2006 at 08:14 AM

• javakiddy - we are right back to what I was saying before with me saying that as someone who did a lot of msft development pre .net development I think webstart is a huge upgrade in comparison.

  alright...i've got nothing more to say on this...best of luck

  Posted by: javaguy44 on November 09, 2006 at 09:10 AM

• Oops, just realised Javakiddy == Simon. :)

  A little while ago Ethan Hawke said Sun are considering an installer for Dolphin (Java 7).

  @javaguy44 - Sun's Chris Melisinos says that ~65% of new PC's come with Java & 18 million downloads of Java occur from www.getjava.com every month (see his cool blog). Still, that's at least 35% of new computers that don't have a recent version Java and who knows how many old ones that don't either.

  
  This basic deployment issue is so big that the game devs on http://www.javagaming.org bend over backwards to avoid using AWT or Swing so that they can compile their games using GCJ or Jet. Sometimes they even illegally distribute their game with a stripped-down bare-bones VM in an exe-file.
  see this thread & scroll to pricec's 7 options

  Posted by: commanderkeith on November 09, 2006 at 09:23 AM

• If Launch4J doesn't do what you want, look at JSmooth.

  I'm not sure what the differences are.

  Posted by: mhall on November 09, 2006 at 11:50 AM

• One-click WebStart is possible even if the client doesn't have a JRE installed - provided the client uses Internet Explorer or FireFox (perhaps others) - using the JRE autoinstaller feature documented here: http://java.sun.com/j2se/1.5.0/docs/guide/javaws/developersguide/launch.html#creating

  Although not mentioned in that guide, there is an autoinstaller in the form of a FireFox plugin script (xpi) as well.

  Sun uses a similar procedure on the java.com site.

  Posted by: herko_ter_horst on November 09, 2006 at 12:20 PM

• regarding video: IBM has a pricey (somewhere aroudn $5k, I think) all-java MPEG-4 library. Not sure if you need to play arbitrary video, or can control the codec, but it might be something to look into.

  Posted by: rbair on November 09, 2006 at 02:48 PM

• Three mostly unrelated potential solutions to Java deployment problems:

  Java should have a ".jxe" extension for executable jars, and leave ".jar" for libraries. Ideally, the jxes could have other jars inside them, more like war files. Not sure how this relates to the new packaging stuff.
  Open source Java will make embedding subsets of the JRE easier for smaller apps. Also related to the Java Kernel project, I guess. But slice and dice however you want if you don't say "Java" once it's open source.
  An improvement to web start: Make a new extension (".jws"?) that is simpler than "jnlp". _All_ it has is the URI of a ".jnlp" or ".jxe" file. Then it would be safe to save these files locally, send them in emails, and whatever else. Since all they have is a URI, you don't have to worry about other information in them becoming stale.

  Posted by: tompalmer on November 09, 2006 at 02:58 PM

• @herko_ter_horst - one-click web start where there's no JRE does not work either since it requires ActiveX controls which are always disabled. You have to tell the user to "look for a yellow warning bar at the top of IE & click set it to allow ActiveX". Then the JRE menus come up and then your app can finally start. That is, if the user persevered through all that pain.

  Tom Palmer, those are excellent ideas. Nevertheless, the JDK should still get a bundled exe-maker. I know its not cross-platform but when 99% of target audience use Windows, what's the point of making life hard for us? MJac & linux distros will always bundle a JRE since its in their interests, but microsoft wants to bury Java so to infiltrate windows we need an exe deployment option. What about an exe file that was really just a .jnlp file, but it could also detect if there is a JRE and when its missing, it downloads & installs the JRE off the net. Then the exe file gets on with Web Starting the app. That way, the exe files aren't any bigger than the jnlp files since they don't include the JRE, but they can download it on demand. Is it feasible?

  Posted by: commanderkeith on November 09, 2006 at 08:38 PM

• I think Jet solved the AWT problem in version 4, they also have a pack feature that uses pack200 or something to create a much smaller installer. Seems like a really cool option, if only they added an auto update feature like webstart...
  Some people (like me) are never happy ;-)

  Posted by: vprise on November 09, 2006 at 11:05 PM

• Re: Video playback

  Software control for video playback is a deeply broken thing on computers. It's a complete nightmare. Almost anyone who has used almost any software for video playback will see just how often it breaks i.e. fails to play the video. And as for software for encoding - well, don't get me started. So, whatever language you choose, you're probably in for a fun time ;-)

  The best choice of language on Windows for writing video software is probably C++. Ugggggghhhh... But thankfully, you can do an OKish job with C#. As for Java, well, it's always been a disappointment as far as handling rich media is concerned. Now, I haven't checked out JMF for a few years. My guess is that not much has changed in that time - there seems to have been very little investment in it.

  Bottom line: if the requirements for this project are tightly defined, and won't change... and Java can do the job, that's great. If you need to build in flexibility to take account of a project that may move in unforeseen directions, Java is probably a risk as choice of language.
  

  Posted by: psynixis on November 09, 2006 at 11:51 PM

• @commanderkeith - that was exactly my point. the statistics you gave would be similar to .net if you were writing .net apps. Simon said no .net...so fine.

  I don't deliver and write games, so I can't say for sure, and I'm in a managed corporate env. As Simon agreed, with a help desk to help those who are not as computer literate, we have no problems w/ webstart.

  Btw -- if someone is that desperate for a free .exe, you should just grok and put your touches from the one for Netbeans.

  Posted by: javaguy44 on November 09, 2006 at 11:59 PM

• Simon, for deployment, if you are considering commercial solutions and “the size does not matter” for you, I'd suggest Macrovision's InstallAnywhere. Honestly saying, I haven't tried it but they are saying it's a replacement for InstallShiled Multiplatform, and hence should have the same features. We've been using ISMP for years and though it's a buggy product, it was capable of producing java installers that worked out of the box with no pre-reqs at all. It is capable of generating native executables for a variety of platforms (including Windows, Mac OS and Linux); the executables contain JRE within them and this JRE is used to launch the installation (and which later can be laid town to the target machine to use with your app). It also was capable of packing the whole installer into one fat native “.exe”.

  Posted by: alexter on November 10, 2006 at 03:10 AM

• @everyone!!! : that's for all the suggestions on installers etc. MUCH APPRECIATED! As is the advice on media playback -- I'm very much a novice when it comes to that aspect of desktop apps, so all the suggestions and advice you've been giving is very much welcome! Looks like I have a lot of stuff to research :)

  (I'm surprised nobody commented on the Torn video :)

  Posted by: javakiddy on November 10, 2006 at 07:29 AM

• the proof is in the pudding: Nucle Browser, painless install, auto update, full media support

  Posted by: jcloeten on November 10, 2006 at 11:24 AM

• For an open-source java Installer check out: IzPack

  If you need a very small bootstrap format use Mozilla's XPInstall. This also gets you the possibility of using Mozilla's JRE package (the same one that Firefox uses to download as an add-on if it doesn't detect the JRE on your machine). This is probably the most-tested cross-platform install tool you'll find anywhere. It's not as easy to use as a MSI Merge package, but you'll get there.

  If you need to install native parts as well (codecs?), you'll have to go with InstallShield for Java, or alternatively use different installer technologies for every platform (.deb, .rpm and MSI or NSIS or InnoSetup (I prefer the latter because of its excellent Pascal script which is very easy to pick up if you know InstallShield's InstallScript)).

  Launch4J works well in my experience, another possibility is JSmooth.

  If Java doesn't cut it, use the Mozilla XPCOM stuff with XUL as your front-end. Firefox is a prime example of how this works and it's not browser-specific as proven by ActiveState's Komodo IDE or SongBird. XPCOM however requires you to keep multiple build environments around, which can be somewhat of a PITA because you'll have to either statically link on Linux or test with at least 3.5 distributions (Debian/Ubuntu, Suse, Redhat).

  If you could give some more information on the presumed components of the application, I could perhaps give you more advice than just a few links :-).

  Posted by: jdelic on November 11, 2006 at 03:20 AM

• I have written a 100% Java Swing Music Player and organizer called Jukes found here: http://melloware.com/products/jukes/index.html

  The trick to good and easy deployment is to make an "uberjar" with all of your dependencies bundled in one JAR. Then for Windows I use Launch4J and make a Windows EXE out of my uberjar and ity will detect if the right JRE is installed on the system and inform the user. My deployment now is as easy as it was with a VB or Delphi applications I use to write. And using JRE 1.5 I find the Swing application performs VERY well and most of my users don't even know its a Java app/ You can see screenshots here:

  http://melloware.com/products/jukes/screenshots.html

  Posted by: elefkof on November 11, 2006 at 05:13 AM

• Good idea! For making an "uberjar" that contains all your dependencies, there's a handy utility jarjar. It might come in very handy for managing classpath-issues!

  Posted by: jdelic on November 11, 2006 at 05:51 AM

• Bit late off the mark, but there are a few deployment options that come to mind.
  Most every-day Mac users are not going to be very accepting of double-clicking a terminal command, I'm afraid. If you are targeting Mac OS X, the best way to get a Mac-native feeling application is to use Apple's deployment tool, JarBundler. It comes with Apple's (free) developer tools. It's a GUI to create a double-clickable, Mac-firendly application (i.e. with options to specify an icon, using the Mac OS menubar, turning hardware accelleration on or off, etc.). You would need a Mac to do this, but with Mac mini's starting at under $600, you know... After all, you're not developing the whole app on the mini, just packaging the Mac dist.
  If you cannot find a Mac to work on, you have two other options that I can see. One is to use a commercial installer. ZeroG used to have a decent one, InstallAnywhere, I think they're part of Macrovision now, or something. NetBeans uses it, I think, as Installshield Java version. Seems to do the job okay. The other is to assemble a double clickable Mac application by hand. This would involve learning some of the Apple-specific system properties for menubar and dock behaviour, and editing an XML Info.plist file, but other than that it is really just a matter of putting the jars, resources and startup bash script in their proper locations inside a .app directory. (Mac OS X applications are just directories, really.)
  Finally, I think deploying desktop applications on the Mac is actually easier than most other platforms because the JVM is provided by Apple, so you always know it's there, and it should typically work just fine. But then, I'm biased :). If you really want to go the whole hog, you can add a few lines of code tying into Apple-specific classes to handle OS events like open-with-document or print-this, as well as putting the Quit and Preferences commands in their "proper" Apple-specific places, and really give users the feeling this is a Mac-native application.
  Haven't got a clue about Windows.
  Good luck!

  Posted by: erwinv on November 17, 2006 at 08:47 AM

• Haven't read all the comments in detail so apologies if this has been posted already.

  Flash isn't preinstalled but you get a nice little 'click here' message to install flash the first time you need it. You should be able to do the same with java as the browser will know (with caveat) whether java is installed and what the version is. Hence replace your start app button with install java button and replace when done.

  Or have I missed something obvious?

  Webstart should be great, but has too many niggles that make it really tough to use outside of a controlled environment...

  By the way, big fan of the blog.

  Dan

  Posted by: dsm on April 19, 2007 at 09:17 PM

This work is licensed under a Creative Commons License.