Difference between revisions of "Talk:Java"
(→About JRE 1.6.0 Update 18 and Java Update) |
m (→About JRE 1.6.0 Update 18 and Java Update) |
||
Line 53: | Line 53: | ||
: Thank you Motmot for your reply, and pointing to the documentation. You say, when you install JRE 1.6 u18 you don't find any "Java Update\" directory and HKLM "jusched.exe" in the registry run key? | : Thank you Motmot for your reply, and pointing to the documentation. You say, when you install JRE 1.6 u18 you don't find any "Java Update\" directory and HKLM "jusched.exe" in the registry run key? | ||
− | If that is the case then I must be missing something, because that is how the u18 installer behaves for me, forcing me to rip away that directory and registry key. | + | : If that is the case then I must be missing something, because that is how the u18 installer behaves for me, forcing me to rip away that directory and registry key. |
− | That said, if I want to manage the installation/upgrade cycle for JRE 1.6, I really must ask Sun for a working and documented option for the installer, say a "NO-UPDATE-AT-ALL=1" would be fine. | + | : That said, if I want to manage the installation/upgrade cycle for JRE 1.6, I really must ask Sun for a working and documented option for the installer, say a "NO-UPDATE-AT-ALL=1" would be fine. [[User:Ilgino|Ilgino]] 12:39, 25 February 2010 (CET) |
− | [[User:Ilgino|Ilgino]] 12:39, 25 February 2010 (CET) | + |
Revision as of 11:41, 25 February 2010
Is it necessary to keep old versions of the JRE package? If someone has to install an old version, he only has to adjust the version number and remove the uninstall strings for more recent versions (and he can even leave them in the package without problems). You can get the version number from the last digits. So 3248F0A8-6813-11D6-A77B-00B0D0160020 would be the string for JRE (1.)6 Update 2. Maybe we could keep only the last recent version plus a short description how to install older versions. -- Laudrin 12:12, 13 July 2008 (CEST)
- I doubt it is necessary to keep the old versions. As you say, a short description should suffice. Alternatively, we could create another page, called i.e. Java:older_versions.
http://java.sun.com/javase/6/docs/technotes/guides/jweb/otherFeatures/jre_install.html#uninstallExamples has info on future uninstall strings, how to install static JREs, and that by default JREs will be upgraded in place (so no need to uninstall the old versions). TRS-80 07:32, 22 October 2008 (CEST)
There are a number of providers of Java (Sun, Blackdown, IcedTea, though not necessarily for Windows) and there are various incarnations of Java for different people - Java SDK, Java JRE, etcetera. So I propose changing this page's name to 'Sun Java JRE'.
- I think this is a nice idea. Maybe "Java" should be a category as "Adobe software" is, grouping all vendors' specific JREs and JDKs silent installers. A drawback could be the low visibility that categories have in home page.
I use the folowing line to stop the "Java Quick Starter" before updating. net stop returns 2 if the service was not running.
Should add this to the example?
<install cmd='net stop "Java Quick Starter"'><exit code='0' /><exit code='2' /></install>
About JRE 1.6.0 Update 14 and Service Tag
Hello, Sun has released the Update 14 of their JRE 1.6.0 (and JDK 1.6.0). As stated in their Release Note (http://java.sun.com/javase/6/webnotes/6u14.html):
- this release does not contain security fixes, so from a security point of view we are not urged to upgrade from Update 13
- this release extends "Service Tag Support" to Windows systems: has anyone used Sun Service Tags before? Is this useful or can it be disabled/uninstalled altogether?
Thank you for your suggestions,
Ilgino 10:56, 3 June 2009 (CEST)
- This only has an effect if you've separately installed the Sun Service Tag software for Windows. Service tags are just a form of inventory management, like OCS Inventory, Hyperic HQ etc. TRS-80 20:41, 14 June 2009 (CEST)
About JRE 1.6.0 Update 18 and Java Update
Hello, Sun has released the Update 18 of their JRE 1.6.0 (and JDK 1.6.0).
Beware that this version does install jusched.exe, jucheck.exe and some other files in c:\programmi\file comumi\Java Update\ (this is for the italian version, I think for english it should be something like c:\program files\common files\Java Update\).
Even worse, it also adds a registry entry in HKLM\Software\Microsoft\Windows\CurrentVersion\Run\ launching "jusched.exe".
So it seems that the installer command line parameters "JAVAUPDATE=0 JU=0 AUTOUPDATECHECK=0" really do not have effect at all.
Does anyone have an idea on how to ENTIRELY avoid the autoupdate mechanism (besides ripping away the registry key and "Java Update" directory after installation), so that we can update JRE only if-and-when we want to?
Thank you, Ilgino 10:26, 19 January 2010 (CET)
Yeah, looking at the help documentation there's no mention of the JAVAUPDATE, JU, or AUTOUPDATECHECK parameters at all. Having said that, and having used the install package XML on this page for some time, it has never auto-updated.
Incidentally, the help documentation states that the IEXPLORE and MOZILLA parameters are deprecated in Java 1.6.x since it now tries to associate itself with all the browsers it can find. Motmot 21:32, 24 February 2010 (CET)
- Thank you Motmot for your reply, and pointing to the documentation. You say, when you install JRE 1.6 u18 you don't find any "Java Update\" directory and HKLM "jusched.exe" in the registry run key?
- If that is the case then I must be missing something, because that is how the u18 installer behaves for me, forcing me to rip away that directory and registry key.
- That said, if I want to manage the installation/upgrade cycle for JRE 1.6, I really must ask Sun for a working and documented option for the installer, say a "NO-UPDATE-AT-ALL=1" would be fine. Ilgino 12:39, 25 February 2010 (CET)