Parmi les véritables nouveautés, commençons par l'esthétique et le bureau. Tout d'abord, il est possible nativement de mettre une icône de l'application Java dans la barre des tâches du système. La gestion de l'affichage a été largement améliorée avec au programme lissage des polices de caractères, double buffering, utilisation d'OpenGL pour avoir des effets 3D comme sous les dernières versions de X.Org et amélioration de quelques autres éléments pour augmenter la réactivité des application Swing.
On notera aussi l'apparition d'un moteur permettant d'utiliser pas mal de langages de scripts dont JavaScript dans une application Java, quelques ajouts sur les annotations.
Question compilation et développement avancé, on verra des API pour permettre aux programmes Java d'appeler un compilateur Java d'eux même, une mise à jour des fichiers .class, sans compter une API pour faire quelques manipulations au niveau de la machine virtuelle elle-même. Les professionnels JEE seront ravis de pouvoir utiliser JDBC 4 et 6 nouvelles API pour gérer XML et WebServices. Enfin, on notera quelques petits trucs en plus sur la gestion des entrées/sorties, les noms de domaines internationalisés.
NdM : rappel de la dépêche précédente « Les composants libérés proviendront de Java 7, et non Java 6, celui-ci étant pratiquement terminé, et ne sera diffusé sous GPL que si le temps le permet. ». Les innovations apportées dans Java 6 sont donc nettement moins nombreuses que ce qui est arrivé avec Java 5, mais nul doute qu'elles devraient largement aider Java à faire un peu plus d'applications client lourd et orientés utilisateurs grand public.
Aller plus loin
- java.sun.com (10 clics)
- Les nouveautés de Java (38 clics)
- Un résumé en français de ces nouveautés (68 clics)
- Java 6 sur le bureau (32 clics)
- Java sur dmoz (5 clics)
- DLFP : Java libre : un rêve devient réalité (2 clics)
# Licence ?
Posté par cougar (site web personnel) . Évalué à 2.
[^] # Re: Licence ?
Posté par Spyhawk . Évalué à 7.
Après vérification, c'est à nouveau la licence Sun qui s'applique :
http://java.sun.com/javase/6/jre-6-license.txt
http://java.sun.com/javase/6/jdk-6-license.txt
Je ne sais pas s'il y a eu, ou non, des changements mineurs dans cette licence depuis la version 5.
[^] # Re: Licence ?
Posté par Spyhawk . Évalué à 2.
[^] # Re: Licence ?
Posté par Mathias Bavay (site web personnel) . Évalué à 3.
Prière de remplacer "javaçapucestpaslibre" par "java6çapucestpaslibre". Un simple script hébergé sur linuxfr devrait pouvoir faire les modifs tous seul, non?
Le troll est dans le couloir de la mort, dépéchez vous, il n'en a plus pour tres longtemps...
Mathias
[^] # Re: Licence ?
Posté par Gabriel . Évalué à 2.
[^] # Re: Licence ?
Posté par sanao . Évalué à 2.
lecouloirdelamortçapuecestpaslibre
[^] # Re: Licence ?
Posté par Minos . Évalué à 1.
Et qu'en est-il de la license ?
Dommage, tu avais bien commencé mais tu as fini en franglais !
[^] # Re: Licence ?
Posté par cougar (site web personnel) . Évalué à 1.
# Les nouveautés
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
http://blogs.sun.com/dannycoward/entry/java_se_6_top_ten
http://about.me/straumat
[^] # Re: Les nouveautés
Posté par zepard . Évalué à 1.
(Single-threaded rendering for OpenGL pipelines) mais pas en 3D.
quelqu'un pour confirmer !!!.
# Mise à jour
Posté par François LEIBER (site web personnel) . Évalué à 4.
Comme quoi, informaticien ne rime pas forcément avec amour de l'innovation !
[^] # Re: Mise à jour
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 7.
[^] # Re: Mise à jour
Posté par François LEIBER (site web personnel) . Évalué à 2.
Ca m'encourage dans
- mon forcing pour utiliser (quand ça apporte vraiment quelque chose, quand même) les technologies récentes, ça nous permet d'avoir un avantage sur les concurrents ;
- trouver une boîte qui pousse ces technologies, ça m'évitera de m'énerver contre des murs de conservatisme ;)
[^] # Re: Mise à jour
Posté par François LEIBER (site web personnel) . Évalué à 2.
[^] # Re: Mise à jour
Posté par Nelis (site web personnel) . Évalué à 10.
[^] # Re: Mise à jour
Posté par snt . Évalué à 10.
>l'innovation !
Je suis pas contre l'innovation. Je suis meme plutot le genre a tester les beta et autres RC. Mais au boulot j'aime pas trop essuyer les platres. Si je dois livrer un truc à plusieurs centaines de clients pas tous degourdis en informatique, je commence par choisir des versions pas trop exotiques et éprouvées. Je m'adapte à mon public pour ainsi dire..
[^] # Re: Mise à jour
Posté par Infernal Quack (site web personnel) . Évalué à 7.
Genre nous on a un Weblogic 8.1 et il n'est pas compatible Java 5 donc on ne migre pas en Java 5 tant que nos applications ne sont pas migrées en Weblogic 9.x qui lui est compatible Java 5.
On ne peut malheureusement pas migrer un système du jour au lendemain d'une version de Java à l'autre :(
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Mise à jour
Posté par - - . Évalué à 7.
et bien non, mOssieur, vous attendrez, comme tout le monde, qu'on est validé et mis en place la nouvelle version des systèmes pour les postes des employés.
nan mais ho
ha mais parce qu'on croit toujours que c'"est un "suffit zuste de mettre le paquet là" , meuh non, y a les dépendances, y a les docs à mettre à jour, y a les installs automatisés à modifier et tester, faut que tout le monde soit prêt au changement, etc etc. alors patience.
donc conservateur : HEUREUSEMENT que oui ! si vous voulez de la techno de pointe, fallait faire pilote d'avion prototype (attention au boum).
(mais non je n'ai pas de déformation professionnelle)
[^] # Re: Mise à jour
Posté par François LEIBER (site web personnel) . Évalué à 5.
La version 5, ça fait un an et demi que je n'ai que ça d'installé sur mon PC pour faire tourner notre appli, sans détecter un seul problème. Vous croyez que les nouvelles versions c'est si monstrueux pour une appli développée par 3 personnes ?? Et quand je parle de nouvelle version, ce n'est pas déployer la 6 qui vient de sortir, mais plutôt la 5 qui doit avoir 2 ans d'existence, ou au moins les mises à jour correctives de la version 1.4, surtout quand certains bugs corrigés depuis nous gênent...
Quand on est dans une startup qui essaie de faire des choses innovantes pour émerger face à la concurrence, vous n'avez pas l'impression qu'une mise à jour qui ne nous coute rien et apporte beaucoup est un problème ? Parlez pour vous, je comprends vos positions, mais ne prenez pas vos cas pour des généralités, je vous en supplie.
Oui je suis énervé. Quand je pense à ce que je pourrais gagner en efficacité sans faire le moindre effort (je peux même vous donner des exemples si vous voulez) en utilisant certaines mises à jour, alors qu'on s'épuise sur d'autres points qui n'apportent rien, ça me hérisse le poil ; alors quand en plus tout ce qu'on me répond c'est que je suis un imbécile, j'ai envie d'être grossier :(
[^] # Re: Mise à jour
Posté par Gniarf . Évalué à 1.
et vice-versa.
[^] # Re: Mise à jour
Posté par bubar🦥 (Mastodon) . Évalué à -2.
okok je connais le chemin
raouste -> []
[^] # Re: Mise à jour
Posté par François LEIBER (site web personnel) . Évalué à 2.
Je signalerai quand même que je dis ça parce que ma passion c'est l'informatique, le développement et le code source, et qu'incidemment c'est d'ailleurs pour ça que je me suis mis à l'open-source, puis à Linux, et que je me retrouve sur ce forum.
Et non je n'ai jamais dit que mon cas était une généralité, j'ai juste regretté que dans ma société, alors qu'il n'y a pas les contraintes que d'autres peuvent avoir, on n'en profite pas pour bénéficier de technologies plus récentes, c'est tout.
[^] # Re: Mise à jour
Posté par GTof . Évalué à 3.
Ca c'est clair ! Suffit de voir la masse d'informaticiens qui codent encore en C. Il y en a même qui disent que c'est un langage de haut niveau ... mouhaha. Ils doivent être insectophiles.
Ceci était un message d'un programmeur O'Caml.
[^] # Re: Mise à jour
Posté par hervé Couvelard . Évalué à 5.
Comment ça non ? Ah bon ? Pourquoi ?
[^] # Re: Mise à jour
Posté par Antoine . Évalué à 5.
Il y en a même qui pensent que pour échapper au C le mieux est de passer à Java :-)
# question
Posté par TImaniac (site web personnel) . Évalué à 3.
? Quelqu'un a des explications sur le pourquoi ca prend du temps de changer la licence ?
[^] # Re: question
Posté par ragoutoutou . Évalué à 10.
Changer la license, ça bouffe du temps parcequ'il faut passer le code en revue pour vérifier qu'il n'y ait rien de problématique dedans, p.ex du code propriété d'une autre entreprise nécessitant des négociations pour le libérer ou du temps pour le remplacer.
[^] # Re: question
Posté par Jean Roc Morreale . Évalué à 4.
[^] # Re: question
Posté par tiot (site web personnel) . Évalué à 3.
Tribune Libres, ténors de l'informatique libre par Chris DiBona
Tu peux le télécharger à cette adresse http://linuxfr.org/redirect/49462.html (de l'article http://linuxfr.org/2006/11/22/21669.html)
Bref le gros problème vient des tiers, il faut demander à chaque tiers s'il veut bien mettre le code en GPL... c'est vite fait casse tête si tu n'as pas tout fait toi même de A à Z.
Bref dans le livre tout ça est assez bien décrit.
[^] # Re: question
Posté par herodiade . Évalué à 1.
Sun - qui avouait craindre comme la peste les forks (la concurrence ?) de son java - s'est senti menacé par les développements récents, de plus en plus aboutis, de gcj et classpath and co. Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux, étant donné le support de Red Hat, des fondations Apache et FSF, et des partisans du libre en général. Or les serveurs linux, ce n'est surement pas un marché que Sun peut se permettre de perdre. Sans parler de la mauvaise presse auprès des unixiens.
Comment retarder ces alternatives libres ? comment leur couper l'herbe sous le pied ? Comment ne pas perdre le contrôle des technos java tout en se redorant le blason à moindre frais ?
C'est très simple, il suffit d'annoncer qu'on va « pas tout de suite mais très bientôt » libérer son implémentation, histoire de démotiver les développeurs et décourager les investissement dans les produits concurrents.
Si l'annonce suffit à les ralentir sérieusement, alors pas besoin de se presser pour tenir parole, pourquoi céder son instrument de pouvoir aujourd'hui si on peut le faire demain (ou après demain), après tout. Il suffit de réitérer ses annonces : « mais oui c'est pour très bientôt », alors toute la presse en coeur (y compris linuxfr) reprendra ses louanges envers Sun : « c'est comme si c'était fait ». Il sera toujours temps de s'exécuter si les choses tournent mal...
Vous avalez les tuyaux marketing élémentaires comme des veaux, mes amis. Personnellement, tant que sun-jdk n'est pas libre, je ne dit pas qu'il est libre, ni presque libre, ni bientôt libre.
[^] # Re: question
Posté par Stéphane Traumat (site web personnel) . Évalué à 10.
Premier point : gcj, classpath sont a des années lumières d'être "aboutis". Je ne connais pas un développeur ou un serveur qui fonctionne avec ces alternatives. Je ne pense pas que Sun ait une quelconque peur de ça.
Deuxième point : il y a d'autres JVM que celle de Sun et je ne pense pas que cela leur fasse peur. Je pense plutôt que ça les arrange du moment qu'elles implémentent bien les specs. Je te rappelle que Sun ne gagne pas d'argent sur les JVM.
troisième point : les sources du prochain JDK sont déjà sur le SVN avec les bonnes licences, donc arrête ta parano et lis un peu !
Ils ne libèrent pas les versions précédents car ca prendrait trop de temps.
Bref, tu fais une analyse débile. Pour dire "Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux", c'est que tu n'es pas du monde Java, c'est le moins qu'on puisse dire.
http://about.me/straumat
[^] # Re: question
Posté par herodiade . Évalué à 1.
Bah oui ils ne sont pas stupides au point de réagir lorsqu'il est trop tard.
Je ne connais pas un développeur ou un serveur qui fonctionne avec ces alternatives. Je ne pense pas que Sun ait une quelconque peur de ça.
Gcj/kaffe/classpath etc. sont déjà les implems de java par défaut dans presque toutes les distribs. Par conséquent, probablement sur la majorité de desktop des utilisateurs de linux. Autrement dit, sur les ordinateurs personnels de la nouvelle génération d'unixiens (plus ou moins le coeur de cible de Sun). Ce n'est pas rien.
il y a d'autres JVM que celle de Sun et je ne pense pas que cela leur fasse peur.
Oui, elles n'ont pas les faveurs de la communauté (insuffisamment libres, ou dev insuffisamment ouvert, etc.). Même lorsqu'elles sont plus évoluées que classpath, ce ne sont pas des menaces sérieuses. La culture linuxienne fait la loi, peu à peu - pas celle d'IBM. Et dans ce beau monde des serveurs web, Red Hat et la fondation Apache (+ la bénédiction des distros), ça pèse. Gcj et classpath n'ont peut-être pas encore vraiment percé sur les serveurs, mais ils ont un soutient affectif de la jeune génération (pas celui des vieux hasbeen, qui ne lâcheront pas leurs habitudes, quoiqu'il advienne bien sûr).
Je te rappelle que Sun ne gagne pas d'argent sur les JVM.
Tu devrais lire le blog de Jonathan Schwartz (le CEO de Sun). Lorsqu'il explique sa stratégie aux journalistes et aux actionnaires : contrôler le développement de Sun, c'est contrôler un composant majeur utilisé par leurs clients, c'est une stratégie qui permet de gagner d'autres marchés (mais dont le succès dépend totalement de leur niveau de contrôle sur java). Le succès de java n'est intéressant pour eux que dans la mesure où il leur donne du pouvoir. Tu croyais qu'ils développaient leur jdk pour la beauté du geste ?
les sources du prochain JDK sont déjà sur le SVN avec les bonnes licences
Oui, et ça compile ? et il y a tout le jdk ? et quand est-ce que ça marchera correctement ? -> quand ils trouveront stratégiquement intéressant de releaser.
Bref, tu fais une analyse débile.
Merci
"Ces nouveaux venus risquaient de devenir peu à peu prédominant sur les serveurs linux", c'est que tu n'es pas du monde Java, c'est le moins qu'on puisse dire.
Bah, c'est surtout que je suis du monde du logiciel libre, où la licence des logiciels est importante. Et où l'éthique consistant à favoriser autant que possible un logiciel prometteur et libre mais de moindre qualité a souvent été récompensée. Ça te choque ? Linux fut a des années lumières de SunOS ... a une époque. La leçon de l'histoire.
[^] # Re: question
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
"Gcj et classpath n'ont peut-être pas encore vraiment percé sur les serveurs, mais ils ont un soutient affectif de la jeune génération"
AH bon ??? Pour cotoyer beaucoup de gens qui font du Java, je ne le vois pas DU TOUT ce soutien.
"Le succès de java n'est intéressant pour eux que dans la mesure où il leur donne du pouvoir. Tu croyais qu'ils développaient leur jdk pour la beauté du geste ?"
Tu confonds deux choses... implémentation et spécificiation. Sun veut garder le contrôle de la spec mais contrairement à ce que tu disais, le fait que l'implémentation qu'il propose soit libre ou pas ne change pas grand chose. J'ai lu son blog très souvent et je coris que tu dois bien comprendre que Java ou JEE, ce sont des specs.
"Oui, et ça compile ? et il y a tout le jdk ? et quand est-ce que ça marchera correctement ? -> quand ils trouveront stratégiquement intéressant de releaser."
Tu es le roi du FUD ma parole. Vas voir sur le svn, va voir le projet OpenJDK ! tu crois quoi ?
qu'ils vont dire "ah oui finalement, on arrête le projet, on recache toutes les sources parce qu'on a plus peur de GCJ !"
Très honnêtement, je n'ai jamais entendu quelqu'un de chez Sun avoir peur de GCJ ou autre... c dans ta tête à mon avis.
"Ça te choque ? Linux fut a des années lumières de SunOS ."
Non ça ne me choque pas comme Java fut a des années lumières de C++. C'est la vie.
Que tu le veuilles ou non, Sun libère Java et ce n'est pas que du marketing. Des gens comme toit disaient pareil pour Open Office ou SunOS et tout le reste...
Je trouve juste que ton analyse qui dit "Sun a peur des implémentations libres de JVM, donc ils disent qu'ils vont libérer Java pour décourager les gens et au final, ils ne le feront pas."
Elle est complètement fausse et désolé de m'énerver, mais je la trouve débile.
http://about.me/straumat
[^] # Re: question
Posté par herodiade . Évalué à 3.
Tu a lu ce que j'ai écrit ci-dessus ? j'énumère le soutient des distributions (et leurs développeurs), des fondations pour le logiciel libre (FSF, ASF & co.), et de grosses sociétés enfin réunies (IBM, Red Hat), et surtout, de ceux pour qui le libre est vraiment important - pas un « supplément d'âme » -. Ça fait beaucoup de soutient, je trouve, pour des logiciels encore imparfaits. En outre la concurrence du libre, dans leur cas, ce n'est pas seulement les autres implems de java, c'est aussi python, ruby on rails, php, etc., bref, tout ce qui a du succès sur les serveurs parce que c'est libre. Bien sûr, ça ne concerne pas les développeurs java windowsiens (sans doute nombreux), mais ce n'est de toute façon surement pas pour eux que Sun parle de libérer son jvm...
À qui crois-tu que s'adresse leur décision de libérer le code et d'adopter la GPL, précisément ?
Et pourquoi crois tu qu'ils ne l'ont pas fait il y a 2 ans, ou même 5 ans ?
Tu confonds deux choses... implémentation et spécificiation.
Alors là, soit tu me prend pour une andouille, soit tu es de mauvaise fois, soit tu a lu en diagonale ce que j'ai écrit (je penche pour le dernier). Je disait que le succès de java (la spec) n'a d'importance pour Sun que dans la mesure où ils en ont le contrôle. À savoir : en contrôlant une « implémentation de référence », en évitant qu'une autre implémentation puisse le devenir (preuve en est de leur crainte du « fork » = perdre un peu de leur contrôle). Libérer, s'ils sont habiles, leur permettra peut-être de rallier les développeurs (et distros, et frameworks etc) concurrents à leur règle du jeu, si les concurrents tapent trop fort.
Des gens comme toit disaient pareil pour Open Office ou SunOS et tout le reste...
Pas pour Ooo, c'est une autre affaire (et il n'y avait pas de concurrent, et d'autres enjeux). L'ouverture récente de Solaris, ça n'a pas manqué de m'évoquer une sorte de culte vaudou des zombies, ou la tentation de ranimer un moribond. Il est clair que les « executives » de Sun doivent amèrement regretter de ne pas l'avoir fait beaucoup plus tôt. Et d'avoir choisi une licence qui finalement les isole. Et ils se sont surement dit qu'il serait peut-être judicieux de ne pas se faire avoir au même piège avec leur jdk...
ils disent qu'ils vont libérer Java pour décourager les gens et au final, ils ne le feront pas.
Ce n'est pas ce que j'ai dit. J'ai dit qu'ils attendent (et font attendre, depuis un bon moment déjà) qu'il soit stratégique pour eux de releaser une implem libre.
[^] # Re: question
Posté par Arnaud . Évalué à 6.
IBM aurait pu passer son JDK sous GPL il y a quelques années, aussi, ça aurait considérablement changé la donne...
[^] # Re: question
Posté par - - . Évalué à 3.
>Oui, et ça compile ? et il y a tout le jdk ? et quand est-ce que ça marchera
>correctement ? -> quand ils trouveront stratégiquement intéressant de releaser.
ca compile, c'est correct, c'est intéressant et c'est du code concret.
Sun a déjà donné le calendrier des sorties de chaque composant.
ils ont déjà expliqué les difficultés et enjeux.
vous avez déjà une jvm et le compilateur en libre, et un bon pan de tout java enterprise en licence opensource qui sera début 2007 aussi sous gpl.
écoutez, si vous êtes aigri et vivez dans un monde dur et méchant, sachez que ce n'est pas le cas pour tout le monde.
en ce qui concerne Java et la GPL et java7 : TOUT VA BIEN.
---
GCJ est peu utilisé au delà d'eclipse dans les redhat/fedora
simplement, tous les enseignants et développeurs pour qui je travaille me demande d'installer le jdk de sun. Il y a trop de manques dans gcj, trop peu de documentations, trop d'ajouts dans java 5 et tout le reste pour que gnu puisse suivre
mas ce n'est PAS LE MEME BUT !!
gcj est très bien déjà pour permettre de faire une application java native et se passer de la jvm java pour certains usages quand ce n'était pas libre.
-
je réponds à Stephane Traumat :
>>"gcj devenait effectivement très utilisable (Eclipse tourne dessus, quand même)."
>C'est pas possible... est ce que tu as déjà essayé de faire tourner eclipse avec GCJ ?
>J'ai essayé avec une fedora et c'est pas ça ! loin de la.
j'ai déjà travaillé et des professionnels avec Eclipse sur gcj, cela marche bien et permet de travailler. ne faites pas un troll inverse.
cela ne veut pas dire que gcj gomme la nécessité d'utiliser jdk et jre.
---
Apache soutient sa propre jvm. il leur faudra du temps avant d'arriver à quelque chose abouti.
mais pourquoi pas ?
-----
>Oui, et puis il faut préciser que la concurrence, dans leur cas, ce n'est pas seulement
>les implémentations libres des specs java, mais aussi les logiciels qui ont du succès
>sur les serveurs web, en grande partie grace au soutient des « libristes » : python,
>ruby/RoR et PHP en particulier, qui deviennent eux aussi de plus en plus capables, et
>qui ne sont pas des pestiférés du LL.
vrai.
flagrant sur le domaine des applications légères et des petits développement en entreprise.
il était donc important que sun réagisse avant que php ou ruby se mette à muter en un équivalent de serveur applications surpuissant mais facile à aborder.
maintenant, en libre, nous avons une gamme de langages et services adaptés à différents scénarios et usages.
et Sun met son propre langage en sécurité.
----
Bien sur que Sun fait un choix calculé et vise son propre intérêt. figurez vous que je suis pareil et que j'estime que sun a raison.
Mais on peut réaliser, que son propre intérêt passe par l'intérêt d'une communauté.
En mettant la jvm et classes Java de références sous gpl, Sun pérennise son développement, aide la communauté libre, chamboule les idées reçus et créé une opportunité sans précédents pour améliorer nos logiciels tout en continuant à participer au libre.
Quel mal peut il y avoir ?
Si Sun gagne de l'argent grâce au retour sur les développements java, leurs propres produits et leur propre expertise : MAIS tant mieux ! tant mieux pour eux et pour nous !
Il n'y a rien de mieux que de vivre de son propre travail, un travail qui bénéficie à tous.
[^] # Re: question
Posté par herodiade . Évalué à 3.
S'il y en a une qui en sait long sur les stratégies opensource de Sun, c'est bien Danese Cooper (cf. http://en.wikipedia.org/wiki/Danese_Cooper et http://madpenguin.org/cms/?m=show&id=3719 si vous ne savez pas qui elle est).
Voilà ce qu'elle disait le 18 Mai 2006 (ici : http://danesecooper.blogs.com/divablog/2006/05/what_sun_does(...) ), je ne cite qu'un extrait mais l'ensemble
est intéressant (elle explique comment l'annonce de la liberation de Java sous une licence approuvée par l'OSI fait immédiatement suite à l'annonce du suppo
rt complet de SWING/AWT par Harmony) :
« Today at JavaONE my pal Geir Magnusson is announcing that Harmony has full support for SWING/AWT. This is really big news if you're following Harmony from the sidelines (as Sun has been doing). [...] Earlier this week we all heard about Jonathan Schwartz and Rich Green hinting they were about ready to release Java under some OSI-approved license. Supposedly they just need to nail down "How to Deal with Compatibility". I read this news with some irony, since I know that they bloody well know exactly what to do already. Its been discussed every year since 1999 inside of Sun. Their covenant with Apache and the Geronimo has already successfully demonstrated that it can be done (compatible FOSS reimplementations of Sun-generated specifications). They are simply being disingenuous. What they really mean is "How can we placate the FOSS community without giving up control?" which is the age-old question for Sun. »
Mais on peut réaliser, que son propre intérêt passe par l'intérêt d'une communauté.
Oui et non. Ou « comment attendre jusqu'au dernier moment, jusqu'à ce que la communauté ai trouvé une solution alternative ». Bof...
Donc tant qu'on n'a pas une release propre et libre dans les bacs (qui viendra, ok : mais ce n'est pas l'heure de les remercier), je maintient que relayer la propagande de ceux qui nous ont baisé si longtemps, c'est contre-productif, l'inverse de ce qui fait avancer les choses. Pour le moment, la nouvelle c'est que Sun a sorti son Java6, qui n'est pas libre. Point barre.
[^] # Re: question
Posté par Dring . Évalué à 2.
gcj devenait effectivement très utilisable (Eclipse tourne dessus, quand même). Apache avait annoncé son intention de sortir son JRE libre. Et Sun pouvait donc à terme perdre son leadership sur la techno java.
Or, même si Sun ne gagne pas d'argent sur les JVM, le fait d'être le principal fournisseur lui permet d'être un acteur incontournable, et donc d'assurer ses revenus *autour* de java.
Il est difficile dans ces conditions de ne pas faire le lien entre la montée en puissance des solutions alternatives et la libération de la JVM.
[^] # Re: question
Posté par Stéphane Traumat (site web personnel) . Évalué à 3.
C'est pas possible... est ce que tu as déjà essayé de faire tourner eclipse avec GCJ ? J'ai essayé avec une fedora et c'est pas ça ! loin de la.
"Apache avait annoncé son intention de sortir son JRE libre."
Ils avaient surtout commencer à travailler dessus... une sortie n'aurait pas été prévue avant longtemps.
"le fait d'être le principal fournisseur lui permet d'être un acteur incontournable, et donc d'assurer ses revenus *autour* de java."
Je ne suis pas d'accord. L'avantage de Sun est de "gérer" les specs et de détenir la marque... mais pas d'avoir un JDK fermé.. je vois pas en quoi c'est mieux que d'avoir un JDK ouvert.
http://about.me/straumat
[^] # Re: question
Posté par arnaudus . Évalué à 4.
Oui... et non. Enfin Sun connait quand même depuis bien longtemps les avantages et les inconvénients du modèle libre. Sun connait depuis bien longtemps "javasapusépablibre", les réticences de certaines distrib Linux à intégrer eur JVM proprio, les critiques des gens qui trouvent que la JVM sous Linux elle pue, les critiques envers OpenOffice quand les dépendances à "javasapusépalibre", etc. En bref, Sun sait depuis très longtemps que la communauté souhaitait une JVM libre. Pourquoi donc n'a t-elle pas été libérée avant?
Je pense que l'hypothèse de la stratégie commerciale n'est pas si décalée et absurde que ça. Autant c'est complètement débile de dire que rien de fonctionnel ne va être libéré, autant c'est peut-être naïf de croire que Sun n'a pas pris en compte la montée en puissance d'implémentations parallèles de leur machine virtuelle. C'était certainement une raison parmi d'autres, mais une raison quand même.
Parce que sans voiloir balancer un gros troll, javasapusélent aussi. Et avec une grosse communauté de devs derrière, il aurait très bien pu être possible pour CGI et ses petits copains de commencer à devenir assez performants, plus portables et moins buggués que leur aïeul... et là ça aurait fini par faire mal à Sun, parce que tout finit par se savoir; et c'est l'image de marque qui en prendrait un coup.
Enfin, il faut bien admettre que le risque d'un fork pour un gros projet est extrêmement limité. Regardez OpenOffice, c'est quand même un logiciel extrêmement utilisé, dont le développement est également assez critiqué (dépendances pourries à Java, lourdeur apparemment insolvable, cycle de release assez long, avec un changement de version majeure pas très évident à part dans le splashscreen, portabilité douteuse (notemment sur Mac)...). Or, à part bourré, personne n'a jamais dû imaginer sérieusement une seule seconde de forker OpenOffice. Autrement dit, même libéré, on garde très probablement une mainmise générale sur le projet, et ça ne doit pas être pour déplaire à Sun.
[^] # Re: question
Posté par herodiade . Évalué à 2.
Lorsque Schwartz annonce* (tient, d'ailleurs, une annonce just in time) qu'il a choisi tout soudain la GPL parce que Novell ne joue pas le jeu du libre (l'accord sur les brevets avec MS), on ne peut pas savoir si c'est la vrai raison, mais on sait ce que Sun veut nous dire. En ce qui me concerne, je traduit par : n'allez pas voir ailleurs, c'est nous qui défendront le libre. Il faut être naïf pour croire que leur timing soit le fruit du hasard ou échappe à leur volonté.
* http://blogs.sun.com/jonathan/entry/fueling_the_network_effe(...)
[^] # Re: question
Posté par isydor . Évalué à 3.
C'est pas possible... est ce que tu as déjà essayé de faire tourner eclipse avec GCJ ? J'ai essayé avec une fedora et c'est pas ça ! loin de la.
je veux pas faire mon voleur de karma, mais : http://www.klomp.org/mark/gij_eclipse/ (c'était en 2002)
et en 2005 :
http://developer.classpath.org/mediation/ClasspathShowcase#h(...)
et waloo !
[^] # Re: question
Posté par Dring . Évalué à 2.
Ben oui, j'ai essayé, et j'ai trouvé ça pas mal du tout. En tout cas, c'était largement utilisable.
Comme déjà dit plus haut, ils auraient été de bien piètres managers si ils avaient attendu que ça sorte.
GCJ ne porte pas la marque java ; ce n'est pas une implémentation certifiée, comme JBoss en son temps n'était pas certifié J2EE. Ce n'est pas ça qui l'a empêché de devenir un des ténors du secteur, en s'octroyant une bonne partie du marché des "petits" serveurs J2EE.
Ce n'est donc pas de détenir la marque qui aurait sauvé Sun de se faire "déposséder" de son bébé. Il aurait suffit que la majorité des acteurs suivent GCJ (je prends GCJ comme exemple, hein, j'aurais pu prendre l'implémentation Apache).
En ouvrant son code, Sun limite évidemment l'intérêt de développer des JRE alternatifs, mais aussi de les utiliser. Pourquoi RedHat, Mandriva, Suse, Debian continueraient de financer/packager d'autres JRE si celui de Sun remplit toutes leurs conditions en terme de licence ?
De toute manière, je ne vois pas comment on pourrait *affirmer* que l'arrivée de JRE alternatifs libres n'a pas eu pour effet de déclencher ou d'accélérer la libération du JRE de Sun.
[^] # Re: question
Posté par domak . Évalué à 2.
Évidemment qu'il y a un but commercial. Vu le bilan chroniquement déficitaire, ils ont intérêt à se bouger !!! (et c'est vrai qu'aujourd'hui, celui qui se fait vraiment du pognon avec Java, c'est IBM).
Mais franchement, vous ne pensez pas plutôt que le vrai concurrent de Java c'est .NET ?
[^] # Re: question
Posté par supergab . Évalué à 3.
Ensuite, Microsoft n'offre qu'une implémentation pour Windows. Je pense que les implémentations de Java sont plus avancés que Mono ou .GNU. Il faut aussi noter que Microsoft n'offre aucun support ou garantie pour ces produits concurrents.
Certains peuvent dire que, contrairement à Java, les spécifications d'une bonne partie de .NET sont standardisés. Il s'agit là d'une façon de rassurer les clients sur la qualité. «Regardez comme notre produit est bon. Il repose sur un standard international.» Ce n'est certainement pas une décision irréfléchie.
La popularité de Java a nuit à .NET qui n'offre pas une solution bien différente ou révolutionnaire. Il y a aussi les anciens produits de Microsoft qui ne veulent pas mourir (Visual Basic 6 par exemple).
Il y a d'un côté de grosses pointures comme IBM et, de l'autre, Microsoft. Le temps de QBasic et des débuts de Microsoft est bien loin.
[^] # Re: question
Posté par Dring . Évalué à 2.
[^] # Re: question
Posté par Mildred (site web personnel) . Évalué à 2.
https://openjdk.dev.java.net/
je vais peut être finir lar le faire moi même
# JSR 202 ?
Posté par alf . Évalué à 5.
Je suis déjà tombé sur cette limite, en faisant des paquets d'include statiques à partir d'une JSP : la compilation de la JSP complète échouait parce qu'une limite du format des fichiers .class était dépassée (je ne sais plus si c'est la limite de taille du bytecode d'une méthode, ou de toute la classe, mais il me semble que c'était plutôt le premier cas).
J'avais compris (après maintes recherches infructueuses) que le JSR 202 était sensé repousser la limite en question, et donc j'attendais de savoir quand il serait implémenté. Pourtant, en lisant le PDF qui compare la spécification avant et après le JSR ( http://jcp.org/aboutJava/communityprocess/final/jsr202/index(...) ), je ne vois pas trop ce qui fait que la limitation de taille a été enlevée, ou au moins que la limite a été repoussée... Il faut dire que je ne suis pas non plus au courant de la machinerie interne des JVM au point de comprendre la spec du format des fichiers .class.
Comme je n'ai pas trouvé d'infos ailleurs, j'en profite pour poser la question ici : est-ce que des gens plus au fait peuvent préciser l'état de la chose ?
PS : oui, je sais, faire des include statiques dans des JSP au point de faire péter le compilateur, il y a un problème de conception à la base, et c'est le code des JSP qu'il faut corriger plutôt que le compilateur. Mais c'était juste pour savoir si la situation avait changé...
# les sources GPL de Java sont dans Subversion
Posté par free2.org . Évalué à 10.
http://www.sun.com/software/opensource/java/getinvolved.jsp
J'ai pas vérifié les licenses de tous les composants, mais Hotspot est bien sous GPL par exemple:
https://openjdk.dev.java.net/source/browse/openjdk/
# Et moi qui venait juste de finir le portage pour la Java 1.5
Posté par syj . Évalué à 2.
Je venais juste finir le portage pour la 1.5 et supprimer toutes les variable "enum" qu'un de mes collegues avec disciminer dans le code :-).
Allez, je m'en vais relancer Eclipse.
# JRE sur PocketPC...
Posté par Marc Le Douarain (site web personnel) . Évalué à 1.
à+
[^] # Re: JRE sur PocketPC...
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: JRE sur PocketPC...
Posté par finesse2600 . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.