Java in Linux: classi di aspetto diverso per root e non root

Question

Ho notato che Java propone classi di aspetto diverso per utenti root e non root. Sto cercando di capire come rendere coerente LAF. Inoltre, è inconsistente anche all'interno di un utente/root: dipende da come user/root visita:

codice di esempio (compilato e confezionato in laf.jar):

import javax.swing.UIManager; 

public class laf { 
    public static void main(java.lang.String[] args) { 
     try { 
      System.out.print(UIManager.getSystemLookAndFeelClassName()); 
     } catch (Exception e) { 
     } 
    } 
} 

Scenario 1 registri per macchina (in modalità GUI) come un utente normale

Esempio di output (come utente)

[xxx@yyy Downloads]$ java -classpath laf.jar laf 
com.sun.java.swing.plaf.gtk.GTKLookAndFeel 

Esempio di output (commuta radice via su)

[root@yyy Downloads]# java -classpath ./laf.jar laf 
javax.swing.plaf.metal.MetalLookAndFeel 

Scenario 2 registri a macchina (in modalità GUI) come root

Esempio di output (come radice)

[root@yyy Downloads]# java -classpath ./laf.jar laf 
com.sun.java.swing.plaf.gtk.GTKLookAndFeel 

Scenario 3 accede a macchina attraverso SSH come un utente normale (simile come sopra scenario # 1, ma in questo caso - stesso LAF)

Esempio di output (come utente)

[xxx@yyy Downloads]$ java -classpath laf.jar laf 
javax.swing.plaf.metal.MetalLookAndFeel 

Esempio di output (commuta radice)

[root@yyy Downloads]# java -classpath ./laf.jar laf 
javax.swing.plaf.metal.MetalLookAndFeel 

Software ver SION:

[root@yyy Downloads]# java -version 
java version "1.7.0" 
Java(TM) SE Runtime Environment (build pxa6470sr9fp10-20150708_01(SR9 FP10)) 
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 Compressed References  20150701_255667 (JIT enabled, AOT enabled) 
J9VM - R26_Java726_SR9_20150701_0050_B255667 
JIT - tr.r11_20150626_95120.01 
GC - R26_Java726_SR9_20150701_0050_B255667_CMPRSS 
J9CL - 20150701_255667) 
JCL - 20150628_01 based on Oracle jdk7u85-b15 

[root@yyy Downloads]# cat /etc/redhat-release 
Red Hat Enterprise Linux Workstation release 6.7 (Santiago) 

Answer 1

La prima linea di getSystemLookAndFeelClassName è:

public static String getSystemLookAndFeelClassName() { 
    String systemLAF = AccessController.doPrivileged(
         new GetPropertyAction("swing.systemlaf")); 

in modo da poter utilizzare le JAVA_OPTS del all'utente di impostare

-Dswing.systemlaf=javax.swing.plaf.metal.MetalLookAndFeel

come predefinito.

aggiungere questo alla .rc -File dell'utente:

set JAVA_OPTS=-Dswing.systemlaf=javax.swing.plaf.metal.MetalLookAndFeel 
export JAVA_OPTS 

saluti

Answer 2

Questo è meno di root e di più su variabili di ambiente.

In sostanza, il metodo UIManager.getSystemLookAndFeelClassName funziona così:

• Controllare la proprietà di sistema swing.systemlaf. Ciò consente all'utente di sovrascrivere qualsiasi cosa il sistema desideri scegliere. Se non è nullo, è usato.
• In caso contrario, se il sistema operativo è Windows, restituisce WindowsLookAndFeel.
• In caso contrario, controlla la proprietà sun.desktop. Se sun.desktop è impostato su gnome e GTK è disponibile in modo nativo, viene restituito allo
• In caso contrario, verifica la presenza di Mac OS X e Solaris e restituisce i valori appropriati per questi sistemi operativi.
• Se tutti gli altri controlli non sono riusciti, restituisce la "piattaforma incrociata" L & F, che è MetalLookAndFeel.

Quindi, la parte che è rilevante per Linux/Unix è la parte che controlla sun.desktop. Questa proprietà viene impostata all'avvio della JVM. È impostato su gnome se la variabile di ambiente GNOME_DESKTOP_SESSION_ID esiste, ignorando il suo contenuto ed è impostata su null in caso contrario. Credo che this is the pertinent native source code faccia questo.

Quindi, in Linux, se è impostata questa variabile di ambiente (e GTK è disponibile), il tuo L sarà impostato su L . In caso contrario, sarà impostato su MetalLookAndFeel.

Quando si accede a un Linux basato su Gnome utilizzando il gestore desktop, il proprio ambiente disporrà di tale set di variabili. Ma il comando non propaga le variabili di ambiente per impostazione predefinita. Pertanto, quando si fa su qualsiasi utente, non necessariamente root, si perde la variabile di ambiente GNOME_DESKTOP_SESSION_ID e Java verrà impostato su MetalLookAndFeel.

È possibile far passare l'ambiente attraverso su utilizzando su -p o se si utilizza sudo, utilizzando sudo -E.

Il comando ssh, come su e sudo, non propagano le variabili di ambiente. Questo può anche essere risolto usando ~/.ssh/environment.

Tuttavia, come già indicato, è possibile forzare facilmente uno specifico L & F passando lo switch -Dswing.systemlaf=... al comando java.