Ah, Kotlin Null Safety contre Java ! Une confrontation classique, comme Godzilla contre Mothra, mais avec moins de monstres destructeurs de villes et plus de peur existentielle… enfin, nulle. ?

Java, Dieu merci, existe depuis l'ère de la connexion commutée. À l’époque, personne ne s’inquiétait du fait que des valeurs nulles fassent planter votre application car, soyons honnêtes, Internet faisant planter votre application était un phénomène beaucoup plus courant. Mais les temps ont changé, et

L'approche Java « tout peut être nul à tout moment » est à peu près aussi bienvenue qu'un modem commuté dans un monde 5G. Entrez Kotlin, l'acolyte du programmeur de super-héros, ici pour sauver la situation (et votre santé mentale) avec son incroyable fonctionnalité Null Safety !

L'erreur d'un milliard de dollars (pas de Clickbait !)

NullPointerException est le fléau de l'existence d'un développeur Java. Elles ressemblent à ces minuscules briques LEGO sur lesquelles vous marchez au milieu de la nuit : petites mais capables de causer une immense douleur.

En fait, Tony Hoare, l'homme qui a inventé la référence nulle, l'a qualifié d'"erreur d'un milliard de dollars". (Nous supposons qu'il a marché sur beaucoup de LEGO.)

Kotlin, en revanche, adopte une approche proactive. C'est comme ces pantoufles confortables que l'on porte pour éviter de marcher sur les LEGO. Avec Null Safety de Kotlin, le compilateur lui-même devient un gardien vigilant, empêchant les valeurs NULL de se faufiler dans votre code et de faire des ravages.

Comment Kotlin le fait (Spoiler : c'est plutôt cool)

Dans Kotlin, vous devez indiquer explicitement au compilateur si une variable peut être nulle en ajoutant un ? à la déclaration de type. Par exemple:

// Kotlin
var name: String? = null // This variable can be null
var age: Int = 42        // This variable cannot be null

C'est simple ? est comme un panneau d'avertissement : "Attention ! Des valeurs nulles pourraient se cacher ici !" Et si vous essayez de faire quelque chose de risqué avec une variable nullable, le compilateur Kotlin vous arrêtera net avec un message d'erreur. C'est comme avoir un garde du corps personnel pour votre code, sauf que ce garde du corps est vraiment bon en grammaire et en syntaxe.

Le contre-mouvement de Java (il essaie, bénis son cœur)

Java, dans ses versions ultérieures, a essayé de rattraper son retard avec des fonctionnalités telles que Facultatif. C'est un effort courageux, un peu comme si votre grand-père essayait d'apprendre TikTok. Il veut dire du bien, mais ce n'est pas tout à fait pareil. Facultatif peut être fastidieux et n'offre pas le même niveau de sécurité au moment de la compilation que Null Safety de Kotlin.

// Java
import java.util.Optional;

public class OptionalExample {

    public static void main(String[] args) {
        // Creating an Optional object

        Optional name = Optional.of("John Doe"); 

        // Checking if a value is present
        if (name.isPresent()) {
            System.out.println("Name is present: "   name.get()); 
        } else {
            System.out.println("Name is absent");
        }

        // Using orElse to provide a default value
        String defaultName = name.orElse("Unknown"); 
        System.out.println("Name: "   defaultName);

        // Using orElseGet to provide a default value with a supplier
        String anotherDefaultName = name.orElseGet(() -> "Another Unknown");
        System.out.println("Name: "   anotherDefaultName);
    }
}

En conclusion (la partie à laquelle tout le monde passe)

Null Safety de Kotlin change la donne. Cela rend votre code plus sûr, plus concis et moins sujet aux redoutables NullPointerException. Donc, si vous en avez assez de combattre les nuls comme s'ils étaient le boss final d'un jeu vidéo, il est peut-être temps de passer à Kotlin. Votre santé mentale vous remerciera. ?

P.S. Si vous êtes toujours indécis, imaginez ceci : un monde dans lequel vous n'aurez jamais à déboguer une autre NullPointerException. Cela ressemble au paradis, n'est-ce pas ? ?