Ce que je ne comprends pas, c'est que tu parle de problème de bibliothèque standard (je ne dis pas qu'elle n'a pas de problème) et qu'il est nécessaire d'utiliser des bibliothèques autres pour faire certaines choses. Hors la plupart des langages compilés sans JIT ont une bibliothèque standard bien plus petite (je pense en particulier à C et C++, mais c'est applicable à d'autres). Je suis d'accord qu'une partie des bibliothèques actuelles sont trop grosses, mais le problèmes c'est surtout qu'elles sont trop grosses et cherchent à faire un peu trop de choses.
Y'a un moment ou il faut faire quelque chose (et on peut le faire sans rien, ou trop, casser) mais le JDK à du mal.
Sans trop casser ce n'est pas acceptable pour la politique de Java. Les nouvelles versions du langage ont déjà bien du mal à être utilisée donc casser la compatibilité même faiblement ce serait se tirer une balle dans le pied. Il n'y a qu'à voir les sécurités Java2 qui ne sont que très rarement utilisées. Sans rien casser je demande à voir. Par exemple tu reproche l'API d'accès au fichier. En Java 5 est arrivé Scanner qui simplifié la lecture en en Java 7 nio2 fini le travail, tu peut toujours continuer à utiliser les anciennes API (d'ailleurs nio2 ne remplace pas tout nio ni tout io). Le projet fonctionne par ajout de fonctionnalités dans l'API, mais c'est apparemment assez difficile de se mettre d'accord (par exemple les lambdas semblent être un vrai combat dans le JCP).
En fait le problème est juste délégué d'un niveau on se retrouve avec un sale JAR hell et des dépendances délirantes.
AMHA c'est surtout du à une très forte réutilisation, là où les autres écosystème en font beaucoup moins. C'est lié à la taille des bibliothèques qui cherchent toute à te préparer une expresso en réutilisant chacune une café différent (ou des fois le même café mais pas de la même année).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Usine
Posté par barmic . En réponse à la dépêche Nouvelle version de Scub Foundation, usine logicielle Java libre. Évalué à 2.
Ce que je ne comprends pas, c'est que tu parle de problème de bibliothèque standard (je ne dis pas qu'elle n'a pas de problème) et qu'il est nécessaire d'utiliser des bibliothèques autres pour faire certaines choses. Hors la plupart des langages compilés sans JIT ont une bibliothèque standard bien plus petite (je pense en particulier à C et C++, mais c'est applicable à d'autres). Je suis d'accord qu'une partie des bibliothèques actuelles sont trop grosses, mais le problèmes c'est surtout qu'elles sont trop grosses et cherchent à faire un peu trop de choses.
Sans trop casser ce n'est pas acceptable pour la politique de Java. Les nouvelles versions du langage ont déjà bien du mal à être utilisée donc casser la compatibilité même faiblement ce serait se tirer une balle dans le pied. Il n'y a qu'à voir les sécurités Java2 qui ne sont que très rarement utilisées. Sans rien casser je demande à voir. Par exemple tu reproche l'API d'accès au fichier. En Java 5 est arrivé Scanner qui simplifié la lecture en en Java 7 nio2 fini le travail, tu peut toujours continuer à utiliser les anciennes API (d'ailleurs nio2 ne remplace pas tout nio ni tout io). Le projet fonctionne par ajout de fonctionnalités dans l'API, mais c'est apparemment assez difficile de se mettre d'accord (par exemple les lambdas semblent être un vrai combat dans le JCP).
AMHA c'est surtout du à une très forte réutilisation, là où les autres écosystème en font beaucoup moins. C'est lié à la taille des bibliothèques qui cherchent toute à te préparer une expresso en réutilisant chacune une café différent (ou des fois le même café mais pas de la même année).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)