Hi Remi,
On 8/30/2012 5:06 AM, Rémi Forax wrote:
On 08/29/2012 09:11 PM, Dan Xu wrote:
On 08/29/2012 08:27 AM, Joe Darcy wrote:
Hello,
On 8/29/2012 1:48 AM, Rémi Forax wrote:
On 08/29/2012 08:33 AM, Kurchi Subhra Hazra wrote:
Thanks for cleaning up those spaces Dan. The changes look fine.
Sorry for the extra trouble!
- Kurchi
On 8/28/12 10:22 PM, Dan Xu wrote:
[snip]
@Joe,
So the question is whenever @SafeVarargs change the status of the
variable 'a'
to consider it as a safe use of a varargs.
Given the fact that the user annotate the method with @SafeVarargs,
the interpretation is that @SafeVarargs is only something for methods
that call asList()
but it has no effect on the body of the method asList().
That make sense.
The specification for the @SafeVarargs annotation types says:
http://docs.oracle.com/javase/7/docs/api/java/lang/SafeVarargs.html
Compilers are encouraged to issue warnings when this annotation type
is applied to a method or constructor declaration where:
* The variable arity parameter has a reifiable element type, which
includes primitive types, Object, and String. (The unchecked warnings
this annotation type suppresses already do not occur for a reifiable
element type.)
* The body of the method or constructor declaration performs
potentially unsafe operations, such as an assignment to an element of
the variable arity parameter's array that generates an unchecked
warning. Some unsafe operations do not trigger an unchecked warning.
[...]
Future versions of the platform may mandate compiler errors for such
unsafe operations.
So currently the SafeVarargs annotation on a method is treated as an
assertion, but compilers are allowed to (and encouraged to) "trust, but
verify" that the assertion is correct. We didn't have enough time to
specify and implement a sufficiently powerful analysis that would have
allowed all the safe varargs methods we wanted to see. The
Arrays.asList method is anomalous in how it works for a SafeVarargs
methods since it intentionally uses aliasing.
-Joe