Talk:Java

I've edited the instructions and code extensively for update 7. Apart from minor things (like spelling changes), I've:

1. added commands to remove the auto update and quick starter features to both .exe and .msi sections
2. removed the extra checks from the .msi section so that it only checks Add/Remove Programs names and not registry keys and binaries too. Was there a particular reason why these names were unreliable?
3. moved instructions relating to version 6 to the older versions section, placing the WPKG package code much closer to the top of the page!
4. amended the download links so they relate to 7
5. the new .exe installer seems to cope with JQS running, so I amended the guidance
6. added install/upgrade conditions to reflect that this is update 00 and the installation appears as "Java (TM) Version 7" rather than "Java (TM) Version 7 Update 00" in Add/Remove Programs

Motmot 13:11, 17 August 2011 (CEST)

Ad 2.: It can happen, that the folder gets removed, but the uninstall key is still there, so checking only the uninstall key is not reliable.

Is there any particular reason you include exitcode=0, since this is success by default?

You may take advantage of the new host attribute matching introduce in WPKG v1.2, which would shorten your package or correct it for 64-bit installations ;-)

StefanP 13:58, 17 August 2011 (CEST)

You seem to have removed the packing for JRE 6. Many people will remain on JRE 6 for some time to come. Can you please leave the JRE 6 packagind and add JRE 7 as an additional version. There's no need to remove valuable information. Pete Boyd 21:13, 21 August 2011 (CEST)

Written as of JRE 6 Update 25, the problem exists since Update 18. We should be aware of Sun's BUG#6947907 ([1]). In short: "performing a repair or reinstallation from the .msi source installation database causes the majority of the files in the JRE's program directory (%ProgramFiles%\Java, by default) to be deleted, leaving Java unusable on the workstation" This can happen to anybody of us when a WPKG fires its update (e.g. after the revision has been incremented) using MSI and the very same JRE is already installed on the target machine. Note that this seems to be the case only when using MSI. The named bug page states that the problem does not exist for the exe installer. -- todeti 2011-04-12

I'm seeing precisely this behaviour with the .exe for 6.0u26. I know Oracle say it only happens with the MSI. I'm fixing it by putting an uninstall line in for 'upgrade' that comes before the install line, that does 'msiexec /qn /uninstall {26A24AE4-039D-4CA4-87B4-2F83216026FF}' Pete Boyd 17:12, 11 August 2011 (CEST)

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>

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)

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)

Ilgino, you won't get anywhere asking that of Sun, they really want the JRE to be updated, not disabled. Pete Boyd 09:41, 8 March 2010 (CET)

OK, thanks to this contribution (http://wpkg.org/index.php?title=Java&diff=7856&oldid=7842) I found out what I was looking for.

That is, using the .MSI for installation DOES RESPECT the JAVAUPDATE=0, JU=0, and AUTOUPDATECHECK=0 property modifications.

Infact, using the .MSI with those values installs the JRE, does not add the jusched.exe in HKLM run registry key, there is no evidence of the "c:\program files\common files\Java Update\" directory, and does not even show the "Updates" tab in the Control Panel Java Icon (four tabs instead of five). I'm pretty happy with this, well, at least until Sun/Oracle will change the behaviour of their installer once again. Thank you all, Ilgino 15:04, 17 March 2010 (CET)

I find a java updater installed after java 6.20 installation, I remove it with: msiexec /qn /norestart /x{4A03706F-666A-4037-7777-5F2748764D10}

--DaD 15:34, 19 April 2010 (CEST)

I created a section for JRE 6.0 update 10 that described the huge changes in that version. Someone has renamed that section 'update 19' and so we can no longer see that a big change happened at update 10. I think it important that we keep a record of how the software operated (such as command-line switches), or changed (such as patch-in-place coming in in 6.0 update 10), with respect to its use with WPKG, from version to version for those versions where there are notable changes, so that this site is a useful record for people who're working with various versions of the software, or are upgrading. All this historical information can easily and cleanly be kept in one page if each version worth commenting on has its own section. Another example is the installer switches for each major version. Please leave them in place for the earlier versions, when they change with a later version, so that we can see the way things where and how they changed with the next version. This also helps disambiguate when you see somewhere on the web people claiming installer switches behave one way, which may not work for you, you can come here and see that that may have been the case with an earlier version but may not now be the case. All this historic info is a valuable resource. I will attempt to restore some of this information that may have been lost. Pete Boyd 23:06, 8 April 2010 (CEST)

Silent install Java x86 from JRE executable file is not possible on Windows x64. It is well-known problem (see http://www.itninja.com/question/failure-exit-code-1619-java-x86). At present the best way unpacks MANUALY, looks out for *.msi and *.cab, copies them to anywhere and uses as MSI package. I'm too lazy doing so many actions ;)

Today I find another way - symlink.

      <variable name="x86_path" value="C:\Windows\System32\config\systemprofile\AppData\LocalLow" />
      <variable name="x64_path" value="C:\Windows\SysWOW64\config\systemprofile\AppData\LocalLow" />

       <install cmd='%COMSPEC% /C if not exist "%x86_path%\Sun" mkdir "%x86_path%\Sun"' architecture="x64"/>
       <install cmd='%COMSPEC% /C if exist "%x86_path%\Sun\Java" rmdir /S /Q "%x86_path%\Sun\Java"' architecture="x64"/>
       <install cmd='%COMSPEC% /C mklink /D %x86_path%\Sun\Java %x64_path%\Sun\Java\' architecture="x64"/>
       <install cmd='"%PKG_SOURCE%\jre-%PKG_VERSION%-windows-i586.exe" %PKG_INSTALL_SWITCH%' />

       <install cmd='%COMSPEC% /C if not exist "%x86_path%\Sun" mkdir "%x86_path%\Sun"' architecture="x64"/>
       <install cmd='%COMSPEC% /C if exist "%x86_path%\Sun\Java" rmdir /S /Q "%x86_path%\Sun\Java"' architecture="x64"/>
       <install cmd='%COMSPEC% /C mklink /D %x86_path%\Sun\Java %x64_path%\Sun\Java\' architecture="x64"/>
       <install cmd='"%PKG_SOURCE%\jre-%PKG_VERSION%-windows-x64.exe" %PKG_INSTALL_SWITCH%' architecture="x64"/>

Marco Gaiarin http://lists.wpkg.org/pipermail/wpkg-users/2013-June/009450.html Sergey Zaikov http://lists.wpkg.org/pipermail/wpkg-users/2013-August/009490.html