Name: rlT66838			Date: 03/30/2000


java version "1.2.2"

Please see Bug 4091380

We have a classpath length of over 3000 characters in our development
environment. This is because of fully qualified paths to many different third
party and internal libraries.

You may think this is crazy, but it works in JDK1.1.8.

Already closed bug 4091380 provided a work around for this which we could live
with, but only for jar javac and javah. What were they thinking? Just add this functionality 
for all the tools. (and while you are at it, why does does javap use -bootclasspath
instead of -Xbootclasspath...)

Perhaps most people don't hit this because on Win32 command/cmd have lower
limits but this really isn't a Win32 limit. More reasonable tools like sh and
perl actually do allow longer strings, which is how we've gotten as far as we
have.
(Review ID: 103050) 
======================================================================

The @file implementation currently prevents -J options from working in
argument files for javac or javadoc.  This prevents users from having
@file as a uniform place to put all command line options.  
Implementing @file in the launcher would not only fix this, 
but would also simplify javac and javadoc, as they would no longer have to 
do this processing.
doug.kramer@Eng 2001-03-16

Name: rl43681			Date: 11/28/2001


Java(TM) 2 Runetime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

I am running Java applications as services on a Windows NT server.  The command
line is not long enough to hold the entire command, once the -classpath text is
added.  java.exe needs the ability to read command-line parameters from a file,
with an @filename parameter.

I classify this as a bug because the addition of Oracle database drivers
increased the command line length sufficiently to break existing applications
(Review ID: 136466)
======================================================================
###@###.### 2004-11-11 22:24:44 GMT