Issue2710

In test_ssl I notice that in a couple of places we have disabled tests when running on Java 9 or beyond (in BasicSocketTests.test_errors and ContextTests.test_load_cert_chain). I am experiencing what looks to be the same failure in test_socket_jy (on Java 9) in SSLSocketConnectTest.test_connect_ex_workout .

test_ssl contains the comment:
# Possible FIXME similar issue as seen in
# test_load_cert_chain - apparently this RSA 1024 cert is too weak and gets a
# java.security.KeyStoreException: Key protection  algorithm not found before the
# ValueError raised on earlier versions of Java;
# but we need to confirm this is truly the case on Java 9
(The test is supposed to raise a ValueError but fails creating the socket, I think.)

I'm raising it as an issue here so we do not just forget it. I cannot tell yet whether this is just a problem with the test material or a real problem in use.

Is this related to failing Travis CI on OSX?
Currently in Travis CI significantly more tests fail on OSX than on Linux.
On Linux only test_urllib2net fails while on OSX we get:

     [exec] 10 tests failed:
     [exec]     test_codecencodings_tw test_dict test_dict_jy test_import_jy
     [exec]     test_os_jy test_re_jy test_signal test_socket_jy test_ssl
     [exec]     test_unicode_jy

See https://travis-ci.org/jythontools/jython/jobs/433951090.
Just asking because the log complains a lot about certs and test_ssl is also failing here.

I would say so. "platform: java10.0.1" is the clue. The list is the same that I see (or saw) on Java 9. I hadn't noticed we were testing on 9+  *<:(

I have eliminated some of these failures this weekend, and the ugly reflective access warnings (except from jnr.posix). I have a couple more in my sights, then will push as a batch to save possible merges.

Another thing to mention is that the idiom:
    if support.get_java_version() < (1, 9):
will not work reliably, so test_ssl (it appears) is not skipping the problematic code. But this also is fixed on my repo.

Do we intend to test on 10? I think this has happened because we allow it to choose the default Java. It's useful to see, but it will be red for a while. Or rather, given our CI *is* running on versions 9+, we should make it run cleanly by skipping (and raising an issue). I can easily do that, and for a couple of them, fixing them is as quick.

Alright, I had overlooked "platform: java10.0.1", just saw OSX platform. Java 9+ is of course an enlightening explanation for the additional failures.

Skipped on Java 9+ for now in: https://hg.python.org/jython/rev/5aa64ce0b8b8