hello,
i’ve run into a problem: how to distribute nicely what is done?!
The application is using java3D and needs access to the network. It’s intended to be several games using a common base.
There are 4 distribution possibilities:
-
as jar files
-
as applet
-
with webstart
-
an install file
-
Jar files.
The problem here is that people must first maybe install JRE, then install java3D, then download the files and lastly run them. Surely a bit too unconvinient for an “average user”. This will surely make “common people” to even not try to make this procedure.
- As applet.
It’s maybe not the nicest solution for some bigger game, but why not, at least it starts immediately.
The java version is detected and a newer version of java is installed if needed, a java3D plugin is installed as well, all this automatically. The problems are coming now: the program is more than one jar, but how to handle multiple jars in an applet?! (i wouldn’t like it at all to make one huge jar). The other possibility would be to leave the classes just like they are, but then, is it possible to sign classes only? Because i need to sign them in order to have access to network!
- With webstart
first problem: no auto-install for java3D, must sign jars, make things… and each program will have their own copy of java3D! (well, i think, because they aren’t installed as extensions but as native libs)
second problem: everything must be signed, again!
third problem: plugin architecture impossible! (Or not?!)
- All in an install file
Have you seen the size of the latest JRE?! 14+MB! Java3D isn’t that small either (4+ MB), and all combined together makes a pretty big install file for a tiny jar. And this for every one of the small games!
Another problem is the nasty event that JRE & Java3D setup are launching “inside” the main setup, it’s not only ugly but also annoying to install 3 things instead of one.
Damn, there are so many possibilities and none seem to be fitting! Isn’t there some nice solution?
I’m seeking your advices…
BTW, InstallAnywhere isn’t able to launch setups or any file inside a setup, but that’s not a problem, other ones can.
) and it’s a great idea. So just bite the bullet and sign your code - even if it’s not with a trusted cert. The more users get used to seeing code signing the more they’ll come to expect it and the more they’ll worry about installing .exes. In these troubled times of viruses and worms on the net the comfort of trusting the safety of a downloaded application is going to be more and more appealing.