Bug ID: JDK-4230619 (process) Need access to unparsed command line arguments

Type: Enhancement
Component: core-libs
Sub-Component: java.lang
Affected Version: 1.1.6

Priority: P4
Status: Closed
Resolution: Not an Issue
OS: generic
CPU: generic

Submitted: 1999-04-17
Updated: 2006-11-20
Resolved: 2006-11-20

Name: gb36485			Date: 04/16/99


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)
======================================================================

EVALUATION 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
20-11-2006
EVALUATION 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
20-11-2006
EVALUATION After one vote in seven years, I think it's time to close this request.
20-11-2006
WORK AROUND Name: gb36485 Date: 04/16/99 A native DLL on Win32 using the Win32 function 'GetCommandLine()'. ======================================================================
11-06-2004
EVALUATION I doubt if we want to encourage this sort of thing. gilad.bracha@eng 1999-04-17
17-04-1999

Relates :	JDK-6468220 - (process) Runtime.exec(String[]) does not pass command line arguments correctly (win)
Relates :	JDK-6276512 - (process) Runtime.exec(cmd[]) ignores quotes around arguments (win)