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.