Skip to content

add macos+windows/+Java 25 - #18

Open
wadoon wants to merge 9 commits into
mainfrom
weigl/extendstestmatrix
Open

wadoon wants to merge 9 commits into
mainfrom
weigl/extendstestmatrix

Conversation

@wadoon

@wadoon wadoon commented Jul 5, 2026

Copy link
Copy Markdown
Contributor

No description provided.

@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch 3 times, most recently from 6a0b765 to 7df802f Compare July 5, 2026 23:44
@github-code-quality

github-code-quality Bot commented Jul 5, 2026 •

Copy link
Copy Markdown
Contributor

Code coverage overview

Languages: Java

Java / code-coverage/jacoco-ubuntu-latest-21

main 4b80003 weigl/extendstestmat... a7f0aeb +/-
57% 57% 0%
View coverage of the 7 most impacted files.
File main 4b80003 weigl/extendstestmat... a7f0aeb +/-
io/github/jmlto...umentService.kt 61% 61% 0%
com/github/java...JavaParser.java 76% 76% 0%
com/github/java...eExtractor.java 84% 84% 0%
com/github/java...BoundLogic.java 89% 89% 0%
io/github/jmlto.../Comparisons.kt 0% 0% 0%
com/github/java...tsInserter.java 97% 98% +1%
io/github/jmlto...tubGenerator.kt 72% 74% +2%

ℹ️ Calculations represent line coverage. Results may change as calculations are updated.


Updated October 24, 2026 16:42 UTC

@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch 2 times, most recently from 185333e to b967c17 Compare July 6, 2026 04:09
@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch 2 times, most recently from 375a0d2 to 9e29060 Compare August 9, 2026 21:23
@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch from a0ec554 to de08a76 Compare August 18, 2026 03:46
@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch from de08a76 to a2f48b4 Compare September 13, 2026 16:31
@wadoon
wadoon force-pushed the weigl/extendstestmatrix branch from a2f48b4 to 98961bb Compare October 17, 2026 17:03
Enabling the Windows matrix in PR #18 surfaced a handful of
Windows-only test failures. They are all caused by platform
differences in how paths, line endings and file URIs are handled,
not by the matrix change itself:

- nameResolution: relativized diagnostic paths use backslashes on
  Windows; normalize to '/' so they match the '//?' expectations.
- jmlstub/smt/lsp tests: normalize CRLF produced by System-based
  line separators before comparing against LF fixtures/text.
- .gitattributes: force LF for '*.symbols' expectation fixtures
  (Windows checkouts would otherwise convert them to CRLF).
- lsp: properly handle 'file:///D:/...' Windows drive-letter URIs
  in the Uri parser instead of stripping 'file://' and leaving a
  '/D:/...' path that Paths.get resolves against the current drive
  root; also emit well-formed URIs from the test helper.
testJREClasses generates stubs via reflection from the runtime JDK and
compares them byte-for-byte against pinned fixtures. The reflection
order of declared fields/constructors/methods is unspecified, and
JDK 21.0.13 reordered java.util.List's class-file members, so macos and
windows (which resolved Zulu 21.0.13+9) failed while ubuntu passed with
its cached 21.0.12. Sort the reflected members explicitly so the stub
output no longer depends on the JDK patch release, and regenerate the
java.lang.Object / java.lang.String / java.util.List fixtures.

Also normalize CRLF vs LF in the fixture comparison so the test is
insensitive to the pretty-printed line endings on any platform.
The "Run shell scripts" step crashed on the Windows runner with a
UnicodeEncodeError from the cp1252 console codec while printing the
file-not-found warning for the literal glob 'tools/cli/shell-tests/**'
(pwsh does not expand '**' like bash does).

- pass the directory instead of the glob; shelltester.py already
  recurses over the test files with rglob('*.txt')
- reconfigure stdout/stderr to UTF-8 so the emoji/pass markers never
  trip over the Windows ANSI codepage
- decode/encode subprocess and file IO as UTF-8 (Java 21 CLIs emit
  UTF-8, the fixtures are UTF-8; the locale codec on Windows would be
  cp1252)
- on Windows, resolve the first token of the run command via PATHEXT so
  'bin/jmltk' correctly maps to the 'bin/jmltk.bat' start script that
  installDist generates
Comment thread scripts/shelltester.py
for stream in (sys.stdout, sys.stderr):
try:
stream.reconfigure(encoding='utf-8', errors='replace')
except (AttributeError, OSError, ValueError):
…nostics

The previous Windows run made both shell-tests fail with empty stdout:
shutil.which() on an extension-less path returns the bare 'bin/jmltk'
POSIX script (installDist also generates it on Windows), so cmd.exe
tried to execute a shell script and produced no output. Prefer the
platform start scripts (.bat/.cmd/.exe) when resolving the command.

Also include the exit code and raw stderr in the failure message, so
command-level problems on CI are diagnosable without a second run.
resolve_windows_executable used partition(' ') which strips the separator
before the arguments, producing '...\jmltk.batstubby --help' (missing
the space after the new extension) and cmd.exe failure. Re-insert the
separator when re-assembling the command line.
jmltk bundles 100+ jars, and Gradle's Windows start script generator
emits a single `set CLASSPATH=` line enumerating every jar. On the
Windows runners that line expands to ~8.8K characters, exceeding
cmd.exe's 8191-character line limit, so `jmltk.bat` fails with
`The input line is too long.` before the JVM is even started.

Post-process the generated Windows scripts (jmltk and jmltk-lsp) to use
the Java classpath wildcard form `%APP_HOME%\lib\*` instead of the
explicit enumeration, keeping them under the limit and making the
distribution actually usable on Windows.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant