Ou pas. Peut être que je fais parfaitement la différence entre la Java Language Specification et la Java Virtual Machine Spécification. Voir même j'ai une petite idée des trous qu'il y a entre les deux même si je suis très très loin d'être un dev OpenJDK ou ex Harmony.
J'ai juste suffisament tordu le truc dans tout les sens ces dix dernières années pour avoir quelques notions relativement solides...
Tu aurais quelque chose d'un peu plus concret que « Java c'est de la merde donc la JVM c'est de la merde » ?
Java n'est pas de la merde. Ses choix initiaux se font par contre de plus en plus payer de jour en jour. On est de deux axiomes: compatibilité reine et moins on t'en donne mieux tu te portes. Dans l'idée ca se tient, sauf qu'en pratique les deux ont conflictés et conflicteront toujours de manière de plus en plus violente. Le sous ensemble fourni était mauvais (et l'est toujours) donc on a passé les dix dernières années à le patcher comme on pouvait. Sauf que la compatibilité à forcée à faire des implémentations complexes de leaky abstraction bourrées de corner cases: Les generics fuient dans tout les sens, l'autoboxing est une horreur tant pour le footprint, que pour les perfs que pour la sureté, les lambdas sont une demi réponse au manque d'objets de premier ordre ca ne couvre pas 50% des besoins et la tête du bytecode à générer est rigolote, l'ajout des default methods est un gros patch qui encore une fois ne règle pas le vrai problème de la composition etc.
Plus ca va, plus les problèmes d'impedance entre Java et ce vers quoi on veut aller augmente. Et c'est encore renforcé par le JDK qui soufre exactement des mêmes symptomes.
Je n'ai jamais dit "beurk caca", la JVM est ses langages sont mon outil de travail depuis des années et c'est actuellement un excellent choix pour beaucoup de chose notamment grace à son ecosysteme, outillage et sa facilité de déployment pour des perfs honnorables.
Par contre dire que l'interop des langages sur la JVM c'est chaud bouillant ca me parait objectif. Si les gens utilisent la JVM c'est rarement pour le côté technique mais pour choper la traction de son ecosysteme afin de pouvoir percer. Et la ca demande d'avoir un langage sur la JVM et qui peut parler à du Java. Et c'est la que les ennuis commencent. Si tu es intéressé les Talks du Java Language Submit sont en ligne depuis des années. On peut aussi dire que Java est de plus en plus en boulet d'une complexité de plus en plus grande pour de faibles de gain en perf ou en sureté (pas du simple sucre syntaxique qui génére le boilerplate pour toi). De même que le JDK reste aussi pauvre conceptuellement d'année en année par rapport à d'autre plateformes.
[^] # Re: « impropre à la création d'applications web complexe » ?
Posté par ckyl . En réponse au journal Normalisation du langage Dart de Google par l'Ecma. Évalué à 3.
Ou pas. Peut être que je fais parfaitement la différence entre la Java Language Specification et la Java Virtual Machine Spécification. Voir même j'ai une petite idée des trous qu'il y a entre les deux même si je suis très très loin d'être un dev OpenJDK ou ex Harmony.
J'ai juste suffisament tordu le truc dans tout les sens ces dix dernières années pour avoir quelques notions relativement solides...
Java n'est pas de la merde. Ses choix initiaux se font par contre de plus en plus payer de jour en jour. On est de deux axiomes: compatibilité reine et moins on t'en donne mieux tu te portes. Dans l'idée ca se tient, sauf qu'en pratique les deux ont conflictés et conflicteront toujours de manière de plus en plus violente. Le sous ensemble fourni était mauvais (et l'est toujours) donc on a passé les dix dernières années à le patcher comme on pouvait. Sauf que la compatibilité à forcée à faire des implémentations complexes de leaky abstraction bourrées de corner cases: Les generics fuient dans tout les sens, l'autoboxing est une horreur tant pour le footprint, que pour les perfs que pour la sureté, les lambdas sont une demi réponse au manque d'objets de premier ordre ca ne couvre pas 50% des besoins et la tête du bytecode à générer est rigolote, l'ajout des default methods est un gros patch qui encore une fois ne règle pas le vrai problème de la composition etc.
Plus ca va, plus les problèmes d'impedance entre Java et ce vers quoi on veut aller augmente. Et c'est encore renforcé par le JDK qui soufre exactement des mêmes symptomes.
Je n'ai jamais dit "beurk caca", la JVM est ses langages sont mon outil de travail depuis des années et c'est actuellement un excellent choix pour beaucoup de chose notamment grace à son ecosysteme, outillage et sa facilité de déployment pour des perfs honnorables.
Par contre dire que l'interop des langages sur la JVM c'est chaud bouillant ca me parait objectif. Si les gens utilisent la JVM c'est rarement pour le côté technique mais pour choper la traction de son ecosysteme afin de pouvoir percer. Et la ca demande d'avoir un langage sur la JVM et qui peut parler à du Java. Et c'est la que les ennuis commencent. Si tu es intéressé les Talks du Java Language Submit sont en ligne depuis des années. On peut aussi dire que Java est de plus en plus en boulet d'une complexité de plus en plus grande pour de faibles de gain en perf ou en sureté (pas du simple sucre syntaxique qui génére le boilerplate pour toi). De même que le JDK reste aussi pauvre conceptuellement d'année en année par rapport à d'autre plateformes.