BrowserLauncher is a bit long in the tooth for my tastes.

I recently implemented something in my app that launches either URLs or
user-selected files using the designated application, and it works for
local HTML files too.  I strive to never use platform-specific code when
it's avoidable, but there are some platform-specifics involved in this
no matter what simply because the mechanism involved is specific to the
underlying OS.

Essentially, what I did was to create a URI for a local user-selected
file by using the File class's toURI() method (for a regular URL, just
use that).

For Windows 2000 and up I used a String array with elements containing
"cmd", "/c", "start", and then the URL or URI, which I then passed to a
Runtime.exec call.  On Windows 98, which my app no longer supports, that
may not work becaus "cmd" command was previously "command.com".

For Mac OS X, String array contains "open" and then the URL or URI.  I
would advise against supporting any Mac running a pre-OS X system in new
apps since Java there is seriously out of date and will not be updated.

The above approach hands off the URL or "file:" URI to the underlying OS
to be handled by whichever application is designated.  It offers the
additional advantage of automatically letting the OS handle prompting if
no app is selected for whatever it's given.

The same approach can work in Linux if you know what desktop environment
is being used and the appropriate command to have that environment's
file management scheme handle the file.  I've found that a URL and a URI
can both be handled in the KDE setting by using "kfmclient" and "exec".  
And it seems true in my testing to date that "nautilus" will work for
Gnome.  I've found that using "nautilus" still works for me in KDE since
it's in my path already.  And taking this approach avoids the hard-wired
path issue that's used in the BrowserLauncher code.

HTH.

= Steve =