Java 3 points de paramètre (varargs) comportement lorsqu'il est passé sans arguments ou null

J'ai essayé et pour obtenir le comportement bizarre de JAVA, quelqu'un peut m'expliquer ce pour moi?

boolean testNull(String... string) {
    if(string == null) {
        return true;
    } else {
        System.out.println(string.getClass());
        return false;
    }
}

boolean callTestNull(String s) {
    return testNull(s);
}

Puis j'ai des cas de test:

    @Test
    public void test_cases() {
        assertTrue(instance.testNull(null)); //NULL
        assertFalse(instance.testNull()); //NOT NULL
        assertFalse(instance.callTestNull(null)); //NOT NULL
    }

La question est de savoir si je l'appelle testNull() directement avec le paramètre null, je vais obtenir true, mais s'appel callTestNull() avec null, qui appelle testNull(), il me dit que le paramètre n'est pas nulle, mais vide.

InformationsquelleAutor Jaiwo99 | 2013-07-17
  1. 56

    La question est de savoir si je l'appelle testNull() directement avec le paramètre null, j'aurai un vrai, mais si l'appel callTestNull() avec la valeur null, ce qui appelle testNull(), il me dit que le paramètre n'est pas nulle, mais vide.

    Oui. Si vous appelez avec un argument avec un le type de compilation de String, le compilateur sait que ne peut pas être un String[], il l'enroule dans un tableau de chaînes. Donc:

    String x = null;
testNull(x);

    est équivalent à:

    String x = null;
testNull(new String[] { x });

    À ce stade, le (faussement nommé) string paramètre aura une valeur non-null - au lieu de cela, il va se référer à un tableau de taille 1, et dont l'unique élément est une référence null.

    Toutefois, lorsque vous utilisez le null littérale directement dans l'appel de méthode, c'est directement convertible pour String[], donc pas d'emballage est effectué.

    De JLS section 15.12.4.2:

    Si la méthode invoquée est une variable arity m, il a nécessairement n > 0 paramètres formels. Le dernier paramètre formel de m a nécessairement de type T[] pour certains T, et m est nécessairement être invoquée avec k ≥ 0 argument réel expressions.

    Si m est appelée avec k ≠ n argument réel des expressions, ou, si m est invoquée, avec k = n argument réel expressions et le type de la k-ième argument de l'expression n'est pas d'affectation compatible avec T[], puis la liste des arguments (e1, ..., en-1, fr, ..., ek) est évalué comme s'il avait été écrit que (e1, ..., en-1, nouveau |T[]| { fr, ..., ek }), où |T[]| désigne l'effacement (§4.6) de T[].

    (C'est moi qui souligne.)

    Le peu que j'ai souligné, c'est pourquoi l'emballage seulement se produit lorsque le moment de la compilation du type de l'argument est String, pas le type null.

    InformationsquelleAutor Jon Skeet