Pause café #37. Un nouvel avenir pour Java. Perspectives JVM, Kotlin et Java après 2020

Source : Medium Java est principalement critiqué pour deux choses : la verbosité et la quantité de code passe-partout qui est généré dans de nombreux cas sans nécessité évidente. Même si j'ai toujours aimé Java, je ne peux pas dire que ces affirmations soient fausses. C'est bien vrai : un excès de détails en Java peut parfois être très ennuyeux. Cependant, nous devons admettre que nous ne vivons pas dans un monde idéal et que, dans la plupart des cas, nous devons choisir le moindre mal. Depuis sa création, Java n’a pas été parfait : nous le savons tous, mais la vraie question est de savoir pourquoi rien n’a été fait auparavant pour résoudre ces problèmes. Je pense que la seule raison pour laquelle les changements ont pris autant de temps est que le langage Java manquait de concurrence et que les choses étaient telles qu'elles étaient. Java a dominé le marché, probablement en raison du manque de concurrents sérieux et des gros efforts déployés d'abord par Sun, puis par Oracle. Le haut niveau de sécurité de type fourni par Java et la bonne structuration du langage l'ont rendu très populaire pour les grands projets. De plus, il s’agit d’un langage multiplateforme qui s’exécute sur sa propre machine virtuelle. Combiné à l’optimisation automatique des performances via le compilateur JIT, tout cela minimise l’impact d’un code mal écrit. Dans l’ensemble, c’est un ensemble de raisons assez convaincantes pour utiliser Java. Mais que s’est-il passé ensuite ? Ce qui s'est passé, c'est que de nouveaux langages sont arrivés sur le marché et peuvent fonctionner dans la même JVM que Java. Des langages qui ont éliminé certains des plus gros inconvénients de Java et, dans certains cas, ont offert aux développeurs un environnement plus agréable avec une barrière à l'entrée plus faible. Avant de continuer, faisons le point et jetons un bref coup d'œil à l'histoire des langages JVM.

Histoire des langages JVM

Tout d'abord, je voudrais clarifier une chose : je n'ai pas mentionné certains des langages JVM existants car ils n'ont jamais eu suffisamment de support pour être considérés comme des candidats à une utilisation généralisée dans notre industrie. Commençons maintenant notre bref aperçu de l’histoire des langages JVM. Nous aurons d’abord Java, le langage le plus ancien et le plus populaire du monde JVM. Java a été officiellement publié en janvier 1996, le langage existe donc depuis 24 ans. Pas mal, non ? Java était à l'origine un langage purement impératif qui suivait un style de programmation orienté objet ; c'était aussi un langage fortement typé. La syntaxe de Java est quelque peu similaire à celle des langages C++ et C, mais elle est considérée comme une version améliorée car l'écriture de code en Java est beaucoup plus facile qu'en C ou C++. D’un autre côté, nous avons le principal argument parmi ses détracteurs : la verbosité. Le deuxième langage JVM était Groovy. Il existe depuis 2003, même si sa première version standardisée, la 1.0, n'est apparue qu'en janvier 2007. L’avantage de Groovy est qu’il peut être utilisé comme langage de script. Groovy est un langage typé dynamiquement, la vérification du type est donc effectuée au moment de l'exécution. C'est l'une des raisons pour lesquelles certains développeurs n'aiment pas Groovy. Vous écrivez votre code dans Groovy et il semble correct au moment de la compilation, mais au moment de l'exécution, vous réalisez que quelque chose ne va pas. Puis un autre langage populaire est apparu : on parle de Scala. Il est sorti en 2004. Il a apporté un nouveau modèle de travail au monde JVM : la programmation fonctionnelle et une approche déclarative. Fondamentalement, Scala a été le premier langage à introduire le concept d’immuabilité, qui a ensuite été utilisé pour améliorer Java. D'un autre côté, les détracteurs n'aiment pas Scala en raison de sa grammaire complexe et de sa lisibilité plutôt faible. Le prochain langage à émerger du monde JVM fut Clojure, un langage purement fonctionnel. Il est devenu très populaire récemment, même s'il est apparu en 2007. Clojure est un langage basé sur LISP qui se caractérise par sa simplicité et l'utilisation de fonctions simples. Parmi ses inconvénients, il y a qu'il est typé dynamiquement (comme Groovy) et que la courbe d'apprentissage est beaucoup plus raide puisque sa syntaxe est complètement différente des autres langages JVM. Et enfin, nous avons Kotlin. Kotlin est apparu pour la première fois en février 2016 et depuis lors, sa popularité n'a cessé de croître. Il est développé par JetBrains avec pour objectif principal : résoudre les problèmes Java les plus connus. De par sa conception, Kotlin a conservé tous les avantages de Java, tout en résolvant de nombreux problèmes. Ce sont les langages JVM les plus importants. Comme je l'ai dit, nous avons manqué d'autres langages qui ne sont pas si populaires : Jython, JRuby, Ceylon, Fantom, etc. Si vous le souhaitez, vous pouvez découvrir la liste complète des langages JVM existantssur Wikipédia. Vous avez probablement réalisé que Java n’avait pas beaucoup de concurrence au cours des huit ou dix années qui ont suivi sa création, mais les choses ont changé depuis. Alors, la concurrence est-elle bonne ou mauvaise ?

Avantages d’une concurrence accrue

Java n'a pas beaucoup changé au cours de ses premières années. Probablement parce que ce n'était pas nécessaire. Ce langage a été largement utilisé et a toujours été très populaire, même s'il est loin d'être parfait. Mais ensuite des concurrents sont apparus, des langages plus modernes qui offraient de nouvelles fonctionnalités et résolvaient certains des problèmes qui tourmentaient les développeurs Java depuis longtemps. Par exemple, regardons le langage Scala. La popularité de Scala ne cesse de croître depuis 2009. Les développeurs ont accueilli favorablement ce nouveau style fonctionnel, qui leur a donné une plus grande flexibilité ainsi que la possibilité d'écrire du code parallèle en toute sécurité et facilement. Comment Oracle a-t-il répondu à cette nouvelle tendance ? En 2014, Java Lambdas et Streams sont apparus. Je pense que nous pouvons tous convenir que c'est à ce moment-là que Java a fait le plus grand pas vers la défaite de Scala. Désormais, tout programmeur sait que Scala n'est plus à la mode. Un autre avantage d'avoir plus de concurrents dans le monde JVM réside dans les améliorations constantes apportées au compilateur JIT et à la JVM. Désormais, de plus en plus de personnes souhaitent optimiser la JVM et améliorer les performances. La compétition fait donc du bien à tout le monde ! L’alternative la plus récente à Java est le langage Kotlin. Son apparition a été très importante pour le développement de Java, puisque le nouveau langage, en un sens, a montré à Oracle la voie à suivre. L'exemple de Kotlin a montré qu'il est possible de conserver les avantages de Java, mais de créer un langage plus compact dans lequel il est plus rapide d'écrire du code. Si vous regardez le graphique Google Trends, vous constaterez que de 2016 à 2018, la popularité de Kotlin a augmenté rapidement. Mais au cours des deux dernières années, l’enthousiasme a diminué. Oracle a examiné de près la réponse de l'industrie à Kotlin. Si vous regardez les notes de version du JDK 15 , vous verrez que certaines des nouvelles fonctionnalités Java sont des copies de ce qui est venu dans Kotlin. Il s'agit de nouvelles entrées Java , de nouveaux blocs de texte (chaînes multilignes avec guillemets triples) et d'un nouvel opérateur switch, qui est essentiellement une copie de l'opérateur whende Kotlin. Tout ce dont nous avons parlé est ce que j'appelle la « Kotlinisation de Java ». En devenant un concurrent plus fort, Kotlin a montré à Java la voie à suivre.

"Kotlinisation" de Java

Certaines des fonctionnalités Java à venir apporteront des améliorations significatives en termes de lisibilité et répondront à l'une des plus grandes faiblesses du langage Java : sa verbosité. On pourrait affirmer que bon nombre des fonctionnalités Java annoncées ressemblent étrangement à certaines fonctionnalités de Kotlin. Mais veuillez noter que la plupart d’entre eux sont des versions préliminaires . Cela signifie que si vous installez JDK 14 ou JDK 15 (lors de sa sortie), vous ne pourrez pas les utiliser par défaut. Les aperçus des fonctionnalités Java sont de nouvelles fonctionnalités introduites dans une version mais désactivées par défaut. Ils sont inclus dans la nouvelle version uniquement pour recueillir les commentaires de la communauté des développeurs, ils peuvent donc encore être sujets à changement. C'est pourquoi il est déconseillé de les utiliser dans le code de production. Pour les activer au moment de la compilation, vous devrez procéder comme suit :

javac --enable-preview --release 14

Si vous souhaitez les activer au moment de l'exécution, vous devrez exécuter ce qui suit :

java --enable-preview YourClass

Bien sûr, vous pouvez également les activer dans votre IDE, mais attention à ne pas activer l'aperçu par défaut dans tous vos nouveaux projets ! Jetons un coup d'œil aux changements qui auront un plus grand impact sur notre codage dans les futures versions de Java.

Messages Java

Java Records est une fonctionnalité que beaucoup d’entre nous réclament depuis longtemps. Je suppose que vous vous êtes retrouvé dans une situation où vous deviez implémenter toString , hashCode , equals , ainsi que des getters pour chaque champ existant. Kotlin dispose de classes de données pour résoudre ce problème , et Java a l'intention de faire de même en publiant des classes d'enregistrement que Scala possède déjà sous la forme de classes de cas . L'objectif principal de ces classes est de stocker des données immuables dans un objet. Prenons un exemple pour voir à quel point Java peut s'améliorer. Voici la quantité de code que nous devrions écrire pour créer et comparer notre classeEmployee :

package com.theboreddev.java14;

import java.util.Objects;

public class Employee {
    private final String firstName;
    private final String surname;
    private final int age;
    private final Address address;
    private final double salary;

    public Employee(String firstName, String surname, int age, Address address, double salary) {
        this.firstName = firstName;
        this.surname = surname;
        this.age = age;
        this.address = address;
        this.salary = salary;
    }

    public String getFirstName() {
        return firstName;
    }

    public String getSurname() {
        return surname;
    }

    public int getAge() {
        return age;
    }

    public Address getAddress() {
        return address;
    }

    public double getSalary() {
        return salary;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Employee employee = (Employee) o;
        return age == employee.age &&
                Double.compare(employee.salary, salary) == 0 &&
                Objects.equals(firstName, employee.firstName) &&
                Objects.equals(surname, employee.surname) &&
                Objects.equals(address, employee.address);
    }

    @Override
    public int hashCode() {
        return Objects.hash(firstName, surname, age, address, salary);
    }

    @Override
    public String toString() {
        return "Employee{" +
                "firstName='" + firstName + '\'' +
                ", surname='" + surname + '\'' +
                ", age=" + age +
                ", address=" + address +
                ", salary=" + salary +
                '}';
    }
}

Et aussi l'objet Addressqu'il contient :

import java.util.Objects;

public class Address {
    private final String firstLine;
    private final String secondLine;
    private final String postCode;

    public Address(String firstLine, String secondLine, String postCode) {
        this.firstLine = firstLine;
        this.secondLine = secondLine;
        this.postCode = postCode;
    }

    public String getFirstLine() {
        return firstLine;
    }

    public String getSecondLine() {
        return secondLine;
    }

    public String getPostCode() {
        return postCode;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Address address = (Address) o;
        return Objects.equals(firstLine, address.firstLine) &&
                Objects.equals(secondLine, address.secondLine) &&
                Objects.equals(postCode, address.postCode);
    }

    @Override
    public int hashCode() {
        return Objects.hash(firstLine, secondLine, postCode);
    }

    @Override
    public String toString() {
        return "Address{" +
                "firstLine='" + firstLine + '\'' +
                ", secondLine='" + secondLine + '\'' +
                ", postCode='" + postCode + '\'' +
                '}';
    }
}

Il y a probablement trop de code pour quelque chose d'aussi simple, n'est-ce pas ? Voyons maintenant à quoi cela ressemblera avec les nouvelles entrées Java :

public record EmployeeRecord(String firstName, String surname, int age, AddressRecord address, double salary) {
}

Et n'oublions pas la classe Address :

public record AddressRecord(String firstLine, String secondLine, String postCode) {
}

C'est la même chose que nous avons écrite plus tôt avec autant de code. D'accord : c'est incroyable. Et la quantité de code que nous allons économiser, et la facilité d'écriture ! Voyons maintenant quelles sont les différences avec le nouvel opérateur switch.

Opérateur amélioréswitch

Le nouvel opérateur switchJava résoudra certains des anciens problèmes, notamment certains bugs et duplications de code. Avec le nouvel opérateur, switchce problème sera résolu. Pour expliquer cela avec un exemple, nous allons créer une énumération DayOfTheWeeken Java :

public enum DayOfTheWeek {
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY,
    SUNDAY
}

Après cela, switchle nôtre nous dira quelle position dans la semaine correspond à ce jour. Voyons d'abord comment nous pouvons faire cela actuellement en utilisant Java 11.

final DayOfTheWeek dayOfTheWeek = DayOfTheWeek.THURSDAY;

        int position = 0;

        switch (dayOfTheWeek) {
            case MONDAY:
                position = 1;
                break;
            case TUESDAY:
                position = 2;
                break;
            case WEDNESDAY:
                position = 3;
                break;
            case THURSDAY:
                position = 4;
                break;
            case FRIDAY:
                position = 5;
                break;
            case SATURDAY:
                position = 6;
                break;
            case SUNDAY:
                position = 7;
                break;
        }

        System.out.println("Day " + dayOfTheWeek + " is in position " + position + " of the week");

Avec l'instruction actuelle, switchnous devrons utiliser une variable, et si nous manquons un des jours de la semaine, notre code se compilera très bien. C'est un des problèmes des opérateurs switch: ils sont trop sujets aux erreurs. Alors, comment Java 14 améliore-t-il les choses ? Jetons un coup d'oeil :

final DayOfTheWeek dayOfTheWeek = DayOfTheWeek.THURSDAY;

        int position = switch (dayOfTheWeek) {
            case MONDAY -> 1;
            case TUESDAY -> 2;
            case WEDNESDAY -> 3;
            case THURSDAY -> 4;
            case FRIDAY -> 5;
            case SATURDAY -> 6;
            case SUNDAY -> 7;
        };

        System.out.println("Day " + dayOfTheWeek + " is in position " + position + " of the week");

Comme vous pouvez le constater, les nouveaux opérateurs switchpeuvent être utilisés comme expression, pas seulement comme instruction. Le résultat est plus concis et expressif. Cela suffirait à convaincre beaucoup d'entre nous de les utiliser, mais l'une des améliorations majeures est que désormais les instructions switchne seront pas compilées à moins que nous couvrions tous les cas dans notre switch. Il nous montrera cette erreur, par exemple :

Error:(9, 24) java: the switch expression does not cover all possible input values

Désormais, il sera impossible de passer outre les cas chez nos opérateurs switch. Ceci est très similaire aux opérateurs whende Kotlin, que vous pouvez lire dans la documentation . Jetons également un coup d'œil aux nouveaux blocs de texte.

Blocs de texte

Vous êtes-vous déjà plaint de la difficulté d'attribuer un blob JSON à une variable en Java ? Java possède des séquences multilignes que vous pouvez décrire en les plaçant entre guillemets triples. Une fois cette fonctionnalité officiellement publiée, il deviendra beaucoup plus facile de décrire de longues séquences sur plusieurs lignes. Regardons les différences entre les deux modes. Si nous voulons utiliser du JSON formaté dans une variable, cela s'avère mauvais :

final String text = "{\"widget\": {\n" +
                "    \"debug\": \"on\",\n" +
                "    \"window\": {\n" +
                "        \"title\": \"Sample Konfabulator Widget\",\n" +
                "        \"name\": \"main_window\",\n" +
                "        \"width\": 500,\n" +
                "        \"height\": 500\n" +
                "    },\n" +
                "    \"image\": { \n" +
                "        \"src\": \"Images/Sun.png\",\n" +
                "        \"name\": \"sun1\",\n" +
                "        \"hOffset\": 250,\n" +
                "        \"vOffset\": 250,\n" +
                "        \"alignment\": \"center\"\n" +
                "    },\n" +
                "    \"text\": {\n" +
                "        \"data\": \"Click Here\",\n" +
                "        \"size\": 36,\n" +
                "        \"style\": \"bold\",\n" +
                "        \"name\": \"text1\",\n" +
                "        \"hOffset\": 250,\n" +
                "        \"vOffset\": 100,\n" +
                "        \"alignment\": \"center\",\n" +
                "        \"onMouseUp\": \"sun1.opacity = (sun1.opacity / 100) * 90;\"\n" +
                "    }\n" +
                "}} ";

En revanche, lorsque les nouveaux blocs de texte seront publiés, tout deviendra beaucoup plus simple :

final String multiLineText = """
                {"widget": {
                    "debug": "on",
                    "window": {
                        "title": "Sample Konfabulator Widget",
                        "name": "main_window",
                        "width": 500,
                        "height": 500
                    },
                    "image": {\s
                        "src": "Images/Sun.png",
                        "name": "sun1",
                        "hOffset": 250,
                        "vOffset": 250,
                        "alignment": "center"
                    },
                    "text": {
                        "data": "Click Here",
                        "size": 36,
                        "style": "bold",
                        "name": "text1",
                        "hOffset": 250,
                        "vOffset": 100,
                        "alignment": "center",
                        "onMouseUp": "sun1.opacity = (sun1.opacity / 100) * 90;"
                    }
                }}
                """;

Cela a définitivement l'air mieux. Tout cela est déjà pris en charge dans Kotlin, comme vous pouvez le voir dans ses définitions de types . Nous avons donc vu que Java « hérite » de nombreuses solutions à ses propres problèmes d'un de ses concurrents : Kotlin. Nous ne savons pas si Oracle a réagi à temps pour lutter contre la montée en puissance de Kotlin ou s'il est arrivé trop tard. Personnellement, je pense que Java fait le bon pas en avant, même si ces changements ont été initiés d'une manière ou d'une autre par ses concurrents et peuvent intervenir avec un certain retard.

Conclusion

Je pense que la concurrence est la meilleure chose qui soit jamais arrivée au langage Java. Mon impression est que sinon Java se reposerait sur ses lauriers. De plus, les concurrents de Java ont montré qu'une autre manière de programmer était possible, montrant comment aller de l'avant et éviter les méthodes obsolètes et inefficaces d'écrire du code. Les changements futurs feront de Java plus puissant que jamais, un langage adapté à l’ère moderne, un langage qui veut évoluer.