pourquoi se compliquer la vie à vouloir détourner gmail?
Parce que quelque part, utiliser le mail comme moyen d'entrer d'un blog me paraît nettement plus intelligent que la saisie dans une interface web, et pour différentes raisons.
D'abord, ça me permet de blogger depuis n'importe quel poste disposant du mail (ce qui est plus facilement le cas qu'un accès web permettant d'aller jusqu'à mon site perso).
Ensuite, parce que GMail contient déja tout ce qu'il faut pour faire un bon blog : des catégories, une notion de discussion (qque je trouve toujours un peu faible dans un blog) des possibilités d'édition (avec les étoiles) et les images jointes. En fait, la seule chose qui me manque un peu, c'est la coloration syntaxique quand je tape du code, mais je me sens bien de faire un hack tout dégueu en php pour intégrer ça automatiquement.
Ah tiens, c'est bizarre, je n'avais pas fait attention à ça. Pourtant, il existe actuellement pléthore d'outils se pluggant sur GMail pour y ajouter des fonctionnalités, du gmail-rss à la version hackée pour opera (qui malheureusement ne marche plus du fait d'une obfuscation du javascript magique), dont certains sont même réintégrés, sous une forme ou une autre, à GMail, comme par exemple le GMail notifier.
Ah tiens, c'est bizarre, je n'avais pas fait attention à ça. Pourtant, il existe actuellement pléthore d'outils se pluggant sur GMail pour y ajouter des fonctionnalités, du gmail-rss à la version hackée pour opera (qui malheureusement ne marche plus du fait d'une obfuscation du javascript magique), dont certains sont même réintégrés, sous une forme ou une autre, à GMail, comme par exemple le GMail notifier.
Je pense que ce qu'il voulait dire, c'est un client open source de la qualité de Dialog ou, surtout, de XNews. Avec par exemple (mais ça n'est que mon critère différentiateur à moi) le scoring...
Si tu utilises Swing dans un logiciel libre en Java, il y a de fortes chances qu'il ne soit pas utilisable dans le « Monde Libre » défini dans le texte. Cette fonctionnalité est disponible dans la plate-forme Java de Sun mais pas dans Classpath.
Sans doute parce que CLASSPATH n'est pas au niveau des autres JVM (je me demande même s'il s'agit d'une JVM validée). Les autres JVM doivent fournir Swing, qui fait partie des API de Java.
Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.
Je ne le comprend pas comme ça. Les classes java.* et javax.* sont disponibles dans toutes les JVM (ça, c'est le "contrat moral" que passent ceux qui fournissent des JVM). En revanche, lorsqu'on accède à une classe sun.tools.javac.Main (par exemple) on sait qu'on n'en disposera que dans la JVM de Sun (et encore, seulement en installant le JDK). Il me semble que Stallman mentionne plutôt le second cas (utiliser une classe non-standard en pensant qu'elle l'est) quel le premier (utiliser une classe standard, et tomber sur une "implémentation" ne respectant pas le standard).
Et dans ce cas, il se gourre violement. Le code que j'écris n'utilise pas autre chose que du java.* (enfin, presque, il y a un peu de org.apache.*, mais ça, c'est quasi-obligé), et peut donc s'exécuter indifférement sur une JVM Sun, IBM, BEA ou CLASSPATH, pour peu qu'icelle supporte réellement les bibliothèques java.*
Pour les DBA, ils me disent qu'on peut pas faire abstration de la base de données ! tout à fait impossible et que de toute façon, ca dégraderait les performances
Il faut les comprendre : leur dire ça revient à leur dénier leur rôle de chef d'orchestre du système d'information, pour en faire de simples administrateurs d'archives. D'un coup, c'est moins classieux. D'un autre côté, c'est exactement leur boulot : une donnée dans une base est à peu près aussi utile qu'un classeur au fond des archives.
En même temps quand on s'appelle Nicolas Delsaux aussi on peut se renseigner... (et je ne prétends pas avoir la vérité absolue, mais bon quand on commence par « C'est un tissu d'âneries ou quoi ? » pour ensuite critiquer sans argument quelqu'un qui a déjà fait énormément de choses (qu'on l'on aime ou pas)...)
L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit
i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.
Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.
De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.
Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).
Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?
Perso, j'aime bien les ejb de sessions avec XDoclet, je trouve que c un bon endroit pour centraliser/tester la logique métier et la rendre accesible aux applis web, lourde, webservices....
Excuse-moi de te dire ça froidement comme ça, mais ... tu rigoles, là ?
Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise. En disant ça, est-ce que je passe pour un demi-extra-terrestre, ou est-ce que je peux éventuellement être dans le vrai ?
et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)
Tiens, c'est marrant, moi aussi. Et générallement, ces DBAs te disent que la charge de leur base est hyper-importante, avant même que quiconque ait fait le moindre test de charge de l'application sur la base, bref, ils te demandent à toi d'optimiser, parce que eux, ça les fatigue ;-)
On peut bien entendu mixer le tout, et on peut alors utiliser ClassPath et les API Mono en même temps :)
Et écrire du code qJava qui ne marche qu'avec Mono ? Génial !
A moins de rétroporter les APIs Mono en java, auquel cas ça pourrait être à peine plus générique ...
C'est un tissu d'âneries ou quoi ?
Est-ce que tu utilises actuellement un ordinateur libre ?
Parce que bon, c'est bien gentil de développer avec une plateforme libre, mais ton OS, lui, il l'est ? (sans doute) Et ton processeur, est-il libre ? Le disque dur, la RAM, le câble réseau, les switches qui t'amènent jusqu'à LinuxFR, sont-ils complètement ouverts ?
Qui qu'on soit, il est toujours bon de se renseigner un minimum avant de causer, quand bien même on s'appelle Stallman.
Le processus définissant l'évolution du langage Java est libre, et organisé par le JCP. Ce qui n'est pas libre, ce sont les implémentations de machine virtuelle, dont celle de Sun. Maintenant, il me semble que cet appel à bosser sur CLASSPATH te vise autant que moi. Alors, si tu arrêtais de te plaindre pour l'aider ?
Maintenant, vous pouvez toujours me moinsser, si ça vous amuse d'assurer l'orthodoxie de LinuxFR ...
J'ai l'impression qu'on reprend les mêmes problèmes mais au lieu de construire une grande solution toute faite et qui se voudrait tout terrain (à la EJB), on reprend avec les bases du langage (POJO) et on construit de petites solutions ciblées : jdo/Hibernate pour la persistence, Struts/webwork/tapestry pour les vues... et un framework d'application (pico Container, Spring) pour relier le tout.
Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
ça amène d'un part à des solutions plus simples à construire et à appréhender.
Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Pas pour les DBAs ;-)
Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...
Inconvénient : bien souvent, l'IoC, ou injection de dépendances, utilise un fichier XML, ce en quoi je ne suis pas d'accord du tout. Mais là, on rentre dans les arcanes de l'élégance Java ...
Je suis pas sur que ce soit Java qui interesse Google.
Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
Je vais parler pour celui que je connais par mail (Cedric Beust). Lui, il m'a surtout l'air d'être une brute en Java. Peut-être qu'il connaît ces problématiques, mais ce qu'il connaît surtout, c'est le Java. Et j'ai comme l'impression que pour les autres têtes, c'est pareil.
En effet, nous voyons de plus en plus fleurir des projets libres dynamiques tournant autour de Java.
Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.
Je ne voudrais pas marcher dans le troll, mais ... pourquoi faire ?
Soyons pragmatiques : les consortiums J2EE sont pour la plupart le fait de grosses structures (même ObjectWeb en fait partie). Et ces structures, si elles voient un intérêt à développer telle ou telle couche applicative, le font. Redévelopper une machine virtuelle, ou participer au développement, ne les intéresse pas, car celles existant (IBM, Sun, BEA) sont suffisament performantes pour leurs besoins.
De plus, dans leur esprit, Java => JVM Sun. J'en veux pour preuve qu'à la SNCF, ils utilisent Weblogic, pourtant fourni avec JRockit (la meilleure JVM pour serveur J2EE), sur une JVM Sun (incompréhensible, mais vrai).
Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.
C'est vrai que ce serait sympa, mais ça n'intéresse personne. par exemple, moi, réécrire les classes du JDK, je suis désolé, mais ça m'emmerde profondément.
Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?
Allez, encore quelques autres nouveautés, et des petites informations complémentaires
Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.
BEA a quand même sorti une très belle nouveauté cette année : Weblogic Workshop, associé au framework Beehive (surcouche de Struts) tous deux très convaincants, comme je l'écris ici http://nicolas.delsaux.free.fr/web/Java/formation.php(...) et qui plus est Open-Source livré à la fondation Apache (qui n'en est plus à un framework web de plus) !
Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.
Tu penses à Spring, manifestement. N'oublions pas Tapestry, WebWork et autres qui montrent une seule chose : il n'existe pas actuellement de solution web réellement convaincante.
À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).
D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.
Kwé ? D'un autre côté, Sun demande la suppression de tous les API Sun (J2SE, J2EE et J2ME) du site jdocs. Dommage !
Pendant ce temps les discussions sur les EJB 3 font rage,
Ah ça, les EJB, c'est toujours pas gagné, surtout quand on voit qu'il faut environ un mois pour écrire un mapper O/R. La dernière fois que j'ai discuté avec des gens qui avaient écrit des EJB, je leur ai demandé ce que ça leur apportait. Difficile d'avoir une réponse claire sur le sujet, sauf de la part d'une personne bossant pour BEA ... Mais ça peut être une réponse orientée.
et Google engage une armée de développeurs Java de très haut niveau...
Et tout le monde se demande pourquoi : porter Google en Java ? Réécrire des interfaces web en J2EE qui sent, ou sortir son propre conteneur ?
Pas seulement. Le seul problème est qu'en Java, les plus mauvaises JVM sont Open-source; Mais si tu prends celle de BEA, par exemple, elle déchire pour toutes les applications serveur (quand je dis elle déchire, je veux dire qu'elle est vraiment plus rapide que celle de Sun, et également gratuite).
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Je ne suis pas d'accord.
L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++
J2EE est un ensemble de normes et d'outils permettant à des applications Java de s'intégrer à une informatique d'entreprise (lire "à un merdier sans nom").
Pour ça, un serveur J2EE doit fournir les outils correspondant à un ensemble de normes dont les noms commencet souvent par J :
JMX (Java Management Extension) pour intégrer le serveur à un Nagios, par exemple
JMS (Java Messaging System) pour l'envoi de messages événementiels sur les systèmes de messages (jai oublié le nom, mais globalement, ça n'a rien à voir avec Evolution, Outlook ou Opera)
JTS (Java Transaction Service) pour gérer les transactions, voire même les transactions distribuées
JSP (Java Server Pages) une petite techno de présentation, qui a vécu.
EJB (Enterprise Java Beans) la norme phare de J2EE, qui définit des "objets métiers" sous un certain nombre de forme qui nous font revenir à l'époque bénie des struct C. Le seul avantage étant qu'ici, les struct peuvent être persistées de manière quasi-transparente ...
Et tant d'autres que j'oublie
Tout ça c'est bien joli, mais en fait, à sens, si J2EE apporte une certaine capacité d'intégration de Java à "l'informatique d'entreprise", ça se fait au prix de nombreuses contorsions :
- Durant le développement, car J2EE est une norme ouverte, qui n'impose que peu de choses (et qui notamment n'impose pas les descripteurs de déploiement permettant d'organiser tout le bouzin). Ce qui fait qu'une appli J2EE n'est en général pas ou peu portable (à moins bien sûr d'être codée avec des outils génériques, comme XDoclet ou Ant, et encore ...). Bref, l'enfer, le véritable enfer du développement J2EE, c'est que loin de nous aider à développer plus facilement grâce à une meilleure organisation Java (ce qui est en partie fait), le code est complètement scindé entre d'un côté le développement de composants Java, et de l'autre leur organisation (qui n'est souvent pas réellement séparée, du fait que ces applications soient le plus souvent des saletés de gestion) qui elle est contenue dans des fichiers XML.
- Durant l'utilisation, on est quand même très loin d'applications rapides. D'accord, ça marche, mais comme le dit de plus en plus de monde, la complexité de J2EE le rend inaccessible à l'immense majorité des développeurs. De plus, comme toute usine à gaz qui se respecte, le coût d'exploitation n'est pas nul, puisqu'il existe désormais des postes d'administrateurs d'applications J2EE, dont le rôle, tout comme pour un admin Oracle, est de faire en sorte que ça continue à marcher (!).
Bon, pour moi, développeur Java, il est clair que c'est uin bon gagne-pain. Toutefois, je trouve ça dommage qu'une techno comme Java serve à "ça", et surtout de cette manière là.
La grosse question, c'est : est-ce que JBoss peut être encore considéré comme un tenant de l'esprit de libre ?
Entre la doc payante (et pas forcément de très bonne qualité), les magouilles pas toujours de très grande qualité de Marc Fleury pour pousser coûte que coûte sa solution (avec notamment les déboires provoqués lors du clash de l'année dernière), je ne trouve pas que ça fasse de JBoss un fleuron du libre, mis à part par le nombre de téléchargements éléphantesque du truc.
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.
C'est pas pour être lourd, mais moi, cette news me fait plutôt l'effet d'un commiqué de presse conjoint Ximian/Microsoft attaquant en règle Java. Je cite :
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java),
Jusqu'ici, tout va bien.
le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes)
Là, ça dérape déja bien. Si .Net est supportée pour Linux, Windows et Mac, grâce à Mono, la liste des plateformes supportant Java (que ce soit en Open-source ou non), est quand même un peu plus longue, incluant par exemple des téléphones portables, des PDAs, des routeurs, des automates programmables, des robots mobiles, des cartes bleues, etc, ...
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
Le site http://www.robert-tolksdorf.de/vmlanguages.html(...) donne effectivement une liste fabuleusement courte de langages pouvant être compilés en bytecode, sans passer par le langage Java. Et, chose étonnante, tous ne sont pas orientés objet (je citerai par exemple Lisp, Logo, Prolog, Eiffel, Smalltalk, Ada, mais pas Cobol, malheureusement)
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
Là, je m'avance, mais dans la mesure où tous ces langages sont compilés en bytecode, il doit être possible de faire facilement des binbdings de l'un à l'autre. je sais que c'est au moins possible pour JScheme, implémentation java d'un interpréteur Scheme permettant d'aller de l'un à l'autre et réciproquement.
- des fonctionnalités supplémentaires comme les méta-données,la détection de débordement
Ben .. ça existe depuis un bon moment en Java, à moins qu'on ne parle pas de la même chose. Quant aux metadonnées, elle sont présentes dans Java 1.5 (ou Java 5) qui sort ces temps-ci.
ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
- la plateforme Java est une solution propriétaire
Non. le langage Java est libre, et son évolution est pilotée par le java Community Process, qui va parfois à l'encontre des souhaits de Sun. En revanche, effectivement, la machine virtuelle de Sun n'est pas libre, mais il existe un certain nombre de JVM libres, qui sont cependant en retard sur celle de Sun.
alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seul les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)
Ca fait peut-être un peu Don Quichotte, mais pour moi cet article est symptômatique : sous couvert de défense du libre, on assiste là) à une attaque en règle contre Java, au profit de quoi , D'une plateforme dont le développement est piloté par Microsoft ? Super.
Sans faire mon bégueule, celle de cybercodeur est quand même plus intéressante. Et, comme j'ai eu droit à une invitation, je peux en rajouter une couche :
Attention : GMail est encore en beta, donc un certain nombre de ces commentaires ne seront plus valides à la fin
D'abord, ce webmail utilise massivement le javascript, avec près de 200 Ko de scripts chargés pour faire tourner l'interface graphique, et également pour limiter au maximum les échanges. En effet, grâce au javascript, la page échangée avec le serveur ne contient que des données, et aucune info de présentation, déplacée dans le javascript. Ca, c'est l'avantage. L'incovnénient, c'est que les développeurs de Google doivent s'amuser à tester leur webmail sur chaque navigateur web utilisé, pour débugger les spécificités. Ca donne parfois des limitations puisqu'Opera, par exemple, n'est pas du tout supporté, bien que d'après un échange mail avec leur support ce ne soit apparement quie temporaire. D'un autre côté, IE, Mozilla et tous ses dérivés, Safari sont parfaitement supportés, car complètement testés.
Ensuite, les filtres sont encore très imparfaits, il est en effet impossible de sélectionner plusieurs adresses "From" pour donner un label.
La "review" de la news explique que, justement, les labels sont une nouveauté assez épatante. Bon, c'est vrai que c'est la première fois dans un webmail (de même, selon moi, que le suivi des conversations, bien que d'autres GMailers ne soient pas d'accord avec cet avis). Toutefois, tous les utilisateurs du mail d'Opera seront d'accord avec moi pour dire que ça a au moins un an.
Au chapitre des manques cruels, il y a l'absence d'une vue du source du message, avec tous les champs d'entête, ainsi que le problème, déja signalé, du curseur qui se positionne dans les réponses au-dessus du mail auquel on répond, ce qui est très gênant.
Dans le même ordre d'idée, il n'est pas possible de scinder une conversation devenue trop longue.
Mais globalement, GMail est tout à fait satisfaisant comme webmail, et les nouveautés qui arrivent (forward automatique, itneface sans Javascript) devraient rapidement en faire un standard du webmail comme il est un standard de recherche.
Enfin, les remarques sur la vie privée, encore bien tenace, ont plutôt tendance à me faire sourire. D'abord parce que je 'nai rien à cacher (enfin, pas grand chose), ensuite parce que je comprend tout à fait que Google rentabilise son activité mail d'une manière ou d'une autre, comme Opera rentabilise son navigateur en y affichant de la pub.
Vous penserez sans doute que je suis un fils de pub, mais non, c'est juste que je comprends que ces entreprises commerciales se doivent de gagner de l'argent, même si je préférerais évidement un service identique gratuit.
Essayes un peu avec les tous derniers JDK, le look'n'feel windows (je ne parle que de ce que j'ai vu) a été terriblement amélioré, et fait que désormais les applications Swing s'intègrent aussi bien que le SWT dans un bureau.
Avec firefox-qui-est-tout-léger y a aucune excuse pour utiliser opera.
A quel niveau est-il plus léger ? Lors du téléchargement (ce qui serait faux parce qu'Opera ne pèse que 3 Mo, contre 4.7 pour Firefox) ?
En plus opera ça pue c'est pas libre,
Le sapusaipalibre, c'est bien quand on parle par exemple d'un format d'échange, ou d'outils non interopérables. Mais Opera est un des navigateurs qui respecte le mieux les différents standards du web, et ne peut donc pas vraiment rentrer dans cette catégorie, sauf pour ceux qui ont évidement un but moral, ce qui est évidement ton cas puisque c'est ton argument majeur (voir la suite).
et il impose de la pub, et même si on arrive à la virer le principe reste honteux.
Attends, je rêve, où tu parles consciement de *cracker* un logiciel pour t'affranchir du modèle économique choisi ? C'est marrant, mais quand je vois cet argument juste sous celui évoquant le fait qu'Opera ne soit pas libre, j'ai plutôt l'impression que pour toi, Libre sonne plutôt free beer qu'autre chose. Du coup, tes arguments me semblent un peu plats.
En plus, la pub, dans la version 7, elle est bien : tu as la possibilité d'utiliser les google ads, ce qui te permet d'aller jeter un oeil à d'autres sites, certes payants, mais parfois assez proches de ce que tu souhaites.
Je me doutes bien que pour un idéologue du libre comme toi, les sirènes publicitaires ne sauraient avoir un charme suffisant. Mais pour ma part, je trouve ça bien pratique.
À la limite je préfère IE à opera.
Oui, bien sûr, utilises donc un produit buggé jusqu'au trognon, techniquement mort, arriéré d'au moins une génération, ouvrant ton PC à toutes les attaques dont LinuxFr aime à se faire l'écho, plutôt qu'on logiciel adhérant fortement aux standards, réputé pour sa qualité, sa rapidité, sa légèreté et son adhérance aux standards.
Mais au fait, tu sais qu'Opera existe aussi pour Linux ? Et que des gens s'en servent sous Linux ? Dingue, non !
Selon ZDNet
On n'en a un peu rien à foutre, non ? LinuxFr n'est pas une succursale de Ziff-Davis, me semble-t-il, mais ça n'est qu'anecdotique.
* Mettre en place les échanges entre membres, contributeurs et utilisateurs.
Je ne crois pas, non. Le patron du consortium Eclipse doit avoir avant tout un rôle d'arbitre politique entre les désirs des différents groupes du consortium (IBM, Oracle, Borland, HP, ...).
* Assurer le lancement de la version 3.0 pour l'été 2004
Ca m'étonnerait vraiment que ce type en ait quoi que ce soit à faire. Les versions de la plateforme Eclipse doivent sans aucun doute avancer à rythme dont il se cogne complètement. Lui n'est pas là pour la technique, mais pour la direction.
* Assurer des bases saines pour le projet open WebTools qui permettra d'utiliser Eclipse du côté serveur.
C'est quoi cette histoire ?
* Mettre en place une équipe dirigeante et superviser les planifications.
En bref faire du consortium un truc rentable.
Son passé de gestionnaire au sein d'Oracle ne sera pas de trop, aux vus de la responsabilité et de la tâche à accomplir ...
Je ne vois ni le rapport, ni le problème. Effectivement, c'est un gestionnaire, car le consortium Eclipse est une entreprise qui vit des subsides de ses membres. Mais la tâche à accomplir ? C'est quoi ?
sans compter qu'Eclipse est un projet d'importance, qui a provoqué de nombreuses rivalités et prises de positions parmi des acteurs importants du marché informatique.
Uniquement Sun et Microsoft (bien que Microsoft n'en parle pas, j'imagine qu'ils doivent surveiller ça de près). Tous les autres poids lourds ont rejoint le consortium, parce qu'ils se rendent bien compte que ça leur rend bien service.
[^] # Re: Pour ceux qui aiment les blogs pas cher
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal Un outil de blog basé sur GMail. Évalué à 1.
Parce que quelque part, utiliser le mail comme moyen d'entrer d'un blog me paraît nettement plus intelligent que la saisie dans une interface web, et pour différentes raisons.
D'abord, ça me permet de blogger depuis n'importe quel poste disposant du mail (ce qui est plus facilement le cas qu'un accès web permettant d'aller jusqu'à mon site perso).
Ensuite, parce que GMail contient déja tout ce qu'il faut pour faire un bon blog : des catégories, une notion de discussion (qque je trouve toujours un peu faible dans un blog) des possibilités d'édition (avec les étoiles) et les images jointes. En fait, la seule chose qui me manque un peu, c'est la coloration syntaxique quand je tape du code, mais je me sens bien de faire un hack tout dégueu en php pour intégrer ça automatiquement.
[^] # Le reload n'est pas ami was Re: Petite précision
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal Un outil de blog basé sur GMail. Évalué à -2.
[^] # Re: Petite précision
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal Un outil de blog basé sur GMail. Évalué à -1.
[^] # Re: Petite précision
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal Un outil de blog basé sur GMail. Évalué à 3.
[^] # Re: lecteur de news
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Sortie de Thunderbird 0.8. Évalué à 1.
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 2.
Sans doute parce que CLASSPATH n'est pas au niveau des autres JVM (je me demande même s'il s'agit d'une JVM validée). Les autres JVM doivent fournir Swing, qui fait partie des API de Java.
Il aurait aussi pu parler de la plate-forme Java d'IBM. Bref ce n'est pas l'architecture Java qui est concernée mais les implémentations propriétaires.
Je ne le comprend pas comme ça. Les classes java.* et javax.* sont disponibles dans toutes les JVM (ça, c'est le "contrat moral" que passent ceux qui fournissent des JVM). En revanche, lorsqu'on accède à une classe sun.tools.javac.Main (par exemple) on sait qu'on n'en disposera que dans la JVM de Sun (et encore, seulement en installant le JDK). Il me semble que Stallman mentionne plutôt le second cas (utiliser une classe non-standard en pensant qu'elle l'est) quel le premier (utiliser une classe standard, et tomber sur une "implémentation" ne respectant pas le standard).
Et dans ce cas, il se gourre violement. Le code que j'écris n'utilise pas autre chose que du java.* (enfin, presque, il y a un peu de org.apache.*, mais ça, c'est quasi-obligé), et peut donc s'exécuter indifférement sur une JVM Sun, IBM, BEA ou CLASSPATH, pour peu qu'icelle supporte réellement les bibliothèques java.*
[^] # De la psychologie du DBA was Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 1.
Il faut les comprendre : leur dire ça revient à leur dénier leur rôle de chef d'orchestre du système d'information, pour en faire de simples administrateurs d'archives. D'un coup, c'est moins classieux. D'un autre côté, c'est exactement leur boulot : une donnée dans une base est à peu près aussi utile qu'un classeur au fond des archives.
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 2.
L'un des avantages de l'industrie informatique, c'est son pragmatisme. Si Bill Gates fait une connerie, n'importe qui ici lui dira (s'il le peut). De la même manière, le fait que Stallman ait écrit un tas de choses pour le libre ne signifie pas qu'il aura raison à tous les coups. Et en l'occurence, ce document est un tissu d'inepties. Par exemple, quand il dit
i vous développez un programme Java sur la plate-forme Java de Sun, vous êtes voués à utiliser de fonctionnalités Sun exclusives sans même vous en rendre compte.
Il se gourre grave. Toutes les classes fournies dans la JVM de Sun, comme dans les autres, sont définies et évoluent grâce au JCP (ou Java Community Process) sur lequel je vous laisse vous documenter librement, mais qui est nettement ouvert dans son processus d'évolution. Il garantit par ailleurs que les fonctionnalités d'une JVM qui y sont définies (en clair, tout les packages java.* ou javax.*) sont standardisés dans leur interface et dans leur implémentation.
Alors, évidement, je ne sais pas si le JCP respecte complètement la Philosophie du Libre comme il l'entend. Mais pour moi, je sais que je peux influencer les JSR en cours, et donc faire évoluer Java dans ma direction. Et ça me suffit largement.
De la même manière, l'argument selon lequel il fallait "sauver" (sous-entendu pour le libre) le C, parce que c'était le seul langage existant, et le shell, parce que bon, sinon, compiler, c'est pas gagné, mais que Java ne mérite pas ce sauvetage parce que l'arche du libre n'est pas assez grande tient vachement la route, mais alors avec une classe folle.
Et puis, terminer par une exhortation à aller vérifier sur le site de la FSF que le programme utilisé est bien libre, ça fait plus concours de hits à l'ancienne qu'autre chose. Surtout quand on compte le nombre de programmes Java majeurs Open Source (au choix Eclipse, Tomcat, Ant, JBoss, NetBeans, Struts (enfin, ça, c'est pas un bon exemple), Beehive, ...).
Bref, pour moi, ça sonne beaucoup plus comme une espèce de message du vieux développeur C bien content d'être libre etr qui nous emmerde tous que comme autre chose.
Les différences entre le matériel et le logiciel sont telles que les problématiques y sont complètement différentes (enfin jusqu'à ce que quelqu'un ait fabriqué une machine à multiplier les cartes mères ou les disques durs à coût nul).
Ca, c'est étayé, comme argument. Il y a des tonnes de différences, et alors ? La JVM est, quelquesoit son constructeur, censée être un processeur virtuel fonctionnant à la base comme interpréteur de bytecode en code machine pour 'larchitecture cible.
Dans un monde idéal, (que Sun n'a JAMAIS appelé de ses voeux), la JVM serait un coprocesseur (ça existe, les processeurs Java, mais ça marche moyen), et serait donc du matériel. Que dirait alors Stallman ? Faites plutôt vos opérations sur les coprocesseurs vidéo, au firmware nettement plus libre ?
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 1.
Excuse-moi de te dire ça froidement comme ça, mais ... tu rigoles, là ?
Parce que moi, ma logique métier, je la mets dans des POJOs, et mes EJBs (je dis mes, mais c'est uniquement didactique) ne servent qu'à la faire s'interfacer avec un monde d'entreprise. En disant ça, est-ce que je passe pour un demi-extra-terrestre, ou est-ce que je peux éventuellement être dans le vrai ?
et j'ai déja eu de très dur débats avec des DBA pour leur dire que quand je développais, je m'en fouttais un peu de la db :)
Tiens, c'est marrant, moi aussi. Et générallement, ces DBAs te disent que la charge de leur base est hyper-importante, avant même que quiconque ait fait le moindre test de charge de l'application sur la base, bref, ils te demandent à toi d'optimiser, parce que eux, ça les fatigue ;-)
[^] # Re: Quelques questions
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 0.
Et écrire du code qJava qui ne marche qu'avec Mono ? Génial !
A moins de rétroporter les APIs Mono en java, auquel cas ça pourrait être à peine plus générique ...
[^] # Re: Java trap
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 3.
Est-ce que tu utilises actuellement un ordinateur libre ?
Parce que bon, c'est bien gentil de développer avec une plateforme libre, mais ton OS, lui, il l'est ? (sans doute) Et ton processeur, est-il libre ? Le disque dur, la RAM, le câble réseau, les switches qui t'amènent jusqu'à LinuxFR, sont-ils complètement ouverts ?
Qui qu'on soit, il est toujours bon de se renseigner un minimum avant de causer, quand bien même on s'appelle Stallman.
Le processus définissant l'évolution du langage Java est libre, et organisé par le JCP. Ce qui n'est pas libre, ce sont les implémentations de machine virtuelle, dont celle de Sun. Maintenant, il me semble que cet appel à bosser sur CLASSPATH te vise autant que moi. Alors, si tu arrêtais de te plaindre pour l'aider ?
Maintenant, vous pouvez toujours me moinsser, si ça vous amuse d'assurer l'orthodoxie de LinuxFR ...
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 2.
Tant mieux, parce que moi, la solution J2EE/EJB ne m'a pas du tout séduit : à chaque fois que j'ai eu des EJBs sous les yeux, j'ai trouvé que c'était nettement trop complexe pour le besoin exprimé. En fait, c'est bien simple, je n'ai jamais vu de cas où ça se justifiait.
ça amène d'un part à des solutions plus simples à construire et à appréhender.
Ca n'est pas non plus systématique. Une solution super-classe à base d'IoC pourra être particulièrement complexe à comprendre, pour le débutant, meêm si elle présentera bien plus d'élégance.
Deuxio, ça pousse (toujours plus) vers les modèles Model-View-Controller. On a donc une séparation des tâches qui devient nette, entre les controllers, le model et les vues.
Et c'est justement ça qui est pour nous évident, alors que pour d'autres il est incompréhensible de faire la séparation. Il y a encore un rude travail d'éducation à faire.
Et dans ce sens je trouve aussi que IoC est un achèvement : cela revient à découper ses classes de manière très strictes, à bien les tester. Chacun fait une seule chose mais la fait bien.
Puis seulement après à les re-cabler , à les relier avec le framework Spring ou Pico.
Mais pourquoi utiliser un framework pour faire ça ? C'est la grosse question que je me pose à propos de l'IoC. Effectivement, c'est très bien dans le concept, mais je ne vois pas pourquoi je vais passer par l'un ou l'autre pour recâbler mon appli.
Le tout est assez cohérent dans la démarche. De plus cela amène une plus grande solidité : si JDO ne suffit pas tu le remplaces dans ton cablage (IoC) par Hibernate ou par une solution jdbc, sans toucher au reste. Ce qui implique naturellement de coder par interface, afin de rendre le code remplaçable facilement: la classe qui utilise hibernate peut être remplacée par la classe qui utilise ojb (ou ejb) tant que le contrat défini par l'interface est rempli. De plus dans le contexte de test, on peut remplacer très facilement les vrais objets par de faux objets qui suivent le même interface mais qui mimeront le comportement d'un objet normal en envoyant des donénes en dur, afin d'isoler l'objet. L'implémentation devient une question de configuration.
Je demande quand même à voir. Tout programme cache dans ses entrailles une bonne dose de dépendances non inversées (ou complexité cyclomatique, tant qu'on y est à utiliser des termes de barbares), et les enlever ne mérite parfois pas l'effort qu'on y fournit.
Cela fait beaucoup de "bonnes pratiques" d'un coup: separation of concerns, Inversion Of Control, classes testables, faire au plus simple (POJO), coder des interfaces.
Oui, enfin, la doctrine KISS, ça fait un bout de temps que ça devrait être le livre de chevet des développeurs Java, même si en réalité ça n'est pas le cas, et de loin.
Et les questions "matérielles", de charges pour la base de données par exemple sont laissés à la base de donnée, ce qui semble assez acceptable.
Pas pour les DBAs ;-)
Là où un programme d'avant gérait lui-même sa charge par une espèce d'effet domino rigolo, le programme moderne risque fort de beaucoup plus charger (notamment dans le cas d'un mapping O/R), et de faire s'affoler inutilement le DBA (je l'ai vu encore tout récement). Et le problème, dans ce cas-là, c'est quon considère encore la base comme plus importante que le logiciel (un blasphème, à mon sens, mais bon ...).
Donc, oui, je pensais aussi à l' IoC :-)
Pour le SOA : on dirait que c'est un peu du vent. Mais l'idée de programmer avec l'objectif derrière de délivrer un service, pourrait bien devenir peu à peu une sorte d'obligation, pour mettre en relation les données de serveur en serveur.
En fait, le SOA, j'ai bien l'impression que ça permet de vendre plus de webservice, alors même que mon esprit orienté performance me sussure que les webservices sont au service d'une contreperformance évidente. mais bon, ça fait plaisir aux dicaïdors pressés ...
[^] # Re: Hasta la revolucion..
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 1.
[^] # Re: Et encore, on est loin du compte ...
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 2.
Plutot des gens qui ont reflechi sur les agents ou les problemes de parallelisation massive.
Je vais parler pour celui que je connais par mail (Cedric Beust). Lui, il m'a surtout l'air d'être une brute en Java. Peut-être qu'il connaît ces problématiques, mais ce qu'il connaît surtout, c'est le Java. Et j'ai comme l'impression que pour les autres têtes, c'est pareil.
[^] # Re: Java et l'OpenSource.....
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 6.
Néanmoins, il semble que peu de monde s'intéresse a contribuer aux différentes implémentations libres de Java (gcj, kaffe,.....)
Je trouve ca dommage. Objectweb, Apache et autres Eclipse connaissent les Avantages de l'OpenSource, puisque c'est une part de leurs argumentaires.
Je ne voudrais pas marcher dans le troll, mais ... pourquoi faire ?
Soyons pragmatiques : les consortiums J2EE sont pour la plupart le fait de grosses structures (même ObjectWeb en fait partie). Et ces structures, si elles voient un intérêt à développer telle ou telle couche applicative, le font. Redévelopper une machine virtuelle, ou participer au développement, ne les intéresse pas, car celles existant (IBM, Sun, BEA) sont suffisament performantes pour leurs besoins.
De plus, dans leur esprit, Java => JVM Sun. J'en veux pour preuve qu'à la SNCF, ils utilisent Weblogic, pourtant fourni avec JRockit (la meilleure JVM pour serveur J2EE), sur une JVM Sun (incompréhensible, mais vrai).
Avec les moyens que ces organisations possèdent, il serait envisageable qu'ils offrent quelques contributions a gcj par exemple. Ecrire les classes qui leurs manquent pour faire tourner leurs softs, et les reverser. Cela permettrait d'obtenir rapidement un gcj bien plus abouti.
C'est vrai que ce serait sympa, mais ça n'intéresse personne. par exemple, moi, réécrire les classes du JDK, je suis désolé, mais ça m'emmerde profondément.
Faudra t'il un coup bas de Sun, ou un rachat de celui ci par MS, pour les faire réagir ?
Tiens, un peu de paranoïa anti méga-corpo ?
# Et encore, on est loin du compte ...
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Brèves Java. Évalué à 5.
Dans le monde des serveurs d'application, Jonas est mis en avant par Red Hat, quand Bea (Weblogic) semble vivre des heures difficiles.
BEA a quand même sorti une très belle nouveauté cette année : Weblogic Workshop, associé au framework Beehive (surcouche de Struts) tous deux très convaincants, comme je l'écris ici http://nicolas.delsaux.free.fr/web/Java/formation.php(...) et qui plus est Open-Source livré à la fondation Apache (qui n'en est plus à un framework web de plus) !
Hors des grands serveurs d'application (Websphere, Weblogic, JBoss, Jonas,...) se sont développées des solutions spécialisées, plus ciblées, qui semblent moins ambitieuses au départ mais qui remplissent une attente.
Tu penses à Spring, manifestement. N'oublions pas Tapestry, WebWork et autres qui montrent une seule chose : il n'existe pas actuellement de solution web réellement convaincante.
À tel point qu'un mouvement mené par les développeurs - et relayé par les éditeurs de livres (O'Reilly, Manning) - pousse vers des solutions plus simples, mieux dimensionnées, plus flexibles et à terme souvent plus efficaces. Ces solutions sont d'autant plus vite menées et promues qu'elles sont toutes open source.
Tu pourrais être plus explicite ? Pour ma part, sur le front du concept, ces derniers mois ont amené l'émergence d'une vraie révolution sémantique, l'IoC, d'un vrai buzzword (l'architecture orientée service ou SOA).
D'un côté Sun reconnaît l'apport du dialogue et de l'ouverture, et le besoin de fédérer des forces autour de Java, en engageant celui qui s'occupe du site de blogs jroller.
Kwé ? D'un autre côté, Sun demande la suppression de tous les API Sun (J2SE, J2EE et J2ME) du site jdocs. Dommage !
Pendant ce temps les discussions sur les EJB 3 font rage,
Ah ça, les EJB, c'est toujours pas gagné, surtout quand on voit qu'il faut environ un mois pour écrire un mapper O/R. La dernière fois que j'ai discuté avec des gens qui avaient écrit des EJB, je leur ai demandé ce que ça leur apportait. Difficile d'avoir une réponse claire sur le sujet, sauf de la part d'une personne bossant pour BEA ... Mais ça peut être une réponse orientée.
et Google engage une armée de développeurs Java de très haut niveau...
Et tout le monde se demande pourquoi : porter Google en Java ? Réécrire des interfaces web en J2EE qui sent, ou sortir son propre conteneur ?
[^] # Re: C'est un troll.
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Mono 1.0 sous le feu des projecteurs. Évalué à 2.
Pas seulement. Le seul problème est qu'en Java, les plus mauvaises JVM sont Open-source; Mais si tu prends celle de BEA, par exemple, elle déchire pour toutes les applications serveur (quand je dis elle déchire, je veux dire qu'elle est vraiment plus rapide que celle de Sun, et également gratuite).
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Je ne suis pas d'accord.
L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++
[^] # Re: newbie
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche JBoss obtient la certification J2EE. Évalué à 10.
Pour ça, un serveur J2EE doit fournir les outils correspondant à un ensemble de normes dont les noms commencet souvent par J :
JMX (Java Management Extension) pour intégrer le serveur à un Nagios, par exemple
JMS (Java Messaging System) pour l'envoi de messages événementiels sur les systèmes de messages (jai oublié le nom, mais globalement, ça n'a rien à voir avec Evolution, Outlook ou Opera)
JTS (Java Transaction Service) pour gérer les transactions, voire même les transactions distribuées
JSP (Java Server Pages) une petite techno de présentation, qui a vécu.
EJB (Enterprise Java Beans) la norme phare de J2EE, qui définit des "objets métiers" sous un certain nombre de forme qui nous font revenir à l'époque bénie des struct C. Le seul avantage étant qu'ici, les struct peuvent être persistées de manière quasi-transparente ...
Et tant d'autres que j'oublie
Tout ça c'est bien joli, mais en fait, à sens, si J2EE apporte une certaine capacité d'intégration de Java à "l'informatique d'entreprise", ça se fait au prix de nombreuses contorsions :
- Durant le développement, car J2EE est une norme ouverte, qui n'impose que peu de choses (et qui notamment n'impose pas les descripteurs de déploiement permettant d'organiser tout le bouzin). Ce qui fait qu'une appli J2EE n'est en général pas ou peu portable (à moins bien sûr d'être codée avec des outils génériques, comme XDoclet ou Ant, et encore ...). Bref, l'enfer, le véritable enfer du développement J2EE, c'est que loin de nous aider à développer plus facilement grâce à une meilleure organisation Java (ce qui est en partie fait), le code est complètement scindé entre d'un côté le développement de composants Java, et de l'autre leur organisation (qui n'est souvent pas réellement séparée, du fait que ces applications soient le plus souvent des saletés de gestion) qui elle est contenue dans des fichiers XML.
- Durant l'utilisation, on est quand même très loin d'applications rapides. D'accord, ça marche, mais comme le dit de plus en plus de monde, la complexité de J2EE le rend inaccessible à l'immense majorité des développeurs. De plus, comme toute usine à gaz qui se respecte, le coût d'exploitation n'est pas nul, puisqu'il existe désormais des postes d'administrateurs d'applications J2EE, dont le rôle, tout comme pour un admin Oracle, est de faire en sorte que ça continue à marcher (!).
Bon, pour moi, développeur Java, il est clair que c'est uin bon gagne-pain. Toutefois, je trouve ça dommage qu'une techno comme Java serve à "ça", et surtout de cette manière là.
[^] # Re: Bonne nouvelle :)
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche L'administration fiscale opte pour JBoss. Évalué à 5.
Entre la doc payante (et pas forcément de très bonne qualité), les magouilles pas toujours de très grande qualité de Marc Fleury pour pousser coûte que coûte sa solution (avec notamment les déboires provoqués lors du clash de l'année dernière), je ne trouve pas que ça fasse de JBoss un fleuron du libre, mis à part par le nombre de téléchargements éléphantesque du truc.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 3.
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement : http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html(...)
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...))
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.
# Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 10.
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java),
Jusqu'ici, tout va bien.
le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes)
Là, ça dérape déja bien. Si .Net est supportée pour Linux, Windows et Mac, grâce à Mono, la liste des plateformes supportant Java (que ce soit en Open-source ou non), est quand même un peu plus longue, incluant par exemple des téléphones portables, des PDAs, des routeurs, des automates programmables, des robots mobiles, des cartes bleues, etc, ...
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
Le site http://www.robert-tolksdorf.de/vmlanguages.html(...) donne effectivement une liste fabuleusement courte de langages pouvant être compilés en bytecode, sans passer par le langage Java. Et, chose étonnante, tous ne sont pas orientés objet (je citerai par exemple Lisp, Logo, Prolog, Eiffel, Smalltalk, Ada, mais pas Cobol, malheureusement)
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
Là, je m'avance, mais dans la mesure où tous ces langages sont compilés en bytecode, il doit être possible de faire facilement des binbdings de l'un à l'autre. je sais que c'est au moins possible pour JScheme, implémentation java d'un interpréteur Scheme permettant d'aller de l'un à l'autre et réciproquement.
- des fonctionnalités supplémentaires comme les méta-données,la détection de débordement
Ben .. ça existe depuis un bon moment en Java, à moins qu'on ne parle pas de la même chose. Quant aux metadonnées, elle sont présentes dans Java 1.5 (ou Java 5) qui sort ces temps-ci.
ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
- la plateforme Java est une solution propriétaire
Non. le langage Java est libre, et son évolution est pilotée par le java Community Process, qui va parfois à l'encontre des souhaits de Sun. En revanche, effectivement, la machine virtuelle de Sun n'est pas libre, mais il existe un certain nombre de JVM libres, qui sont cependant en retard sur celle de Sun.
alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seul les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)
Ca fait peut-être un peu Don Quichotte, mais pour moi cet article est symptômatique : sous couvert de défense du libre, on assiste là) à une attaque en règle contre Java, au profit de quoi , D'une plateforme dont le développement est piloté par Microsoft ? Super.
[^] # Re: Dans le même style
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche L'avis d'un Gmailer. Évalué à 4.
Attention : GMail est encore en beta, donc un certain nombre de ces commentaires ne seront plus valides à la fin
D'abord, ce webmail utilise massivement le javascript, avec près de 200 Ko de scripts chargés pour faire tourner l'interface graphique, et également pour limiter au maximum les échanges. En effet, grâce au javascript, la page échangée avec le serveur ne contient que des données, et aucune info de présentation, déplacée dans le javascript. Ca, c'est l'avantage. L'incovnénient, c'est que les développeurs de Google doivent s'amuser à tester leur webmail sur chaque navigateur web utilisé, pour débugger les spécificités. Ca donne parfois des limitations puisqu'Opera, par exemple, n'est pas du tout supporté, bien que d'après un échange mail avec leur support ce ne soit apparement quie temporaire. D'un autre côté, IE, Mozilla et tous ses dérivés, Safari sont parfaitement supportés, car complètement testés.
Ensuite, les filtres sont encore très imparfaits, il est en effet impossible de sélectionner plusieurs adresses "From" pour donner un label.
La "review" de la news explique que, justement, les labels sont une nouveauté assez épatante. Bon, c'est vrai que c'est la première fois dans un webmail (de même, selon moi, que le suivi des conversations, bien que d'autres GMailers ne soient pas d'accord avec cet avis). Toutefois, tous les utilisateurs du mail d'Opera seront d'accord avec moi pour dire que ça a au moins un an.
Au chapitre des manques cruels, il y a l'absence d'une vue du source du message, avec tous les champs d'entête, ainsi que le problème, déja signalé, du curseur qui se positionne dans les réponses au-dessus du mail auquel on répond, ce qui est très gênant.
Dans le même ordre d'idée, il n'est pas possible de scinder une conversation devenue trop longue.
Mais globalement, GMail est tout à fait satisfaisant comme webmail, et les nouveautés qui arrivent (forward automatique, itneface sans Javascript) devraient rapidement en faire un standard du webmail comme il est un standard de recherche.
Enfin, les remarques sur la vie privée, encore bien tenace, ont plutôt tendance à me faire sourire. D'abord parce que je 'nai rien à cacher (enfin, pas grand chose), ensuite parce que je comprend tout à fait que Google rentabilise son activité mail d'une manière ou d'une autre, comme Opera rentabilise son navigateur en y affichant de la pub.
Vous penserez sans doute que je suis un fils de pub, mais non, c'est juste que je comprends que ces entreprises commerciales se doivent de gagner de l'argent, même si je préférerais évidement un service identique gratuit.
[^] # Re: Trop lent...
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 3.
[^] # Re: Firefox
Posté par Nicolas Delsaux (site web personnel) . En réponse au journal Le scandale de la toolbar DLFP. Évalué à 4.
A quel niveau est-il plus léger ? Lors du téléchargement (ce qui serait faux parce qu'Opera ne pèse que 3 Mo, contre 4.7 pour Firefox) ?
En plus opera ça pue c'est pas libre,
Le sapusaipalibre, c'est bien quand on parle par exemple d'un format d'échange, ou d'outils non interopérables. Mais Opera est un des navigateurs qui respecte le mieux les différents standards du web, et ne peut donc pas vraiment rentrer dans cette catégorie, sauf pour ceux qui ont évidement un but moral, ce qui est évidement ton cas puisque c'est ton argument majeur (voir la suite).
et il impose de la pub, et même si on arrive à la virer le principe reste honteux.
Attends, je rêve, où tu parles consciement de *cracker* un logiciel pour t'affranchir du modèle économique choisi ? C'est marrant, mais quand je vois cet argument juste sous celui évoquant le fait qu'Opera ne soit pas libre, j'ai plutôt l'impression que pour toi, Libre sonne plutôt free beer qu'autre chose. Du coup, tes arguments me semblent un peu plats.
En plus, la pub, dans la version 7, elle est bien : tu as la possibilité d'utiliser les google ads, ce qui te permet d'aller jeter un oeil à d'autres sites, certes payants, mais parfois assez proches de ce que tu souhaites.
Je me doutes bien que pour un idéologue du libre comme toi, les sirènes publicitaires ne sauraient avoir un charme suffisant. Mais pour ma part, je trouve ça bien pratique.
À la limite je préfère IE à opera.
Oui, bien sûr, utilises donc un produit buggé jusqu'au trognon, techniquement mort, arriéré d'au moins une génération, ouvrant ton PC à toutes les attaques dont LinuxFr aime à se faire l'écho, plutôt qu'on logiciel adhérant fortement aux standards, réputé pour sa qualité, sa rapidité, sa légèreté et son adhérance aux standards.
Mais au fait, tu sais qu'Opera existe aussi pour Linux ? Et que des gens s'en servent sous Linux ? Dingue, non !
# ZDNet, non, LinuxFr, oui
Posté par Nicolas Delsaux (site web personnel) . En réponse à la dépêche La fondation Eclipse nomme son directeur. Évalué à 1.
On n'en a un peu rien à foutre, non ? LinuxFr n'est pas une succursale de Ziff-Davis, me semble-t-il, mais ça n'est qu'anecdotique.
* Mettre en place les échanges entre membres, contributeurs et utilisateurs.
Je ne crois pas, non. Le patron du consortium Eclipse doit avoir avant tout un rôle d'arbitre politique entre les désirs des différents groupes du consortium (IBM, Oracle, Borland, HP, ...).
* Assurer le lancement de la version 3.0 pour l'été 2004
Ca m'étonnerait vraiment que ce type en ait quoi que ce soit à faire. Les versions de la plateforme Eclipse doivent sans aucun doute avancer à rythme dont il se cogne complètement. Lui n'est pas là pour la technique, mais pour la direction.
* Assurer des bases saines pour le projet open WebTools qui permettra d'utiliser Eclipse du côté serveur.
C'est quoi cette histoire ?
* Mettre en place une équipe dirigeante et superviser les planifications.
En bref faire du consortium un truc rentable.
Son passé de gestionnaire au sein d'Oracle ne sera pas de trop, aux vus de la responsabilité et de la tâche à accomplir ...
Je ne vois ni le rapport, ni le problème. Effectivement, c'est un gestionnaire, car le consortium Eclipse est une entreprise qui vit des subsides de ses membres. Mais la tâche à accomplir ? C'est quoi ?
sans compter qu'Eclipse est un projet d'importance, qui a provoqué de nombreuses rivalités et prises de positions parmi des acteurs importants du marché informatique.
Uniquement Sun et Microsoft (bien que Microsoft n'en parle pas, j'imagine qu'ils doivent surveiller ça de près). Tous les autres poids lourds ont rejoint le consortium, parce qu'ils se rendent bien compte que ça leur rend bien service.