Java: using system parameters vs "regular" command line options

Question

Let us assume a Java application, accepting an integer command line argument, say bubu.

Assuming one uses a decent command line parser (and I do - https://github.com/jopt-simple/jopt-simple) plus keeping in mind the -D java switch, these are some of the typical ways to pass this command line parameter:

1. --bubu 5 (or --bubu=5 or --bubu5)
2. -Dbubu=5

Where the first one is the program argument and must be handled by the application using some command line parser, whereas the second is the VM argument and is already parsed by java, making it available as Integer.getInteger("bubu")

I am kinda puzzled. What should I use? Using the system property facility:

• seems to cost nothing
• does not depend on any command line parser library
• provides convenient (albeit unexpected) API to obtain the values

As far as I can see, the only cons is that all the command line options have to use the -D flag.

Please, advice.

Thanks.

EDIT

Another pros for the system parameters - "they're usable even when the application is not a stand-alone app starting from a main, but also when the app is a webapp or a unit test." - thanks https://stackoverflow.com/users/571407/jb-nizet

EDIT2

Let me be more focused here. Is there any serious reason (besides esthetics) not to use the system parameters, like always?

EDIT3

OK, I think I get it now. If my code is likely to be loaded by a web application, then there is an issue of a potential name clash, since other web applications hosted by the same web container share the system property space with my code.

Therefore, I have to be prudent and disambiguate my system properties beforehand. So, no more bubu, it is com.shunra.myapp.bubu now. Meaning that instead of a simple

-Dbubu=5

I have

-Dcom.shunra.myapp.bubu=5

which becomes less attractive for a simple command line application.

Another reason is given by Mark Peters, which is pretty good to me.

Answer 1

I feel that there are many things that an average user like me do not need to know. System properties will help the developer of a system preset a number of value that will enable a system to run. For example, when I download GlassFish app server, it always come with many preset parameters that I have no ideas what they're for. I am not very experienced at dealing with server's setting. If you ask me to start GlassFish server with 20 parameters in the command line, I would have to learn what these parameters are for and how much should I set, etc. It's too troublesome.

In brief, when a system gets larger and larger, it may have more and more properties. With system properties preset, users may only need to know what they are when they really need to. For example, I only need to know about GlassFish's -XX:PermSize when I need to increase memory.

Answer 2

I'd argue that the advantage Fortyrunner cites is actually the most significant negative for system properties--they are available to anyone who asks for them.

If the flag or option is meant to be a command-line option, it should be available to the layer or module of your code that deals with taking input from the command line, not any code that asks for it.

You can get some destructive coupling from global state, and system properties are no different than any other global state.

That said, if you're just trying to make a quick and dirty CLI program, and separation of concerns and coupling is not a big concern for you, system properties give you an easy method that however leads to (IMO) poor user experience. Some getopt library will give you a lot more support for building a good CLI user experience.

Answer 3

One of the main advantages of system properties is that they are available at any time during the life of you program.

Command line arguments are only available in the main method (unless you persist them).