Jsr-201 including varargs in public review

Question

Now that jsr-201 has gone into public review I have sent an email about varargs to:
[email protected]
I have included below some of the reasons why I think the Concise Object Array Literals syntax is better than their currently proposed varargs syntax.
They claim that most of the feedback they have got prefers the vararg syntax, I did another search in this forum and it still appears to me that people prefer the Concise Object Array Literals syntax , hence maybe others could also send their comments to [email protected]
* the callee can clearly see that they are passing in varargs
* the callee can pass in many var arg parameters, not just 1 at the end
e.g.
public void foo(int arg1, Object[] arg2, Integer[]) {
public void test() {
  foo(1, {"hello", true, 5, 5L, 5F, 5.0}, {1, 2, 3});
}* the callee can choose to pass in a different number of arguments based on a condition:
e.g.
public void foo(int arg1, Object[] arg2, int arg3) {
public void test() {
  foo(1, condition ? {"hello", true, 5, 5L, 5F, 5.0} : {"hello", true, 5}, 3);
}* the callee can call other 3rd party methods that already exist without having to wait for them to change all their methods to the ... syntax (Concise Object Array Literals is more compatible with existing code)

Answer 1

They claim that most of the feedback they have got
prefers the vararg syntax, I did another search in
this forum and it still appears to me that people
prefer the Concise Object Array Literals syntax ,
hence maybe others could also send their comments to
[email protected]
I don't like varargs, too. Your observation about this forum may be quite simple to explain - people who really understand problems with varargs do not write to these forums. For lots of people, typing extra { and } with concise array literals will not be an issue. However, they consider this extra curly braces "an overhead" and submit feedback that they like varargs syntax more, just because it does not have curly braces. It seems that they do not fully realize consequences or just simply have not spent enough time to think about them. At the first glance, of course, varargs will look more attractive than concise array literals for method calls.
I also object that "varargs are good because they help to see that certain method is interested only in values of array". We have javadoc for this! One can also use Tiger's annotation facility for this. There is no need to invent new syntaxt just for annotation/documentation. I'm alarmed when I read "this is what I like the most about varargs". It means - varargs are no good.
However, it may not be possible to resurrect concise array literals in Tiger due to timing. My opining on this matter is expressed fully in my JSR-201 comment. Here's a copy:
lease, do not include varargs as they currently specified into Tiger.
There seem to be too much controversy between varagrs and concise
array liters at this point. It is evident that a better solution that
addresses needs for both sides is needed. It may not be enough time to
find such solution for Tiger, but inclusion of varargs into the
language as they currently specified may ruin better alternatives in
the future. For example, concise array literals (or similar proposals)
will look extremely ugly combined with varargs as per PRD.
I understand that varargs are needed to support important marketing
features in Tiger like printf. Yes, it is marketing (with questionable
need in education sector), because real projects will not use printf.
Real projects are using logging and MessageFormat. They are not very
convenient without concise array literals, but at least everybody is
already accustomed to them. People have already written a lot of
helper classes themselves for MessageFormat&Logging that do not need
any varargs and have higher performance than PRD varargs will. They
simply declare methods with varying number of parameters. They have as
may version of their methods as their really need in their project.
This practice is not going to stop with introduction of varargs. Just
look at EnumSet.of(...) series of methods! This kind of
[unquestionably ugly] design even got into Tiger which already
supposed to have varargs.
Varargs break language clarity and consistency in too many places
(overloaded method resolution is clearly getting out of hands). I
doubt that varargs benefits justify their shortcomings.
However, if customer demand for varargs-like facility is overwhelming,
then, at least, consider alternatives that are not based on arrays.
Array-based varargs (as in PRD) are especially devastating for future
language evolution. A special interface or class shall be defined to
pass varargs behind the scenes. For example, the following interface
may be defined in "java.lang":
public interface Indexed<T> extends Iterable<T> {
public int size();
public T get(int index);
// Btw, java.util.List<T> can be retrofitted to implement Indexed<T>
So, in "myMethod(T... arg)" the arg will actually have a type of
"Indexed<T>" instead of "T[]".
This solves a lot of issues! For example, it will become possible to
define varargs based on generic types (which is not possible with
array-based varargs).
Moreover, when compiler creates code to call varargs method it may
create an instance of a special class for chosen small number of
arguments. It is obvious, that a special implementation of Indexed for
one element will be always faster on modern HotSpot than a
single-element array (although naive iteration with "foreach" facility
will require extra Iterator object, but that can be fixed if needed by
recognizing Indexed object as a special case in "foreach" statement).
Performance will be on the side of array-based varargs when number of
arguments is large, but something tells me that people who really need
varargs and drive their inclusion into Java do not care about
performance that much and will be perfectly Ok with extra object that
implements Indexed interface and wraps underlying array for many
argument cases.
In conclusion I must stress that if the following is legal in the
Java language (regardless of underlying implementation):
void myMethod(MyClass... arg); // declaration
myMethod(1, 2, 3); // call site
Then the following must be also legal:
MyClass... arg = 1, 2, 3;