Jump to page sections
Initially written around 2012-2013 some time. Last update: 2023-07-19.

This script was written to automatically install/update Java JRE when a new version is found on the java.com web site. It uses two files that contain the "last java.com file ID" for 32-bit and 64-bit Java, and will try to install the correct version on 32- and 64-bit Windows versions, unless you specify the -Force32bit parameter, which makes it try to install the 32-bit version regardless of CPU architecture.

First of all, I make no guarantees. During my testing, I have come across several problematic/broken scenarios. Oracle is to blame for those, not this script. More on that below.

The web page that's parsed to look for new file IDs is currently http://www.java.com/en/download/manual.jsp - and it's parsed using HTML Agility Pack (formerly on Codeplex: http://htmlagilitypack.codeplex.com/ ). The .NET 2.0 version of the DLL is bundled with the zip file download. Now that it's the year 2023, you definitely usually want a newer .NET version of HTML Agility Pack, so download it from the link. At the time of writing they have over 83 million downloads.

The logic is simple, and if the current contents of the appropriate processor architecture's last ID file does not match the latest version found on that web page, an attempt will be made to download and install the latest version. By default the last ID files are populated with the text "Default", which means Java will be installed or reinstalled with the latest version found - even if it already is installed with the latest version. Subsequent runs will say it's already the latest version since it populates the last ID file for the relevant processor architecture with the latest installed ID, after a successful install, and it will not be reinstalled/updated until the file ID on java.com changes.

I became aware that silent installs of Java represent a whole world of pain. If you install Java twice silently with this script by changing the ID file's content (this script just calls the installer, so it applies to silent installs in general), you will find yourself with a broken Java install. Furthermore, I discovered that even uninstalling then, after a "double install", breaks. You'll get a rundll32.exe popup with this error: "''There was a problem starting C:\Program Files\Java\jre7\bin\installer.dll. The specified module could not be found''". To work around this I built a somewhat elaborate mechanism for uninstalling that automatically handles this scenario. The logic is quite crude and simple, and it just kills running rundll32.exe processes (yes, this will also kill anything else that might be running under rundll32.exe; I don't think it's too common for this to be running persistently, but beware). The broken behaviour seems to be related to this known bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6947907 .

Since this is based on HTML parsing, it's inherently fragile in nature, and therefore I made an attempt to be able to handle changes in the HTML flexibly without having to edit the code itself - by sticking some values in a configuration file.

This script could be set up to run in a scheduled task (remember that it requires elevation / administrator privileges to install Java). Set the default working directory to the directory/folder the script and the rest of the files are in. You might want to use the -UninstallFirst option, and possibly tweak the configuration file, if you're actually using this for mass-deployment, because of the situations I talk about before where you end up with broken Java installs if it gets installed twice silently. What a mess Sun/Oracle turned this into.

This script now supports 32-bit Java on 64-bit Windows! Use the -Force32bit parameter.

This PowerShell script requires PowerShell version 2 or later.


Here's a test run on a computer that did not have Java installed.

Configuration File

The configuration currently looks like this by default:
32-bit=Download Java software for Windows Offline
64-bit=Download Java software for Windows (64-bit)
UserAgent=Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0
UninstallSwitches=/qn /norestart
*The URL to parse can be changed by editing the configuration file.
*The 32-bit value is the title of the link that links to 32-bit Java, offline version. The "href" link value that goes with this title is used.
*The 64-bit value is the title of the link that links to 64-bit Java, offline version. The "href" link value that goes with this title is used.
*The UserAgent that's used by System.Net.WebClient by default gave me different HTML source code than a real browser, and the 64-bit version was missing, so that's why I had to add this field. I made it configurable in the configuration file so it can be changed/updated easily. The default is currently set to what Firefox v25 uses on 64-bit Windows (2013-11-05), and this currently gives access to source that provides links to both the 32-bit and 64-bit versions of Java JRE.
*The InstallString value is simply "/s" for "silent" by default, and everything else is implicitly set to Oracle's default choices. The unattended install parameters are currently documented here on java.com. I've heard rumors there are some more undocumented switches.
*The UninstallSwitches value is the switches that'll be passed when uninstalling. Defaults are the "most silent" (/qn /norestart).
*The UninstallDisplayNameWildcardString is used when uninstalling, and is a string that'll be passed to the PowerShell -like operator when it's reading installed products on the computer and their corresponding "DisplayName" string as seen in the registry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall.,The default is simply anything that starts with "Java" followed by anything. A complete match is required, so pad with the "*" wildcard if necessary.
*The UninstallTimeout value is used when uninstalling and represents the timeout in seconds to wait for a job before trying to kill the stuck rundll32.exe popup about installer.dll (this is "ugly", but the only way I could find to make it work - blame Oracle, not me).


UninstallFirstThis will check if there's a new version of Java available before trying to uninstall, and only then will it uninstall before proceeding to install the presumed new version that's available. Possibly suited for daily runs as a scheduled task or similar (untested in the real world).
UninstallOnlyThis will not check for new versions, and will simply uninstall all installed software found that matches the "UninstallDisplayNameWildcardString" found in the configuration file (default: "Java*"). It will not install or update Java, just uninstall.
NoInstallDo not install. Sort of like a "dry run" to check for a new version.
Force32bitInstall a 32-bit version of Java even if the processor architecture is 64-bit (AMD64).


*Update-Java.zip - download and unzip. Remember that you might need to unblock files. PowerShell version 3 and up has the cmdlet Unblock-File.

*2013-12-06: Added -Force32bit and -NoInstall parameters.
*2013-11-25: Added -UninstallFirst and -UninstallOnly parameters.
*2013-11-06: Removed the -Raw parameter to Get-Content as it's PSv3+-only.

Powershell      Windows      Java          All Categories

Google custom search of this website only

Minimum cookies is the standard setting. This website uses Google Analytics and Google Ads, and these products may set cookies. By continuing to use this website, you accept this.

If you want to reward my efforts