Como usar as anotações @Nullable e @Nonnull com mais eficiência?

Eu posso ver que @Nullablee @Nonnullanotações pode ser útil na prevenção NullPointerExceptions, mas eles não se propagam muito longe.

• A eficácia dessas anotações diminui completamente após um nível de indireção, portanto, se você adicionar apenas algumas, elas não se propagam muito longe.
• Como essas anotações não são bem aplicadas, existe o risco de assumir que um valor marcado com @Nonnullnão é nulo e, consequentemente, não executa verificações nulas.

O código abaixo faz com que um parâmetro marcado com @Nonnullseja nullsem apresentar nenhuma reclamação. Ele lança um NullPointerExceptionquando é executado.

public class Clazz {
    public static void main(String[] args){
        Clazz clazz = new Clazz();

        // this line raises a complaint with the IDE (IntelliJ 11)
        clazz.directPathToA(null);

        // this line does not
        clazz.indirectPathToA(null); 
    }

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }
}

Existe uma maneira de tornar essas anotações mais rigorosamente aplicadas e / ou propagar mais?

Resposta curta: acho que essas anotações são úteis apenas para o seu IDE avisar sobre erros de ponteiro potencialmente nulos.

Como dito no livro "Código Limpo", você deve verificar os parâmetros do seu método público e também evitar a verificação de invariantes.

Outra boa dica é nunca retornar valores nulos, mas usar Null Object Pattern .

Além do seu IDE, fornecendo dicas quando você passa nullpara métodos que esperam que o argumento não seja nulo, há outras vantagens:

• As ferramentas de análise de código estático podem testar o mesmo que o seu IDE (por exemplo, FindBugs)
• Você pode usar o AOP para verificar essas afirmações

Isso pode ajudar seu código a ser mais sustentável (já que você não precisa de nullverificações) e menos propenso a erros.

Eu acho que essa pergunta original aponta indiretamente para uma recomendação geral de que a verificação de ponteiro nulo em tempo de execução ainda é necessária, mesmo que o @NonNull seja usado. Consulte o seguinte link:

Novas anotações de tipo do Java 8

No blog acima, é recomendado que:

As anotações de tipo opcionais não substituem a validação de tempo de execução. Antes das anotações de tipo, o local principal para descrever itens como nulidade ou intervalos estava no javadoc. Com as anotações de tipo, essa comunicação entra no bytecode de maneira a verificar em tempo de compilação. Seu código ainda deve executar a validação de tempo de execução.

Compilando o exemplo original no Eclipse na conformidade 1.8 e com a análise nula baseada em anotação ativada, obtemos este aviso:

    directPathToA(y);
                  ^
Null type safety (type annotations): The expression of type 'Integer' needs unchecked conversion to conform to '@NonNull Integer'

Esse aviso está redigido em analogia com os avisos que você recebe ao misturar código gerado com código herdado usando tipos brutos ("conversão não verificada"). Temos exatamente a mesma situação aqui: o método indirectPathToA()possui uma assinatura "herdada", pois não especifica nenhum contrato nulo. As ferramentas podem relatar isso facilmente, de modo que o perseguirão por todos os becos onde as anotações nulas precisam ser propagadas, mas ainda não são.

E ao usar um inteligente @NonNullByDefault , nem precisamos dizer isso o tempo todo.

Em outras palavras: se as anotações nulas "propagam-se muito longe" podem depender da ferramenta que você usa e de quão rigorosamente você atende a todos os avisos emitidos pela ferramenta. Com as anotações nulas TYPE_USE, você finalmente tem a opção de deixar a ferramenta avisá-lo sobre todos os NPE possíveis em seu programa, porque a nulidade se tornou uma propriedade intrínseca do sistema de tipos.

Concordo que as anotações "não se propagam muito longe". No entanto, vejo o erro do lado do programador.

Entendo a Nonnullanotação como documentação. O método a seguir expressa que requer (como pré-condição) um argumento não nulo x.

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }

O seguinte trecho de código contém um erro. O método chama directPathToA()sem impor que ynão seja nulo (ou seja, não garante a pré-condição do método chamado). Uma possibilidade é adicionar uma Nonnullanotação também a indirectPathToA()(propagar a pré-condição). A possibilidade dois é verificar a nulidade de yin indirectPathToA()e evitar a chamada de directPathToA()quando yé nulo.

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

O que faço em meus projetos é ativar a seguinte opção na inspeção de código "Condições e exceções constantes":
Sugira anotação @Nullable para métodos que possivelmente retornem nulos e relatem valores nulos passados ​​para parâmetros não anotados

Quando ativado, todos os parâmetros não anotados serão tratados como não nulos e, portanto, você também verá um aviso em sua chamada indireta:

clazz.indirectPathToA(null); 

Para verificações ainda mais fortes, o Checker Framework pode ser uma boa opção (consulte este bom tutorial .
Nota : Eu ainda não o usei e pode haver problemas com o compilador Jack: consulte este relatório de erros

Em Java, eu usaria o tipo opcional do Guava . Sendo um tipo real, você obtém garantias do compilador sobre seu uso. É fácil ignorá-lo e obter um NullPointerException, mas pelo menos a assinatura do método comunica claramente o que ele espera como argumento ou o que ele pode retornar.

Se você usar o Kotlin, ele suportará essas anotações de nulidade em seu compilador e impedirá que você passe um nulo para um método java que requer um argumento não nulo. Mesmo que essa pergunta tenha sido direcionada originalmente para Java, mencionei esse recurso do Kotlin porque ele é direcionado especificamente para essas anotações em Java e a pergunta era "Existe uma maneira de tornar essas anotações mais rigorosamente aplicadas e / ou se propagarem mais?" e esse recurso torna essas anotações mais rigorosamente aplicadas .

Classe Java usando @NotNullanotação

public class MyJavaClazz {
    public void foo(@NotNull String myString) {
        // will result in an NPE if myString is null
        myString.hashCode();
    }
}

Classe Kotlin chamando a classe Java e passando nulo para o argumento anotado com @NotNull

class MyKotlinClazz {
    fun foo() {
        MyJavaClazz().foo(null)
    }
}  

Erro do compilador Kotlin ao aplicar a @NotNullanotação.

Error:(5, 27) Kotlin: Null can not be a value of a non-null type String

consulte: http://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

Desde o novo recurso Java 8, opcional, você não deve usar @Nullable ou @Notnull em seu próprio código . Veja o exemplo abaixo:

public void printValue(@Nullable myValue) {
    if (myValue != null) {
        System.out.print(myValue);
    } else {
        System.out.print("I dont have a value");
}

Pode ser reescrito com:

public void printValue(Optional<String> myValue) {
    if (myValue.ifPresent) {
        System.out.print(myValue.get());
    } else {
        System.out.print("I dont have a value");
}

Usar um opcional obriga a verificar o valor nulo . No código acima, você pode acessar o valor apenas chamando oget método

Outra vantagem é que o código fica mais legível . Com a adição do Java 9 ifPresentOrElse , a função pode até ser escrita como:

public void printValue(Optional<String> myValue) {
    myValue.ifPresentOrElse(
        v -> System.out.print(v),
        () -> System.out.print("I dont have a value"),
    )
}