You might have already guessed that Java system properties are consumed by a similar mechanism that is used for environment variables, and you would be correct. The only real difference is the implementation of PropertySource. This time, a more generic MapPropertySource implementation is used by StandardEnvironment.

What you have also probably noticed is the need to launch our application using the java -Dmy.config.value="From System Config" -jar ./build/libs/bookpub-0.0.1-SNAPSHOT-exec.jar command instead of just simply invoking the self-executing packaged JAR by itself. This is because, unlike the environment variables and command-line arguments, Java system properties have to be set on the Java executable ahead of everything else.

We did manage to work around this need by effectively hardcoding the values in our build.gradle file, which, combined with the enhancements that we made to launch.script, allowed us embed the my.config.value property in the command line in the self-executing jar, as well as use it with the Gradle's bootRun task.

The risk of using this approach with the configuration properties is that it will always override the values that we set in the higher layers of the configuration, such as application.properties and others. Unless you are explicitly constructing the Java executable command line and not using the self-launching capabilities of the packaged JAR, it is best not to use Java system properties and consider using the command-line arguments or environment variables instead.