C'est le moment idéal pour publier ceci, juste à la sortie de Java 19. Oui, un autre article "ma langue est meilleure". Non, je ne voulais pas l'écrire. Mais parfois, la des gens prend le dessus sur moi. Dans ce cas, le message a commencé comme un commentaire et j'ai fini par décider de le transformer en message. Cela a été renforcé avec qui se plaint principalement de Quarkus (un peu injustement si je puis ajouter). mauvaise projection ce post Le premier article est principalement un appât à clics absurde et obsolète. Je vais vous résumer dans les affirmations suivantes : Getters/Setters Surcharge d'opérateur manquant spécifiquement pour sur les collections et sur n'importe quoi [] + Exceptions vérifiées Gestion des dépendances Le deuxième article contient des plaintes qui sont davantage liées à Jakarta EE et à l'esthétique générale des programmeurs dans la JVM. Plus précisément, l'utilisation d'annotations pour les validations et les revendications similaires. Il s'agit d'un article bien mieux informé, mais qui présente quelques défauts que j'aborderai vers la fin. Getters et Setters Les getters et les setters ne sont pas nécessaires pour Java moderne. Nous avons des records depuis Java 14 et Lombok est toujours bon malgré certaines affirmations contraires. Le seul point où nous aurions besoin de getter/setters est dans des contextes très spécifiques (par exemple JPA) où encore une fois, Lombok résout parfaitement le problème. L'article s'appuie sur une tirade sur le manque de fonctionnalités de sucre syntaxique en Java. C'est intentionnel. Vous pouvez consulter Kotlin si vous êtes intéressé par les dernières nuances de syntaxe. Java est "lent et régulier". C'est une bonne chose et la principale raison de la longévité de Java. Sucre de syntaxe et surcharge d'opérateur Java moderne inclut des modèles dans switch, var, chaînes multilignes et bien plus encore. Certaines fonctionnalités à venir incluent des modèles de chaîne. La prise en charge des modèles de chaîne prend un certain temps car Java veut "faire les choses correctement". Il y a un certain support pour cela au niveau de l'API (et ce depuis un certain temps). Ce n'est pas performant. L'objectif des modèles de chaîne est de créer une syntaxe radicalement remplaçable qui choses comme : permettrait des ResultSet rs = DB."SELECT * FROM Person p WHERE p.last_name = \{name}"; depuis la publication de cet article, les développeurs ont supposé à tort que le code ci-dessus était une vulnérabilité d'injection SQL. Ce n'est pas le cas. Cela ressemble à un remplacement de chaîne, mais c'est du code qui utilise cette syntaxe pour générer un appel SQL paramétré. Mise à jour : Notez que est une variable que le compilateur vérifiera et obtiendra dynamiquement de la portée ! name La base de peut être implémentée de manière personnalisée par le développeur et n'a pas besoin d'être "intégrée", vous pouvez donc créer des modèles complexes directement sur place. DB Mais parlons du Java que nous avons aujourd'hui, pas de celui qui arrivera dans 6 mois. L'utilisation d'append n'a pas été la recommandation pour depuis une décennie ou plus. Utilisez qui est le plus performant et le plus facile à lire. À propos des collections, la différence entre et est littéralement de quatre caractères. Ces personnages comptent beaucoup. Nous pouvons facilement contourner cela. Nous pouvons également comprendre les différences sémantiques. Les tableaux Java sont TRÈS rapides, dans de nombreux cas, la vitesse native est rapide. Les collectes ne peuvent pas être aussi rapides, le fait que nous puissions voir cela ici instantanément est très précieux. String + get() [] Le fait que les opérateurs être surchargés est un énorme avantage. Si je vois , je sais qu'il s'agit soit d'une chaîne, soit d'un nombre, et non d'une méthode cachée. C'est l'une des plus grandes forces de Java et l'une des raisons pour lesquelles il est populaire depuis près de 30 ans alors que d'autres langages sont laissés de côté. La syntaxe de Java est conçue pour une lecture à grande échelle. Lorsque vous avez un projet avec 1 million de lignes de code ou même 100 000, les problèmes se déplacent. À ce stade, il est difficile de découvrir que le programmeur X du module Y a remplacé un opérateur de manière incorrecte lorsque vous déboguez un problème. La syntaxe doit être simple à ce stade et tout coût mineur que vous avez initialement économisé sera payé avec un intérêt de 10x. La définition des retournements simples en tant que code devient plus complexe et vieillit. Ajoutez à cela la puissance des outils pour analyser un code simple et strict à grande échelle et cela devient un avantage encore plus important. ne puissent pas a + b Exceptions vérifiées Les exceptions cochées sont facultatives. Mais c'est l'une des MEILLEURES fonctionnalités de Java. Tant de code échoue de manière inattendue. Quand vous construisez des trucs comme passe-temps, ça peut aller. Lorsque vous souhaitez créer une application professionnelle, vous devez gérer chaque erreur. Les exceptions vérifiées vous aident à éviter ce non-sens. Les gens détestent les exceptions cochées à cause de la paresse. Java vous protège contre vous-même. Il ne devrait y avoir aucun cas où j'établis une connexion réseau, une connexion DB, ouvre un fichier, etc. et n'ai pas besoin de gérer l'erreur potentielle. Je peux le lancer, mais les exceptions vérifiées m'obligent à continuer à le lancer quelque part. C'est une fonctionnalité incroyable. Dépendances J'ai beaucoup de problèmes avec Maven et Gradle. Mais quand vous le comparez à à peu près n'importe quel autre système de dépendance avec un peu de millage dessus, ils se débrouillent très bien. Ils ont des problèmes mais vous ne pouvez pas les comparer à quelque chose de jeune comme le fret qui n'a presque pas de colis en comparaison. Maven central est avec 27 téraoctets de jars et 496 milliards de requêtes. Il fonctionne parfaitement et n'a presque pas de temps d'arrêt. MASSIF D'autres outils comme NPM démontrent parfaitement les points forts de maven. Si les dépendances dans maven posent problème, alors NPM a 100 fois le problème et aucune supervision. Au fur et à mesure que ces choses grandissent, il y a des complexités. Surtout avec plusieurs versions de maven sur le marché. Cependant, l'une des choses que maven et gradle ont pour eux est l'outillage. Dans de nombreux cas, les IDE aident à résoudre les problèmes et à trouver le correctif immédiatement. Problèmes culturels en Java Le deuxième article est plus intéressant et dans une certaine mesure, je suis d'accord. Les développeurs Java ont tendance à transformer chaque problème en un problème plus compliqué. Dans certains cas, cela est nécessaire, Java est le gorille de 800 livres des plates-formes de programmation et ses solutions sont souvent sur-conçues. Cela a tendance à être meilleur que sous-alimenté, mais cela a un prix. Pourquoi l'annotation pour la validation L'article a soulevé un exemple intéressant qui semble être la "bonne chose" pour l'observateur occasionnel mais qui est problématique. @NotNull @Email String noReplyEmailAddress L'auteur prétend que c'est mauvais et qu'il faut implémenter un typage personnalisé, par exemple : public record EmailAddress(String value) { public EmailAddress { // We could've used an Either data type, ofc; Objects.requireNonNull(value); // regexp could be better if (!value.matches("^[^@\\s]+@\\S+$")) throw new IllegalArgumentException( String.format("'%s' is not a valid email address", value)); } } Ceci est tout à fait possible en Java car le code ci-dessus est un code Java valide. Mais il a plusieurs problèmes, c'est pourquoi nous avons la validation du bean. Cela ne peut pas être optimisé - La validation du bean peut être déplacée vers le haut de la chaîne de validation par le framework. Il peut même être validé dans le code côté client de manière transparente puisqu'il s'agit d'une API déclarative. Ici, nous devons réellement exécuter le constructeur pour effectuer la validation. Les annotations déclaratives peuvent être déplacées vers le bas de la chaîne pour appliquer les contraintes de la base de données de manière transparente, etc. Nous pouvons appliquer plusieurs annotations à la fois La syntaxe est plus concise Par conséquent, les annotations peuvent sembler bizarres et n'imposent pas la saisie. C'est vrai. Mais ils augmentent les performances et la puissance. Il y a beaucoup de réflexion et de bon sens derrière leur utilisation. Je comprends le point des auteurs, je ne suis pas non plus un grand fan d'IoC, mais dans ce cas précis, il a tort. Pour terminer Cet article a passé beaucoup trop de temps sur la défensive. Il est temps de changer de vitesse. Java existe depuis près de 30 ans et est encore principalement compatible avec Java 1.0. C'est fantastique et incomparable ! L'un des pouvoirs de son approche conservatrice est qu'il peut faire d'étonnantes optimisations "sous le capot" sans qu'aucun d'entre vous ne remarque ce qui s'est passé. Java 9 a complètement manière transparente et a considérablement réduit l'utilisation de la RAM. De même, Loom augmentera le débit des applications synchrones Java. Valhalla améliorera encore les performances de collecte et unifiera le clivage Objet/Primitif. Panama va enfin nous débarrasser de JNI et rendre le processus d'intégration avec le code natif tellement plus agréable. remplacé la façon dont les chaînes étaient représentées en mémoire de La bonne chose est que la JVM est une grande tente. Si vous n'êtes pas fan de Java, Kotlin ou Scala pourraient convenir à vos goûts. L'avantage de la JVM s'applique universellement et la plupart des fonctionnalités que j'ai mentionnées ici bénéficieront à l'ensemble de notre écosystème commun. Cette histoire a été publiée pour la première fois ici.

Chain

Instantly

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Talk to the Duck Blog

Read My Stories

Newsletter

Follow me on Twitter

2021 - HackerNoon Contributor of the Year - KOTLIN

2021 - HackerNoon Contributor of the Year - JAVA

Nominated for 2022 - HackerNoon Contributor of the Year - Monitoring

Nominated for 2022 - HackerNoon Contributor of the Year - Debugging

Nominated for 2022 - HackerNoon Contributor of the Year - Java

Nominated for 2022 - HackerNoon Contributor of the Year - Coding Skills

Nominated for 2022 - HackerNoon Contributor of the Year - Software Testing

Author/DevRel/Entrepreneur/Hacker

Cet audio est produit dans la langue originale de l'histoire !

Trop long; Pour lire

In your car, at home, or at work — Bosch technology shapes many areas of life.

Pourquoi Java est toujours populaire

Pourquoi Java est toujours populaire

Trop long; Pour lire

Company Mentioned

Coin Mentioned

Shai Almog

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

Pourquoi Java est toujours populaire

Trop long; Pour lire

Company Mentioned

Coin Mentioned

Shai Almog

About Author

ÉTIQUETTES

Languages

CET ARTICLE A ÉTÉ PARU DANS...

HISTOIRES CONNEXES