Review request: 8003562: Provide a command-line tool to find static dependencies (original) (raw)
Ulf Zibis Ulf.Zibis at CoSoCo.de
Tue Dec 18 17:06:14 UTC 2012
- Previous message: Review request: 8003562: Provide a command-line tool to find static dependencies
- Next message: Review request: 8003562: Provide a command-line tool to find static dependencies
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: Review request: 8003562: Provide a command-line tool to find static dependencies
- Next message: Review request: 8003562: Provide a command-line tool to find static dependencies
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]