Le JCP a tout de même son gros effet pervers : le lobbying.
Jusqu'à récemment, il n'était constitué que d'industriel qui crééait surtout des JSRs pour mettre en avant leur propre produit. Car il y a une chose qui très forte mais qui créé tout le lobbying, toute JSR doit être accompagnée d'une implémentation.
On en veut pour preuve le problème avec Jigsaw/OSGi, Closure/Lamba Expression/etc, ou même l'API de cache de Red Hat...
Ensuite avoir un comité de pilotage implique une forte lenteur des changements puisqu'il faut que la moitié des membres aillent dans le même sens. Le langage n'évolue pas énormément, malgré toute l'envie qu'il y a de toute part (utilisateurs, JUG leaders, industriels, etc.). On voit bien de nouvelles fonctionnalités s'ajouter mais peu de choses en place qui évolue.
Un autre point noir pour Java et une des fameuses règles qui finira sûrement par tuer Java si elle n'est pas brisée d'ici les 2-3 prochaines versions majeurs : la rétrocompatibilité binaire. La règle qui tue tout, comme avoir des génériques uniquement "compile-time". Aucun intérêt puisque la compatibilité de l'API n'est pas garantie.
Concernant l'investissement de Sun dans Java, il ne faut pas oublié qu'une part importante des développeurs et des technologies intégrés dans Java ne sont pas de Sun mais d'Apache, IBM, Xerox, Red Hat et autres.
Aujourd'hui la seule force de Java c'est d'avoir été là et relativement bon avec une courbe d'apprentissage très rapide au moment de la bulle Internet. Tout comme COBOL dans les années 70-80. Franchement, il y a un paquet de langage que je préfère à Java. Cependant Java n'a aucune niche, donc il est voué à mourir s'il ne se met pas au niveau de langage plus évolué. Ou alors l'avenir se jouera sur des langages alternatifs comme Groovy et Scala. Comme C# l'a été pour la plateforme Microsoft en remplacement de VB et C++.
7 |
0 |