RFR: 8259267: Refactor LoaderLeak shell test as java test. [v3]

Igor Ignatyev iignatyev at openjdk.java.net
Tue Jan 5 21:36:57 UTC 2021

On Tue, 5 Jan 2021 20:58:37 GMT, Ivan Šipka <isipka at openjdk.org> wrote:

>> test/jdk/java/lang/annotation/LoaderLeakTest.java line 54:
>>> 52:         List<String> classes = List.of("A.class", "B.class", "C.class");
>>> 53:         for (String fileName : classes) {
>>> 54:             Files.move(
>> I don't think it's a good idea to move files created and managed by `jtreg`. I'd recommend you copying them here and, in `runJavaProcess...` constructing `ProcessBuilder` youself:
>> var args = new ArrayList<String>(command.length + 1);
>> args.add(JDKToolFinder.getJDKTool("java"));
>> Collections.addAll(args, command);
>> var pb = new ProcessBuilder(args).directory(Paths.get(Utils.TEST_CLASSES).toFile());
> They are intentionally moved out of class path so that the application class loader can not find them. If they are not moved they will be loaded by the application class loader and they need to be [loaded](https://github.com/openjdk/jdk/blob/bc56a63702b8730abc1d0aebee133a5884145fa1/test/jdk/java/lang/annotation/LoaderLeakTest.java#L96) by the tests very own `SimpleClassLoader` in order to be able to test for the leakage.

I understand the intention, but it can be achieved w/o messing around w/ jtreg managed directories, for example by changing `SimpleClassLoader` to not delegate the loading of `A`, `B`, `C` classes to the application CL.


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

More information about the core-libs-dev mailing list