United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4344368 : Compiler support for variable length argument lists

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Affected Versions:
Fixed Versions:
5.0 (tiger)

Related Reports

Sub Tasks

Name: skT45625			Date: 06/08/2000

java version "1.2.2"
Classic VM (build 1.2.2-L, green threads, nojit)

Quite often I find that the best, most efficient way to code certain types of
methods is to code them using variable length argument lists.  This
functionallity would be nice to have in Java.  It is occassionally adequate to
use method overloading to get the same functionality as variable length argument
lists, but many times the types and number of the parameters to be passed are
not known at the time the code is written.  Code is also much easier to maintain
if all of it is in one method instead of spread throughout dozens of overloaded
methods.  Believing that method overloading can always supply the same
functionallity as variable length arguments is quite naive I have found.

The classic example of the necessity for variable length arguments is the printf
function in C.  Neither the number nor the types of the arguments are known in
advance.  I have found many other times when this is the case.

Unlike C, Java has a built-in mechanism which would be quite adequate to support
this feature.  All that would be needed is the addition of one keyword (or use
of a currently unused reserve word) and support in the compiler. The keyword
would be needed to denote the point in the argument list where the variable
aspect takes affect.  The compiler would then know to take all the remaining
arguments and "wrap" them in an Object array.  The user could also specify a
name after this "variable length keyword" which would be the name of the
Object[] that is created.  In this way, no extra keyword would be needed for the
name of this array.  There would also need to be _no_ change to the class file
format to support this, as it would simply look like another parameter passed to
the method.  If no "optional" parameters are passed, the compiler would simply
create a zero length array.

So an sprintf like function in Java may look like the following:

public String sprintf(String format, VARLIST params);

The method would then parse the format string to find the type of the parameters
and proceed from there.  Of course, all native types would need to be wrapped in
one of the java.lang classes.

The user could then check the length of the array to find out the number of
extra parameters, and could use some mechanism built-in to the other parameters,
or the Java instanceof keyword to look for expected types.

Such functionality would greatly enhance the ability to write and maintain
efficient code.
(Review ID: 105913) 



JSR-65 was withdrawn.  Support for variable length argument lists was added to Tiger (jdk5.0) under JSR-201: 
A complete description of this language feature may be found in the Java Language Specification, Third Edition, section "Formal Parameters", see the paragraph regarding variable arity parameters. 

Name: skT45625			Date: 06/08/2000

The workaround is quite painful, but doable.  You must declare a method that has
all non-optional arguments and a method that has all these arguments plus an

The user would then need to wrap any optional arguments an an Object[] as

foo(a,b,new Object[] { c,d,e });

It would be nice if the compiler could do the object wrapping for you.

There is one other extremely awkward way to overcome this problem.  But again,
this method would spread functionality throughout many different methods.  You
could simply make a method with all non-optional parameters.  Then make another
method which adds one parameter of type Object.  You could keep adding Objects
until you have as many as you anticipate.  This would look something like this:

foo(int a);
foo(int a, Object b);
foo(int a, Object b, Object c);
foo(int a, Object b, Object c, Object d);
etc, etc

This is also painful for the user because they must wrap native types in the
java.lang wrappers.  The method I outlined would do this for them.  This method
also has the limitation (which, granted probably isn't much of a limitation, and
I would hate to read the code where it became limiting) of only being able to
take 256 parameters (255 for non-static methods), due to the limitation of the
VM.  Whereas, a variable argument list could support more than 256 parameters.

This is being addressed by JSR-65, "Concise Object Array Literals".

This is being addressed by JSR-65, "Concise Object Array Literals".

gilad.bracha@eng 2000-06-26

Hardware and Software, Engineered to Work Together