EVALUATION
Some of the examples under test/tools/javac/diags create a file named Gen.java under the scratch dir. A skeleton class is written to this file. One of these examples, ProcUnclosedTypeFiles, leaves the file open as part of the test. The file never gets explicitly closed.
At the start of each example, the files under scratch/ are deleted, but the delete fails silently for this Gen.java if it is still open.
jtreg then attempts to delete the files under scratch/ at the start of the next test. If a delete fails, the test fails as an error.
On Windows, there have been cases where this Gen.java file stays open throughout the test run. which causes every subsequent test to fail. Note that when the file object is gc'd the file gets closed, so the number of tests that fail, if any, is non-deterministic.
Getting this file closed is difficult. As an easy out, we just run these tests in othervm mode which causes the files to be closed when the test terminates.
|
EVALUATION
Using the standard jtreg /othervm mechanism is a simple and clever solution, but it does leave open the possibility of the problem example interfering with downstream examples, although admittedly we are not actually seeing that in practice.
A somewhat more sophisticated fix would be to run just the one problem example in its own JVM. This could be down by updating Example.Compiler.run to support a new option, "exec", similar to "simple", which execs javac instead of invoking it directly via Main. This could be done by moving the invocation in Example.Compiler:466 to a separate method which be overridden in a subtype of SimpleCompiler which would exec javac in a separate JVM.
|
Java