Duplicate system property declarations in JVM launcher arguments are treated silently. The last declaration of a system property in such launcher args is the one that's used. This is long standing practice.

A recent issue cost developers cycles when expected application behavior was not observed and a JDK bug was assumed. Take for example a smaller example of properties listed in an imaginary application's launcher arguments: (the production app had 100's of system properties in launcher args)

*******

-Xmx16384m -Xms16384m -cp /somepath/libs/launcher.jar \
-Dsunshine.env.classpath=true \
-Dserver.instance.name=oracorn_flare1 \
-Djdk.serialFilter=package=com.mynewcompany.*
-Djava.security.policy=/somepath/libs/security.policy \
-Dserver.identity.file=/somepath/domains/flaredomain/servers/oracorn_flare1/data/node/key.bin \
-Dnode.service.enabled=true \
-Dnode.service.rotation.enabled=true \
-Dpipeline.cache.preload=ENABLED \
-Dpipeline.cache.size=2048 \
-javaagent:/agents/wizardtrace/javaagent.jar \
-Dwizardtrace.application.name=Primrose-App \
-Dwizardtrace.tier.name=CORE-Tier \
-Djdk.serialFilter=package=com.mycompany.*
-Dwizardtrace.node.name=oracorn_flare1 \
-Dwizardtrace.ssl.validation.skip=true \
-Djava.system.class.loader=com.generic.custom.ClassLoader \
-Dcustom.protocol.handlers=sunshine.protocol|pixie.dust.handler|rainbow.uddi.handler|cloud.fs.protocol


*******
The arguments may look fine but the "jdk.serialFilter" property is defined twice. As a result the "-Djdk.serialFilter=package=com.mynewcompany.*" setting is silently ignored and application developers are left wondering why their application isn't working correctly.

Can functionality be added to the JDK to detect this anomaly ? Perhaps a warning in the jcmd VM.info, VM.system_properties or VM.command_line could be issued to alert the end user ? Perhaps a warning in -XshowSettings could also be considered.