Home > Archive > Java Help > March 2004 > java webstart
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| patrick 2004-03-27, 12:30 am |
| For installing java applications is java Webstart a substitute for making an
installer using, for example, InstallAnywhere ?
patrick
| |
| Yoyoma_2 2004-03-27, 12:30 am |
| patrick wrote:
> For installing java applications is java Webstart a substitute for making an
> installer using, for example, InstallAnywhere ?
>
>
> patrick
>
>
Yes it is, and it guarantees that the latest version will alwaise be on
the machine. IE its like InstallAnywhere and Live Update all in one.
Problem is that it doesn't let you control the classpath and there are
some issues with resources and stuff...
At work when we came to the conclusion that it wasen't good enough for
our large enterprise application, we built an installer to set up the
config files etc.
Hope it helps.
| |
| Richard Chrenko 2004-03-27, 12:30 am |
| On Thu, 25 Mar 2004 15:26:25 GMT, Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com>
wrote:
> patrick wrote:
>
> Yes it is, and it guarantees that the latest version will alwaise be on
> the machine. IE its like InstallAnywhere and Live Update all in one.
> Problem is that it doesn't let you control the classpath and there are
> some issues with resources and stuff...
>
> At work when we came to the conclusion that it wasen't good enough for
> our large enterprise application, we built an installer to set up the
> config files etc.
>
> Hope it helps.
>
>
I can second that opinion. Java Web Start seemed like a great opportunity
for our scientific simulation program until we discovered a few irritating
limitations which removed it from consideration:
1. Internet updates can not be disabled. For a simulation program, getting
different results after an automatic (invisible) update will give our
customers fits. Although there appears to be some JSP-based server-side
versioning capability, this was more effort than we wanted to spend.
2. Downloads are limited to JAR files. For database updates, we would have
to pack our SQL scripts and data into a JAR file and unpack and manually
update table data on the client.
3. Predefined application home. You cannot prompt the user to install the
application where they please. It is instead automatically saved to a
uniquely named directory somewhere beneath the Web Start home directory.
So after much initial enthusiasm, we will end up using an installer to
deploy our Java application.
Rich
| |
| patrick 2004-03-27, 12:30 am |
| Thanks for those responses.
some other questions:
1. Is it easy for web surfers to install the application from a website if
they dont already have JWS installed on their pc? Does the initial install
of JWS need a messy restart of their PC?
2. Can a desktop shortcut be automatically installed?
Is there menuitem for the java app put in start/programs menu for a JWS
installed application.?
tia
patrick
"Richard Chrenko" <richard.chrenko@solarenergy.ch> wrote in message
news:opr5fhc5m1caoj5g@news.hsr.ch...
> On Thu, 25 Mar 2004 15:26:25 GMT, Yoyoma_2 <Yoyoma_2@[at-]Hotmail.com>
> wrote:
>
>
> I can second that opinion. Java Web Start seemed like a great opportunity
> for our scientific simulation program until we discovered a few irritating
> limitations which removed it from consideration:
>
> 1. Internet updates can not be disabled. For a simulation program, getting
> different results after an automatic (invisible) update will give our
> customers fits. Although there appears to be some JSP-based server-side
> versioning capability, this was more effort than we wanted to spend.
>
> 2. Downloads are limited to JAR files. For database updates, we would have
> to pack our SQL scripts and data into a JAR file and unpack and manually
> update table data on the client.
>
> 3. Predefined application home. You cannot prompt the user to install the
> application where they please. It is instead automatically saved to a
> uniquely named directory somewhere beneath the Web Start home directory.
>
> So after much initial enthusiasm, we will end up using an installer to
> deploy our Java application.
>
> Rich
| |
| Yoyoma_2 2004-03-27, 12:30 am |
| patrick wrote:
> Thanks for those responses.
> some other questions:
> 1. Is it easy for web surfers to install the application from a website if
> they dont already have JWS installed on their pc? Does the initial install
> of JWS need a messy restart of their PC?
Java Web Start is installed with the standard sun J2SE JVM. Also the JDK.
But if your web site sends the no-cache directive, clicking on the java
web start directive not work directly.
If you want to try it, i have a nice little application I made for a
school project. http://andre.bonin.ca/webstart
the BoninsoftATC project (a little Air Traffic Control simulation I
programmed) loads off java web start. Well at least, attempts to load :)
Note: the writer is not liable for any use of this program to the
maximum extent of the law. The maps should not be used or the program
should not be used as actual air traffic simulation or otherwise.
> 2. Can a desktop shortcut be automatically installed?
> Is there menuitem for the java app put in start/programs menu for a JWS
> installed application.?
Yes, web start asks you if you want a shortcut installed on your desktop
and start menu.
>
> tia
> patrick
>
> "Richard Chrenko" <richard.chrenko@solarenergy.ch> wrote in message
> news:opr5fhc5m1caoj5g@news.hsr.ch...
>
>
>
>
| |
|
|
| Roedy Green 2004-03-27, 12:30 am |
| On Thu, 25 Mar 2004 19:08:27 -0000, "patrick" <networkone@eircom.net>
wrote or quoted :
>1. Is it easy for web surfers to install the application from a website if
>they dont already have JWS installed on their pc? Does the initial install
>of JWS need a messy restart of their PC?
If you have a recent java, you automatically have JWS.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Roedy Green 2004-03-27, 12:30 am |
| On Thu, 25 Mar 2004 19:08:27 -0000, "patrick" <networkone@eircom.net>
wrote or quoted :
>2. Can a desktop shortcut be automatically installed?
It prompts the user whether he wants a desktop shortcut made.
--
Canadian Mind Products, Roedy Green.
Coaching, problem solving, economical contract programming.
See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
| |
| Bent C Dalager 2004-03-27, 12:30 am |
| In article <opr5fhc5m1caoj5g@news.hsr.ch>,
Richard Chrenko <richard.chrenko@solarenergy.ch> wrote:
>
>1. Internet updates can not be disabled. For a simulation program, getting
>different results after an automatic (invisible) update will give our
>customers fits. Although there appears to be some JSP-based server-side
>versioning capability, this was more effort than we wanted to spend.
I believe the user can disable it on a JWS-wide scale by clicking an
"off-line" checkbox in the JWS config utility.
>2. Downloads are limited to JAR files. For database updates, we would have
>to pack our SQL scripts and data into a JAR file and unpack and manually
>update table data on the client.
Why couldn't you just do online table-lookups directly from the client
utility when necessary?
>3. Predefined application home. You cannot prompt the user to install the
>application where they please. It is instead automatically saved to a
>uniquely named directory somewhere beneath the Web Start home directory.
Why is it necessary for your users to have this sort of micro-control?
Cheers
Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs
| |
| Richard Chrenko 2004-03-27, 12:30 am |
| On Fri, 26 Mar 2004 11:56:45 +0000 (UTC), Bent C Dalager <bcd@pvv.ntnu.no>
wrote:
> In article <opr5fhc5m1caoj5g@news.hsr.ch>,
> Richard Chrenko <richard.chrenko@solarenergy.ch> wrote:
>
> I believe the user can disable it on a JWS-wide scale by clicking an
> "off-line" checkbox in the JWS config utility.
Thanks for the tip! I just tried this and it appears that the setting is in
fact on a per-application basis. However, there is a 20-30 second delay
before the application starts locally which I presume to be a network
timeout (hopefully editable!).
>
>
> Why couldn't you just do online table-lookups directly from the client
> utility when necessary?
Our application uses a client-side embedded database. The first problem in
that the initial installation of the database requires not only copying the
relevant DB engine JAR files but also extracting the data files from the
JAR and setting the connection path. This is easier using an installer.
We will provide product information updates (a few MB) on a regular basis.
These updates could theoretically be done by the application over the
network, but this appears much more complex and error-prone than
downloading files and having the client do the update locally.
>
>
> Why is it necessary for your users to have this sort of micro-control?
It's not really necessary from the developer perspective, but for customer
support purposes it's easier to tell the user to search for the application
directory which he himself chose. Also, it's not clear to me how Web Start
manages program versions or what happens when the customer upgrades to a
new version of Web Start. With an installer the customer is always in
control of his installation path.
>
> Cheers
> Bent D
| |
| Bent C Dalager 2004-03-27, 12:30 am |
| In article <opr5g90ky2caoj5g@news.hsr.ch>,
Richard Chrenko <richard.chrenko@solarenergy.ch> wrote:
>
>It's not really necessary from the developer perspective, but for customer
>support purposes it's easier to tell the user to search for the application
>directory which he himself chose. Also, it's not clear to me how Web Start
>manages program versions or what happens when the customer upgrades to a
>new version of Web Start. With an installer the customer is always in
>control of his installation path.
It seems to me that this could easily strike both ways, depending
somewhat on how much of a clue your users have. If they don't then
they are likely to not care or having forgotten where they installed
it, prompting your support staff to lead a phone hunt for it, whileas
you will presumably always be able to know where it is if it's in the
"standard" JWS directory.
Of course, with JWS, it may vary quite a bit between different JWS
implementations so your support staff may well be in for a couple of
surprises anyway :-)
I am still undecided as to whether or not it is a good thing to hide
installation directory details from the user. I am leaning towards
thinking it's a good thing, but I am eager to find more reasons for
and against.
Cheers
Bent D
--
Bent Dalager - bcd@pvv.org - http://www.pvv.org/~bcd
powered by emacs
|
|
|
|
|