Bug 212155 – Java System Preferences unusable ( possibly also User Preferences )

• Product: Gentoo Linux
• Status: CONFIRMED ---

[Description Alistair Bush (RETIRED) 2008-03-03 05:49:43 UTC]

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

[Comment 1 Alistair Bush (RETIRED) 2008-03-03 05:50:49 UTC]

Created attachment 145180 [details]
Test.java - a very basic demonstration.

[Comment 2 Alistair Bush (RETIRED) 2008-03-03 05:51:50 UTC]

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.

[Comment 3 Jean-Noël Rivasseau (RETIRED) 2008-03-03 21:08:58 UTC]

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

[Comment 4 Jean-Noël Rivasseau (RETIRED) 2009-07-23 06:05:42 UTC]

Created attachment 198877 [details]
Default empty XML prefs file

[Comment 5 Jean-Noël Rivasseau (RETIRED) 2009-07-23 06:06:09 UTC]

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.

[Comment 6 Jean-Noël Rivasseau (RETIRED) 2009-07-23 13:59:53 UTC]

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.

[Comment 7 Jean-Noël Rivasseau (RETIRED) 2009-07-25 09:25:23 UTC]

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.

[Comment 8 Petteri Räty (RETIRED) 2009-07-27 18:47:00 UTC]

(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.