si, mais il faut réfléchir un tout petit peu.
Oui, réfléchissons ensemble, encore une fois, sur le fait que le langage Java peut être utilisé dans un environnement libre.
allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ?
C'est défini intégralement par le Java Community Process (JCP) qui est une instance distincte de Sun. Celui-ci définit pour les versions à venir du langage et de la plateforme Java le contenu et la manière dont ce sera réalisé. N'importe qui peut se présenter pour participer à des JSR (Java specif... je-sais-plus-quoi). Ces JSR définissent chacune une fonctionnalité qui sera intégrée dans la prochaine version de la JVM. Par exemple, les JSR de Java 1.5 (que j'appelerais personnellement Java3) définissent la généricité (argl), les annotations (un truc formidablement génial) l'autoboxing des types primitifs (on se demande pourquoi ça arrive seulement maintenant), j'en passe et des meilleures.
Une fois les JSR adoptées, les fournisseurs de JVM divers (dont fait partie Sun) doivent implémenter celles-ci pour se voir reconnus fabricants de JVM.
c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?
Oui, grâce aux JVM libres, ou en utilisant une JVM d'un autre fabricant de Logiciel (BEA, IBM)
oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC
Bien sûr que si, ces classes sont une partie des APIs Java. En tant que telles, si les implémentations fournies dans la JVM sont la propriété de Sun, on est toutefois libre d'en faire d'autres.
sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.
Tu dis quand même un peu n'importe quoi. Les restrictions de look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple qui ne souhaitent pas (ce que je peux comprendre) voir leur travail utilisé sans leur accord sur un système d'exploitation concurrent.
De la même manière, le fait que le look'n'feel Metal ne soit pas utilisable ne me dérange plas plus que ça.
je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.
[^] # Re: Comparé aux autres ?
Posté par Nicolas Delsaux . En réponse à la dépêche Lucane Groupware 0.7 stable est disponible. Évalué à 2.
Oui, réfléchissons ensemble, encore une fois, sur le fait que le langage Java peut être utilisé dans un environnement libre.
allez, au pif : les classes java de base, ce qui fait le fichier rt.jar, tout ce qui rentre dans java.* et ceci inclut java2d aka Swing, les JFC, c'est libre ?
C'est défini intégralement par le Java Community Process (JCP) qui est une instance distincte de Sun. Celui-ci définit pour les versions à venir du langage et de la plateforme Java le contenu et la manière dont ce sera réalisé. N'importe qui peut se présenter pour participer à des JSR (Java specif... je-sais-plus-quoi). Ces JSR définissent chacune une fonctionnalité qui sera intégrée dans la prochaine version de la JVM. Par exemple, les JSR de Java 1.5 (que j'appelerais personnellement Java3) définissent la généricité (argl), les annotations (un truc formidablement génial) l'autoboxing des types primitifs (on se demande pourquoi ça arrive seulement maintenant), j'en passe et des meilleures.
Une fois les JSR adoptées, les fournisseurs de JVM divers (dont fait partie Sun) doivent implémenter celles-ci pour se voir reconnus fabricants de JVM.
c'est utilisable sans avoir à installer la JVM de Sun et en avoir accepté la licence et les conditions d'emploi ?
Oui, grâce aux JVM libres, ou en utilisant une JVM d'un autre fabricant de Logiciel (BEA, IBM)
oui, des implémentations compatibles au niveau de l'API existent ou sont en projet. mais ce n'est même pas sûr qu'on ait le droit de faire une implémentation libre de Swing/JFC
Bien sûr que si, ces classes sont une partie des APIs Java. En tant que telles, si les implémentations fournies dans la JVM sont la propriété de Sun, on est toutefois libre d'en faire d'autres.
sans devoir respecter certains points comme ne pas fournir de look&feel Windows ou Mac sous *nix, ou de look Apple depuis Windows.
Tu dis quand même un peu n'importe quoi. Les restrictions de look'n'feel ne sont pas le fait de Sun, mais de Microsoft et d'Apple qui ne souhaitent pas (ce que je peux comprendre) voir leur travail utilisé sans leur accord sur un système d'exploitation concurrent.
De la même manière, le fait que le look'n'feel Metal ne soit pas utilisable ne me dérange plas plus que ça.
je ne dis pas ici que Java c'est mal, je dis juste qu'il y aura les mêmes contraintes, légales sinon techniques, qu'avec .NET et Mono.
Pas du tout.