The test "failure" is unrelated to this PR. Opened #372 for it. We should get the ci fixed before any new PRs can be merged, I suppose. Apart from that, tests look good to me. Would like to hear a statement from @jeff5 on this, since he found the original issue, but then we're good to go.

I agree there's negligible chance this PR has broken the launcher.

@Stewori , the pull request now updates Netty to 4.1.119. I re-ran the test suite, and got the expected results.

6 tests skipped:
    test_codecmaps_hk test_curses test_smtpnet test_subprocess
    test_urllib2net test_urllibnet
1 test failed:
    test_os_jy
1 fail unexpected:
    test_os_jy
Platform: 
    'Java-1.8.0_442-OpenJDK_64-Bit_Server_VM,_25.442-b06,_Temurin-on-Linux-6.11.0-21-generic-amd64'
Command line: 
    ['/home/wfouche/IdeaProjects/jython/dist/Lib/test/regrtest.py', '-e', '-m', 'regrtest_memo.txt']

Can this pull request now be merged?

Why is a failure in test_os_jy "the expected result"?

We find ourselves tolerating a number of failures with skips, but this isn't one (yet).

This can't be merged as it stands because it doesn't come with the JARs it references. (The targets in the Ant build need the JARs checked in.)

I ran the CI expecting it to fail for that reason, but actually I mis-thought: the affected sections only come into play when we build a distribution, which isn't being tested. The tests are running with the 4.1.73 JARs. 🤦‍♂️ .

However, I feel safer when we get the JARs ourselves, than when a PR comes with them, so thank you for leaving them out. I'll do that bit and push to the PR.

• Replace Netty JARs
• Update NEWS
• Contributor agreement/check

IMO it's a waste of time to update dependencies unless a release is due. This effort will have to be repeated right before 2.7.5 is released (with Netty 4.1.127 or so). Updating even just cherry-picked deps earlier wouldn't be reflected on maven. Users who want newer deps can use jython-slim - I think our pom does not pin versions, just requires minimum versions.

Edit: Just re-read my earlier replies where I say "we're good to go". I guess that was under the assumption that this would not involve any more work than pressing the merge button. Given that more effort is required, I would recommend to bundle it in an overall dependency update right before release.

IMO it's a waste of time to update dependencies unless a release is due. This effort will have to be repeated right before 2.7.5 is released (with Netty 4.1.127 or so).

This is a good point. And when I go to download the JARs, I find netty is already up to .121, one day after .120 .came out. It's a hopeful sign, though, that the story is not all regression. I will try them out, but we should hold off merging until at least a beta is due.

I think an ultimate squash-commit will make the change set no bigger than for a single update.

It failed on my machine, but it is helpful to have the detail visible, so I pushed anyway and ran the CI.

In the read-me we recommend running regression tests either with the jython command or ant. However, regrtest is a complicated thing and the default command given is only good as a verification after installation. (It's good because it won't fail in network-diminished environments.) For a PR we should ask that ant regrtest pass (and ant javatest).

Why is a failure in test_os_jy "the expected result"?

We find ourselves tolerating a number of failures with skips, but this isn't one (yet).

@jeff5 , there were files from a previous aborted test run that I did not clean up. Having done that, the test_os_jy test suite runs without errors.

$ dist/bin/jython Lib/test/test_os_jy.py 
test_issue1727 (__main__.OSFileTestCase) ... ok
test_issue1755 (__main__.OSFileTestCase) ... ok
test_issue1793 (__main__.OSFileTestCase) ... ok
test_issue1824 (__main__.OSFileTestCase) ... ok
test_issue1825 (__main__.OSFileTestCase) ... ok
test_issue2068 (__main__.OSFileTestCase) ... ok
test_issue2083 (__main__.OSDirTestCase) ... ok
test_rmdir (__main__.OSDirTestCase) ... ok
test_stat_with_trailing_slash (__main__.OSStatTestCase) ... ok
test_write_buffer (__main__.OSWriteTestCase) ... ok
test_env (__main__.UnicodeTestCase) ... ok
test_env_naively (__main__.UnicodeTestCase) ... ok
test_getcwd (__main__.UnicodeTestCase) ... ok
test_getcwdu (__main__.UnicodeTestCase) ... ok
test_listdir (__main__.UnicodeTestCase) ... ok
test_uname (__main__.UnicodeTestCase) ... ok
test_strftime_japanese_locale (__main__.LocaleTestCase) ... ok
test_strptime_locale (__main__.LocaleTestCase) ... ok
test_turkish_locale_posix_module (__main__.LocaleTestCase) ... ok
test_turkish_locale_string_lower_upper (__main__.LocaleTestCase) ... ok
test_system_no_site_import (__main__.SystemTestCase) ... ok
test_system_uses_os_environ (__main__.SystemTestCase)
Writing to os.environ is made available as env vars in os.system subprocesses ... ok
test_bad_link (__main__.LinkTestCase) ... ok
test_link (__main__.LinkTestCase) ... ok
test_bad_symlink (__main__.SymbolicLinkTestCase) ... ok
test_readlink (__main__.SymbolicLinkTestCase) ... ok
test_readlink_non_symlink (__main__.SymbolicLinkTestCase)
os.readlink of a non symbolic link should raise an error ... ok
test_readlink_nonexistent (__main__.SymbolicLinkTestCase) ... ok

----------------------------------------------------------------------
Ran 28 tests in 32.699s

OK

It failed on my machine, but it is helpful to have the detail visible, so I pushed anyway and ran the CI.

@jeff, please check and report which version of Java 8 you are using. I'm using

• Java 8.0.452-tem
• Netty 4.1.121

and zero tests are failing. You may have to update your version of Java 8.

Results of latest build test.

# Run tests
dist/bin/jython -m test.regrtest -e -m regrtest_memo.txt

Output (last few lines):

skipped = [
    'test_codecmaps_hk',
    'test_curses',
    'test_smtpnet',
    'test_subprocess',
    'test_urllib2net',
    'test_urllibnet',
 ]
6 tests skipped:
    test_codecmaps_hk test_curses test_smtpnet test_subprocess
    test_urllib2net test_urllibnet
0 tests failed:

Platform: 
    'Java-1.8.0_452-OpenJDK_64-Bit_Server_VM,_25.452-b09,_Temurin-on-Linux-6.14.0-15-generic-amd64'
Command line: 
    ['/home/wfouche/IdeaProjects/jython/dist/Lib/test/regrtest.py', '-e', '-m', 'regrtest_memo.txt']

IMO it's a waste of time to update dependencies unless a release is due.

The only important issue I want to resolve through the current pull request is to get agreement on which version of Java 8 to use to run the Jython regression tests. We cannot just assume that newer version of Netty will continue to work flawlessly on older (buggier) version of Java 8. Tons of bugs have been fixed in Java 8, so we should standardize on the latest release which 8.0.452. We cannot be using different versions of Java 8 to run Jython regression tests (and then run into differeint error conditions).

The JARs named in the Ant script don't actually determine what you run with: they only determine what gets into the shaded JAR and the POMs. When you run the developer-build target, it just copies whatever JARs you have from ~/extlibs to ~/dist/javalib. You can test with any JARs you want by dropping them directly into ~/dist/javalib and deleting the competition. To make Jython use updated JARs permanently you have to update them in ~/extlibs (and in the Ant and Gradle builds for consistency).

At the moment, you are running with the 4.1.119 JARs. The tests are passing because they do not exercise the networking.

Normally we run ant regrtest.

It is very rare for the version of Java to be an issue. I'm using:

Java(TM) SE Runtime Environment (build 1.8.0_321-b07)
Java HotSpot(TM) 64-Bit Server VM (build 25.321-b07, mixed mode)

because it is the latest Oracle will give away.

... there were files from a previous aborted test run that I did not clean up. Having done that, the test_os_jy test suite runs without errors.

Good. We try to keep them passing, even if it means adding skips (to revisit later, ideally).

You can can see this fails in the CI. For completeness, I repeated on my own machine having dropped netty 4.1.121 JARS with the recent Temurin Java 8.:

     [exec] == 2.7.5a1-DEV (heads/pr-370-Netty119-dirty:9232904d7, May 5 2025, 17:30:19)
     [exec] == [OpenJDK 64-Bit Server VM (Temurin)]
     [exec] == platform: java1.8.0_452
     [exec] == encodings: stdin=cp850, stdout=cp850, FS=utf-8
     [exec] == locale: default=('en_GB', 'windows-1252'), actual=(None, None)
...

I get the expected networking failures.