Quand un développeur Java entend parler de Kotlin pour la première fois, la réaction est généralement l'une de ces deux choses.

Première : « Oh, intéressant — je devrais regarder ça. »

Deuxième : « Pourquoi s'embêter ? Java marche. Le salaire tombe. Tout va bien. »

Java vs Kotlin : une comparaison honnête - 1

Les deux réactions se comprennent. Quelqu'un a passé des années à apprendre Java, le maîtrise bien, ne veut pas repartir de zéro — c'est tout à fait raisonnable.

Mais il y a une troisième réaction dont personne ne parle : « C'est le langage vers lequel notre CTO nous migre le trimestre prochain. »

Pour ces trois cas — regardons ça honnêtement. Sans déclaration de guerre, sans évangélisme enthousiaste.

D'où vient Kotlin — et quel est le rôle d'Oracle

Java est apparu en 1995. Trente ans — un écosystème énorme, Spring, Hibernate, Maven, Gradle, des millions de développeurs, des montagnes de documentation. Ça ne meurt pas. Ça vit, évolue et se porte très bien.

Kotlin est sorti en 2016. JetBrains l'a créé pour ses propres besoins — épuisés par le boilerplate en développant IntelliJ IDEA. La décision clé : Kotlin compile vers le même bytecode JVM que Java. Ils fonctionnent ensemble dans le même projet. Pas de guerre — juste des outils différents.

En 2017, Google a annoncé Kotlin comme langage officiel pour Android.

Officiellement — parce que les développeurs le demandaient et que le langage est plus pratique. Vrai.

Mais il y a un contexte à connaître.

À partir de 2010, Google était engagé dans une bataille juridique avec Oracle au sujet de l'utilisation des API Java dans Android. Oracle réclamait 8,8 milliards de dollars — de quoi mettre même Google mal à l'aise. L'affaire est allée jusqu'à la Cour suprême des États-Unis et n'a été résolue qu'en 2021, avec la victoire de Google. Onze ans d'incertitude juridique.

Kotlin de JetBrains est open source et sans risque de licence. Google n'a jamais officiellement lié sa décision au procès. Mais comme on dit — la corrélation n'est pas la causalité, jusqu'à ce qu'elle le soit quand même.

Kotlin

Le bon côté : la concurrence a poussé Oracle à développer Java plus activement. Records, sealed classes, pattern matching dans les versions récentes — en partie parce qu'il fallait suivre le rythme de Kotlin. Que Oracle l'ait voulu ou non, tous les développeurs JVM y ont gagné.

Syntaxe : une comparaison en direct

Une tâche — filtrer une liste d'utilisateurs ayant 18 ans ou plus.

// Java
List<User> adults = users.stream()
    .filter(u -> u.getAge() >= 18)
    .collect(Collectors.toList());


// Kotlin
val adults = users.filter { it.age >= 18 }

Quatre lignes contre une. Dans la plupart des tâches quotidiennes, Kotlin est nettement plus compact.

Pour être honnête : en Java, tout est explicite. Tu lis le code et tu sais exactement ce qui se passe. En Kotlin, certaines constructions demandent un temps d'adaptation. Pour les débutants, Java est en fait plus transparent dans ce sens.

Mais si tu as passé plusieurs années en Java et que tu écris Collectors.toList() en pilote automatique — à ce stade, c'est peut-être plus de la mémoire musculaire que de « l'explicite ».

Null-safety : la plus grande différence

Tony Hoare a inventé null en 1965 et l'a ensuite publiquement appelé son « erreur à un milliard de dollars ». Rare cas où l'auteur lui-même a admis le bug. Le NullPointerException a coûté bien plus à l'industrie depuis — mais qui compte.

// Java
String name = null;    // Le compilateur reste silencieux
name.length();         // NPE en runtime. Généralement un vendredi soir.
                       // Parfois lors d'une démo live chez un client.

// Kotlin
var name: String = null   // Erreur de compilation. Immédiatement. Avant l'exécution.

var name: String? = null  // Explicitement nullable — maintenant OK
name?.length              // Si null — retourne null, ne plante pas
name?.length ?: 0         // Si null — retourne 0

Java 8 a introduit Optional comme solution partielle. Ça aide, mais ce n'est pas utilisé partout — et les NPE arrivent encore.

En Kotlin, la null-safety est intégrée dans le système de types. Le compilateur ne laissera pas passer du code où tu pourrais attraper un NPE sans l'autoriser explicitement. Comme un code reviewer strict — sans les commentaires « tu as bien vérifié le null ici ? »

Boilerplate : data class vs POJO

Un modèle de données simple — un utilisateur avec trois champs.

// Java
public class User {
    private final String name;
    private final int age;
    private final String email;

    public User(String name, int age, String email) {
        this.name = name; this.age = age; this.email = email;
    }

    public String getName() { return name; }
    public int getAge() { return age; }
    public String getEmail() { return email; }

    @Override public boolean equals(Object o) { ... }
    @Override public int hashCode() { ... }
    @Override public String toString() { ... }
}

40 à 50 lignes. On pourrait utiliser Lombok — mais ça ajoute une dépendance, nécessite une config IDE, et puis quelqu'un dans l'équipe dit inévitablement « Lombok ne marche pas chez moi ».

// Kotlin
data class User(val name: String, val age: Int, val email: String)

Une ligne. Le compilateur génère equals(), hashCode(), toString() — et aussi copy() :

val alice = User("Alice", 30, "alice@example.com")
val olderAlice = alice.copy(age = 31)  // Copie avec un champ modifié

copy() — quelque chose que Java n'a pas out of the box. Pourquoi — bonne question à laquelle Java n'a toujours pas répondu.

Coroutines vs Threads

En Java, le travail asynchrone passe par Thread, ExecutorService, CompletableFuture. Puissant. Mais le code devient vite une chaîne que même son auteur ne peut plus déchiffrer un mois plus tard.

// Java
CompletableFuture.supplyAsync(() -> fetchUser(id))
    .thenApply(user -> processUser(user))
    .thenAccept(result -> sendResult(result))
    .exceptionally(e -> { handleError(e); return null; });

// Kotlin
suspend fun loadAndProcess(id: Int) {
    val user = fetchUser(id)
    val result = processUser(user)
    sendResult(result)
}

Le code Kotlin se lit comme de la logique synchrone ordinaire — de haut en bas, sans imbrication. Et il s'exécute quand même de manière asynchrone sans bloquer les threads.

Remarque importante : les coroutines ne remplacent pas les threads. Elles sont idéales pour les workloads I/O-intensifs — des milliers d'opérations légères sans créer des milliers de vrais threads OS. Pour les calculs CPU lourds, tu as toujours besoin de threads. Les coroutines n'aideront pas là.

Interopérabilité — l'argument qu'on oublie souvent

Kotlin et Java fonctionnent ensemble dans le même projet. Simultanément.

Les fichiers Java et Kotlin se côtoient. Ils appellent mutuellement leurs méthodes. Ils compilent vers le même JAR. Ils partagent les mêmes bibliothèques.

Ce qui veut dire : ce n'est pas tout ou rien. Tu peux commencer avec de nouveaux modules en Kotlin sans toucher au code existant. La plupart des équipes font exactement ça — progressivement, sans héroïsme, sans nuits blanches.

Là où Java gagne vraiment

Documentation et Stack Overflow. Des décennies de documentation Java existent. N'importe quelle question — il y a déjà cent réponses sur Stack Overflow, dont une est correcte. L'écart avec Kotlin se réduit, mais il est encore là.

Projets legacy. Un système construit il y a 15 ans sur Java 8 qui fonctionne — n'y touche pas. Aucun gain, seulement des risques.

Environnements enterprise. Dans les grandes organisations, les stacks tech changent lentement et douloureusement. Java est familier pour tout le monde : l'équipe, les auditeurs, les équipes sécurité. Et pour le nouveau développeur qui arrivera dans un an et demandera « mais pourquoi on utilise Kotlin ? »

C++

Là où Kotlin gagne vraiment

Android. Affaire classée. Google recommande officiellement Kotlin, toutes les nouvelles API sont écrites pour lui, et Jetpack Compose est Kotlin-only. Démarrer un nouveau projet Android en Java en 2026 susciterait chez tes collègues la même réaction qu'arriver au bureau à cheval.

Nouveaux services backend. Moins de code, null-safety intégrée, coroutines — un choix sensé pour les nouveaux projets.

Kotlin Multiplatform. Logique métier partagée pour iOS, Android et le web depuis une seule base de code. Netflix, Philips et d'autres grandes entreprises l'utilisent déjà.

Faut-il vraiment choisir ?

Non.

Ce n'est pas « Java ou Kotlin ». C'est « Java seulement, ou Java plus Kotlin ».

Java restera — son écosystème est énorme et personne ne réécrit du code qui marche pour un nouveau langage. Kotlin grandit — surtout en mobile et dans les nouveaux projets backend.

Connaître les deux, c'est ouvrir plus de portes. Sans rien perdre de ce qu'on a déjà.

Pour un développeur Java, la transition prend des semaines. Même JVM, même logique. La seule chose à faire : commencer.

Si tu veux vraiment apprendre Kotlin — on a un cours. 62 niveaux, plus de 1 100 exercices, 3 projets pour ton portfolio. Le premier niveau est gratuit.

→ codegym.cc/fr/courses/kotlin

Continuer la lecture