Fix parameter mismatch in CreateSwtWebView2Options native declaration

[GreenFuze]

Fixes #3519.

The Java declaration takes no parameters:

// COM.java:518
public static final native long CreateSwtWebView2Options();

while the C++ stub that implements it takes one:

// com_custom.cpp:441
JNIEXPORT jlong JNICALL COM_NATIVE(CreateSwtWebView2Options)
	(JNIEnv *env, jclass that, jobject host)

The JVM binds a native method by its symbol, not by its signature — the argument descriptor appears in the entry symbol only for overloaded natives — so nothing checks that the two ends agree. The stub is entered with two arguments pushed and reads a third from wherever the calling convention says it lives.

The value read is currently harmless because the parameter is unused, and the parameter itself looks like a copy of the neighbouring CreateSwtWebView2Host, which does use its host argument. It becomes a real defect the moment the parameter is read.

The Java side is the correct one: SwtWebView2Options::Create() takes no arguments, and the sole caller — Edge.java:619 — passes none.

One question for a committer

This changes native code, so the Windows libraries need rebuilding and possibly a Library.REVISION bump. I have not touched Library.java or the checked-in binaries, since I cannot produce the official Windows builds — please tell me if you would like the version bump included here, or whether that is handled on your side.

---

Reported and fixed as part of a research project on cross-language contract checking; the mismatch was found by static comparison of the two declarations rather than by a failing test, which is why the issue quotes no reproducer.

[github-actions]

Test Results (win32)

   35 files  ±0     35 suites  ±0   5m 29s ⏱️ +26s
4 871 tests ±0  4 795 ✅ ±0  76 💤 ±0  0 ❌ ±0 
1 398 runs  ±0  1 374 ✅ ±0  24 💤 ±0  0 ❌ ±0 

Results for commit 77961e3. ± Comparison against base commit 83e249e.

[HeikoKlare]

Thank you for contributing this fix.
The issue analysis and the derived change are sound.

This changes native code, so the Windows libraries need rebuilding and possibly a Library.REVISION bump. I have not touched Library.java or the checked-in binaries, since I cannot produce the official Windows builds — please tell me if you would like the version bump included here, or whether that is handled on your side.

The natives will automatically be regenerated when this PR is merged. The CI build already executed a natives compilation on the fly to validate the change.

This can be merged as soon as development opens for 2026-12.