Java Forum / General / December 2005
Runtime.exec for launching browser windows: location-independent?
Mickey Segal - 08 Dec 2005 16:16 GMT As the "pure Java" way of launching new browser windows, the showDocument method, is rendered nonfunctional in more and more environments by popup blockers, developers whose Java applets are digitally-signed have been able to get the same functionality by using Runtime.exec calls.
On the Macintosh one can open a new Firefox window regardless of the location of Firefox as follows:
Runtime.getRuntime().exec(new String[] {"open", "-a", "Firefox.app", url.toString()});
On Windows it is possible to launch Internet Explorer or Firefox by assuming a particular location as follows:
Runtime.getRuntime().exec("\"C:\\Program Files\\Internet Explorer\\IEXPLORE.EXE\" " + url); Runtime.getRuntime().exec("\"C:\\Program Files\\Mozilla Firefox\\firefox.exe\" \"" + url + "\"");
The problem is that these forms depend on the browser files being in their usual locations. Is there a way of launching the browsers in a location-independent way using Java code on Windows, by analogy to what works on the Macintosh even if Firefox is not in its usual location in the /Applications folder?
NOTE: We use new browser windows to display further information on outside Web sites such as articles about a diagnosis being considered by the user. Using a new browser window allows us to do so without destroying our applet or trying to shoehorn someone else's Web page into a frame on the same page as our applet.
Thomas Fritsch - 08 Dec 2005 17:44 GMT > As the "pure Java" way of launching new browser windows, the showDocument > method, is rendered nonfunctional in more and more environments by popup > blockers, developers whose Java applets are digitally-signed have been able > to get the same functionality by using Runtime.exec calls. I assume you are talking about showDocument(URL) of class Applet here.
[...]
> NOTE: We use new browser windows to display further information on outside > Web sites such as articles about a diagnosis being considered by the user. > Using a new browser window allows us to do so without destroying our applet > or trying to shoehorn someone else's Web page into a frame on the same page > as our applet. showDocument(URL) of JavaWebStart should be more powerful/flexible than its Applet counterpart. Other posters probably have more experience about it than me. See also <http://java.sun.com/products/javawebstart/1.0.1/javadoc/javax/jnlp/BasicService. html#showDocument(java.net.URL)>
In a WebStart application it is used like this: import javax.jnlp.*;
BasicService basicService = (BasicService) ServiceManager.lookup("javax.jnlp.BasicService"); basicService.showDocument(url);
Of course, this approach would require you to move your design from browser-ebedded applet to free-standing WebStart-application.
 Signature "Thomas:Fritsch$ops:de".replace(':','.').replace('$','@')
Mickey Segal - 08 Dec 2005 18:28 GMT > Of course, this approach would require you to move your design from > browser-ebedded applet to free-standing WebStart-application. That may be a good long-term solution but it will not work with the environment constraints on many of our users.
One person suggested that the Windows "start" command is pretty much equivalent to the Macintosh "open" command. Does anyone know the syntax?
I've also tried: Runtime.getRuntime().exec("rundll32 url.dll,FileProtocolHandler " + url); This opens the default browser, but unfortunately when it is run from the Web in Internet Explorer as the default browser it opens the applet in the same window, destroying the applet.
Steve W. Jackson - 08 Dec 2005 19:47 GMT > > Of course, this approach would require you to move your design from > > browser-ebedded applet to free-standing WebStart-application. [quoted text clipped - 10 lines] > Web in Internet Explorer as the default browser it opens the applet in the > same window, destroying the applet. What I used for Windows and the "start" command was simply a URL. If it's a file, I made it a file URL. So whatever type of URL I used, I ended up with "cmd start URL" being passed to exec().
I temporarily switched my XP system to IE as default and tested it. The behavior you describe where it replaces the current page is but one of many reasons I thoroughly despise IE. If not for the fact that my company (like so many others) insists on forcing me to use resources that ONLY work with IE on Windows, I'd never touch it.
= Steve =
 Signature Steve W. Jackson Montgomery, Alabama
Roedy Green - 08 Dec 2005 23:59 GMT On Thu, 8 Dec 2005 13:28:43 -0500, "Mickey Segal" <not_monitored@example.com> wrote, quoted or indirectly quoted someone who said :
>One person suggested that the Windows "start" command is pretty much >equivalent to the Macintosh "open" command. Does anyone know the syntax? you exec cmd.exe and pass it the same command line you would from the DOS prompt.
See http://mindprod.com/jgloss/exec.html
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Roedy Green - 08 Dec 2005 23:58 GMT On Thu, 08 Dec 2005 17:44:21 GMT, Thomas Fritsch <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted someone who said :
>showDocument(URL) of JavaWebStart should be more powerful/flexible than >its Applet counterpart. I gather it would use HotJava for rendering?
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Andrew Thompson - 09 Dec 2005 09:49 GMT > On Thu, 08 Dec 2005 17:44:21 GMT, Thomas Fritsch > <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted [quoted text clipped - 4 lines] > > I gather it would use HotJava for rendering? Why? *
a) HotJava is virtually useless for real world (wide web) HTML. b) The method mentions "This will typically replace the page currently being viewed in a browser..". I imagine they could be more definitive if the browser component was HotJava.
And as a follow-up to both this and my own question (next thread up 'BrowserLauncher - JWS example') of.. 'Has anybody used this successfully?'
Tests here running with the 1.5.0-beta JRE keep throwing .. javax.jnlp.UnavailableServiceException: uninitialized
I'll keep working on it, but if anyone here can tell me how to initialise that dang service, or cause it to be initialised, please speak up.
* If it did, I would consider the method to be essentially useless.
 Signature Andrew Thompson physci, javasaver, 1point1c, lensescapes - athompson.info/andrew
Andrew Thompson - 09 Dec 2005 12:15 GMT >> On Thu, 08 Dec 2005 17:44:21 GMT, Thomas Fritsch >> <i.dont.like.spam@invalid.com> wrote, quoted or indirectly quoted >> someone who said : >> >>> showDocument(URL) of JavaWebStart should be more powerful/flexible >>> than its Applet counterpart. Yes, in that it seems to work[1]. No, in that the programmer cannot specify a frame or window name (..and that is probably A Good Thing).
>> I gather it would use HotJava for rendering? No[1]. On my system (running 1.5.0-beta, on Win XP Pro), it opens Mozilla 1.7.2 - my default browser (currently).
[1] Here are the examples I am using .. <http://www.physci.org/browserlauncher/jnlp/> there is both an application and applet.
How well does this work for other people? Does it - steal an existing window? - open a new browser, or browser-tab? - do nothing at all? ( What browser/Java/OS as well, please )
Mickey, it occured to me that if you use WebStart to launch your applets, they can not only have access to a more reliable 'show a page' functionality, but also have the advantage that the applet becomes independent of the original HTML page (the user can navigate from it, but the applet stays on-screen).
Of course, once you go WebStart, the temptation is to break out of applets entirely and create an application, but applets are supported (to some extent*) within JWS.
* No JS interaction, but it seems that most of your JS is simply to work around the unpredictable effects of browsers in any case, so it should become unnecessary in the JWS version..
Follow-up note.
My earlier attempts to use JWS services were failing because I was attempting it from a non-JWS application, and the ServiceManagerStub had not been created or set.
I am not sure if there is a way to do that yourself, but have not investigated it much yet. Experiences at creating an Applet stub suggest to me it is not trivial.
 Signature Andrew Thompson physci, javasaver, 1point1c, lensescapes - athompson.info/andrew
Mickey Segal - 09 Dec 2005 13:40 GMT > Mickey, it occured to me that if you use WebStart to launch your > applets, they can not only have access to a more reliable 'show > a page' functionality, but also have the advantage that the applet > becomes independent of the original HTML page (the user can navigate > from it, but the applet stays on-screen). Our typical user is loading our software from the hospital network computer that happens to be nearest to them at the moment. They are reluctant to (and discouraged from) doing anything that seems like a software installation. The launching code I posted in response to one of Steve Jackson's messages in this thread seems to be doing what we want so I am inclined to keep with this approach as long as it works.
BTW Andrew, why are you using 1.5.0-beta instead of 1.5.0_06 or 1.6.0-rc? We have converted to 1.6.0-rc because of its fix to the HotSpot crash problem (www.segal.org/java/sun_jit/).
Andrew Thompson - 09 Dec 2005 15:16 GMT (snip - makes sense) ..
> BTW Andrew, why are you using 1.5.0-beta instead of 1.5.0_06 or 1.6.0-rc? Because I'm evil? No ..wait, because I'm lax and more than a little stupid? Yep - that sounds more like it.
Must update - Real Soon Now.
In fact, I'm sure I have at least _04 about here somewhere.. why the heck is the browser using -beta? (wanders off, ..muttering)
 Signature Andrew Thompson physci, javasaver, 1point1c, lensescapes - athompson.info/andrew
Roedy Green - 09 Dec 2005 17:13 GMT On Fri, 09 Dec 2005 09:49:02 GMT, Andrew Thompson <seemysites@www.invalid> wrote, quoted or indirectly quoted someone who said :
>> I gather it would use HotJava for rendering? > >Why? * When you run an Applet with JAWS, what is it running in? Does that think support showDocument? If yes, what else does Sun have that can run an Applet and make a feeble attempt at rendering HTML.
 Signature Canadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching.
Andrew Thompson - 09 Dec 2005 22:18 GMT > On Fri, 09 Dec 2005 09:49:02 GMT, Andrew Thompson > <seemysites@www.invalid> wrote, quoted or indirectly quoted someone [quoted text clipped - 5 lines] > > When you run an Applet with JAWS, what is it running in? AppletViewer. At least, it looks like AppletViewer to me. <http://www.physci.org/pc/jtest-applet.jnlp>
>...Does that > think support showDocument? No.
>..If yes, what else does Sun have that can > run an Applet and make a feeble attempt at rendering HTML. AppletViewer makes no attempt to render any HTML.
The 'document base' required by the JNLP applet-desc element is simply to provide a documentBase() if it is requested by the applet.
 Signature Andrew Thompson physci, javasaver, 1point1c, lensescapes - athompson.info/andrew
Steve W. Jackson - 08 Dec 2005 18:56 GMT > As the "pure Java" way of launching new browser windows, the showDocument > method, is rendered nonfunctional in more and more environments by popup [quoted text clipped - 26 lines] > or trying to shoehorn someone else's Web page into a frame on the same page > as our applet. On a Mac, you can omit the "-a" switch to the "open" command and allow the system to use the preferred browser. By default, that's Safari on all recent systems, but it can of course be changed. I have mine set for Firefox, and it's in a non-standard location, but that approach works perfectly in my testing. It also works for files, provided the system has a setting for the application to handle the file.
On Windows systems beyond 98 (we dropped support in our app for 98 and earlier, including NT), you can use "cmd start url" to hand off the URL to the designated default browser. The same approach seems to work for files if there's an association for them. I believe I recall that it resulted in prompting when no associated application was found (and perhaps for Mac OS X as well). I haven't tried in Windows 98, but the "cmd.exe" used to be "command.com" and may well work there too. Aside from renaming the command interpreter, I don't know how much else has changed down deep.
Even on Linux, I found that an approach could be used that depends on information about the desktop environment being used. That's more tricky to do, but it's clearly possible since any given environment (like KDE, Gnome, etc.) has some kind of file manager program that can show files and allow one to be opened with a designated application.
= Steve =
 Signature Steve W. Jackson Montgomery, Alabama
Mickey Segal - 08 Dec 2005 19:50 GMT > On Windows systems beyond 98 (we dropped support in our app for 98 and > earlier, including NT), you can use "cmd start url" to hand off the URL [quoted text clipped - 5 lines] > from renaming the command interpreter, I don't know how much else has > changed down deep. The following seem to work both locally and from the Web using Windows XP:
From Internet Explorer: Runtime.getRuntime().exec("iexplore.exe " + url);
From Firefox 1.5: Runtime.getRuntime().exec("firefox.exe \"" + url + "\""); (note the quotes around the URL)
This seems like a clean approach. Does it fail somewhere I haven't noticed (I haven't tried Windows 98 yet)?
Steve W. Jackson - 08 Dec 2005 20:05 GMT > > On Windows systems beyond 98 (we dropped support in our app for 98 and > > earlier, including NT), you can use "cmd start url" to hand off the URL [quoted text clipped - 17 lines] > This seems like a clean approach. Does it fail somewhere I haven't noticed > (I haven't tried Windows 98 yet)? I'm assuming it relies on some mechanism I can't see to locate the exe file. It doesn't work in a command prompt window on my XP system. But if it appears to work from Java code, I guess that's not so relevant. Of course, there's the fact that only Firefox and IE are covered, whereas those who use Netscape, Mozilla or other browsers aren't.
= Steve =
 Signature Steve W. Jackson Montgomery, Alabama
Mickey Segal - 08 Dec 2005 20:27 GMT > I'm assuming it relies on some mechanism I can't see to locate the exe > file. It doesn't work in a command prompt window on my XP system. But > if it appears to work from Java code, I guess that's not so relevant. > Of course, there's the fact that only Firefox and IE are covered, > whereas those who use Netscape, Mozilla or other browsers aren't. It seems to work on Windows 98 too.
Presumably the approach could be extended to other browsers as well. What we currently do is check for the following browsers: 1. Windows Firefox 2. Windows Internet Explorer 3. Macintosh Firefox
and use the appropriate Runtime.exec call. For all others we use showDocument. In the case of Macintosh Safari showDocument still works. I haven't tested Netscape or Mozilla recently.
Oliver Wong - 08 Dec 2005 20:53 GMT >> The following seem to work both locally and from the Web using Windows >> XP: [quoted text clipped - 15 lines] > Of course, there's the fact that only Firefox and IE are covered, > whereas those who use Netscape, Mozilla or other browsers aren't. I'd assume it depends on those executables appearing on the System PATH.
- Oliver
Steve W. Jackson - 08 Dec 2005 21:46 GMT > >> The following seem to work both locally and from the Web using Windows > >> XP: [quoted text clipped - 19 lines] > > - Oliver That's why I tested it in a Command Prompt under XP. But it failed precisely because neither of the two browsers he named are in my PATH. So I figured there must be something else at work from within Java.
= Steve =
 Signature Steve W. Jackson Montgomery, Alabama
Mickey Segal - 08 Dec 2005 22:10 GMT To sum up, here is a working version of the code for applications and signed applets (microsoftBrowser, firefoxBrowser, windowsOS and macOS are booleans set elsewhere in the code based on information derived from the browser or Java properties):
final static void showInBrowser(URL url) { try { if (microsoftBrowser && windowsOS) Runtime.getRuntime().exec("iexplore.exe " + url); else if (firefoxBrowser && windowsOS) Runtime.getRuntime().exec("firefox.exe \"" + url + "\""); else if (firefoxBrowser && macOS) Runtime.getRuntime().exec(new String[] {"open", "-a", "Firefox.app", url.toString()}); else appletContext.showDocument(url, "_blank"); } catch (Exception e) { System.out.println("Couldn't show in browser: " + e); } }
It doesn't cover certain browser/OS versions, but they get showDocument until special code for them is added.
If there are problems with this approach other than the impurity of treating browsers differently or the audacity to want showDocument functionality in a signed applet I'd be interested in hearing about the problems.
If there are improvements or additions for other browser/OS combinations it would be good to hear about them. (No special code seems necessary for Safari on the Macintosh since it allows showDocument.)
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|