Java generics and varargs

Question

I'd like to implement a function with both generics and varargs.

public class Question {
    public static <A> void doNastyThingsToClasses(Class<A> parent, Class<? extends A>... classes) {
        /*** something here ***/
    }
    public static class NotQuestion {
    }
    public static class SomeQuestion extends Question {
    }
    public static void main(String[] args) {
        doNastyThingsToClasses(Object.class, Question.class, SomeQuestion.class); // OK
        doNastyThingsToClasses(Question.class, SomeQuestion.class); // OK
        doNastyThingsToClasses(Question.class, Object.class, SomeQuestion.class); // compilation failure
    }
}

The intention here is to assert that all parameters passed to this function are Class objects extending the Class given as the first parameter. So the two first lines of main method would compile and the 3rd one generates an error.

My question is: Why I get "Type safety : A generic array of Class is created for a varargs parameter" message for the first two lines?

Am I missing something here?

Additional question: how to redesign it to prevent this warning from being shown on every line calling "doNastyThingsToClasses" function? I can change it to "doNastyThingsToClasses(Class<A> parent, Class<?>... classes)" and get rid of the warnings but this also removes the compilation-time type checking --- not so good if I wanted to assure the right use of this function. Any better solution?

score 42 · Accepted Answer · edited Mar 12 '11 at 01:14

42

As almost always, Angelika Langer's Java generics FAQ explains it in great detail. (Scroll to "Why does the compiler sometimes issue an unchecked warning when I invoke a "varargs" method?" - the ID doesn't work well.)

Basically, you end up losing information in a worse way than normal. Yet another little pain point in Java generics :(

edited Mar 12 '11 at 01:14

Nicole

32,841
11
75
101

answered Jun 22 '10 at 20:12

Jon Skeet

1,421,763
867
9,128
9,194

22

I suggest it's a pain point in varargs - they shouldn't have used arrays. In fact, the misfeature should have been replaced by immutable list (and others) literals. – Tom Hawtin - tackline Jun 22 '10 at 20:19
@Tom: Yes, that would certainly have solved this particular one. Arrays and generics would still be a pain together, of course :) – Jon Skeet Jun 22 '10 at 22:01
2

at least a way to work around this particular piece of ugliness is coming, eventually (see my answer) – Cowan Jun 23 '10 at 02:39

Cowan · Answer 2 · 2010-06-23T09:52:47.127

Jon Skeet's answer is (of course) correct; I'll expand on it a little by pointing out that you CAN get rid of this warning, with a big 'if'. You can avoid this warning IF you're willing to commit to having your project build using Java 7.

Bob Lee wrote a proposal to let this warning be suppressed at method-declaration site, rather than usage site, as part of Project Coin.

This proposal was accepted for JDK7 (though the syntax changed slightly, to @SuppressWarnings("varargs")); you can, if you're curious, look at the commit that added this support to the JDK.

Not necessarily helpful for you, but I thought I'd make this a separate answer so it lives on for future readers, who may be lucky enough to live in a post-Java-7 world.

See [@Scott's answer](http://stackoverflow.com/a/6864043/152061) about @SafeVarargs — Brad Cupit, Jun 10 '13 at 18:43

score 11 · Answer 3 · edited Feb 26 '23 at 21:36

11

As a side note, the warning can be suppressed using the @SafeVarargs annotation introduced in Java 7.

@SafeVarargs
public static <A> void func( Class<A> parent, Class<? extends A>... classes ) {
    // Do func...
}

edited Feb 26 '23 at 21:36

Vessel

139
1
3
10

answered Jul 28 '11 at 18:43

Scott

2,233
2
15
8

LuisKarlos · Answer 4 · 2011-10-15T23:48:32.427

6

My solution to this problem was to

create a class Nastier
remove ... from doNastyThingsToClasses
make doNastyThingsToClasses none static method
make the name short, like do
return this

move repetitive args to class properties

class Nastier {
  private final Class<A> parent;

  public Nastier(Class<A> parent) {
     this.parent = parent;
  }

  public <A, C extends A> Nastier do(Class<? extends A> clazz) {
     System.out.println(clazz);
     return this;
  }
}

public static void main(String[] args) {   
  Nastier nastier = new Nastier(Object.class);
  nastier.do(Question.class).do(SomeQuestion.class).do(NotQuestion.class);
}

I believe the code looks clean and I am happy.... :)

edited Oct 15 '11 at 23:48

answered Sep 25 '11 at 17:05

LuisKarlos

527
6
6

1

I haven't thought about method chaining... this is a _really_ nice workaround! – Chris Oct 13 '11 at 21:29
9

Nitpicking, but `do` is a keyword and can't be a method name :-) – Brad Cupit Jun 10 '13 at 18:31
Should `do` be declared as `do(Class clazz)`? – Clement Cherlin Aug 16 '21 at 15:03

score 2 · Answer 5 · answered Jun 23 '10 at 19:41

OK, so finally I end up throwing the varargs away:

public class Question {

    public static <A, C extends A> void doNastyThingsToClasses(Class<A> parent, List<Class<? extends A>> classes) {
        /******/
        for(Class<? extends A> clazz : classes) {
            System.out.println(clazz);
        }
    }

    public static class NotQuestion {
    }
    public static class SomeQuestion extends Question {
    }

    public static void main(String[] args) {

        ArrayList<Class<? extends Object>> classes = new ArrayList<Class<? extends Object>>();
        classes.add(Question.class);
        classes.add(SomeQuestion.class);
        classes.add(NotQuestion.class);
        doNastyThingsToClasses(Object.class, classes);

        ArrayList<Class<? extends Question>> clazzes = new ArrayList<Class<? extends Question>>();
        clazzes.add(Question.class);
        clazzes.add(SomeQuestion.class);
        clazzes.add(NotQuestion.class); // yes, this will _not_ compile
        doNastyThingsToClasses(Question.class, clazzes);

    }

}

The only flaw is the long code for populating the collection used to carry function's arguments.

Collection population can be easily done with Arrays.asList(...) — mihallievich, Jan 28 '22 at 15:08

score -1 · Answer 6 · answered Jun 22 '10 at 20:15

The second argument Class<? extends A>... that must extend the class that the first argument is (ex. argument one is a Question so the second argument be something that extends Question.

The Breakdown:
NastyThingsToClasses(Object.class, Question.class, SomeQuestion.class); // OK
Everything extends Object so the second argument is correct.

NastyThingsToClasses(Question.class, SomeQuestion.class); // OK
SomeQuestion extends Question so thats fair game.

NastyThingsToClasses(Question.class, Object.class, SomeQuestion.class);
Object does not extend Question hence error.

hopefully that cleared things up.

-Brett

The OP was asking about the warnings of the first two lines, not about the error. — True Soft, Jun 22 '10 at 20:18

Java generics and varargs

6 Answers6

Linked