BT

Oracle Paves the Way to Standardise Command Line Options in the JDK

| by Abraham Marín Pérez Follow 8 Followers on Jul 27, 2016. Estimated reading time: 2 minutes |

Jonathan Gibbons, Lead for the Java SE Language Tools Team at Oracle, has created JEP 293 to introduce a set of guidelines for command line options in JDK tools in an attempt to fix the existing disparity among them. The JEP has no target version yet, meaning it will be delivered with Java 10 as soonest; however, taking into account that the scope is only to create a set of guidelines for new options, not to modify existing options, it may take even longer for the effects to be felt.

As indicated in the JEP itself, the different tools in the JDK have evolved to include command line options that are not aligned with each other. For instance, short options are sometimes one letter (like the new -p to indicate a module) and sometimes more than one (like the existing -cp to indicate the classpath). Also, the same option may be invoked in different ways depending on the tool, like -version for javac but --version for pack200 (note the double dash on the second case). This complicates the creation of utilities that work on top of JDK tools, and creates an additional barrier for new developers that try to get acquainted with the command line options.

In order to fix this situation, the new JEP will create a set of guidelines for new command line options resembling UNIX-style and largely based in getopt(3). Although the full set is available in the documentation, the guidelines that are more likely to be relevant to the everyday user are:

  • Options should have a long and a short format. Short format is compounded by one dash and one letter, long format by two dashes and then as many letters and dashes as needed.
  • Short options can be grouped, e.g., -m -k would be the same as -mk.
  • Options may have an optional parameter.
  • Help should be obtained the same way in all tools.

In line with the spirit of backwards-compatibility, the JEP states that the guidelines are to be applied for new command line options, but not necessarily for the existing ones. This means that some or all of the current options may never be removed, even if they don't meet the guidelines. Moreover, new guideline-abiding options may be provided to work together with existing ones, meaning that some functionalities will have both legacy and new command line options. Although this sounds like a good compromise between backwards-compatibility and improvement, some have already pointed out in the discussion group that hard-to-resolve ambiguities will arise as a result. As conversations progress, it is likely that the guidelines themselves are modified to adapt to these issues.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT