Currently the Java run-time returns an array of strings to a
Java application no matter what the user enters on the command
line.

This it not desired. I want to be able to give my users proper
feedback about errors they have made, so they understand what
they did wrong.

I know command-line arguments are not 100% pure, and I will
ensure that I do not rely on them for critical parameters. This
applies to GUI applications. There are a lot of platforms which
do have a command line interface and I want to write programs for
this interface too. One requirement for this is that I can
reliably and consistently parse the command line.

I would prefer a static method being added to the System class
Which returns the command line. This method would return the
UNPARSED string entered on the command line AFTER the name
of the class. The whitespace between the first non-whitespace
character and the class name MAY be removed.

The application can not found out which VM and which VM
parameters were used to start it.
(Review ID: 57009)
======================================================================
Posted Date : 2006-11-20 14:20:44.0

A native DLL on Win32 using the Win32 function
'GetCommandLine()'.
======================================================================

I doubt if we want to encourage this sort of thing. 

  xxxxx@xxxxx   1999-04-17
After one vote in seven years, I think it's time to close this request.
Posted Date : 2006-11-20 14:20:44.0

Moving to classes_lang; this is a process-related RFE.

It's true that there's an impedance mismatch between the Java API's
view of the world (that command line arguments are a String[])
and the Windows view of the world (that command line arguments are a String)
and this mismatch is a source of confusion in the process-related API
like Runtime.exec and the launcher itself.

This mismatch is very subtle, cannot be solved without introducing an
extremely confusing parallel API using String in addition to String[],
with each having primacy on different operating systems.

It's actually worse than that:
- on Unix, the native command line is effectively a byte[][]
- on Windows, the native command line is effectively a String

and both suffer from subtle data loss on conversion to String[].

We chose not to address similar issues for File I/O and environment variables.
We will do the same here, and not provide complete access to the native representation.

See also:
6468220: (process) Runtime.exec(String[]) does not pass command line arguments correctly (win)
6276512: (process) Runtime.exec(cmd[]) ignores quotes around arguments
Posted Date : 2006-11-20 17:27:33.0

The "real" Windows command line is available via GetCommandLine,
which is documented here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/getcommandline.asp
Posted Date : 2006-11-20 18:53:56.0

The reason I posted this article is that I want to write command-line tools. I
know these tools are not compatible with all operating systems, but there are a
lot of operating systems which do support them.
Being able to correctly parse a command line  is a necessity to make
command-line tools accepted. The arbitrary way the command line is split up
into separate arguments at this moment, which always succeeds, is not good
enough.
The suggestion in the Java Tutorial to be POSIX-compliant when you do want to
support the command line can not even be implemented in a robust manner.