¿Cómo usar las anotaciones @Nullable y @Nonnull de manera más efectiva?

Puedo ver eso @Nullabley las @Nonnullanotaciones pueden ser útiles para prevenir NullPointerExceptions pero no se propagan muy lejos.

• La efectividad de estas anotaciones disminuye completamente después de un nivel de indirección, por lo que si solo agrega unas pocas, no se propagan muy lejos.
• Dado que estas anotaciones no se aplican correctamente, existe el peligro de asumir que un valor marcado con @Nonnullno es nulo y, en consecuencia, no realiza comprobaciones nulas.

El siguiente código hace que un parámetro marcado con @Nonnullsea nullsin generar ninguna queja. Lanza un NullPointerExceptioncuando se ejecuta.

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        
    }
}

¿Hay alguna manera de hacer que estas anotaciones se apliquen más estrictamente y / o se propaguen más?

Respuesta corta: supongo que estas anotaciones solo son útiles para que su IDE le advierta de posibles errores de puntero nulo.

Como se dice en el libro "Código limpio", debe verificar los parámetros de su método público y también evitar los invariantes.

Otro buen consejo es que nunca devuelve valores nulos, sino que usa el Patrón de objetos nulos .

Además de su IDE que le da pistas cuando pasa nulla métodos que esperan que el argumento no sea nulo, existen otras ventajas:

• Las herramientas de análisis de código estático pueden probar lo mismo que su IDE (por ejemplo, FindBugs)
• Puede usar AOP para verificar estas afirmaciones

Esto puede ayudar a que su código sea más fácil de mantener (ya que no necesita nullverificaciones) y menos propenso a errores.

Creo que esta pregunta original apunta indirectamente a una recomendación general de que todavía se necesita la verificación de puntero nulo en tiempo de ejecución, aunque se use @NonNull. Consulte el siguiente enlace:

Nuevas anotaciones de tipo de Java 8

En el blog anterior, se recomienda que:

Las anotaciones de tipo opcionales no sustituyen la validación de tiempo de ejecución Antes de las anotaciones de tipo, la ubicación principal para describir cosas como la nulabilidad o los rangos estaba en el javadoc. Con las anotaciones de tipo, esta comunicación entra en el código de bytes de una manera para la verificación en tiempo de compilación. Su código aún debe realizar la validación de tiempo de ejecución.

Compilando el ejemplo original en Eclipse en el cumplimiento 1.8 y con el análisis nulo basado en anotaciones habilitado, obtenemos esta advertencia:

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

Esta advertencia está redactada de forma análoga a las advertencias que se obtienen al mezclar código genérico con código heredado utilizando tipos sin formato ("conversión no verificada"). Tenemos exactamente la misma situación aquí: el método indirectPathToA()tiene una firma "heredada" en el sentido de que no especifica ningún contrato nulo. Las herramientas pueden informar fácilmente de esto, por lo que lo perseguirán por todos los callejones donde las anotaciones nulas deben propagarse pero aún no lo son.

Y cuando usas un inteligente @NonNullByDefault , ni siquiera tenemos que decir esto cada vez.

En otras palabras: si las anotaciones nulas "se propagan muy lejos" pueden depender de la herramienta que use y de cuán rigurosamente preste atención a todas las advertencias emitidas por la herramienta. Con las anotaciones nulas TYPE_USE , finalmente tiene la opción de dejar que la herramienta le advierta sobre cada NPE posible en su programa, porque la nulidad se ha convertido en una propiedad intrínseca del sistema de tipos.

Estoy de acuerdo en que las anotaciones "no se propagan muy lejos". Sin embargo, veo el error del lado del programador.

Entiendo la Nonnullanotación como documentación. El siguiente método expresa que se requiere (como condición previa) un argumento no nulo x.

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

El siguiente fragmento de código contiene un error. El método llama directPathToA()sin exigir que yno sea nulo (es decir, no garantiza la condición previa del método llamado). Una posibilidad es agregar una Nonnullanotación también a indirectPathToA()(propagar la condición previa). La posibilidad dos es verificar la nulidad de yin indirectPathToA()y evitar la llamada a directPathToA()cuando yes nulo.

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

Lo que hago en mis proyectos es activar la siguiente opción en la inspección del código "Condiciones constantes y excepciones":
Sugerir anotación @Nullable para métodos que posiblemente puedan devolver valores nulos e informar valores anulables pasados ​​a parámetros no anotados

Cuando se activa, todos los parámetros no anotados se tratarán como no nulos y, por lo tanto, también verá una advertencia en su llamada indirecta:

clazz.indirectPathToA(null); 

Para verificaciones aún más fuertes, el Checker Framework puede ser una buena opción (vea este buen tutorial .
Nota : aún no lo he usado y puede haber problemas con el compilador Jack: vea este informe de errores

En Java, usaría el tipo Opcional de Guava . Al ser un tipo real, obtienes garantías de compilación sobre su uso. Es fácil omitirlo y obtener un NullPointerException, pero al menos la firma del método comunica claramente lo que espera como argumento o lo que podría devolver.

Si usa Kotlin, admite estas anotaciones de nulabilidad en su compilador y evitará que pase un método nulo a un método java que requiere un argumento no nulo. Aunque esta pregunta originalmente estaba dirigida a Java, menciono esta característica de Kotlin porque está específicamente dirigida a estas anotaciones de Java y la pregunta era "¿Hay alguna manera de hacer que estas anotaciones se apliquen más estrictamente y / o se propaguen más?" y esta característica hace que estas anotaciones se apliquen más estrictamente .

Clase Java usando @NotNullanotaciones

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

Clase Kotlin llamando a la clase Java y pasando nulo para el argumento anotado con @NotNull

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

Error del compilador de Kotlin al aplicar la @NotNullanotación.

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

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

Dado que la nueva característica de Java 8 Opcional ya no debe usar @Nullable o @Notnull en su propio código . Tome el siguiente ejemplo:

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

Podría reescribirse con:

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

El uso de una opción te obliga a comprobar el valor nulo . En el código anterior, solo puede acceder al valor llamando alget método.

Otra ventaja es que el código se vuelve más legible . Con la adición de Java 9 ifPresentOrElse , la función podría incluso escribirse como:

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