RFR: 8298939: Refactor open/test/jdk/javax/rmi/ssl/SSLSocketParametersTest.sh to jtreg java test [v3]

[Stuart Marks]

On Tue, 7 Feb 2023 20:38:40 GMT, Matthew Donovan <duke at openjdk.org> wrote:

>> Removed SSLSocketParametersTest.sh script (which just called a Java file) and configured the java code to run directly with jtreg
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added exceptions for cases 4 and 5

test/jdk/javax/rmi/ssl/SSLSocketParametersTest.java line 163:

> 161:                 }
> 162:             }
> 163:         }

It looks like this finally-block is intended to unexport any exported RMI service, which will let the JVM exit. However, this is somewhat fragile. If the unexportObject() call fails with some other exception, the object might remain exported, and the JVM will hang indefinitely. (This has historically been a problem with RMI tests.)

Since the original version of the test ran each case in a separate JVM, I think it's ok to continue to do the same. The old version of the test called System.exit() along most code paths. It's somewhat odd that exit wasn't called along all code paths. Perhaps those code paths weren't taken, or if they were, the JVM exited of its own accord. In any case, I'd suggest ensuring that exit() is called along all code paths (success and failure) and keeping separate `@run main/othervm` lines in the header to run each case in its own JVM. This is at least equivalent to what the shell script based test was doing.

As an optimization, it might be reasonable to try to run some subset of the tests in a single JVM. They can't all be run in the same JVM though, because of system properties, so this would require some complexity to support running some cases in the same JVM and some in separate JVMs. It's not clear to me whether that's warranted.

-------------

PR: https://git.openjdk.org/jdk/pull/11910