Java System Preferences Under Different Users in Linux

java system preferences under different users in linux

Set these settings per user:

mkdir -p ~/.java/.systemPrefs
mkdir ~/.java/.userPrefs
chmod -R 755 ~/.java
export JAVA_OPTS="-Djava.util.prefs.systemRoot=/home/user/.java -Djava.util.prefs.userRoot=/home/user/.java/.userPrefs"
  <run appl>

Without creating the directories, some Java virtual machines default to /etc/.

See also: Java - Setting Preferences backingstore directory

Java - Setting Preferences backingstore directory

In a Linux system, the System root preference node will be under /etc. This is due to history, and is a standard that is regulated by the Linux Standard Base. Any non-system preferences can go in other locations, but it is a violation of the design of the operating system to have system preference go elsewhere.

Odds are your define is ineffective in a Linux system because it fails to start at /etc. Apparently something in the Java code defers to the specification of the operating system over your decision to re-base the preference root.

Typically such files are protected against modification by not being world (or even most user) writeable. This means that for users to have access to Preferences, they should go under

 Preferences.userRoot()

Which will place them in hidden directories just off their home directory (where they will have modification privileges).

If your want any user to read any other user's preferences (the description sounds like you might) then you will need to have an installer that runs as a sufficiently authorized user (typically root) to make the required directory under /etc and change it's permissions to be world writeable.

Typically files under /etc are not world writable as users changing other's user's setting is then possible, and considered a type of security breach of the user's expected environment. For example, a careless employee (or a disgruntled one) could wipe out all other user's preferences in one stroke.

Preferences getting locked

You likely want to use Preferences pref = Preferences.userRoot().node("example"); ... systemRoot is intended for system wide preferences for all users.

Java: java.util.Preferences Failing

Unfortunately most of the answers you got here are wrong ... at least slightly. In the sense that the symptom is being treated, not the cause.

Let's recap. Java Preferences has two "trees": the user tree and the system tree. You can write your own backend to Java Preferences (called a backing store) but few developers do, so you end up with the JDK's default backing store. On a Windows platform this means the Win Registry, more specifically:

• The user tree is written into HKEY_CURRENT_USER\Software\JavaSoft\Prefs (the OS user always has write access here)
• The system tree is written into HKEY_LOCAL_MACHINE\Software\JavaSoft\Prefs (only an OS user with admin privs has write access here)

In summary: As long as your code doesn't attempt to use the system tree, you should be fine and shouldn't need to mess with assigning privileges at the OS level. The system tree is meant for "all users on the host" and the user tree is meant for the specific logged-in user. In your case I'm confident you can suffice with the user tree, so that is really your solution. Don't go messing with privileges, running as Administrator, and what not.

.... but there's more. Suppose your code deliberately doesn't touch the Java Preferences system tree, as instructed. You'll then still see this warning on Windows:

WARNING [java.util.prefs]: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.

So what is going on? Did I give you the wrong advice ? Not really. Stay with me.

Diving into the JDK source code you'll see that 0x80000002 means HKLM, i.e. the place in the Win Registry that shouldn't be touched. Your code never references the system tree and yet you still see this warning !?? (At this point you must be ripping all your hair out ... as I did)

Well, this is one of the rare occasions where there really is a JDK bug. You can read more about it in this answer by me which I encourage you to read if you are interested in why subtle bugs can go undetected in the JDK for years. The bug has existed ever since JDK 1.4 but has only recently been fixed and not yet backported to JDK 8 (update: the fix has now been backported to version 8u192 onwards of the JDK)

Best advice

• Make sure your code only references the user tree, not the system tree. It is only fair that the OS requires all kinds of privs for you to write to a system-wide location. If you really need to write into such a location then there really is no other solution than assigning privs, executing as Administrator or what not.

• Ignore the warning. It'll go away once you are on Java 8 update 192 or later. The warning can be safely ignored.

• Alternatively you can try to programmatically silence the warning. It comes from the JDK's Platform Logger, so something like this should work, albeit I haven't tried it myself:

    sun.util.logging.PlatformLogger platformLogger = PlatformLogger.getLogger("java.util.prefs");
    platformLogger.setLevel(PlatformLogger.Level.OFF);
  

Java symbol not in system preferences anymore, but still installed

The Java symbol that you are looking for in your system preferences is the "Java Control panel". It has been removed in the newest versions of Java:

https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html#JDK-8185077

[...] Please note that the Java Control Panel, which was used for configuring the deployment technologies, has also been removed along with the shared system JRE (but not the server JRE) and the JRE Auto Update mechanism.

How can I access preferred applications from Java running on Linux?

Have a look at java.awt.Desktop. That supports opening/editing/printing a file in the user's preferred program, opening a URL in the user's preferred browser, sending a eMail, ...

---

Related Topics