¿Advertir a Kotlin sobre la asignación de tipo flexible / plataforma al tipo no nulo?

Cuando llamamos a una function de Java anotada sin anulación de Kotlin, obtenemos valores de retorno de tipo flexible, indicados con signos de exclamación, por ejemplo String! .

Kotlin permite silenciosamente asignar estos valores flexibles a un tipo normal no nulo, por ejemplo, String , que puede causar NullPointerExceptions en time de ejecución.

Preferiría recibir advertencias o compiler errors para tales asignaciones. De forma alternativa, trate los types de plataforma como equivalentes a los types anulables (por ejemplo String? ).

Como ejemplo, con este código de Java:

 import android.os.SystemClock; import android.support.annotation.NonNull; import android.support.annotation.Nullable; public class NullTest { private String maybe() { if (SystemClock.elapsedRealtimeNanos() % 2 == 0) { return null; } return "ok"; } public String annotatedNothing() { return maybe(); } @Nullable public String annotatedNullable() { return maybe(); } @NonNull public String annotatedNonNull() { return "ok"; } } 

… y el siguiente código de Kotlin, me gustaría get errores en dos líneas nuevas (ver comentarios):

 fun testnulls() { val obj = NullTest() val nullExact: String = obj.annotatedNullable() // already gives an error val nullMaybe: String? = obj.annotatedNullable() val nullInfer = obj.annotatedNullable() val okayExact: String = obj.annotatedNonNull() val okayMaybe: String? = obj.annotatedNonNull() val okayInfer = obj.annotatedNonNull() val bareExact: String = obj.annotatedNothing() // I want a compiler error here val bareMaybe: String? = obj.annotatedNothing() val bareInfer = obj.annotatedNothing() print("length " + nullExact.length) print("length " + nullMaybe.length) // already gives an error print("length " + nullInfer.length) // already gives an error print("length " + okayExact.length) print("length " + okayMaybe.length) // already gives an error print("length " + okayInfer.length) print("length " + bareExact.length) print("length " + bareMaybe.length) // already gives an error print("length " + bareInfer.length) // I want a compiler error here } 

El punto es que esto me obligará a agregar controles nulos o !! , asegurándome de que al less tengo que ser explícito al respecto.

es posible?

En los comentarios de esta publicación del blog JetBrains 2014 , cuando presentaron los types de plataforma / flexibles, parece que estaban planeando agregar una opción para advertir sobre estas situaciones, pero no he podido encontrar más información al respecto.

    La documentation de Kotlin describe este caso exacto:

    Cualquier reference en Java puede ser nula, lo que hace que los requisitos de Kotlin de security nula estricta no sean prácticos para los objects provenientes de Java. Los types de declaraciones Java se tratan especialmente en Kotlin y types de plataforma llamados. Las comprobaciones nulas se relajan para dichos types, de modo que las garantías de security para ellos son las mismas que en Java

    Lamentablemente, significa que no hay forma de emitir una advertencia durante un time de compilation. El lado positivo es que Kotlin evitará al less que la propagación nula en time de ejecución.

    Cuando llamamos a methods en variables de types de plataforma, Kotlin no emite errores de nulabilidad en time de compilation, pero la llamada puede fallar en el time de ejecución, debido a una exception de puntero nulo o una aserción que Kotlin genera para evitar la propagación de nulos

    Si no controlo el código fuente de una biblioteca Java que utilizo, considero que todos los resultados son potencialmente anulables, a less que sea evidente que no lo son.

    Sí, es posible get advertencias y / o compiler errors para cualquier asignación de los methods de Java con una fuerte suposition de que si el método no tiene la anotación @Nullable es @Nullable .

    ¿Cómo? 🙂 Deberá escribir su propio complemento Idea Custom Inspection .

    Aquí hay algunos enlaces útiles para cualquier persona con la experiencia suficiente como para build ese plugin de inspección personalizado (probablemente estaría entre sus agradecidos usuarios):

    1. Desarrollo de los complementos de ideas Guía de inicio rápido
    2. Fuentes de todas las inspecciones existentes de Idea Kotlin (podrían ser útiles como ejemplos de controles de security nulos existentes)

    Si es un desarrollador de plugins de Idea familiar y experimentado, es posible que no le lleve mucho time. De lo contrario, no creo que el resultado que va a lograr realmente valga la pena el time que tendrá que gastar.

    Me gusta su idea, pero AFAIK en las primeras etapas del desarrollo de kotlin hubo un bash de implementar controles de security nulos completos como sea posible y resultó que había demasiadas asignaciones potencialmente inseguras.

    ps Si finalmente va a build ese plugin de inspección, por favor avíseme. Personalmente, intenté hacerlo, pero en mi caso primero tendré que aprender más sobre los complementos de Idea.

    para cadenas no nulas –

    check isEmpty () No podrá pasar cadenas no nulas en ese método. Entonces es seguro.

    para cadenas nulas

    puede verificar nulo en si estado.