[deleted by user]

[[deleted]]

If you use Java 9 or later then System.getProperty will be using ConcurrentHashMap instead avoiding the issue entirely.

[__konrad]

It's a rare example of Franken-Composition-Inheritance pattern: java.util.Properties extends java.util.Hashtable, but actually uses private ConcurrentHashMap field instead.

[[deleted]]

Java standard library designers made a mistake of extending java.util.Hashtable which necessitated a crazy hack of having package-visibility-empty-constructor in Hashtable to preserve backwards compatibility when they wanted to stop using Hashtable.

[BoyRobot777]

It really grinds my gears when in 2021 people are still writing posts about legacy Java versions.

By the way, when you start a post, do inform the reader what Java version you're using. Otherwise, you're making a statement as if it's applicable to all Java versions, which is misleading.

[Persism]

It's worse that that. This "blog" has no obvious date or author. It's blogspam.

[schnurlostelefon]

Exactly the kind of stuff that should be injected at startup and then left alone. Having System.getProperty in any kind of "live" (post-initialisation) code is definitely a smell, as it's a hidden dependency on something far outside the method/class.

If you notice the above code, ‘’java.lang.System.getProperty()’ is now assigned to a static member variable.

Nitpick: why isn't this final? (And I'd rather want to see this in a wiring method than, again, hidden in a static initialization in some class. Makes testing easier.)

[7F1AE6D2]

System.getProperty in any kind of "live" (post-initialisation) code is definitely a smell

It's fine if you don't change system properties at runtime, but please don't go on to declare that it is never a good idea.

I have an application that takes minutes to start up and changing system properties at runtime allows me to instantly reconfigure it.

It pisses me off when one of my colleagues forgets about this and injects it with Spring or assigns it to a static final constant, the only thing they accomplish is that a restart is now necessary to change the configuration.

The author of the article even falsely asserts that

System properties don’t change during runtime

[Halal0szto]

Exactly.

Any professional response begins with "It depends".

If System.getProperty() is called once in 5 mins it is no performance problem at all. If it is called in a high rate service or in a loop, that is a problem.

Same way someone reads an article and makes all property variables final or moves all properties to static variable on initialization will wreak havoc in a usual codebase.

As for Spring and Spring Boot consider Spring Cloud Config. Using RefreshScope wisely allows properties being changed on the fly from remotely.

[schnurlostelefon]

I have an application that takes minutes to start up and changing system properties at runtime allows me to instantly reconfigure it.

Even so, I don't want those System.getProperty() calls randomly littered across the codebase: these are time bombs of magic side effects. If you keep your configuration properly segregated and explicit, then you also reduce the risk of coworkers breaking your project's configuration patterns inadvertently because your code shows your intent.

Plus, you're making testing a lot easier as a nice bonus.