Java Automatic Unboxing - Y a-t-il un avertissement de compilateur?

Question

Je suis un grand fan de l'auto-boxing à Java car il économise beaucoup de code de plaque de chaudière laid. Cependant, j'ai constaté que l'auto-boxing était confuse dans certaines circonstances où l'objet numéro peut être nul. Existe-t-il un moyen de détecter où se produit automatiquement une base de code dans une base de code avec un avertissement Javac? Toute autre solution pour détecter les occurrences de déballage uniquement (telles que Findbugs ou un avertissement de compilateur spécifique à l'éclipse) serait appréciée car je ne trouve aucune.

Pour clarifier, je ne veux pas que des avertissements soient générés sur la boxe - un déballage uniquement.

Voici un exemple simple d'un code qui peut provoquer la confusion de NullPointerExceptions:

class Test {
    private Integer value;

    public int getValue() {
        return value;
    }
}

Answer 1

Eclipse vous permettra de syntaxer les opérations de boxe et de déballage (mais pas l'une ou l'autre). Je les ai réglés sur le rouge vif: si l'un ou l'autre se produit, cela signifie que j'ai été bâclé dans les paramètres et les arguments correspondants.

Answer 2

Ouais. Dans Eclipse:

Préférences-> Java-> Compiler-> erreurs / avertissements-> Problèmes de programmation potentielles-> Conversions de boxe et de déballage

Answer 3

Malheureusement, il n'y en a pas. C'est l'un des problèmes avec les numéros de déballage automatique. Tu peux

• L'initialiser à une valeur par défaut, comme private Integer value = 0
• Vérifiez un null return value != null ? value : 0

Personnellement, je préfère la première méthode. En général, je pense que vous n'auriez pas trop de cas où vous devriez avoir un numéro nul.

De plus, pourquoi utilisez-vous un grand entier pour stocker la valeur. Si vous ne retournez qu'un peu Int, pourquoi ne pas le stocker de cette façon?

Answer 4

Je doute que ce soit un cas d'avertissement. C'est l'une des bizarreries de l'auto-boxing.

Joshua Bloch aborde cela dans son livre "Effective Java". Fondamentalement, le compilateur essaie de faire plus pour vous que ce qui est attendu. En d'autres termes, ce type de problème est plus communément lié à l'utilisation et, par conséquent, il est difficile de "repérer l'erreur" car l'erreur est, sémantiquement, tout simplement pas là.