Found reviewing PR #232 (Windows JDK bootstrap). Verified against install.ps1 as merged.
What happens
The JDK is bootstrapped into $Target before anything validates that the requested install can succeed:
- install.ps1:426 —
if (-not (Resolve-Java)) { exit 1 }, which downloads and unpacks ~300 MB into <Target>\jdk when the host has no suitable Java
- install.ps1:1149 —
Download-Jar, which is where a bad -Version or an unreachable artifact is discovered, and which exit 1s (install.ps1:593)
Consequence
A typo in -Version, an artifact that does not exist for the chosen -EsVersion, or an Artifactory outage leaves roughly 300 MB of orphaned jdk\ in the target directory. There is no uninstaller, and nothing in the failure output mentions that a JDK was left behind, so the user is not told what to delete or that there is anything to delete.
It compounds with the re-download issue: the orphan is not reused on the next attempt either.
Suggested fix
Either
- resolve the artifact version before bootstrapping a JDK (the version probe is a cheap HTTP call and it is the input most likely to be wrong), or
- record that this run created
<Target>\jdk and remove it on a failure path that never produced a working install.
Option 1 is the smaller change and also shortens the failure loop for the far more common "wrong version" mistake.
Found reviewing PR #232 (Windows JDK bootstrap). Verified against
install.ps1as merged.What happens
The JDK is bootstrapped into
$Targetbefore anything validates that the requested install can succeed:if (-not (Resolve-Java)) { exit 1 }, which downloads and unpacks ~300 MB into<Target>\jdkwhen the host has no suitable JavaDownload-Jar, which is where a bad-Versionor an unreachable artifact is discovered, and whichexit 1s (install.ps1:593)Consequence
A typo in
-Version, an artifact that does not exist for the chosen-EsVersion, or an Artifactory outage leaves roughly 300 MB of orphanedjdk\in the target directory. There is no uninstaller, and nothing in the failure output mentions that a JDK was left behind, so the user is not told what to delete or that there is anything to delete.It compounds with the re-download issue: the orphan is not reused on the next attempt either.
Suggested fix
Either
<Target>\jdkand remove it on a failure path that never produced a working install.Option 1 is the smaller change and also shortens the failure loop for the far more common "wrong version" mistake.