On 23/03/2020 07:44, Baesken, Matthias wrote:
Hello, we noticed the following issue in
tools/jpackage/share/RuntimePackageTest.java .
See also https://bugs.openjdk.java.net/browse/JDK-8241415 .
When running a whole jdk jtreg test suite we see failures of the the
tools/jpackage/share/RuntimePackageTest.java test.
Failures are like this :
TRACE: Missing 3 files:
TRACE: .systemPrefs
TRACE: .systemPrefs/.system.lock
TRACE: .systemPrefs/.systemRootModFile
TRACE: Done
ERROR: Failed: Check there are no missing files in installed image
Looking into the jdk under test, we notice the mentioned files were created
inside the jdk under test
(by previous jtreg tests, this is indicated by the time stamps of those files).
my estimation is that some other tests using FileSystemPreferences might
created those files.
The RuntimePackageTest.java test however does not expect those files in the jdk
image under test.
Any comments ? Should we check for these files at just delete them at the
beginning of tools/jpackage/share/RuntimePackageTest.java (or skip the test
in case the files exist) ?
Otherwise we might tolerate those 3 files .
Tests should never modify the "JDK under test". It should be possible to
test a JDK that is on a read-only file system for example. There are a
small number of tests that need edit configuration files and they are
supposed to replicate the JDK to another location so it doesn't
interfere with other tests running at the same time or later. For the
prefs API, there are system properties (java.util.prefs.systemRoot and
java.util.prefs.userRoot) to configure where the system and user prefs
are stored. There were several issues in the past with userRoot and I
think all those tests were fixed to run the tests with the system
property set. We might have to do a similar exercise for the systemRoot.
-Alan
