Comme le fait remarquer Pierre Tramo, il existe des contraintes qui empêcheraient une implémentation libre Java d'être reconnue comme telle.
Le processus de normalisation de Java est à mon avis particulièrement efficace, surtout si on regarde le C ou le SQL (normalisés par l'ISO). Parmi tout l'éventail des compilateurs C, combien respectent la norme et toute la norme C99 ? Quelle proportion de programmes C n'est pas liée à un compilateur particulier ? Quant au SQL, il est affligeant de voir à quel point la norme est insuffisante : pas d'auto-incrément par exemple, qui est un type tellement indispensable que même dans des systèmes de bases de données très basiques (je serais tenté de citer Access, mais bon, restons sérieux ^_^ ) on n'envisagerait pas de ne pas trouver une telle fonctionnalité, mais comme la norme ne prévoit rien, chaque système de bases de données a choisi sa propre solution, toutes incompatibles entre elles, évidemment.
Ainsi on peut comprendre la motivation de Sun de ne pas commettre les mêmes erreurs pour ne pas comprommettre la crédibilité même de la normalisation Java. Et force est de reconnaître que de ce point de vue, c'est jusqu'à présent un succès, d'autant plus que la norme évolue à un rythme soutenu et est de plus en plus indépendante vis-à-vis de Sun.
Par contre, dans l'arsenal de mesures que Sun a prévu pour protéger la norme, certaines vont à l'encontre de l'existence d'implémentations libres et n'ont (toujours à mon avis) aucune justification crédible dans le cadre de la défense d'une norme forte et cohérente.
Donc il n'est malheureusement pas totalement faux d'écrire Java(tm) != libre.
[^] # Re: Des incidences de la Société du Spectacle sur le public linuxéférien
Posté par Pierre Tramo . En réponse à la dépêche Java libre : Sun sur la défensive. Évalué à 2.
Le processus de normalisation de Java est à mon avis particulièrement efficace, surtout si on regarde le C ou le SQL (normalisés par l'ISO). Parmi tout l'éventail des compilateurs C, combien respectent la norme et toute la norme C99 ? Quelle proportion de programmes C n'est pas liée à un compilateur particulier ? Quant au SQL, il est affligeant de voir à quel point la norme est insuffisante : pas d'auto-incrément par exemple, qui est un type tellement indispensable que même dans des systèmes de bases de données très basiques (je serais tenté de citer Access, mais bon, restons sérieux ^_^ ) on n'envisagerait pas de ne pas trouver une telle fonctionnalité, mais comme la norme ne prévoit rien, chaque système de bases de données a choisi sa propre solution, toutes incompatibles entre elles, évidemment.
Ainsi on peut comprendre la motivation de Sun de ne pas commettre les mêmes erreurs pour ne pas comprommettre la crédibilité même de la normalisation Java. Et force est de reconnaître que de ce point de vue, c'est jusqu'à présent un succès, d'autant plus que la norme évolue à un rythme soutenu et est de plus en plus indépendante vis-à-vis de Sun.
Par contre, dans l'arsenal de mesures que Sun a prévu pour protéger la norme, certaines vont à l'encontre de l'existence d'implémentations libres et n'ont (toujours à mon avis) aucune justification crédible dans le cadre de la défense d'une norme forte et cohérente.
Donc il n'est malheureusement pas totalement faux d'écrire Java(tm) != libre.