Automatic Java VM installation
Brought to you by:
grzegok
Menu
▾
▴
#9 Automatic Java VM installation
Great tools, best free Java launcher I've seen. It
would be even better if it's possible to include &
launch a exe file when Java is not found or version
mismatch. Then for example if we include the offline
Java installer from Sun, users can enjoy a smooth
install experience.
Logged In: YES
user_id=115043
Note there is a way to "silently" install the JRE:
http://java.sun.com/j2se/1.5.0/docs/guide/deployment/deployment-guide/silent.html
Ideally, you could just include the JRE installer in the
generated .exe, and supply the arguments to do a silent
install. I'm trying to integrate this with izpack to make an
installer that's a .exe and includes a JRE install.
Logged In: YES
user_id=115043
As a workaround, you can use launch4j with the Orangevolt
ANT task sfx to enclose the launch4j executable with a jre,
and execute both. Here's a page I created on the IzPack wiki
with some instructions:
http://openfacts.berlios.de/index-en.phtml?title=IzPack/JRE-Install
It would still be nice if this were integrated into
launch4j, though. In that case it would execute the JRE
installer only when a suitable JRE was not already
installed. With this workaround, the JRE install is
attempted no matter what.
Scott
(see: http://ovanttasks.sourceforge.net/rat/index.html )
Logged In: YES
user_id=1275982
Originator: NO
I can add this feature; it's certainly easy enough to do. But wouldn't this normally be a function of the installer, and not the executable?
I like InstallJammer, for example (www.installjammer.com), and it can be easily modifeied to do a silent install if it doesn't find a JRE. I imagine other installers like izPack and NSIS can be customized to do it too...
Logged In: YES
user_id=115043
Originator: NO
NSIS may be able to do it, but izPack generates a Java installer, so in order to run the installer we need a JVM. In this case, we're using launch4j to execute the installer in the first place.
Logged In: YES
user_id=1275982
Originator: NO
splante,
I say, let's go ahead and do this. Here are some options:
** Can't find a JVM, launch java.net website in a browser, let the user click the download link. Requires user to have a browser installed.
** Can't find a JVM, launch a web page that uses Javascript to determine whether Java is installed using methods at http://java.sun.com/developer/technicalArticles/JavaLP/javawebstart/AutoInstall.html . Requires a browser; also requires Javascript to be enabled.
** Can't find a JVM, do a silent install of a bundled JVM. Doesn't require a browser. May have legal implications (licensing issues).
Which way do you think we should go?
Logged In: YES
user_id=115043
Originator: NO
Hi Steve,
Those are all good alternatives. In our case, we offer two versions of our software for download: With and without the JVM. The with-jvm option currently automatically initiates the jvm install no matter what. We do that using the method described here:
http://izpack.org/wiki/native_launcher_and_alternatives#creating_a_native_launcher_that_installs_a_jre
Basically, it creates an executable zip file that runs a two line batch file; the first line runs the JRE installer, and the second executes our IzPack installer. If you enhanced Launch4j to detect no (or wrong) JVM and execute the included JRE installer, it would be better than our current method because we currently initiate that install even if the correct JRE is already there. This can lead to some confusion and support calls. BTW, we don't use the silent install because it's also silent about any errors (Plus you're right about the license agreement issue, though there might be some ways to get around that).
Then, we also offer a version for download that does not include the JVM for folks that know they have Java already installed and don't want to have such a large download. Sometimes, though, people download the wrong version and get the no-JV version when they don't actually have Java installed. For these people, your second alternative (Webstart method) would be great. We already assume they have a browser, as ours is a browser based application. The no-Javascript could be a problem, though I'm guessing there's some way of detecting that and just reverting to java.com for download.
Thanks,
Scott
Logged In: YES
user_id=1275982
Originator: NO
Scott,
Well, I have to backtrack a bit - Option #1 is already available in 3.0.0-pre2 (my fault for not confirming that first... I'm rather new to Launch4j, please forgive me).
#2 is iffy (browser compatibility issues), although it still shouldn't be difficult to implement correctly.
I'm going to implement #3. Not sure what the timeframe will be, as I am doing L4j development work in my spare time, but I'm going to do it.
And by the way, if you want to get really fancy, create an SFX that extracts your izPack installer and the JVM and automatically runs the installer's EXE. You can do that with 7-Zip, which is LGPL'd. Download, double-click, install, done! :)
Logged In: YES
user_id=115043
Originator: NO
You wrote:
> And by the way, if you want to get really fancy, create an SFX that
> extracts your izPack installer and the JVM and automatically runs the
> installer's EXE. You can do that with 7-Zip, which is LGPL'd. Download,
> double-click, install, done! :)
Yes, that's what I was describing with the second paragraph. I said executable zip, but technically it is actually the SFX (7-zip) method. That's working out ok for us, though as I mentioned, the only problem is that it *always* runs the JRE installer, even if they have an appropriate one already installed.
So thanks for offering to implement #3. It will be an improvement over our current sfx method. I imagine you'll allow us to configure the command line to execute the installer. I don't think we'll want to use the silent installer option unless they've created a better way to deal with errors. Hey, actually I just had an idea. Perhaps you could write it so it could try the silent JRE install first, then if that fails, try the regular JRE install. That's probably more than you signed up for, but give it a think.
Scott
Logged In: YES
user_id=1275982
Originator: NO
Hey Scott,
Haven't forgotten about you. :)
"Perhaps you could write it so it could try the silent JRE install first, then if that fails, try the regular JRE install. That's probably more than you signed up for, but give it a think."
That sounds fine to me. I think, however, that we might want to wait for a few months. Java 1.6 is a huge download. The 1.6.0 JRE is 70MB uncompressed. I checked, and Sun's license explicitly ALLOWS redistribution and they package the JRE with a list of files you can get rid of to save space, but you must include rt.jar, which is 40MB all by itself.
This will be addressed by a Sun initiative documented here:
http://java.sun.com/developer/technicalArticles/javase/consumerjre/
Two of the things that the Consumer JRE will address are download size (the plan is to break up rt.jar into several smaller files so you only have to bundle what you need), and easier JVM detection. I'm very interested in seeing Sun's developments in this area and I think we should support them.
Thoughts?
Logged In: YES
user_id=115043
Originator: NO
Hi Steve,
I agree that the 1.6 JRE is pretty large--actually that's why we've been behind on the Java versions for a long time. We were shipping 1.3 until maybe a year, year-and-a-half ago. We're still shipping 1.5, though it's only been in the last few months that java.com defaulted to 1.6 and we'll probably switch to that soon.
I just downloaded the 1.6 update 3 offline JRE installer and while it's a whopping 14MB, that's still reasonable compared to the 70MB uncompressed size you were talking about. It's the 14MB you'd be downloading after all. If you think of it in terms of disk space used, with drives costing under a dollar a GB, 70MB is practically nothing. :-)
Anyway, I think the Consumer JRE is a great idea. We're still shipping the regular JRE right now and I think there'll still a need for that even once the Consumer JRE option is released. We offer downloads but we also ship CDs. We'll probably always include the full JRE on the CDs if for no other reason than some of our customers install our software in secure environments that won't allow the Consumer JRE to download any additional bits it may need in the future. I encourage you to move forward with the current JRE installer, and then look at supporting the Consumer JRE whenever it becomes available.
Thanks for your interest in and work on this enhancement.
Scott
Java6u10 is officially released.
Is there any progress on this one?
the issue was copied to http://code.google.com/p/jliftoff/issues/list