I'd like to embed the directory and subdirectories from a current Java 1.6 update 11 into a software package that I will be installing on several other PCs and will like to know what the cons about doing this are (if any). I want to do that so that my version on Java doesn't override other versions on the PCs.
views:
99answers:
3
+4
A:
On Linux, no issues. On Windows too, should not be any issues if you are using the JDK/JRE by setting the path and JAVA_HOME to the directory. You won't be able to use the applet plugin, however, without messing with the registry.
talonx
2009-03-10 03:15:25
I suppose there could be issues if the two computers use different chip architectures (x86 vs. amd64 for example)...
David Zaslavsky
2009-03-10 03:22:00
+1, but you can also run javacpl.exe after the fact to configure the plugin for your browsers
John Ellinwood
2009-03-10 03:22:57
@David: Good point - I hadn't thought of that.
talonx
2009-03-10 04:33:08
+1
A:
I've seen some software do that (ie: package the JRE with the software), the main disadvantage of this approach is the larger size of your package and it defeats one of the good reasons to use JRE (the fact that it is widley distributed).
Why are you worried to install a newer JRE over pre-existing ones? The JRE should be backwards compatible. If this is your motivation I would consider installing the new JRE instead of packaging in the way you suggested as there shouldn't be any backward compatibility issues.
hhafez
2009-03-10 03:17:44
I disagree. Definitely install your own JRE with your code as is the version you tested on. If you upgrade a common JRE someone else can update it again later and break your code. The JRE "should" be backwards compatible, but it isn't so it's safest to have your own.
Dave Webb
2009-03-10 06:38:24
so if there is a security vunreability in the JRE you distributed the user can't patch it by downloading the latest JRE? Instead the user needs to wait until the developer sends a new version of their package...
hhafez
2009-03-10 22:35:32
A:
Thanks for your replies; the reason I want to use this approach is because one of my applications don't work with a version of Java higher than 1.6u11; if a user has auto updates set to on for Java or if he/she decides to upgrade to a higher version, that will break my other application that only works with Java 1.6u11. By embedding the jre files/folder structure with the installation of my application and pointing the ini files to execute the application using that version of Java I'll make sure that version is the one used by the application and not the one defined in JAVA_HOME, whichever that is (higher or lower than 1.6u11).
Any comments are more than welcome.
Makes sense - I have used this approach successfully in one of my apps - for both Linux and Windows - for precisely the same reason.
talonx
2009-03-10 16:47:17