Project Coin: Safe Varargs in JDK Libraries

Back for JDK 7 build 123, the language support for the Project Coin's safe varargs feature was pushed; the time has come to update the libraries to take advantage of this feature.

Following the same general methodology used to systematically flush out types that should be made Closeable or AutoCloseable, I wrote an annotation processor to identify candidate varargs methods and constructors where adding a @SafeVarargs annotation might be appropriate.

Several JDK library methods were known candidates for @SafeVarargs; running the annotation processor found another one. The complete list of methods to be annotated in a java.\* or javax.\* package is:

  • public static <T> List<T> java.util.Arrays.asList(T... a)
  • public static <T> boolean java.util.Collections.addAll(Collection<? super T> c, T... elements)
  • public static <E extends Enum<E>> java.util.EnumSet<E> EnumSet.of(E first, E... rest)
  • protected final void javax.swing.SwingWorker.publish(V... chunks)

After this update, many fewer spurious unchecked warnings will be reported when calling core library classes.

Comments:

Are you sure about EnumSet.of? The only (current) types that would additionally allow are Enum<>, which permits EnumSets containing multiple enum types (caught at runtime). That does seem to be a general problem with EnumSet.

Posted by Tom Hawtin on January 24, 2011 at 08:35 PM PST #

@Tom,

I'm not sure what you mean by your comment. The EnumSet.of code takes its arguments and copies them into an EnumSet. For the variable argument, it just iterates over the elements of the array, as one would expect. This does not merit unchecked warnings at every call site of EnumSet.of, warnings which the @SafeVarargs annotation removes. The application of the @SafeVarargs annotation does not interact with the type inference of the E type variable.

Posted by Joe Darcy on January 25, 2011 at 02:30 AM PST #

Could you please explain why AutoCloseable was added? Wasn't the existing Closeable interface sufficient?

Posted by Gili on January 26, 2011 at 01:34 AM PST #

@Gili,

The need for AutoCloseable was covered at length during the development of ARM (automatic resource management)/try-with-resources. In brief, the method java.io.Closeable.close is defined to throw the checked IOException, which is not appropriate or desirable in all classes that would benefit from a method named "close."

Posted by Joe Darcy on January 26, 2011 at 01:45 AM PST #

Makes sense. Thanks Joe.

Posted by Gili on January 26, 2011 at 01:50 AM PST #

Post a Comment:
Comments are closed for this entry.
About

darcy

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
News

No bookmarks in folder

Blogroll