Je vois du vrai et de l’obsolète dans ce que tu écris :
Java est très verbeux, donc plus difficile à lire.
Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
Il n'est pas assez paramétrique ce qui oblige à jouer avec des @..., voir des bouts de définition en XML à coté du code, ce qui implique lourdeur, et lenteur.
Sur un projet moderne, ça fait des années que je n’ai plus eu à configurer quoi que ce soit en XML à côté du code en Java. Quant à la lourdeur et la lenteur incluses parce que « pas assez paramétrique », je suis réellement curieux d’avoir un exemple de ce que tu entends par là (c’est une vraie question, pas un troll).
Une appli web qui ne fait pas grand chose : 500Mo d'artefact de gitlab...
Ha ? Tu utilises quoi comme framework ? J’ai un projet perso avec Spring Boot + Kotlin + connexion à la BDD + génération de pages en HTML avec Thymeleaf, je râlais parce que le JAR exécutable (et unique fichier produit) était passé de 49 à 65 Mo en passant à la dernière version de Spring Boot. C’est objectivement gros, surtout quand Quarkus peut produire des binaires natifs beaucoup plus petits (mais sur des piles moins grosses), mais un ordre de grandeur sous ce que tu donnes.
Le type 'null' est toujours là. Les types de base ne sont pas des objets.
Tout ça, OK (et à mon sens le null est peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.
Il n'y a pas de notion de layout mémoire, tout objet est "boxé" ce qui implique une grosse quantité de pointeur de partout.
Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
Le modèle "multi-thread" est pas top, ce n'est ni Go, ni Rust.
C’est assez vrai, mais Java date de 1996, Go de 2009, Rust de 2010. Les API récentes ont aussi beaucoup amélioré l’utilisation des threads, et on trouve des API réactives tout à fait convaincantes et performantes depuis peu.
Les licences entre openjdk et jdk d'Oracle, ne sont pas claire.
C’est en effet un problème, de même que les incompatiblités entre les différents fournisseurs de JVM/JDK (on les rencontre surtout pour les modes graphiques).
Et retrouver aujourd'hui, une jvm 8 est compliqué.
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . En réponse à la dépêche Java 15 est sorti. Évalué à 5.
Je vois du vrai et de l’obsolète dans ce que tu écris :
Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
Sur un projet moderne, ça fait des années que je n’ai plus eu à configurer quoi que ce soit en XML à côté du code en Java. Quant à la lourdeur et la lenteur incluses parce que « pas assez paramétrique », je suis réellement curieux d’avoir un exemple de ce que tu entends par là (c’est une vraie question, pas un troll).
Ha ? Tu utilises quoi comme framework ? J’ai un projet perso avec Spring Boot + Kotlin + connexion à la BDD + génération de pages en HTML avec Thymeleaf, je râlais parce que le JAR exécutable (et unique fichier produit) était passé de 49 à 65 Mo en passant à la dernière version de Spring Boot. C’est objectivement gros, surtout quand Quarkus peut produire des binaires natifs beaucoup plus petits (mais sur des piles moins grosses), mais un ordre de grandeur sous ce que tu donnes.
Tout ça, OK (et à mon sens le
nullest peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
C’est assez vrai, mais Java date de 1996, Go de 2009, Rust de 2010. Les API récentes ont aussi beaucoup amélioré l’utilisation des threads, et on trouve des API réactives tout à fait convaincantes et performantes depuis peu.
C’est en effet un problème, de même que les incompatiblités entre les différents fournisseurs de JVM/JDK (on les rencontre surtout pour les modes graphiques).
10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est à connaitre si tu travailles avec Java).
La connaissance libre : https://zestedesavoir.com