[OKAN-SOFTWARE]

Fixes #1745.

Summary

Correct the Windows User32.SetCursorPos mapping to use the native API's 32-bit int coordinates, while preserving the existing long overload for binary compatibility.

Changes

• Add SetCursorPos(int x, int y) with the correct Windows API parameter types.
• Keep SetCursorPos(long x, long y) and mark it @Deprecated for binary compatibility.
• Add a regression test verifying the method signatures and deprecation annotation.
• Extend the cursor-position test to verify that both X and Y coordinates are preserved.
• Update CHANGES.md.
• Squash the implementation, tests, and changelog into one commit (6f7b6ca3), as requested.

Testing

Windows 11 — 64-bit JVM

• JDK 25; Apache Ant 1.10.18.
• Command: ant "-Dtests.include=**/User32Test.java" test-platform
• Result: 41 tests, 0 failures, 0 errors, 2 skipped.
• Ant: BUILD SUCCESSFUL.

Windows 11 — 32-bit JVM (native runtime verification)

• Azul Zulu JDK 17, Windows x86.
• Confirmed os.arch=x86 and sun.arch.data.model=32.
• Ran org.junit.runner.JUnitCore com.sun.jna.platform.win32.User32Test with the PR's locally built JNA and JNA Platform artifacts on the classpath.
• Result: OK (39 tests), with 2 tests ignored; JUnit exit code 0.
• The User32Test suite includes a native SetCursorPos invocation using the corrected int overload. No native invocation failures were observed.

git diff --check also passed.

Notes

The 32-bit Windows runtime verification requested during review has now been completed successfully. No further code changes were needed for this validation.

[matthiasblaesing]

Please squash into one commit. There is no additional value in splitting this.

Source changes and regression tests have been reviewed, but runtime tests have not been executed locally.

Why not? How did you determine, that they actually work? The tests can be run in isolation, even from CLI. This call for example:

ant -Dtests.include=**/X11Test.java test-platform

executed from the base of the source tree, will run only tests that are located in a file called X11Test.java. The ** is the directory spanning wildcard, the * is treated as a wildcard on a single level.

The existing CI covers Java compilation on Linux and macOS. Verification on 32-bit Windows is still recommended.

This is wrong. The problem is not the java side of the equation. That will compile (one platform is enough to verify that), the interesting question is: Will the interaction with the native library work. That need exection on a 32bit platform.

[OKAN-SOFTWARE]

Follow-up on the 32-bit native runtime verification:

I completed the Windows x86 verification using Azul Zulu JDK 17 (32-bit).

• JVM architecture: os.arch=x86, sun.arch.data.model=32
• PR commit: 6f7b6ca3
• Test suite: com.sun.jna.platform.win32.User32Test
• Result: OK (39 tests), with 2 additional tests ignored
• JUnit exit code: 0

The tests executed against the PR's locally built JNA artifacts using the 32-bit JVM, including the native SetCursorPos test. No native invocation failures were observed.

The earlier 64-bit Windows test run also passed (41 tests, 0 failures, 2 skipped).

The requested changes remain squashed into a single commit. This completes the 32-bit runtime verification requested in your earlier feedback.

Thank you for the guidance!