Using Webstart

[Luc The Perverse]

I know I SHOULD know how to do this.

But I am writing a program which uses a JAR file in it's classpath.

I'd like to bundle this together with my classfiles in a way that is easily
runnable for my wife and brother.

Should I use Webstart or just a JAR file?

Either way I don't know how to make it to include the things in the JAR file
I am currently using. For webstart I don't know how to make this at all.

Can someone point me to a tutorial/example?

 

[Roedy Green]

Should I use Webstart or just a JAR file?

the advantage of webstart is:
1. easier install.
2. automatic update.

On one project the boss stopped using webstart and used a Zero G
installer. His reasons were

1. the install then would seem more familiar and professional to
windows users.

2. you could start with a virgin machine without a working Java. The
installer could install a private JVM.

3. more control over just where the files went so that the user could
get at them himself by a sensible name.

 

[Roedy Green]

Should I use Webstart or just a JAR file?

See my chart comparing the advantages and disadvantages of
Applet/JAWS/Applications at
http://mindprod.com/jgloss/javawebstart.html

 

[Andrew Thompson]

http://mindprod.com/jgloss/javawebstart.html

Nice summary.

A couple of questions/suggestions (tid-bits - compared
to the reams of info. in that document).

<http://mindprod.com/jgloss/javawebstart.html#SANDBOX>
"..Unlike an unsigned Applet, an unsigned JAWS app can read and
write its own files without user permission. "

What do you mean? How? An unsigned JWS app. has access
to the FileSaveService API, but that is a very 'noisy' affair
(significant end user involvement, and lots of messages).

"There is still no way for even a signed JAWS app to
find some persistent disk space in an easy way. It
pretty well has to ask the user for the name of some
directory to use."

Huh!?! AFAIU, a signed JWS app. could do IO on files in
user.home without further user intervention.

<http://mindprod.com/jgloss/javawebstart.html#APPLETSVSJAWS>
"Table: Applets vs JAWS vs Applications

Digitally Signed

Yes, to doing do anything interesting, though simple
Applets can be unsigned."

Last line typo. - that makes little sense - did you mean?

"Yes, to do anything interesting, though.."

 

[Roedy Green]

"There is still no way for even a signed JAWS app to
find some persistent disk space in an easy way. It
pretty well has to ask the user for the name of some
directory to use."

Huh!?! AFAIU, a signed JWS app. could do IO on files in
user.home without further user intervention.

In a normal app, the install assigns a directory in Xrogram files
for use by program and some data. There is no Jaws equivalent unless
you arrange it in your own installer class.

 

[Andrew McDonagh]

In a normal app, the install assigns a directory in Xrogram files
for use by program and some data. There is no Jaws equivalent unless
you arrange it in your own installer class.

A signed webstart - is similar to a normal app. And has access to any
part of the disk.

You can use user.home which translates for example to C:\Documents and
Settings\Andrew

or even create a temp file in the OSs temp directory

// Create temp file.
File temp = File.createTempFile("pattern", ".suffix");

 

[Roedy Green]

A signed webstart - is similar to a normal app. And has access to any
part of the disk.

But it is not assigned a sensibly named corner of the disk for its own
use the way a installer-installed app is.

 

[Andrew McDonagh]

But it is not assigned a sensibly named corner of the disk for its own
use the way a installer-installed app is.

So...

those apps have to be coded to know the location the installer has
provided for them.... Or they just use 'user.home\$AppName$\' which is
platform independent way of getting the same behavior.

all the installers do is create a directory and possibly set a
configuration variable to point there... not that difficult for the app
to do itself.

 

[Thomas Weidenfeller]

In a normal app, the install assigns a directory in Xrogram files
for use by program and some data.

Yep, and the assigning of space for data under "Program Files" is a
typical, bad habit of windows programmers. Particular, when it is
supposed to be for user's data. User's data doesn't belong in a global
"Program files\SomeApp" directory, it belongs in the user's own directory.

It's wrong from a security point of view (needing to grant write
permission for everyone to the program files directories), it is wrong
from a backup point of view (error prone to selectively back up all of a
user's data), and it is wrong form an software update point of view
(danger to remove user data when deinstalling / updating the software).
And yet still after 10, 15 years of Windows in (un)"production" Windows
programmers still ship such applications.

/Thomas

 

[Roedy Green]

those apps have to be coded to know the location the installer has
provided for them.... Or they just use 'user.home\$AppName$\' which is
platform independent way of getting the same behavior.

That is still an ad hoc scheme. There is no provision to avoid
collisions if you do that. There should be a place for user data
files with a name so that

1. there is no possibility of clashes between different vendors

2. the name is human typeable and meaningful.

3. allows different data for different users with shared common files.

 

[Andrew Thompson]

That is still an ad hoc scheme. There is no provision to avoid
collisions if you do that. There should be a place for user data
files with a name ..

<suggestion E.G.>
{'user.home'}/com/mindprod/theapplicationpackage/user.dat
</suggestion E.G.>

...in other words, use the package structure for the class most
associated with the data.

...and see Thomas' reply for all the good reasons *not* to
put data in the "application's own directory".

 

[Andrew McDonagh]

<suggestion E.G.>
{'user.home'}/com/mindprod/theapplicationpackage/user.dat
</suggestion E.G.>

Good call.

...in other words, use the package structure for the class most
associated with the data.

...and see Thomas' reply for all the good reasons *not* to
put data in the "application's own directory".

+1

 

[Roedy Green]

<suggestion E.G.>
{'user.home'}/com/mindprod/theapplicationpackage/user.dat
</suggestion E.G.>

Fine. But that should be a Sun standard, along with a place to put
stuff common to all users. If that is not a suitable place on some
platform, the API should deal with that.

 

[Andrew McDonagh]

Fine. But that should be a Sun standard, along with a place to put
stuff common to all users. If that is not a suitable place on some
platform, the API should deal with that.

user.home is a standard...how your app uses it can't be 'standardized'
as no one size fits all....

 

[Roedy Green]

user.home is a standard...how your app uses it can't be 'standardized'
as no one size fits all...

but your suggested convention could be. Further, user.home is not a
suitable place to put stuff common to all users.