PROPOSAL: Simplified Varargs Method Invocation

Bob Lee crazybob at
Fri Mar 6 11:46:50 PST 2009

Thanks, Mark. I'll add bug #5048776 to the reference section.

It sounds like we have three issues I'll address in the next rev:

1) Overriding vararg methods with array methods and vice versa: This
generated a warning in Java 5, but it doesn't appear to do so in Java 6. I
can't find anything about it in the JLS. I'm going to update the proposal to
recommend that we bring the warning back in Java 7 (being sure to specify it
in the JLS this time around).

2) Overriding a non-refiable varargs method with a reifiable varargs method
(for example, T... with String...): If a client doesn't know the type of T
and they call the reifiable version of the method through the non-reifiable
API, the client will create an Object[], but the reifiable method only takes
a ReifiableType[], so the client gets a CCE at run time.

I don't think that modifying the reifiable method to use Object[] under the
covers is a viable option. Doing so would break compatibility. For example,
if I run against a library compiled with an older compiler, I'll get the CCE
at run time but no warnings at compile time.

It's interesting that not one of the references I cited mention this
situation (it certainly doesn't spring to mind when I see an "unchecked or
unsafe operation" warning). As an API designer, it's already the case today
that I can't use varargs in this situation, so I'm going to update the
proposal to suggest that we generate a warning when you try to override a
non-reifiable varargs with a reifiable varargs. This has the added benefit
of failing faster. If I do make this mistake in my API, I'll find out right
away instead of waiting until someone tries to compile code that uses a
non-reifiable type against my API. Addressing this issue makes the proposal
even more compelling than before.

On the bright side, there are no examples of this in the JDK. All of the
varargs methods with non-reifiable types are static.

3) There is a small window where you'll get no warning. For example, I
compile the API and client in Java 7 but run against a library compiled in
Java 6. This is nothing new. For example, I could compile against a
generified API, but run against an older implementation of the API compiled
targeting Java 4 and get no warnings. I'll note this in the disadvantages

Can you think of anything else I should address in the next rev?


More information about the coin-dev mailing list