The "Java versions regrtest 2.7" action runs the usual regression test on Java 17 and 25, on Ubuntu and Windows. With the stability and proxy change in place, the baseline results are:
17, Ubuntu:

     [exec] 4 fails unexpected:
     [exec]     test_httplib test_os test_posix test_socket

17, Windows:

     [exec] 1 fail unexpected:
     [exec]     test_httplib

25, Ubuntu:

     [exec] 11 fails unexpected:
     [exec]     test_cmd_line test_float_jy test_httplib test_java_integration
     [exec]     test_json test_jy_internals test_os test_posix test_socket
     [exec]     test_subprocess test_threading

25, Windows:

     [exec] 8 fails unexpected:
     [exec]     test_cmd_line test_float_jy test_httplib test_java_integration
     [exec]     test_json test_jy_internals test_subprocess test_threading

This is the baseline against which to measure progress adding the changes specific to Java 25 from #424.

Here I've taken just the improvements to the jython launcher script (used on Unix-like systems) and the jython.py launcher from #424, then regenerated the jython.exe launcher by steps described here but which we should add to the process docs. This ought to close #426, probably after compatible changes to the launcher test.

Some of the changes in #424 seem to be compensating the absence of this windows launcher in compiled form, or or any launcher (e.g. in the Ant script), providing options that the launcher(s) will supply. So let's see what additional passes we get just by fixing the launchers.

That's a lot better. New results are:
17, Ubuntu:

     [exec] 1 fail unexpected:
     [exec]     test_socket

17, Windows: passes
25, Ubuntu:

     [exec] 4 fails unexpected:
     [exec]     test_float_jy test_java_integration test_jy_internals test_socket

25, Windows:

     [exec] 3 fails unexpected:
     [exec]     test_float_jy test_java_integration test_jy_internals

The test_socket failures are all [Errno 98] Address already in use, which is often flakiness in tear-down of a test.

The test_socket failures are all [Errno 98] Address already in use, which is often flakiness in tear-down of a test.

This is what I was trying to fix in the tests. In many of these tests, the previous test is relying on garbage collection rather than explicit cleanup of sockets listening on a port. That creates a race condition when a subsequent test tries to bind to the same port, making the tests flaky...

The test_socket failures are all [Errno 98] Address already in use, which is often flakiness in tear-down of a test.

This is what I was trying to fix in the tests. In many of these tests, the previous test is relying on garbage collection rather than explicit cleanup of sockets listening on a port. That creates a race condition when a subsequent test tries to bind to the same port, making the tests flaky...

I was disappointed too. I thought I had incorporated all such changes into the first commit on this branch, but have I missed something?

Some of the changes in #424 seem to be compensating the absence of this windows launcher in compiled form

No. Not everyone uses (or can use) this compiled Windows launcher; for example, WLST doesn't. We can get by without this compiled Windows launcher. I filed the issue simply for completeness.

I was disappointed too. I thought I had incorporated all such changes into the first commit on this branch, but have I missed something?

If you look back at the comments on #424, you will see that I said that I tried to fix the race conditions I ran into but that there are likely others. It is not easy to find race conditions without running into them.

On further thought, I think the re-run of test_socket is misleading. Sure test_socket fails, and fails to close a socket I expect, but when regrtest runs that suite again verbose, they all fail for that reason. The original cause is buried. I need to run the failing suites verbose on a fresh machine.

Some of the changes in #424 seem to be compensating the absence of this windows launcher in compiled form

No. Not everyone uses (or can use) this compiled Windows launcher; for example, WLST doesn't. We can get by without this compiled Windows launcher. I filed the issue simply for completeness.

By "some of them" I mean where a test does use the launcher, including in build.xml, we don't need to add those arguments.