PROPOSAL: Simplified Varargs Method Invocation (Round II)

[Reinier Zwitserloot]

Joe, I'm a bit unclear about what is/isn't acceptable for coin.

There's only one way for Simplified Varargs Method to result in heap  
corruption WITHOUT triggering at least 1 warning.

That's the following case:

varargs-accepting-method is compiled with javac5 or javac6, and

code that calls that method is compiled with javac7.


__however__, that situation has happened before!

It is perfectly legal (no warnings, no errors) to write a method that  
takes a List (no generics) and adds a string to this list, if you  
compile it with javac4 (or javac5/6 with -source 1.4 -target 1.4).

it is also perfectly legal (no warnings, no errors) to write a method  
that creates a List<Integer> and then calls the method from the  
previously produced class file. You now have a string in a  
List<Integer>, and 0 warnings. Oops.

Entirely analogous to this proposal's situation, just across a  
different version boundary (1.6/1.7 instead of 1.4/1.5).


So, given that precedent, allowed for coin, or not? I'd be very happy  
if this got fixed, because, frankly, varargs are almost useless in the  
current state. A fun trick to make printf work, not much more than  
that. I can't make a library that is **guaranteed** to produce  
warnings in client code, eventhough there is 0 chance anything could  
possibly go wrong. I work around it now by supplying each method in  
quadruplicate just to avoid the warnings:

public void foo(T one) {}

public void foo(T one, T two) {}

public void foo(T one, T two, T three) {}

public void foo(T one, T two, T three, T... rest) {}


it's a valid workaround, but as far as workarounds go, this one is  
ridiculous. Not to mention it wreaks havoc on the javadoc and auto- 
complete.

  --Reinier Zwitserloot



On Mar 17, 2009, at 23:46, Joseph D. Darcy wrote:

> Bob Lee wrote:
>> Simplified Varargs Method Invocation
>>
>> AUTHOR: Bob Lee
>>
>> OVERVIEW
>>
>> FEATURE SUMMARY: When a programmer tries to invoke a varargs  
>> (variable
>> arity) method with a non-reifiable varargs type, the compiler  
>> currently
>> generates an "unsafe operation" warning. This proposal moves the  
>> warning
>> from the call site to the method declaration.
>>
>
> The general contract when adding generics was "if your entire program
> compiles without unchecked warnings, you won't get heap pollution at
> runtime," heap pollution being where "a variable of parameterized type
> refers to an object that is not of that parameterized type" (JLSv3
> 4.12.2.1).
>
> While warning at the declaration site is fine for a lint-style  
> warning,
> the use sites merit warnings too because of heap pollution.
>
> Generics and arrays (including varags) simply do not play well  
> together!
>
> -Joe
>
>