Java System.getProperty versus System.getenv

1. Inleiding

Het pakket java.lang wordt automatisch geïmporteerd in een Java-applicatie. Dit pakket bevat veel veelgebruikte klassen van NullPointerException naar Voorwerp, Wiskunde, en Draad.

De java.lang.System klasse is een laatste class, wat betekent dat we het niet kunnen onderklassen, daarom zijn alle methoden dat statisch.

We gaan kijken naar de verschillen tussen twee Systeem methoden voor het lezen van systeemeigenschappen en omgevingsvariabelen.

Deze methoden zijn getProperty en getenv.

2. Met behulp van System.getProperty ()

Het Java-platform gebruikt een Eigendommen bezwaar te maken informatie over het lokale systeem en configuratie en we noemen het Systeem eigenschappen.

Systeemeigenschappen bevatten informatie zoals de huidige gebruiker, de huidige versie van de Java-runtime en het bestandspadnaamscheidingsteken.

In de onderstaande code gebruiken we System.getProperty ("log_dir") om de waarde van het onroerend goed te lezen log_dir. We maken ook gebruik van de parameter standaardwaarde, dus als de eigenschap niet bestaat, getProperty rendement van /tmp/ log:

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

Gebruik de methode om systeemeigenschappen tijdens runtime bij te werken System.setProperty methode:

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

We kunnen onze eigen eigenschappen of configuratiewaarden doorgeven aan de applicatie met behulp van de eigendomsnaam opdrachtregelargument in de indeling:

java -jar jarName -DpropertyName = waarde

De eigenschap van foo instellen met de waarde bar in app.jar:

java -jar app -Dfoo = "bar"

System.getProperty zal altijd een Draad.

3. Met behulp van System.getenv ()

Omgevingsvariabelen zijn sleutel / waarde-paren zoals Eigendommen. Veel besturingssystemen gebruiken omgevingsvariabelen om configuratie-informatie door te geven aan applicaties.

De manier om een ​​omgevingsvariabele in te stellen, verschilt van besturingssysteem tot besturingssysteem. In Windows gebruiken we bijvoorbeeld een systeemhulpprogramma van het configuratiescherm, terwijl we in Unix shell-scripts gebruiken.

Bij het maken van een proces erft het standaard een kloonomgeving van het bovenliggende proces.

Het volgende codefragment toont het gebruik van een lambda-expressie om alle omgevingsvariabelen af ​​te drukken.

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

getenv () geeft een alleen-lezen terug Kaart. Als je probeert waarden aan de kaart toe te voegen, wordt een UnsupportedOperationException.

Om een ​​enkele variabele te verkrijgen, belt u getenv met de variabelenaam:

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

Aan de andere kant kunnen we vanuit onze applicatie een ander proces creëren en nieuwe variabelen aan zijn omgeving toevoegen.

Om een ​​nieuw proces in Java te maken, gebruiken we ProcessBuilder class die een methode heeft genaamd milieu. Deze methode retourneert een Kaart maar deze keer is de kaart niet alleen-lezen, wat betekent dat we er elementen aan kunnen toevoegen:

ProcessBuilder pb = nieuwe ProcessBuilder (args); Map env = pb.environment (); env.put ("log_dir", "/ tmp / log"); Proces proces = pb.start ();

4. De verschillen

Hoewel beide in wezen kaarten zijn die bieden Draad waarden voor Draad toetsen, laten we eens kijken naar een paar verschillen:

  1. We kunnen eigenschappen bijwerken tijdens runtime, terwijl omgevingsvariabelen een onveranderlijke kopie zijn van de variabelen van het besturingssysteem.
  2. Eigenschappen bevinden zich alleen binnen het Java-platform, terwijl omgevingsvariabelen globaal zijn op het niveau van het besturingssysteem - beschikbaar voor alle toepassingen die op dezelfde computer worden uitgevoerd.
  3. Eigenschappen moeten aanwezig zijn bij het verpakken van de applicatie, maar we kunnen op bijna elk punt omgevingsvariabelen op het besturingssysteem maken.

5. Conclusie

Hoewel conceptueel vergelijkbaar, is de toepassing van zowel eigenschappen als omgevingsvariabelen behoorlijk verschillend.

De keuze tussen de opties is vaak een kwestie van omvang. Met behulp van omgevingsvariabelen kan dezelfde applicatie worden geïmplementeerd op meerdere machines om verschillende instanties uit te voeren en kan deze worden geconfigureerd op het niveau van het besturingssysteem of zelfs in AWS of Azure Consoles. Het verwijderen van de noodzaak om de applicatie opnieuw te bouwen om de configuratie bij te werken.

Onthoud dat altijd getProperty volgt camel-case conventie en getenv doet niet.


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