Java System.getProperty vs System.getenv

1. Introduksjon

Pakken java.lang importeres automatisk når det er i et Java-program. Denne pakken inneholder mange ofte brukte klasser fra NullPointerException til Gjenstand, Matte, og String.

De java.lang.System klasse er en endelig klasse, noe som betyr at vi ikke kan underklasse den, derfor er alle metodene statisk.

Vi skal se på forskjellene mellom to System metoder for lese systemegenskaper og miljøvariabler.

Disse metodene er getProperty og getenv.

2. Bruke System.getProperty ()

Java-plattformen bruker en Eiendommer objekt å gi informasjon om det lokale systemet og konfigurasjonen og vi kaller det System egenskaper.

Systemegenskaper inkluderer informasjon som den nåværende brukeren, den gjeldende versjonen av Java-kjøretiden og skillelinjen for filsti.

I koden nedenfor bruker vi System.getProperty (“log_dir”) for å lese verdien av eiendommen log_dir. Vi bruker også standardverdiparameteren, så hvis eiendommen ikke eksisterer, getProperty retur av /tmp/Logg:

Streng log_dir = System.getProperty ("log_dir", "/ tmp / log"); 

For å oppdatere systemegenskaper ved kjøretid, bruk metoden System.setProperty metode:

System.setProperty ("log_dir", "/ tmp / log");

Vi kan overføre våre egne egenskaper eller konfigurasjonsverdier til applikasjonen ved hjelp av eiendomsnavn kommandolinjeargument i formatet:

java -jar jarName -DpropertyName = verdi

Angi eiendommen til foo med verdien bar i app.jar:

java -jar app -Dfoo = "bar"

System.getProperty vil alltid returnere a String.

3. Bruke System.getenv ()

Miljøvariabler er nøkkel- / verdipar som Eiendommer. Mange operativsystemer bruker miljøvariabler for å la konfigurasjonsinformasjon overføres til applikasjoner.

Måten å sette en miljøvariabel på er forskjellig fra ett operativsystem til et annet. For eksempel i Windows bruker vi et System Utility-program fra kontrollpanelet mens vi bruker Unix shell-skript.

Når du oppretter en prosess, arver den som standard et klonmiljø fra den overordnede prosessen.

Følgende kodebit viser bruk av et lambdauttrykk for å skrive ut alle miljøvariabler.

System.getenv (). ForEach ((k, v) -> {System.out.println (k + ":" + v);}); 

getenv () returnerer en skrivebeskyttet Kart. Å prøve å legge til verdier på kartet kaster en Ikke-støttetOperationException.

For å få en enkelt variabel, ring getenv med variabelnavnet:

Streng log_dir = System.getenv ("log_dir");

På den annen side kan vi lage en ny prosess fra applikasjonen vår og legge til nye variabler i miljøet.

For å lage en ny prosess i Java bruker vi ProcessBuilder klasse som har en metode som kalles miljø. Denne metoden returnerer a Kart men denne gangen er ikke kartet skrivebeskyttet, noe som betyr at vi kan legge til elementer i det:

ProcessBuilder pb = ny ProcessBuilder (args); Map env = pb.environment (); env.put ("log_dir", "/ tmp / log"); Prosessprosess = pb.start ();

4. Forskjellene

Selv om begge er i hovedsak kart som gir String verdier for String tastene, la oss se på noen forskjeller:

  1. Vi kan oppdatere egenskaper ved kjøretid mens miljøvariabler er en uforanderlig kopi av operativsystemets variabler.
  2. Egenskaper er bare inneholdt i Java-plattformen, mens miljøvariabler er globale på operativsystemnivå - tilgjengelig for alle applikasjoner som kjører på samme maskin.
  3. Egenskaper må eksistere når du pakker applikasjonen, men vi kan opprette miljøvariabler på operativsystemet på nesten ethvert tidspunkt.

5. Konklusjon

Selv om det er konseptuelt likt, er anvendelsen av både egenskaper og miljøvariabler ganske annerledes.

Valget mellom alternativene er ofte et spørsmål om omfang. Ved å bruke miljøvariabler kan den samme applikasjonen distribueres til flere maskiner for å kjøre forskjellige forekomster og kan konfigureres på operativsystemnivå eller til og med i AWS eller Azure Consoles. Fjerner behovet for å gjenoppbygge applikasjonen for å oppdatere konfigurasjonen.

Husk det alltid getProperty følger kamelkoffertkonvensjonen og getenv gjør ikke.


$config[zx-auto] not found$config[zx-overlay] not found