8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files
Alan.Bateman at oracle.com
Mon Mar 23 08:10:54 UTC 2020
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.
More information about the core-libs-dev