RFR: 8273242: (test) Refactor to use TestNG for RuntimeTests ExecCommand tests

Lance Andersen lancea at openjdk.java.net
Tue Sep 7 22:15:11 UTC 2021


On Wed, 1 Sep 2021 16:37:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The ExecCommand test of Runtime.exec is difficult to maintain; the parallel arrays are hard to keep in sync.
> This cleanup converts to use TestNG DataProviders and other improvements.

Looks good Roger.

A couple trivial questions/suggestions below but feel free to ignore :-)

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 107:

> 105:     private static void deleteOut(String path) {
> 106:         try {
> 107:             Files.delete(FileSystems.getDefault().getPath(path));

More of a curious question, is there a reason you couldn't use Files::deleteIfExists or Path.of() instead of FileSystems.getDefault....

test/jdk/java/lang/RuntimeTests/exec/ExecCommand.java line 199:

> 197:         System.setSecurityManager(null);
> 198: 
> 199:         testCommandMode(command, "Ambiguous Unset", testFile, perModeExpected.get(0));

Any thought to creating a constant for the index value for perModeExpected.get(XX) for extra clarity?

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/5335


More information about the core-libs-dev mailing list