8241415: tools/jpackage/share/RuntimePackageTest.java fails because of systemPrefs files

[Alan Bateman]

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