Review request: 8003562: Provide a command-line tool to find static dependencies

[Ulf Zibis]

Am 18.12.2012 05:15, schrieb Mandy Chung:
> On 12/17/12 8:13 AM, Ulf Zibis wrote:
>> Am 17.12.2012 16:23, schrieb Alan Bateman:
>>> I mostly agree with your argument that this is a new tool and that we should be consistent with 
>>> GNU-style options. So what was the final bid is, is it --classpath or --class-path?
>
> I propose --class-path so that it makes it easier to determine -classpath is not supported

I have some objections against --class-path and vote for --classpath. Reasons:
- -classpath is easier to type in
- -classpath matches better with environment variable CLASSPATH
- I'm not sure if the term "classpath" is really wrong in english grammar. Looking into the docs, 
term "classpath" is in use, but less than "class path":
http://docs.oracle.com/javase/6/docs/technotes/tools/windows/javac.html
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/java.html
http://docs.oracle.com/javase/7/docs/technotes/tools/windows/classpath.html
- people are familiar with "classpath"
- there are similar options/terms that then also need to be changed, if some day we would adopt all 
other existing tools to GNU-style. E.g. --boot-class-path IMO looks bad and could semantically be 
interpreted as "boot the class path" or "path of the boot class".
- the '-' separator usage in GNU commands and options I only know, where a verb has to be separated 
from a subject, e.g. "update-grub", but maybe there are contradictory examples. ...And there are 
examples, where even verbs are not separated from subjects, e.g. "grub-mkconfig", which should be 
"grub-mk-config" according the rule.

What about allowing (maybe define for preferred usage) GNU/UNIX path separators even on Windows? E.g.
java --classpath=C/java/jre6/lib/rt.jar ...
- This would make java again more platform independent.
- The mixure of UNIX and/or GNU-style options with Windows path syntax looks ugly to me.

Additionally we also have a 3rd style in use, e.g. "java mypackage.MyClass".


>>> I guess it wouldn't do any harm to silently supporting -cp and -classpath as folks used to java* 
>>> tools will probably use them without thinking.
>>
> How important to carry the same option -cp and -classpath on j* tools?  I do think developers can 
> well adapt to a slight different option when using a new tool.  I'm inclined not to mix these 
> styles.  In addition, I'd like to see how jdeps will be used after the initial push and people 
> finds --class-path hard to move to.

My vote:
silently support old style with space as separator and document this as a side note on:
http://docs.oracle.com/javase/6/docs/technotes/tools/windows/jdeps.html

>
>> Thanks for supporting my arguments about "silent familarity" to old style, Alan.
>> As --class(-)path is a frequent and important option, I additionally think, we should have an 
>> official short form. If '-cp' doesn't conform with GNU-style, what about '-C' ?
>
> I considered '-C' and it might be confused with 'jar -C' and 'tar -C' option to change the 
> directory.  I think '-c' may be okay and it can avoid such confusion and closer to '-cp'.   Are 
> you okay with that?

I agree! "-C" was from my non-reflected guess, that '-c' would be yet occupied, as you didn't 
consider a short form from the beginning. Thanks for your closer look.

-Ulf