Verification task for #180 (fixes #179), which rewrites install.ps1 and both generated Windows launchers.
Why this needs its own issue: #180 was developed and tested on macOS with PowerShell 7.4.5 against a local mirror of the artifact repo. That covers version resolution, both install paths, licence extraction, and the launcher's java invocation — but it can never cover cmd.exe or Windows PowerShell 5.1, which is the version that ships with Windows. Two HIGH-severity bugs in the generated .bat were already caught by code review (cmd expands every %VAR% in a parenthesised block in one parse pass, so a quote-strip inside the block was dead code and if defined X if %X% GEQ 9 guarded nothing). Both are fixed, but neither was executed — that is what this issue is for.
Do not merge #180 on the strength of the macOS testing alone.
1. cmd.exe running the generated bin\softclient4es.bat
The least-tested file in the change. The Java-major parse is the risky part.
2. Windows PowerShell 5.1 — the whole installer
Not just 7.x. Run .\install.ps1 end to end and check:
3. bin\softclient4es.ps1 under 5.1
4. irm … | iex — the documented entry point
README.md:31 and documentation/client/repl.md:81 both tell Windows users to run:
irm https://raw.githubusercontent.com/SOFTNETWORK-APP/SoftClient4ES/main/install.ps1 | iex
5. Java floor and ES 9
Reporting
Please record the actual output for anything that fails, plus $PSVersionTable.PSVersion, the Windows build, and the JDK vendor/version — the Java-version parse depends on the exact java -version text, and vendor differences are a plausible source of divergence.
Known gaps, not part of this verification
AppCDS is deliberately not ported to Windows in #180 (a pure cold-start optimisation; install.sh generates the archive at install time on JDK 13-18 and passes -XX:+AutoCreateSharedArchive on 19+). Worth a separate issue if Windows cold start matters. Also absent by design: the ELASTIC_* empty-env-unset loop, benign on Windows because setting an env var to "" deletes it there.
Verification task for #180 (fixes #179), which rewrites
install.ps1and both generated Windows launchers.Why this needs its own issue: #180 was developed and tested on macOS with PowerShell 7.4.5 against a local mirror of the artifact repo. That covers version resolution, both install paths, licence extraction, and the launcher's java invocation — but it can never cover
cmd.exeor Windows PowerShell 5.1, which is the version that ships with Windows. Two HIGH-severity bugs in the generated.batwere already caught by code review (cmd expands every%VAR%in a parenthesised block in one parse pass, so a quote-strip inside the block was dead code andif defined X if %X% GEQ 9guarded nothing). Both are fixed, but neither was executed — that is what this issue is for.Do not merge #180 on the strength of the macOS testing alone.
1.
cmd.exerunning the generatedbin\softclient4es.batThe least-tested file in the change. The Java-major parse is the risky part.
JAVA_MAJORis a bare integer (not"11, not empty). Add a temporaryecho JAVA_MAJOR=[%JAVA_MAJOR%]before the java line.--add-opensactually reaches the JVM: temporaryecho EXTRA_OPTS=[%EXTRA_OPTS%], expect--add-opens=java.base/java.nio=ALL-UNNAMED -Dio.netty.tryReflectionSetAccessible=trueon Java 9+. This is the flag pair the whole ticket exists to deliver; if it is empty, the Arrow/DuckDB JOIN path is still broken.9 was unexpected at this time.) on any run.javaabsent from PATH → cleanError: Java is not installed. Java 11+ is required.and exit code 1, not a parse error or a silent start.C:\Program Files\softclient4esand the defaultC:\Users\<name with space>\softclient4es. The default matters most:%USERPROFILE%routinely contains a space, so this is the common case, not the exotic one. Expect noCould not find or load main class.softclient4es.bat -c "SELECT * FROM my_index WHERE name = 'John Doe'".-c "SELECT \"field\" FROM idx"— confirm what actually reaches the CLI.-cp+lib\*works on Windows).2. Windows PowerShell 5.1 — the whole installer
Not just 7.x. Run
.\install.ps1end to end and check:-allbundle and its own version line.Test-UrlExists) — confirm it does not spuriously return false and demote every install to the plain artifact.$ProgressPreferenceis set toSilentlyContinuearound it precisely because 5.1's per-chunkWrite-Progressmakes a download this size crawl while showing nothing. If it still takes many minutes, say so — the fallback isSystem.Net.WebClient.DownloadFile.licenses\(3 files) +NOTICEviaSystem.IO.Compressionon 5.1 (7.x has the types preloaded; 5.1 needs theAdd-Type).-NoExtensionsand-ListVersionsbehave as on 7.x.3.
bin\softclient4es.ps1under 5.1$env:JAVA_OPTSunset → defaults to-Xmx512m.$env:JAVA_OPTSsingle flag (-Xmx1g).$env:JAVA_OPTSmulti flag (-Xmx1g -XX:+UseG1GC) — each must arrive as its own argument.$env:JAVA_OPTSwith a leading space (" -Xmx2g") — the empty element must be dropped; otherwise java reads""as the main class and refuses to start.-c: 5.1's native argument quoting mangles embedded"where 7.3+ does not. Establish what actually works on 5.1 and document it if the two differ.exit $LASTEXITCODE): run a failing statement, check$LASTEXITCODE.4.
irm … | iex— the documented entry pointREADME.md:31 and documentation/client/repl.md:81 both tell Windows users to run:
param()block and itsexitcalls behave underiex. Anexitinsideiexterminates the host session, so any error path (bad ES version, missing Java, failed download) may close the user's PowerShell window rather than print an error.-NoExtensions/-Versionrequire the download-then-run form. If so, the docs should say it.5. Java floor and ES 9
Check-Prerequisites. fix(installer): bring install.ps1 to parity with install.sh — Windows launchers ignored lib/ via java -jar (#179) #180 raises the floor from 8 to 11 because the 0.20+ CLI bundles logback 1.5.x (Java-11 bytecode) and does not start on 8. Previously the installer accepted Java 8 and the failure surfaced later asUnsupportedClassVersionError.Reporting
Please record the actual output for anything that fails, plus
$PSVersionTable.PSVersion, the Windows build, and the JDK vendor/version — the Java-version parse depends on the exactjava -versiontext, and vendor differences are a plausible source of divergence.Known gaps, not part of this verification
AppCDS is deliberately not ported to Windows in #180 (a pure cold-start optimisation; install.sh generates the archive at install time on JDK 13-18 and passes
-XX:+AutoCreateSharedArchiveon 19+). Worth a separate issue if Windows cold start matters. Also absent by design: theELASTIC_*empty-env-unset loop, benign on Windows because setting an env var to""deletes it there.