PDA

View Full Version : [java] System.getProperty() a volte non recepisce una variabile


perporsof
28-03-2011, 15:42
ciao a tutti


sto usando System.setProPerty(), System.getProPerty() per scrivere il valore di una variabile e poi leggerlo.

Il tutto in un loop sulle righe di un file (legge una riga, elabora, scrive un valore con setProperty, poi successivamente legge il valore
con System.getProPerty() ed elabora ancora).

Va tutto bene, eccetto che per le prime tre righe, per cui sembra che System.setProPerty() non abbia effetto, e quindi System.getProPerty(), solo per queste tre righe, successivamente legge null, anzi da' proprio eccezione.

Sembra che ci sia un ritardo con cui il sistema agisce..

Ho trovato una soluzione mettendo un ritardo : Thread.sleep(800L) solo per la prima riga, pero' questo valore di ritardo sembra che dipenda dal server (su altri server deve essere minimo 2-3 secondi), e vorrei usare un'altra soluzione.

Chiedo cortesemente se qualcuno ha qualche idea.. grazie

PGI-Bis
29-03-2011, 15:03
Il comportamento descritto è piuttosto bizzarro perchè set/get property si risolve nell'invocazione di un set/get su un'istanza di Properties, previa verifica dei permessi di sicurezza.

Quindi o capita una SecurityException o la proprietà è necessariamente impostata prima che il flusso di esecuzione passi all'enunciato successivo: se così non fosse il codice non rispetterebbe le norme di esecuzione del linguaggio di programmazione Java il che sarebbe strano per una classe che è parte del linguaggio stesso.

Il caso che proponi sarebbe invece tipico di programma con più flussi di esecuzione paralleli: l'accesso alle proprietà di sistema (cioè al contenuto del campo props della classe System) non è sincronizzato dunque se il thread a imposta una proprietà e il thread b la legge il thread b, a differenza dell'ipotesi del flusso unico, può ricevere tre risposte: null, il valore precedente all'ultimo, l'ultimo valore inserito (l'unico corretto).

Se sei nel caso del concorso, allora risolvi stabilendo un punto di sincronizzazione tra le scritture e le letture dei valori delle proprietà di sistema.

perporsof
30-03-2011, 16:09
grazie per la risposta, in effetti il tutto avviene tramite un thread; il numero dei thread pero' e' parametrizzato, ed e' UNO.
Inoltre sia il setproperty che il getproperty avvengono per ulteriore sicurezza tramite metodi synchronized, infatti il tutto alla fine funziona regolarmente,
ECCETTO che per i primi tre giri..

mettendo un Thread.sleep(2000L) solo una volta, dopo il primo giro, funziona tutto al 100%, pero' mi piacerebbe capire perche' c'e' questo ritardo iniziale da parte della virtual machine a recepire il valore di System.getproperty..

(i primi 3 giri in effetti, senza questo ritardo, danno un eccezione di nullpointerexception al momento della lettura, system.getproperty..)

PGI-Bis
30-03-2011, 16:37
Questo è quello che fanno System.set e get property:

...estratto dal sorgente java.lang.System.java
private static void checkKey(String key) {
if (key == null) throw new NullPointerException("key can't be null");
if (key.equals("")) throw new IllegalArgumentException("key can't be empty");
}

public static String setProperty(String key, String value) {
checkKey(key);
SecurityManager sm = getSecurityManager();
if (sm != null) sm.checkPermission(new PropertyPermission(key, SecurityConstants.PROPERTY_WRITE_ACTION));
return (String) props.setProperty(key, value);
}

public static String getProperty(String key) {
checkKey(key);
SecurityManager sm = getSecurityManager();
if (sm != null) sm.checkPropertyAccess(key);
return props.getProperty(key);
}

Non è materialmente possibile che un get successivo ad un set, per la stessa proprietà, manchi il bersaglio.

Sarebbe tra l'altro un bug talmente marchiano da essere stato rilevato almeno una volta mentre non ve n'è alcuna traccia.

Se il contesto in cui ti muovi non è concorrente allora l'unica possibilità è che il nome della proprietà impostata non coincida con il nome della proprietà di cui tenti la lettura.

Se puoi incolla il codice così vediamo.