support for sometimes-required, sometimes-not-required params #12

ryonday opened this Issue Apr 17, 2012 · 12 comments


None yet
4 participants

ryonday commented Apr 17, 2012

I love this library, but I've had to write a lot of gross, hacky code to support the following use case.

I have several small application where sometimes a certain parameter will be required, let's say a username, and sometimes it should NOT be required depending on whether or not another param exists.

Let's say we're getting a file, and the app supports both HTTP and FTP. For HTTP we might not need a username and password and for FTP we almost always would. It would be nice to specify that if FTP is specified, username and password must also be specified. Otherwise, they are optional.


pholser commented Apr 17, 2012

I've held off on features like this for a while, because I didn't want to overcomplicate the API. However, now that OptionSpecs are part of the API, I'm interested in seeing about doing this.

What about something like:


requiredIf() could be overloaded to accept OptionSpecs as well as string representations of options.

Can you imagine a scenario in which a given option might become required if one of several different options are present on the command line?

Mrc0113 commented Jun 4, 2012

This would also be useful in the case of a "-h or --help" option to print the help/usage screen...maybe someway to assign a "help" option that doesn't require any other options with it...


pholser commented Jun 4, 2012

I'm open to the possibility of adding this feature. I'd like to get a sense of what API makes sense for the most requesters. I'm thinking of the above...maybe:

ArgumentAcceptingOptionSpec.requiredIf(String required, String... otherRequireds)
ArgumentAcceptingOptionSpec.requiredIf(OptionSpec<?> required, OptionSpec<?>... otherRequireds)

What do you think of this?

@Mrc0113, can you elaborate some more on the idea of a "-h" or "--help" option that doesn't require options with it?

Mrc0113 commented Jun 4, 2012

If I have a class that requires several options I want the ability to be able to display the command line help without the user having to include all the required options. (they may need to view the command line help to understand what the required options are)

For example, right now I might have a class that requires 3 options [and also has a 'help' option which tells me to parser.printHelpOn(System.out);] but if the user types this:

java -cp .:jopt-simple-4.3.jar blah.blah.Main --help

He will currently get this:
joptsimple.MissingRequiredOptionException: Missing required option ['option1', 'option2', 'option3']

I'm not sure of the best way to do this...either be able to specify a "printHelpOn" option or give the ability to ignore required options in some cases....I could see that maybe being useful if someone wanted to include a -version option as well.

Mrc0113 commented Jun 5, 2012

@pholser, I guess I didn't answer your first question above; but yes I do like the idea of having a .requiredIf option. I think that solves the issue this thread was opened for and could possibly be used for my issue of not having a way of just specifying the help option when other options are required (I'd just have to tie all the other options together using requiredIf)


pholser commented Jun 5, 2012

Right on. I may tackle the help option bit under separate cover.


pholser commented Jul 3, 2012

I've added #14 to track the bit about designating a "help" option that doesn't cause JOpt Simple to raise an exception if present but no "required" options are.

Thanks for #14 - I waited for it too. Do you plan to update ?

Great library, by the way.


pholser commented Sep 18, 2012

@MarkKharitonov Thanks! I'd like to get a couple more features in before declaring a 4.4 beta.


pholser commented Oct 11, 2012

@ryonday @Mrc0113 There is a 4.4-SNAPSHOT jar deployed at -- if you have a minute, feel free to test-drive requiredIf().


pholser commented Nov 20, 2012

Available in 4.4 beta 2

pholser closed this Nov 20, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment