2012-01-23 8 views
10

È possibile utilizzare gli argomenti -Dproperty=value per impostare le proprietà arbitrarie del sistema (non alcune serie fisse di proprietà di sistema effettivamente utilizzate dalla JVM) e un programma può ottenere queste proprietà in seguito utilizzando System.getProperty("property"). È corretto farlo?È corretto utilizzare le proprietà del sistema Java per impostare e ottenere parametri di programma arbitrari?

Non ho trovato una risposta autorevole su questo, ecco perché sto chiedendo qui. Mi sembra che i parametri del programma dovrebbero essere impostati tramite gli argomenti della riga di comando al programma, non alla JVM. Tuttavia, forse questa è una pratica accettata che non è documentata da nessuna parte che ho visto finora. Mi piacerebbe esserne sicuro. Grazie.

risposta

1

A mio parere questo non è "errato" e ci sono programmi e librerie che utilizzano le proprie proprietà di sistema per la configurazione.

Tuttavia, è probabilmente più pratico per mettere i parametri di configurazione per il vostro software in un file di configurazione (in qualsiasi formato che pensi sia adatto - un file .properties, un file XML, o qualcos'altro). È ingombrante, soprattutto se si dispone di molti parametri di configurazione, di dover mettere tutti i parametri sulla riga di comando con le opzioni -Dname=value.

+0

Concordato, ma questi potrebbero anche essere utilizzati per specificare uno o due o una manciata di file di proprietà (come vengono utilizzati in questo caso). Non dovrebbero essere solo argomenti da linea di comando? Posso vedere che usare le proprietà del sistema in questo modo è utile e flessibile, sono solo interessato a sapere se c'è qualche giustificazione per questo o se è una sorta di uso accettabile specificato, o se è semplicemente successo e diventa un modello. –

+0

C'è qualche documentazione sul fatto che questo sia un uso accettabile o supportato? –

+0

È supportato; la documentazione dell'API Java non ti avvisa di non usarlo. Perché hai bisogno di una risposta "autorevole" e chi è l'autorità è abbastanza buona da fidarti? – Jesper

0

È possibile utilizzare questo metodo per impostare alcune delle impostazioni dell'applicazione. Penso alle impostazioni in contrasto con gli argomenti del programma. Per esempio. Pensiamo a qualche convertitore di file. Converte i file da A a B. Quindi i file A e B dovrebbero essere parametri della riga di comando. Se il tuo convertitore ha bisogno di una cartella temporanea, puoi rendere l'ID impostabile da -Dmy.package.tempfolder=\my\tmp\folder. Ma ci dovrebbe essere un'impostazione predefinita per questo e il programma dovrebbe funzionare senza questa impostazione.

Pensateci come alternativa al file .properties. Il file .properties sarà sicuramente più conveniente.

+0

Perché non impostare la cartella utilizzando un terzo parametro della riga di comando anziché utilizzare una proprietà di sistema? –

+0

Sono interessato a sapere perché questi sono considerati "impostazioni del programma" quando sono in realtà proprietà del sistema JVM. Teoricamente potrebbero scontrarsi con le future proprietà del sistema JVM, o una JVM potrebbe ignorare quelle che non vengono utilizzate, e questo sarebbe solo un comportamento indefinito per un uso non intenzionale. –

+0

Pensateci come un'impostazione come massimo heap di memoria JVM, livello di registrazione ecc. Ciò non modifica la logica del vostro programma, ma semplicemente cambia l'ambiente. Naturalmente puoi aggiungere il terzo parametro della riga di comando, ma perché dovresti complicare l'API dei programmi se solo il 2% degli utenti lo userebbe? –

2

Penso che le proprietà del sistema Java vengano utilizzate per trasferire i valori dalla riga di comando alle librerie o ai plugin all'interno dello nell'esecuzione. È, quel componente insider non ha modo diretto di ricevere il parametro dal programma principale che lo sta eseguendo. Così legge da un "contesto" le proprietà del sistema Java.

Se li consideriamo come livelli, gli argomenti della riga di comando sarebbero parametri per il livello inferiore immediato e le proprietà Java del sistema sono contesto per tutti i livelli inferiori.

command line: arguments + properties 
    main program: uses arguments 
     some library/plugin: uses properties from context 

Se non è questo modo il programma principale dovrebbe avere per trasportare tutti i parametri che l'utente potrebbe fissati agli strati inferiori e può essere molto ingombrante.

Non mi piace dipendere dalle proprietà contestuali, quindi se progetto un programma proverei a passare tutte le proprietà in un modo non globale. Ma può essere molto utile alcune volte (e usando il namespace non è probabile che si scontrino).

+0

Sono d'accordo con questa linea di ragionamento. Tuttavia, solo per mettere davvero l'ultimo chiodo in questa cosa, c'è qualche documentazione che dice che questo uso è accettabile o che è noto e continuerà ad essere supportato dalla JVM? –

+0

Nessuna idea. Dovrebbe essere bello avere qualche guida su come farlo bene :) – helios

0

Devi solo sapere cosa stai facendo. Se la tua applicazione è una applicazione standalone, le proprietà di sistema forniscono un modo facile da usare per passare argomenti con nome, in qualsiasi ordine, al programma, e non vedo nulla di intrinsecamente cattivo nell'usarli.

Se la tua app è una webapp che deve essere distribuita in un app server condiviso da più webapp, allora potrebbe non essere una buona idea, specialmente se non ti è permesso cambiare il modo in cui il server è avviato, o se Devo distribuire più versioni della stessa applicazione.

0

Da http://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html:

Ad esempio, la seguente invocazione di getProperty guarda la proprietà sistema chiamato subliminal.message. Questa non è una proprietà del sistema valida , quindi, anziché restituire null, questo metodo restituisce il valore predefinito fornito come secondo argomento: "Acquista StayPuft Marshmallows!"

System.getProperty("subliminal.message", "Buy StayPuft Marshmallows!");

Questo implica che le proprietà diverse da quelle utilizzate dalla JVM sono "non valido". Tuttavia, più avanti nello stesso documento, fornisce l'esempio del caricamento di un file di proprietà contenente la stessa impostazione di proprietà.

subliminal.message = Acquista Marshmallow StayPuft!

Si consiglia solo "In generale, fare attenzione a non sovrascrivere le proprietà del sistema."

Quindi sembra che questo sia un uso supportato delle Proprietà di sistema. Sembra un caso di nomi fuorvianti. Quando sento "Proprietà del sistema" penso "proprietà della JVM" dove la JVM è il sistema. Mentre le proprietà vengono utilizzate per questo, possono anche essere utilizzate per le impostazioni dell'applicazione. Penso che prenderò una nota mentale per pensare a questo come "Proprietà del sistema e dell'applicazione".

Qualcuno non è d'accordo con questo?

Problemi correlati