Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2005

Tip: Looking for answers? Try searching our database.

Runtime.exec for launching browser windows: location-independent?

Thread view: 
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 Magazines

Get 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 ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.