Aujourd'hui Fedora 9 est la première distribution GNU/Linux à inclure un JDK libre 100% conforme aux spécifications Java 6 grâce aux efforts des ingénieurs de Sun, RedHat et de la communauté Fedora. RedHat envisage d'inclure OpenJDK dans la prochaine RHEL 5.3. Le « Java trap » (piège java) est définitivement mort.
Un récapitulatif des épisodes précédents est disponible dans le suite de l'article. Récapitulatif des épisodes précédents :
Mai 2006: Sun annonce à Java One que Java sera disponible sous une licence libre prochainement.
Octobre 2006: Sun commence à libérer des composants majeurs du JDK 7 sous le nom d'OpenJDK notamment le compilateur javac et la machine virtuelle JIT HotSpot.
Mai 2007: Sun libère le Classpath à l'exception des composants dépendant de code tiers (ie: gestion des fontes, son, SNMP) soit 96% du JDK avec l'intention de remplacer les parties incriminées par du code libre.
Juin 2007: RedHat démarre IcedTea. IcedTea a pour but de permettre la compilation avec un chaîne de compilation libre et de combler les trous principalement avec du code provenant de GNU Classpath.
Très rapidement, IcedTea est compilable par GCJ et franchira l'étape du "bootstrap" en devenant capable de se compiler lui-même. Par la suite, IcedTea inclura un plugin web basé sur Gcjwebplugin, le support de Java Webstart grâce à netx. Pour faciliter le portage d'OpenJDK sur les diverses architectures supporté par Linux, IcedTea réécrit un port générique de la machine virtuelle Hotspot: Zero (zero assembly for Hotspot). En complément, Gary Bensom d'IcedTea écrit un compilateur JIT Shark indépendant de la plateforme matérielle sous-jacente. Fedora 8 fut la première distribution GNU/linux a offrir par défaut le support d'OpenJDK 7 en remplacement de GCJ/GNU Classpath. La dynamique est désormais lancée, les ports d'OpenJDK sur de nouvelles architectures (iePowerPC 32/64) et OS (ie: BSD, MacOS X) se multiplient.
Novembre 2007: Sun décide de libérer Java 6, la raison invoquée est que Java 7 ne sera pas prêt avant un an ou deux. Un accord est signé avec RedHat, le but étant de porter les avancées de IcedTea (variante d'OpenJDK 7) dans OpenJDK 6 et l'accès pour les développeurs d'OpenJDK au "Test Compatibility Kit". Celui-ci étant l'étape nécessaire pour pouvoir valider la conformité aux spécifications Java. L'adoption d'OpenJDK 6 est très rapide, Fedora 9 et Ubuntu 8.04 adoptent rapidement celui-ci comme implémentation de Java par défaut.
Juin 2008: la dernière version d'OpenJDK 6 dans Fedora 9 (x86 et x86_64) passe les tests rigoureux du TCK.
Aller plus loin
- OpenJDK (20 clics)
- Annonce de IcedTea (2 clics)
- OpenJDK 6 passe le TCK dans Fedora 9 (8 clics)
- Article wikipedia sur OpenJDK (4 clics)
- Article wikipedia sur IcedTea (4 clics)
- DLFP : Java libre : un rêve devient réalité (24 clics)
# et le jre ?
Posté par B16F4RV4RD1N . Évalué à 6.
cela semble une bonne nouvelle. Par contre qu'en est-il du JRE (machine virtuelle) ? Est-il possible actuellement d'utiliser une Machine virtuelle Java libre, et qui fonctionne parfaitement ?
Si je me réfère aux infos que je trouve sur internet, la machine virtuelle java officielle de sun est sous licence gpl, mais à partir de la version 7 seulement, est-ce qu'il faudra donc attendre encore longtemps ou pas pour avoir ces machines virtuelles libres sur beaucoup de plateformes ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: et le jre ?
Posté par GeneralZod . Évalué à 5.
Au passage, ce n'est pas tant le classpath que les machines virtuelles qui faisaient défaut au logiciel libre.
[^] # Re: et le jre ?
Posté par ʭ ☯ . Évalué à 6.
Bref, c'est pas (encore?) gagné. De plus, le plugin Web est loin d'être fonctionnel, d'après mes quelques tests sur javaboy.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: et le jre ?
Posté par GeneralZod . Évalué à 7.
En revanche pour les impôts, reste le problème du plugin web, gcjwebplugin a encore quelques lacunes mais il est loin de ne pas être fonctionnel.
[^] # Re: et le jre ?
Posté par Pierre Jarillon (site web personnel) . Évalué à -3.
[^] # Re: et le jre ?
Posté par freeze . Évalué à 8.
ça ne change pas grand chose ... juste le responsable, un détail
[^] # Re: et le jre ?
Posté par Boa Treize (site web personnel) . Évalué à 2.
Je crois pas non. Ils exigent une machine Java qu'ils ont pu tester, mais par exemple sous Mac, ça doit passer avec l'implémentation d'Apple.
Parts de marché pour info :
- 87 % Sun
- 10 % Microsoft (Java 1.1)
- 3 % Apple
- 0,07 % Blackdown
- 0,07 % IBM
- 0,004 % autres
[^] # Re: et le jre ?
Posté par Sylvain Sauvage . Évalué à 2.
(C’est pas pour critiquer-gnagna, c’est que ça pourrait reservir…)
[^] # Re: et le jre ?
Posté par Boa Treize (site web personnel) . Évalué à 1.
Disons que ces valeurs sont issues d'un site dont la visite s'impose à la plupart de mes concitoyens... ;-)
[^] # Re: et le jre ?
Posté par vida18 . Évalué à 3.
[^] # Re: et le jre ?
Posté par GPL . Évalué à 2.
Tu peux faire la comparaison avec la communauté Linux: il y a pleins d'auteurs qui ont garder les droits sur leur code. Donc changer la licence ou avoir le droit de fournir une version propriétaire (cf MySQL...) doit avoir l'aval de tous les auteurs de l'ensemble du code de Linux (le "whole" de la licence GPL qui est explicitement arrêté au niveau du user space). En fait, c'est une excellente protection contre les tentatives de prise de contrôle mais par contre cela bloque une possible évolution vers la GPLv3.
Quand tu contribues à un projet GNU, la FSF va te demander de lui abandonner tes droits. Or confondre la FSF, fondation à but non lucratif, avec le conseil d'administration d'une grosse multinationale... ça n'a évidement pas la même portée.
[^] # Re: et le jre ?
Posté par ckyl . Évalué à 10.
Le modèle économique de Qt/MySQL est l'un des plus honnête et rationnel. Ta boite investie pour faire du logiciel libre, si la GPLte convient c'est tout bénef pour toi. Si tu veux faire du proprio tu casques une licence proprio. Et ca, ca n'est faisable que si tu gardes le copyright sur l´ensemble de la base du code.
Maintenant si MySQL/Qt change d'avis et décide de passer en proprio, il te reste les anciennes versions libres. À la communauté du LL de reprendre le bébé. Jusque ici elle avait tout eu gratis
La cession du copyright ce n'est pas fait par plaisir, c'est qu'autrement ta boite perd la possibilité de se retourner (un projet bloqué en GPLv2 seulement par exemple). Et même quand tu as la main sur toute la base du code, opensourcer ou changer de licence relève du parcours du combattant.
Investi plusieurs années de ta vie et de ton pognon pour créer une boite et tu changeras peut être d'avis. Si la FSF ou la fondation Apache demande la cession de copyright ce n'est pas pour rien ! KDE l'a compris dans la douleur.
Ca me tue les mecs a qui on donne des choses et qui trouvent encore le moyen de gueuler ! Tu peux forker Java si tu ne veux pas contribuer mainstream et garder ton copyright.
Mais tu sais, dans la vraie vie sur les projets importants, les contributeurs externes sont rares. Mysql table sur 6 patchs externes cette année. OpenOffice y'a pas plus de 10 commiters externes etc. Alors la communauté est plutôt gagnante dans le deal.
Toi qui ne manque pas de tout critiquer. Qu'à tu fais pour le LL aujourd'hui (et hier) ? Certains tentent de faire avancer les choses, même si on pourrait mieux faire, d'autres font la morale sur les forums. Tu es de quel coté ?
[^] # Re: et le jre ?
Posté par jm trivial (site web personnel) . Évalué à 6.
Je connais au moins un développeur dans mon entourage proche qui choisi de ne pas céder son droit d'auteur, et donc qui ne contribue pas à des projets de ce type.
Je pense donc que le faible taux de patches externes sur ce type de projet n'est pas une justification du modèle, mais au contraire un point négatif: en fermant ainsi les contributions, on prend le risque d'avoir moins d'yeux qui regardent le code source, moins de corrections de bugs (juste des bugreports sans code), etc.
Bref, je suis d'accord que le modèle économique est un bon compromis, mais il entrave le libre développement d'un logiciel, et c'est ce que tu pointes du doigts qui en est la concrétisation.
[^] # Re: et le jre ?
Posté par ckyl . Évalué à 5.
Y'a eu une présentation assez intéressante à javaOne cette année sur comment combiner communauté open Source et développement drivé par une entreprise:
http://developers.sun.com/learning/javaoneonline/2008/pdf/TS(...)
(désolé il est tôt j'ai cliqué sur inutile au lieu de pertinent)
[^] # Re: et le jre ?
Posté par vida18 . Évalué à -1.
Donc entre choisir de migrer son code de la GPL v2 à la v3 ou se retrouver au chômage, le choix est vite fait. Moral le boss a toujours le dernier mot.
[^] # Re: et le jre ?
Posté par wismerhill . Évalué à 5.
[^] # Pipo
Posté par Kerro . Évalué à -1.
[^] # Re: et le jre ?
Posté par ckyl . Évalué à 1.
Sauf clause spéciale dans ton contrat, tu n'as pas ton mot à dire sur le code produit dans le cadre de ton travail. Et même un peu plus... Si tu bosses sur un logiciel de CAO et que tu fais un autre logiciel de CAO sur ton temps libre qui pourrait concurrencer le premier attends toi à recevoir une lettre du service juridique. De même que si tu bosses pour un projet sous GPL et que tu y contribues le WE attends toi à ce que le copyright de ce code revienne tout de même à l'employeur.
[^] # Re: et le jre ?
Posté par stephwww . Évalué à 2.
>De même que si tu bosses pour un projet sous GPL et que tu y contribues le WE attends toi à ce que le copyright de ce code revienne tout de même à l'employeur.
Tu es sur de toi ? Un programmeur ne peut programmer que pour son employeur, dès qu'il fait un truc perso potentiellement ça appartient à son employeur ?
Ou est ce que ce genre de clause peut être stipuler dans le contrat de travail ?
[^] # Re: et le jre ?
Posté par phyce . Évalué à 4.
Sinon bien sur, ce que tu codes sur ton temps libre est ta propriété, pas celle de ton employeur.
[^] # Re: et le jre ?
Posté par stephwww . Évalué à 2.
[^] # Re: et le jre ?
Posté par alice . Évalué à -7.
Dans le cadre de mon travail, j'ai écrit un bout de code qui aurait sa place dans Qt. Je pourrais donc :
- l'envoyer à Trolltech, mais quel est mon intérêt? Bosser gratuitement alors qu'ils vont se faire du pognon avec?
- le distribuer séparément, mais ça demande du temps et la non intégration fait perdre de l'intérêt au projet.
Je choisirais peut être cette dernière solution, mais c'est dommage.
[^] # Re: et le jre ?
Posté par Jean B . Évalué à 10.
Il y a un truc choquant dans ton post : mais quel est mon intérêt?
Réfléchit deux minutes aux intérêts des gens qui ont codé tous les logiciels que tu utilise. Toi tu leur sert à rien ? Pourquoi il te permettent de l'utiliser ?
[^] # Re: et le jre ?
Posté par Guillaume Rossignol . Évalué à 3.
une contribution à Qt qui serait récupérée par Qt pour faire une distribution d'un logiciel sous licence libre et une autre sous version fermée
RedHat qui à première vue ne fournit pas de version de ses produit sous licence fermée
Il est tout a fait normal qu'un contributeur n'ai pas envie que son travail puisse se retrouvé sous licence fermée (sinon, tout le monde utiliserait une licence BSD)
[^] # Re: et le jre ?
Posté par alice . Évalué à 0.
Ca a été très mal compris apparemment, mais je voulais dire que je veux bien contribuer gratuitement à un projet libre, car il profite à tous, mais pas à un projet propriétaire.
Le problème de la double licence associé à la cession de droit est qu'on ne peut pas choisir de contribuer uniquement à la version libre.
Ils ont pour la plupart :
- contribué gratuitement à un projet libre.
- été payés pour contribuer à un projet libre ou sous double licence.
Mais combien, à part des stagiaires, acceptent de travailler gratuitement pour un projet propriétaire ou sous double licence?
[^] # Re: et le jre ?
Posté par Thomas Douillard . Évalué à 6.
Dans le cas de la double licence, seul le détenteur du copyright peut le faire, n'importe qui dans le cas de la BSD. Pourtant des contributeurs en BSD il y en a.
[^] # Re: et le jre ?
Posté par alice . Évalué à 2.
Bien vu! Sur ce point la BSD me semble plus équitable que la double licence GPL/proprio.
[^] # Re: et le jre ?
Posté par ckyl . Évalué à 2.
En général quand une boite choisie un modèle de double licence c'est pour ne pas qu'une boite concurrente puisse faire la même chose; les forcer à passer par toi. En gros tu veux éviter qu'un intégrateur se fasse le pognon tout seul alors que c'est toi qui développe.
Si ton business model ne prévoit pas ça, alors soit une simple GPL suffit soit tu fais du LGPL/BSD.
[^] # Re: et le jre ?
Posté par alice . Évalué à 2.
[^] # Re: et le jre ?
Posté par Thomas Douillard . Évalué à 2.
C'est technique, donc chronophage à priori et pas forcément trivial, ça demande des compétences, ...
[^] # Re: et le jre ?
Posté par B16F4RV4RD1N . Évalué à 6.
on dirait que tu n'as pas trop compris l'intérêt des logiciels libres !
Effectivement, tu bosses gratuitement, pour trolltech et tous les projets gpl qui vont pouvoir bénéficier de ton code. Cela te dérange tant que cela que cette amélioration puisse améliorer kde, et tout les logiciels libres qui dépendent de qt ?
En ce cas, ne contribue pas à d'autres logiciels libres, car il y a beaucoup de SSII qui gagnent un maximum d'argent juste en mettant en place des logiciels libres (apache, php etc), et sans forcément recontribuer dans l'autre sens.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: et le jre ?
Posté par Vador Dark (site web personnel) . Évalué à 10.
Et toi, tu as économisé combien en reprenant leur travail gratuitement, par rapport à si tu avais payé une licence pour Qt ou une lib équivalente?
Finalement, est-ce que ça ne serait pas un juste retour des choses?
# Je comprends pas un truc
Posté par cram51 . Évalué à 0.
>ingénieurs de Sun
Java ca appartient a Sun non? Pourquoi se fatiguer a recréer un programme qui existe déja? Il ne leur était pas plus simple de libérer le leur ? Comme ca en plus tous les gens qui ont participé a la création de ce nouveau paquet libre aurait contribuer a celui de Sun et plutot que d'en avoir deux on en aurai eu un de compète ....
Il y a surement un truc qui me dépasse
[^] # Re: Je comprends pas un truc
Posté par karmatronic . Évalué à -7.
[^] # Re: Je comprends pas un truc
Posté par stephwww . Évalué à 7.
C'est surprenant, quand je développe du code c'est mon employeur qui décide de la licence du code qu'il va appliqué. Il m'a payé pour faire du code il lui appartient.
Dans la dépêche il est dit, pour classpath, que c'est du code tiers qui empêche la libération (une entreprise externe je pense). C'est probablement le cas pour les autres composants.
[^] # Re: Je comprends pas un truc
Posté par Mithfindel (site web personnel) . Évalué à 6.
C'est une excellente nouvelle que la libération totale de Java, bravo aux courageux développeurs qui ont contribué à OpenJDK !
[^] # Re: Je comprends pas un truc
Posté par case42 (site web personnel) . Évalué à 10.
[^] # Re: Je comprends pas un truc
Posté par GeneralZod . Évalué à 10.
[^] # Re: Je comprends pas un truc
Posté par cram51 . Évalué à 4.
# Ouais !
Posté par Jerome Alet (site web personnel) . Évalué à -1.
> a re-coder ces bouts la...
C'était sûrement ce code là qui était lent comme une vache morte et qui bouffait toute la mémoire disponible, donc YOUPI !!!
[^] # Re: Ouais !
Posté par Nicolas Legrand (site web personnel) . Évalué à 10.
Je croyais que c'était ça les critères de la compatibilité java...
# Bof
Posté par GPL . Évalué à -10.
Est-ce qu'on peut le compiler *sans* une version fermée de java (aka juste avec un compilateur C++)?
Est-ce que je peux télédéclarer mes revenus avec ce JDK sans me faire envoyer bouler par le site de la DGI (Direction Générale des Impôts)? (Sachant qu'un canal SSL est largement suffisant).
Est-ce que si je suis contributeur de code à ce bloat, je suis obligé d'abandonner mes droits au conseil d'administration de Sun?
Qui sont les fous qui vont maintenir la pile logicielle suivante pour une application java:
1 - Noyau (Ouch!)
2 - Le compilateur C (la tool chain en fait)
3 - La bibliothèque C standard
4 - Le compilateur C++ (un truc de barge)
5 - La bibliothèque C++ standard (un truc de fou furieux).
6 - Les 80Mo de code compressés du JDK en C++ brain damage (no comment...)
Pour ma part, je m'arrête au niveau 3.5 (en effet je triche, j'utilise des bibliothèques C en plus de la bibliothèque C standard).
Dsl mais je ne suis pas fan de bloatware. Surtout que celui-là, sans Sun, déraisonable de le maintenir... donc dire que la java trap est morte... mouaif, elle se cache sous une couche "open source" mais elle est toujours là. Y a même MS/Novell qui fait la même chose avec son mono (.net).
Java n'est qu'un nouveau COBOL (hum... il est poilu celui-là!)
Un point positif, il y a quand même JNI pour l'intéropérabilité: je peux appeler du code JAVA dans mon code C et vis-et-versa (en théorie).
[^] # Re: Bof
Posté par GeneralZod . Évalué à 9.
Non, depuis un bon moment déjà.
http://mail.openjdk.java.net/pipermail/security-dev/2007-Sep(...)
> Est-ce qu'on peut le compiler *sans* une version fermée de java (aka juste avec un compilateur C++)?
Oui, GCC/GCJ suffit à compiler OpenJDK, d'ailleurs, OpenJDK 6/IcedTea n'aurait jamais pu être distribué dans Fedora si ce n'était pas le cas.
> Est-ce que je peux télédéclarer mes revenus avec ce JDK sans me faire envoyer bouler par le site de la DGI (Direction Générale des Impôts)? (Sachant qu'un canal SSL est largement suffisant).
Il ne manque plus qu'un plugin web fonctionnel à 100% au lieu de 95%
Le TCK garantit quant à lui que le JDK/JRE est 100% conforme aux spécifications de Sun donc à ce niveau-là aucun souci.
> mouaif, elle se cache sous une couche "open source" mais elle est toujours là.
La java trap concernait l'environnement d'éxécution non libre, aujourd'hui ce n'est plus le cas.
Au passage, OpenJDK deviendra l'implémentation de référence dès Java 7 et remplacera définitivement l'implémentation propriétaire de Sun, c'est objectif de la release.
> Qui sont les fous qui vont maintenir la pile logicielle suivante pour une application java:
C'est le cas de la totalité des langages de haut niveau.
Je suis ingénieur en système embarqué et j'apprécie au moins tout autant que toi le C, mais il faut reconnaitre que Java et autres langages de haut niveau ont leur utilité.
De plus, la communauté libriste est largement capable de maintenir une pile logicielle comme Java, ce n'est pas les développeurs de Python, Mono, Perl, Ruby qui me contrediront.
[^] # Re: Bof
Posté par barmic . Évalué à 4.
Les dev de la STL, de gcc, de g++ et de linux reste à leur tâche si c'est ce qu'il préfèrent. Il existe depuis déjà quelques temps des implémentations libres du JDK mais pas parfaite. Ces dev vont probablement passer à OpenJDK.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Bof
Posté par Larry Cow . Évalué à 4.
Que veux-tu dire? Que la DGI aurait pu se passer d'une applet et utiliser les fonctionnalités standards de SSL?
Il me semblait qu'on avait déjà largement débattu de ce point-là...
[^] # Re: Bof
Posté par psychoslave__ (site web personnel) . Évalué à 3.
[^] # Re: Bof
Posté par ndesmoul . Évalué à 2.
https://linuxfr.org/~MrLapinot/26625.html#931463
[^] # Re: Bof
Posté par Frédéric Lopez . Évalué à 1.
[^] # Re: Bof
Posté par ckyl . Évalué à 6.
Quand tu utilises de la bonne facon les bonne technos, le coût runtime est infime par rapport au gain de robustesse et de productivité. Par contre aucun langage n'empêche les mauvais codeurs/architectes de pondre des bouzes. D'ailleurs tu peux me donner des pointeurs sur tes contributions d'exceptions au logiciel libre ?
Exercice supplémentaire: Regarder comment fonctionnent les JVM. Comparer l'assembleur produit par gcc et hotspot.
[^] # Re: Bof
Posté par zul (site web personnel) . Évalué à 0.
Quelles sont les qualités de java, à par d'être un langage vu par tous à l'école, et une techno de décideurs pressés ? (et aussi générer un maximum d'architectures bloatwares (le problème ne vient pas uniquement du langage, mais de la façon de penser complétement biaisée des architectes logiciels en bonne partie amha), chiantes à maintenir, donc qui rapporte de l'argent).
Qu'est qui fait que java est robuste ? J'ai jamais rien vu d'impressionant, à par catcher le milliard d'exception qui peut etre levé par le système.
Pourquoi quand on parle de bonnes technologies ne parle-t-on pas plutot des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).
[^] # Re: Bof
Posté par ckyl . Évalué à 10.
Tu remplaces Java par J2EE et je suis d'accord avec toi :-) Souvent quand on parle de Java le gens pensent J2EE ou Java 1.2. Depuis ca a un peu évolué dans le bon sens tant en perf qu'en fonctionalités.
> Quelles sont les qualités de java
Facile à utiliser, lib standard assez complète, bon écosystème, portabilité aisée. En général tu fais facilement ce que tu veux. Tu passes plus de temps à faire des choses fun que réinventer la roue en général.
Ce n'est pas LA solution, et je n'irais pas l'utiliser pour n'importe quoi.
> Qu'est qui fait que java est robuste ?
Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.
> des langages qui nous donnent des assurances sur les types par exemple (ocaml, haskell), ou qui font du distribué vraiment pas cher (erlang).
Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés). Si tu veux être viable à long terme il faut pouvoir attirer des gens et autant que possible faire le moins de travail toi même.
Attention je n'ai jamais dit que Java c'était LE truc génial et inégalé. C'est un outil adapté à certains problèmes qui a l'avantage d'être mainstream (et avec OpenJDK on peut espérer voir des gens du LL débarquer).
Même si tu ne veux pas faire de Java, réjouis toi de l'ouverture de Hotspot. Ca doit juste être un des bouts de code les mieux optimisés au monde. Il y a aussi pas mal de projet réutiliser la JVM, et ses perfs, pour d'autre langage (ca fait un .Net portable).
Après si quelqu'un veut discuter technique je pense avoir le background C et Java pour apporter quelques réponses sur les perfs etc.
[^] # Re: Bof
Posté par zul (site web personnel) . Évalué à 1.
Facile et difficile à utiliser sont des notions je pense complétement lié à l'éducation. Si on apprenait aux gens à réfléchir autrement, en particulier, si ils avaient des cours un peu poussé de programmation fonctionnelle, ça changerait surement la donne. Ce n'est pas un avantage du langage en soit, juste la conséquence d'un manque de culture informatique, dans le but d'être "attractif pour l'entreprise".
Quand à la portabilité, j'attend de pouvoir compiler facilement en natif openjdk sur un BSD ou une architecture exotique, on verra ensuite. :)
> Java n'est pas "robuste". Mais d'expérience entre un programme écrit en C (voir commentaire de GPL) et un programme dans un langage de plus haut niveau, j'ai mon idée sur celui ou tu passes plus de temps à avoir un truc qui marche correctement (conception + debug). On parle de base de 50k à 1M de lignes de code hein, pas de projet du dimanche.
Evidemment, comparé java et C, java s'en tire sur la robustesse. Je parlais évidemment en comparaison avec les langages sous-cités. Quand au projet à 1M de ldc, il serait intéressant à ramener aux nombres de concepts manipulés. Je trouve java très inefficace de ce point de vue (écrire beaucoup de code pour exprimer peu de chose, même avec sa superbe librairie standard complexe).
> Par ce que malheureusement ce sont des langages difficilement accessibles et à l'écosysteme assez faible (les deux sont liés).
Pour la partie difficiles, se rapporter au layus sur la facilité du java. L'ecosystème est faible, parce que le système se mord la queue (il faut la confiance dans une grosse boite qui l'utilise ou qui le developpe ...). À noter qu'il me semble que cet argument est moins vrai pour erlang vu qu'ericson l'a pas mal poussé et qu'il a de nombreuses caractéristiques intéressantes.
Pour les performances, je n'ai pas remis en doute les performances de java, juste des architectures :) On peut avoir la vm la plus optimisé du monde, une mauvaise architecture et des mauvais algos (si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java), ça ne changera rien au résultat. Et ça aucun langage n'y peut rien. Seule l'éducations et une bonne formalisation peuvent faire des choses à ce sujet ...
[^] # Re: Bof
Posté par ckyl . Évalué à 7.
Je prends une vision pragmatique de développeur/chef de projet. Tu as un choix a faire maintenant tu fais quoi ? (il n'y a pas de réponse unique)
Cela dit dans facilité tu as aussi la notion de maturité des frameworks. Récemment j'ai voulu faire un bot IRC pour générer des flux RSS/mail (il mange aussi des connexions Telnet et récupéré des metadata sur des sites comme youtube). Je me suis donné le choix entre Ruby et Python. Mais après avoir comparé les docs/examples des modules dans les différents langages je me finalement suis rabattu sur Java alors que j'aurais bien scripté... Moins de 500 lignes au final.
D'un point de vue encore plus personnel, je me fou de la soit disant "beauté" du langage. Si j'écris 5 lignes de code au lieu de 10 je suis content. Mais ce qui m'importe le plus c'est de pouvoir faire les choses (outils, libs etc.), comprendre aisément du code de quelqu'un d'autre, avoir une base de code maintenable sur la durée, quand je code un lib avoir des utilisateurs potentiels et ne pas sortir mon soft 3 ans après avoir épuisé les crédits.
Et par pitié n'assimile pas une techno a quelques uns de ses utilisateurs: "si y'a encore beaucoup de gens qui savent ce que c'est qu'un algo en java". Y'a un marché de dev Java important. Ca draine les déchets, c'est évident. Mais je pense pas régresser mentalement lorsque je passe du C au Java. Tout comme il serait bon de ne pas traiter d'imbéciles les mecs d'Apache, de Sun ou qui font des archis comme Yahoo, Ebay ou LinkedIn.
Dans l'informatique pro y'a 70% de boulets, faut bien qu'ils utilisent quelque chose. Tu n'y changeras rien (et ils ont une petite chance de faire moins de mal en Java qu'en C ou C++ :-) )
[^] # Re: Bof
Posté par patrick_g (site web personnel) . Évalué à 3.
Je te trouve optimiste. La loi de Sturgeon stipule pourtant que "90% de n'importe quoi ne vaut rien".
http://en.wikipedia.org/wiki/Sturgeon's_law
[^] # Re: Bof
Posté par zul (site web personnel) . Évalué à -2.
Je ne vois pas bien ce que ça démontre. A par 1/ bloatware (qui a besoin d'un "framework" pour coder un pauvre bot IRC 2/ la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu). En utilisant java, tu as à mon avis, augmenter considérablement la taille de ton projet (en ligne de code), et perdu sur l'aspect dynamique de la chose. Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500, c'est ton choix. Mais je vois pas la portée de l'argument. Mais hésite pas à argumenter plus avant.
Pour en revenir sur le chef de projet, utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats. Sauf si tu veux te taper dans les 90% (ce qui me semble un chiffre plus raisonnable) des gens peu compétents. Evidemment, ils risque d'être plus cher, mais on peut pas avoir l'argent du beurre, et le cul de cremière :).
Je ne pense pas avoir parlé de la "beauté" du code. J'ai parlé de l'expressivité du langage et des choses assurés par le compilateur. Y'a des choses assez inexprimables sans evaluation paresseuse par exemple. L'inférence de type c'est un truc à mon avis bien plus puissant que les trucs utilisés pour faire de la généricité en java ou en C++... Et je n'ai jamais parlé de C. Le C est utile pour un certain nombre de choses, en particulier le système. J'ai toujours parlé de langages de haut-niveau.
Et même pour les "boulets", le java est encore largement trop permissif. Un langage encore plus contraint sera à mon avis bien plus efficace, en supprimant encore de nouvelles erreurs.
[^] # Re: Bof
Posté par ckyl . Évalué à 3.
framework = bibliothèque :-)
https://rome.dev.java.net/
https://pircbot.dev.java.net/
http://code.google.com/apis/youtube/overview.html
http://mina.apache.org/
Mina est 100x overkill mais j'avais envie de jouer avec. Si utiliser des libs c'est du bloat...
> la résitance au changement (utiliser java plutôt qu'un langage que je suppose moins connu).
C'est con c'était le but et j'ai tout de même écrit une version python.
> Après si tu préfère maintenir un truc de 5000 lignes de code plutot qu'un truc de 500
Ca fait 500 lignes de code pour prendre ses entrées sur X chan IRC, telnet et parser régulièrement l'output XML du serveur d'intégration continue; dispatcher ces infos sur différents planet en fonction de la config chaque planet poussant les infos sur des flux RSS ou sur IRC.
> Mais je vois pas la portée de l'argument
Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.
> utiliser des langages plus "ésotériques" permet de faire à priori un tri extrémement rapide sur les candidats
Non. Ca te fais prendre des universitaires qui n'y connaissent pas forcément grand chose en ingénierie logiciel :-)
[^] # Re: Bof
Posté par zul (site web personnel) . Évalué à 1.
Tu as une définition assez personnelle de la notion de framework. Ma définition s'approche plus de celle de wikipedia (et je suppose que c'est "un point de vue majoritaire".
Evidemment, utiliser des libs, ce n'est pas forcément bloatware, (quoi que ça dépend des libs). C'est un exemple parfait pour démontrer qu'il s'agit surtout d'un collage bout à bout de libs, sans trop se poser de questions, sans problème d'algorithmie, etc ...
> Mon argument c'est qu'un langage a beau être 10x mieux sur le papier si les libs autour ne suivent pas, alors ce n'est pas un bon choix. Il faut que les libs soit nombreuses, de bonne qualité et bien documentées.
Ton argument, c'est que pour qu'un langage soit un bon choix, il faut que ce soit un bon choix dès le départ, cad qu'un gros industriel le sorte avec assez de vie pour qu'ils soient utilisables. Ici encore, le système se mord la queue. Plus un système utilisé, et plus le nombre de bibliothéques augmentent, dans un grand cercle virtueux. Et inversement, aucun 'petit langage' ne peut vraiment émerger.
Pour finir, je citerai alors scala, qui profite de l'ensemble des bibliothèques java, mais qui apporte quelques améliorations sustanciels des langages préalablement suscité.
Et sinon, bravo pour les moinssages à l'emporte pièce, l'auto-modération est vraiment quelquechose qui m'est vraiment de plus en plus insupportable, surtout lorsqu'elle est faite sur des posts plus ou moins argumentés, sans grossiéretés, ni propos choquant (à part de défier la PENSÉE UNIQUE) (respect à tous ... :)
[^] # Re: Bof
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Bof
Posté par ckyl . Évalué à 2.
J'ai choisi cet exemple au hasard pour montrer que l'écosystème d'un langage est aussi très important. Clairement Perl n'a rien à prouver de ce point de vue là.
# Richard vas nous lacher la grap
Posté par Loic Dreux . Évalué à -1.
# Re:
Posté par IsNotGood . Évalué à 4.
> Aujourd'hui Fedora 9 est la première distribution GNU/Linux à inclure un JDK libre 100% conforme aux spécifications Java 6
C'est cool. Mais plus important, d'autres vont rapidement suivre.
> grâce aux efforts des ingénieurs de Sun, RedHat et de la communauté Fedora.
Et de la communauté "sans étiquette".
> RedHat envisage d'inclure OpenJDK dans la prochaine RHEL 5.3.
Il me semble que c'est déjà disponible "en option" (preview) pour RHEL 5.2.
> Fedora 8 fut la première distribution GNU/linux a offrir par défaut le support d'OpenJDK 7
Ça s'appellait IcedTea. Ça ne pouvait pas s'appeller OpenJDK 7 car l'API n'était pas figée (contrairement à OpenJDK 6). Mais Sun a aussi assouplie l'emploi du nom OpenJDK et c'est cool aussi.
> Un accord est signé avec RedHat, le but étant de porter les avancées de IcedTea (variante d'OpenJDK 7) dans OpenJDK 6 et l'accès pour les développeurs d'OpenJDK au "Test Compatibility Kit".
Peut-être que ma mémoire me trahie.
Il me semble que l'accord permet à Red Hat (et seulement Red Hat est couvert pas cet accord) d'utiliser le TCK.
L'accord permet aussi à Red Hat de faire parti du "directoire" de Java. Red Hat participe aux décisions et a toutes les informations à égalité avec Sun.
> L'adoption d'OpenJDK 6 est très rapide, Fedora 9 et Ubuntu 8.04 adoptent rapidement celui-ci comme implémentation de Java par défaut.
Je peux me tromper mais je doute très fort que Fedora ou Ubuntu puis clamer être compatible Java. Si c'était le cas, au-lieu d'utiliser le nom OpenJDK, il pourrait directement utiliser le nom Java (ce que va très probablement faire Red Hat pour RHEL). Je crois que l'accord entre RedHat et Sun ne donne le droit qu'à Red Hat d'utiliser le nom Java (et donc de clamer être compatible Java (ou de passer les tests TCK)).
OK, je chipote. D'ailleurs je ne garantis pas l'exactitude de ce que j'avance.
Mais je crois que ce n'est pas aussi idyllique que tu le crois.
M'enfin, ne boudons pas notre plaisir.
Il n'y a que quelques détails qui ne sont pas parfait mais ne remettent pas en cause la liberté d'OpenJDK et donc la possibilité de fédérer une large communauté autour d'OpenJDK.
[^] # Re: Re:
Posté par GeneralZod . Évalué à 2.
C'est clair qu'il faut remercier l'ensemble de la communauté du logiciel libre pour cet incroyable cadeau mais sans se voiler la face, le gros du boulot a été fait par les ingénieurs de Sun et l'équipe d'IcedTea (et c'est un peu mon boulot d'ambassadeur de mettre en avant le boulot de la communauté Fedora dont IcedTea fait partie).
> Il me semble que c'est déjà disponible "en option" (preview) pour RHEL 5.2.
Exact, mais normalement OpenJDK deviendra l'implémentation par défaut dans RHEL 5.3, j'aurais du le préciser.
Quant à l'utilisation du nom "OpenJDK 7", seul Java 7 devait être entièrement libéré au départ, la libération du JDK 6 fait que rétroactivement on a appelé IcedTea openJDK 7 pour le différencier d'OpenJDK 6.
C'est probablement un abus de langage comme tu le précises, mais c'est repris par la communauté y compris dans les releases notes.
http://docs.fedoraproject.org/release-notes/f9/en_US/sn-Java(...)
Sun a accordé une licence spéciale du TCK pour la communauté afin de pouvoir tester la conformité des builds basé sur OpenJDK sous licence GPL.
C'est ce qu'affirme du moins la FAQ.
http://www.sun.com/software/opensource/java/faq.jsp#k4
OpenJDK devrait inclure une option de compilation permettant de valider la conformité du build, c'est peut-être même déjà fait.
Quant aux marques Java, JDK et OpenJDK, le premier n'est utilisable qu'avec l'accord de Sun, les JDK et OpenJDK sont soumis aux règles du "fair use".
L'accord RedHat-Sun permet à Fedora d'utiliser la marque "OpenJDK", c'est même dans les releases notes de Fedora 9: "Sun has licensed the OpenJDK trademark for use in Fedora."
Quant à Ubuntu, je suppose que c'est de même.
C'est vrai, il y a encore beaucoup de boulot, améliorer le plugin web, nettoyer le code pour le rendre plus portable, plus performant, etc ... C'est une étape importante pour faire de Java un citoyen de première zone dans la communauté du logiciel libre.
ça va redonner du courage à la communauté et donner du crédit au pro-libre au sein de Sun.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Je l'ignorais. Merci pour cette excellente nouvelle pour le libre (et java car diminura les dérives/incompatibilités non volontaires).
[^] # Re: Re:
Posté par Loic Dreux . Évalué à 1.
Le nom Java appartient à Sun, je ne vois pas ce que vient faire un nom dans la compatibilité Java. Personnellement, j'utilise les deux paquets java-6-sun et java-6-openjdk et à part quelques "bugs" graphique sous OpenJDK : les thèmes Swing ne s'affiche pas aussi bien qu'avec la JVM officiel, c'est surement du à la réécriture d'une partie de l'API qui est encore jeune, tout le reste fonctionne à 100%.
# super nouvelle
Posté par BAud (site web personnel) . Évalué à 5.
Déjà j'étais content que IcedTea ait boosté la disponibilité du greffon web java pour x86_64 en natif mais je dois dire qu'il me restait encore quelques doutes de la disponibilité réelle d'un Java entièrement libre pour septembre, je suis vraiment content de m'être trompé de 3 mois : ça laisse une chance d'avoir de très intéressantes distributions GNU/Linux pour l'automne.
Sinon, quelqu'un a des nouvelles de jpackage pour mutualiser les efforts de packaging entre les différentes distributions ? http://www.jpackage.org/ (j'avais l'impression que c'était un peu délaissé par certaines distributions, mais j'ai dû me tromper aussi...), nul doute que la standardisation sur une version libre plutôt que la jungle des alternatives va simplifier leur essor et la rationalisation du packaging.
[^] # Re: super nouvelle
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Ensuite, toutes les debian (et dérivée) me semble éliminées...
Bref, je ne crois pas trop à jpackage en fin de compte. Le plus dur dans la construction de paquet, c'est de bien définir les dépendances avec les nuémros de version de ces dépendances. Cela prends un temps fou de faire un truc propre et homogène sur une disribution comme debian. Je ne vois pas comment tu veux mutualiser cela dans un format jpackage, mais peut être n'ai je rien compris.
Si en fin de compte, jpackage est un tarball plus évolué, cela me semble de peu d'intérêt aussi. De plus en plus, on va avoir des gestionnaires de versions de type GIT qui vont faire la liaison entre l'équipe de développement du code et la partie adaptée pour la distribution. Avec ces outils de versionning, tout le monde va y gagner en boucle de retroaction.
Donc jpackage la dedans ... Non vraiment je ne vois pas bien.
[^] # Re: super nouvelle
Posté par Thomas Douillard . Évalué à 3.
Avec jpackage, justement, tu devrai pouvoir générer correctement les package et les dépendances qui vont bien suivant ta configuration, gérer l'enfer des "cette version est spécifique pour gcj", et laisser le boulot de la gestion de package proprement dite à apt/rpm et consors. Le tout centré sur les package java.
Bon arpès effectivement ils sont pour l'instant rpm centrés, mais avec un peu de boulot ça a l'air jouable de générer des deb en plus des rpms.
[^] # Re: super nouvelle
Posté par nimnim . Évalué à 2.
S'il y a une chose qu'on peu déplorer, c'est qu'à côté de Red Hat qui contribue beaucoup, Mandriva & Novell se contentent de suivre et récupérer le résultat sans trop contribuer (et on retriouve les paquets JPackage dans beaucoup d'autres distros rpm comme alt)
[^] # Re: super nouvelle
Posté par nimnim . Évalué à 2.
https://www.zarb.org/pipermail/jpackage-announce/2008-June/t(...)
# Pourquoi ?
Posté par Spack . Évalué à 1.
Donc pourquoi la libération du code ? Un petit historique de l'histoire ?
[^] # Re: Pourquoi ?
Posté par ckyl . Évalué à 9.
Mon interprétation personnelle est la suivante. Java à atteint son seuil de pénétration depuis un moment. Ils ne font pas d'argent sur J2SE, c'est destiné aux end users et il y a des implémentations de BEA et d'IBM tout aussi performantes.
Java n'a jamais réussi à pénétrer sur le Desktop (il y a des raisons techniques la) alors qu"on voit du mono débarquer ! Et il suffit de voir les réactions ici pour comprendre ce que pense la communauté du LL sur la stack Java.
Bref ca ne leur coutera pas plus cher, je ne pense pas qu'ils attendent d'énormes contributions hormis des portages vers des archi exotiques, et ils ont une chance de gagner des utilisateurs.
On peut noter que l'évolution de Java est depuis longtemps ouvert à la communauté (JCR/JCP). Ce qui a mal été compris est la volontée de Sun de n'avoir sous le nom Java que des implémentations qui passent le TCK (souvenez vous de la VM de microsoft). C'est la même stratégie que la mofo, si vous voulez notre nom alors vous respectez nos règles.
En dehors du JDK, la politique à la mode chez Sun c'est d'offrir des implémentation de référence des specs libres, et d"en tirer des versions supportées. On peut citer: glassfish (serveur J2EE), OpenDS (directory service), OpenSSO, Hudson (_LE_ serveur d'integration continue) etc.
C'est le mouvement général de Sun depuis quelques années. Rien qu'a voir le nombre de bloggers qu'ils mettent pour faire leur com. Après Sun a toujours changé d'avis tout le temps :-)
Mais rien que pour Hudson, merci khosuke et Sun !
[^] # Re: Pourquoi ?
Posté par nimnim . Évalué à 3.
1. SUN avait verrouillé la plate-forme, et était seul en mesure de l'adapter au contexte desktop
2. SUN avait abandonné le desktop et le considérait acquis à Microsoft (petit Yalta entre amis)
Maintenant que Microsoft utilise sa main-mise sur les postes utilisateurs pour pousser c#/.Net, et .Net pour détrôner Java en Entreprise, SUN se découvre un soudain intérêt pour les postes utilisateurs sous Linux et surtout les équipes de développement desktop Linux. (La montée en puissance de GNU/gcj/classpath et IBM/Motorola/Harmony ont aussi contribué.)
Mais pour être présent sous Linux il faut être distribué. Placé dos au mur SUN a fini par admettre que sans licence libre, il n'irait jamais très loin côté Linux, que Linux lui était nécessaire, et que son ancien argumentaire contre l'ouverture était assez creux.
[^] # Re: Pourquoi ?
Posté par Frédéric Lopez . Évalué à 4.
Java n'a jamais réussi sur le desktop parce que1. SUN avait verrouillé la plate-forme, et était seul en mesure de l'adapter au contexte desktop
2. SUN avait abandonné le desktop et le considérait acquis à Microsoft (petit Yalta entre amis)
Je pense que l'échec de Java sur le desktop est beaucoup plus lié aux défauts techniques de ses débuts qu'à la politique de Sun de l'époque :
- le "Write once, run anywhere" n'a jamais tenu ses promesses (="Write once, debug everywhere") ;
- performances désastreuses en vitesse d'exécution et/ou consommation mémoire ;
- disponibilité aléatoire et hétéroclite des JVM côté client (merci Microsoft...) ;
- GUI immonde, pas intégrée du tout aux environnements de bureau existants ;
- outils de développement pendant longtemps très en retrait par rapport à la concurrence.
Je ne pense pas que le passage en Open Source change quelque chose pour son avenir sur le desktop maintenant que Flash s'est imposé côté navigateur et que .NET/Mono sont en train d'occuper sa niche...
[^] # Re: Pourquoi ?
Posté par nimnim . Évalué à 1.
> de ses débuts qu'à la politique de Sun de l'époque :
Certes mais des défauts ce n'est pas insurmontable, ça se corrige. Encore faut-il pouvoir le faire. Tout le monde n'était pas d'accord avec les choix désastreux de SUN en matière de GUI mais SUN s'était mis en situation de seul maître à bord.
(et sans Eclipse/SWT je suis sûr que SUN serait encore en train d'insister que look motif + éléments mauves = bien)
[^] # Re: Pourquoi ?
Posté par wismerhill . Évalué à 3.
- le "Write once, run anywhere" n'a jamais tenu ses promesses (="Write once, debug everywhere") ;
Ça c'est encore assez vrai, je constate malheureusement encore fréquamment que pour des interfaces swing tu peux avoir des bugs complètements différents entre un windows et un Linux (ou même entre winXP et vista), et ne parlons même pas de drag'n'drop vers d'autres programmes. Mais swing n'a jamais été une API très bien faite.
Dommage que pour mon boulot il est hors de question d'utiliser qt jambi.
- performances désastreuses en vitesse d'exécution et/ou consommation mémoire ;
Pour la vitesse ce n'est plus du tout d'acualité, pour la conso mémoire c'est très dépendant du programmeur, même si java induit en lui-même une certaine surcharge, mais pas très gênant sur des gros projets.
- disponibilité aléatoire et hétéroclite des JVM côté client (merci Microsoft...) ;
en pratique, c'est du sun presque partout, à l'excès même car certaines personnes codent en utilisant des API non documentées de sun, ou en tenant compte de leurs bugs (on avait fait ça il y a quelques temps pour un bug swing dans java 1.5).
- GUI immonde, pas intégrée du tout aux environnements de bureau existants ;
Swing n'est pas intégré c'est vrai, mais il propose plusieurs thèmes suivant les gouts, dont des thèmes contribués (et j'en ai déjà testé un qui utilisait des widget gtk pour l'affichage, mais ce n'était pas très stable).
Et si tu parle de AWT, je répète qu'on n'en est plus au temps de java 1.1, et pour ceux qui n'aiment pas swing il y a SWT et plus récemment qt jambi.
- outils de développement pendant longtemps très en retrait par rapport à la concurrence.
Je ne connais pas bien la concurrence, mais ça fait plus de quatre ans que je développe avec eclipse et c'est très performant.
Je ne pense pas que le passage en Open Source change quelque chose pour son avenir sur le desktop maintenant que Flash s'est imposé côté navigateur et que .NET/Mono sont en train d'occuper sa niche...
Flash est quand même très orienté vidéo/animation là où java est généraliste. C'est bien pour ça que flash s'est imposé (plus simple pour faire des petites animations interractives), c'est pour ça qu'ils essaient de relancer le truc avec javaFX, mais ça arrive bien tard...
[^] # Re: Pourquoi ?
Posté par zul (site web personnel) . Évalué à 0.
[^] # Re: Pourquoi ?
Posté par wismerhill . Évalué à 1.
(par contre, celui-ci est tout à fait inutile)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.