[lsb-discuss] Java

Ron Hale-Evans rwhe at ludism.org
Wed Jul 2 14:36:51 PDT 2008


Thanks for your quick and helpful feedback, Joe. Responses below.

On Wed, Jul 2, 2008 at 1:16 PM, Joseph Kowalski <jek3 at sun.com> wrote:
>
> I'll send my shot at the pruning.  It will be a little bit different than
> yours.
>
> However, we seem to have a major issue with GNU argument option syntax.
>
> Java has a rather unique command line syntax.  It's not POSIX, its not CLIP
> (Sun pseudo standard - POSIX extension, but in the flavor of GNU), its not
> GNU (should I mention GNU is not unambiguous?), its just Java's.

GNU = GNU's Not Unambiguous? ;)

> There are a couple of significant differences.
>
>   1)   There are *no* single character options.

What about "--?" ? Or are you counting the dashes as characters?

>   2)   All option arguments are delimited by ":".  Not " " (POSIX) or " " |
> "=" (GNU).

That's interesting. I don't know how it would affect the spec, if at
all. Can someone more knowledgeable jump in here, please?

>   2a)  Yea, the "cp" | "classpath" is unique.  Its just history.
>
>   3)   To characterize agentlib as baroque is an understatement.
>
> However, we maintain these options (as they are) because they span multiple
> platforms (in the Windows, Linux, Solaris, MacOS,... sense).

Noted.

> Ron Hale-Evans wrote:
>> Page 1:
>> client, server: OK
>>  Page 2:
>> agentlib, agentpath: baroque
>>
>
> How about, "dev-only"?

That suits me. I was considering marking it as both. It also falls
into the baroque category, as you noted above. But spec readers will
never see how we categorize them, so as long as we agree it shouldn't
be part of the spec, it doesn't make much difference.

>> classpath, cp, Dproperty=value, d32, d64: OK
>>
>
> d32, d64 fall away because the LSB doesn't provide a standard for supporting
> multiple ISAs.

Noted.

>> Page 4:
>> verbose: OK
>> verbose:* - dev-only
>>
>
>
> I don't see how verbose is "OK" while "verbose:*" are dev-only.  Its one or
> the other.

I take your point. My rationale was that a Java user might want to see
all messages to get an idea why a Java app was crashing, but wouldn't
necessarily want to fuss with narrowing it down, so --verbose:* was
complicating usability unnecessarily.

At this point, I would be OK with using both --verbose and
--verbose:*, neither, or just the first, as I suggested. Does anyone
else have comments?

>> version: OK
>> version:release: OK, but limited to functionality in Notes section on p.7
>>
>
> Not functionality; policy.  The NOTES are just to warn "there is rope here"
> and if you go beyond the policy you may find that you have hung yourself
> with that rope.

Again, here's my rationale. The LSB is writing a specification for the
java executable and its behavior. I am suggesting /specifying/ only
the behavior in the Notes section. That is, only that behavior is
mandatory for the --version:release option. If Sun or whoever else is
writing a java executable wishes to extend that functionality, that's
fine, but only the specified behavior should be mandatory.

Does that make sense?

>> showversion, ?, help: OK
>>
>
> Actually, showversion is deprecated.  (Its a bug that its not called out in
> the man page.)
>
> Just use version.

Noted.

>> Pages 4-7:
>> All options in the Non-Standard Options section: non-std
>>
>
> But, there should be an entry that any option starting with -X is
> non-standard.  Maybe this is only of interest to JVM vendors, but its cheep
> and helpful.

I think that's fine.

Here is the revised list of suggested options:

--?
--Dproperty=value
--classpath
--client
--cp
--help
--jar
--server
--verbose (maybe)
--verbose:* (maybe)
--version
--version:release (specify only the functionality in the Notes section on p.7)

Ron



More information about the lsb-discuss mailing list