This bug started after seeing a reply to a post made by elvanor on groovys mailing list. Currently I believe (and could elvanor confirm) that he has some test failing as they are unable to access system prefs. Basically currently a user temping to access system prefs recieves the following GENTOO_VM="blackdown-jdk-1.4.2" java Test 3/03/2008 18:40:03 java.util.prefs.FileSystemPreferences$3 run WARNING: Could not create system preferences directory. System preferences are unusable. 3/03/2008 18:40:03 java.util.prefs.FileSystemPreferences$8 run WARNING: Prefs file removed in background /opt/blackdown-jdk-1.4.2.03/jre/.systemPrefs/prefs.xml System Keys or GENTOO_VM="sun-jdk-1.6" java Test 3/03/2008 18:46:04 java.util.prefs.FileSystemPreferences$7 run WARNING: Prefs file removed in background /opt/sun-jdk-1.6.0.04/jre/.systemPrefs/prefs.xml System Keys What are the other java dev's opinion on this. I certainly don't think it is major ( or else it would have been dealt with ). I for one would be interested to know to consequences of running tests in a sandbox.... or whether there are ways we could "move" the preferences location. Some other notes Sun bug, related but not particularly helpful. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4838770
Created attachment 145180 [details] Test.java - a very basic demonstration.
Sun doco's http://java.sun.com/j2se/1.4.2/docs/guide/lang/preferences.html http://java.sun.com/j2se/1.4.2/docs/api/java/util/prefs/Preferences.html sorry for the extra bug spam.
I do have some test failing, not sure if it is related to this issue. Probably is. The exception I get is: [junit] Exception in thread "Thread-18" java.lang.SecurityException: Could not lock User prefs.Lock file access denied. [junit] at java.util.prefs.FileSystemPreferences.checkLockFile0ErrorCode(FileSystemPreferences.java:919) [junit] at java.util.prefs.FileSystemPreferences.lockFile(FileSystemPreferences.java:908) [junit] at java.util.prefs.FileSystemPreferences.sync(FileSystemPreferences.java:714) [junit] at java.util.prefs.FileSystemPreferences.flush(FileSystemPreferences.java:807) [junit] at java.util.prefs.FileSystemPreferences.syncWorld(FileSystemPreferences.java:451) [junit] at java.util.prefs.FileSystemPreferences.access$1200(FileSystemPreferences.java:33) [junit] at java.util.prefs.FileSystemPreferences$5$1.run(FileSystemPreferences.java:429) This happens both when I am root and normal user, and on JDK 1.5 and 1.6
Created attachment 198877 [details] Default empty XML prefs file
I looked at this today. Actually the Java System Preferences are usable on Gentoo (at least with Sun JDK 1.6). The warning that appears is only due to the fact that the initial prefs.xml file is absent. As it is created in /opt, you need to have write permission to this directory to store system preferences, but it's perfectly possible. In addition, if you put an empty prefs.xml file in the specified path, the warning disappear. Reading from this (as a non root user) works perfectly. Maybe we should install a default empty prefs file? I attached such a file in the bug.
I also spent quite some time trying to get stuff like this working in the Portage sandbox. Actually you can define a different directory to use for the User Preferences via the property java.util.prefs.userRoot. Or you can define a different user.home which will also do the trick. I have a problem with this approach though; apparently a task defined in a build.xml file via taskdef will not use the Java properties that Ant sees perfectly well. This may be due to the fact that Ant loads another JVM. If someone knows something about this, please comment on this bug, I spent 2 hours of googling without any success.
Ok, I finally found out how to use these in the Portage sandbox (you must modify the Java properties; Ant properties differ from Java ones). I will try to edit the sun-jdk ebuilds (at least 1.6) to install an empty file as part of the installation, and will close this bug.
(In reply to comment #7) > > I will try to edit the sun-jdk ebuilds (at least 1.6) to install an empty file > as part of the installation, and will close this bug. > Sounds good to me.
