Un petit coup de gueule, car les "copier/coller" de phrase marketing ont le don de me faire réagir :
Jusqu'à preuve du contraire : test de compatibilité officiel et indépendant couvrant toutes les fonctionalités de .net,
mono n'est pas l'implementation de .net !
Mono est une tentative d'implémentation de .net.
La différence ? ennorme ! par exemple, je tente de gagner au loto, mais est-ce que je gagne ? et est-ce que je gagnerai ? quelle est la probabilité que j'arrive à gagner ?
Comme le prouve le projet Classpath de la FSF, tenter de ré-implementer plateforme en perpétuel mouvement est quelquechose de très délicat (même ce dernier projet semble maintenant en capacité de rattraper sous peu la cible, cf. taux de compatibilité recement annoncé).
D'autant plus pour .net dont on n'a que peu d'information (seule la partie centrale ayant été publiquement spécifiée). Ainsi, .net reste un ensemble propriétaire, en grande partie non spécifié publiquement ainsi que intégralement sous controle de microsoft. Comment faire une "copie fonctionnelle" et s'assurer de sa pérénité dans de telle conditions ? (aveugle, et soumis au bon vouloir du "guide omnipotent")
Tant que MS refusera de livrer les spécifications complètes ou de publier avec une license ouverte les codes sources, quel est l'interet de mono, mise à part de montrer ce que l'on sait déjà : on peut toujours tenter de copier MS ;-) Mais ça je pense que Wine l'a fait de façon beaucoup plus probante ...
Au final, rappelons que les responsables de MS l'ont clairement rappelé lors de diverses allocutions: .net ne sera disponible que pour les OS de Microsoft. Pour l'instant, il ne compte pas attaquer tout contrevenant mais leur position face aux "copieurs" de .net n'est pas aussi clairement exposé.
Car MS est parti de Java c'est bien pour ne pas reproduire ce qu'ils considerent comme "erreurs" : possibilité à un tier de réimplémenter mais sous condition de compatibilité, manque de controle sur la plateforme car liés à des processus de spécifications (et bien sur à un éditeur tiers).
Sachant que la vrai plateforme MS est Windows, .net pour moi reste un "avatar" qui devrait dans l'avenir disparaitre en tant que tel et se voir intégré dans windows sous peine de mettre en danger MS. Qui dit plus d'intégration dit plus grande difficulté à dupliquer !!! Tout celà enlevant un quelconque interret à une plateforme qui n'est disponible au final que sous windows et pour x86.
Avec tout celà on est loint du « Mono, l'implémentation libre de l'environnement .NET de Microsoft »....non ;-)
Firebird est une base opensource sous license dérivée de la MPL, donc plutôt généreuse ...
Son gros avantage est de disposé de tonnes de fonctionalités : transations avancées, triggers, procedures stockées, unicode ... et tout ça fonctionant sous les principaux OS.
Fyracle est un ensemble de scripts/procedures et diverses améliorations qui va se greffer sur Firebird et permet à une immence partie du code Oracle de fonctionner directement sans modification !
Pour preuve, Fyracle permet de faire tourner Compiere http://www.compiere.org/ le célèbre outil ERP + CRM opensource sous MPL qui ne marchait que sous Oracle !!! Vraiment impressionant comme réussite.
Je ne m'explique clairement pas pourquoi MySQL a pendant si longtemps dominé le marché des bases libre étant donné son manque de fonctionalité chronique.... mais finalement tout vient à point qui sait attendre on a enfin les views sous MySQL .... sauf que perso, je les ait sous Firebird depuis plus de 5 ans ;-)
As tu testé le Font2DTest.jar présent dans demo/jfc/Font2DTest sur le JDK ?
Celà te permettra de vérifier que la VM de ton mac est bien configurée coté police de caractères :)
Petit rappel, comme sous Java tout est en unicode, normalement le stockage des caractères ne posent pas de PB, par contre le rendu peut poser les problèmes suivants :
- aucune police unicode complète n'est disponible (et vu la taille d'une police complète on peut comprendre)
- aucune police n'est disponible pour la zone unicode ciblée
- la police utilisée à la volée (vu que tu peux par exemple livrer la police à utiliser avec ton appli) ne contient pas de caractères pour la zone unicode ciblée
Dans tous les cas, vérifier à l'aide du Font2DTest que tout est bien OK et que la fonte contient bien les bons glyphes.
MyFaces pour la présentation,
Spring pour le framework d'integration,
Hibernate pour le mapping Objet Relationel,
Apache Lucene pour la recherche
Et de ce que j'en comprend il doit utiliser Apache Slide pour la gestion WebDAV ;-)
Et vraisemblablement d'autres ....
JBoss et Tomcat pour le serveur applicatif proposé par défaut comme implémentation J2EE, mais je me demande le niveau d'adhérence par raport à ces deux composants.
Celà serait interressant de tester un passage sous Apache Geronimo :)
Ce genre de produit peut faire un malheur si la qualité d'implémentation est au rendez vous car J2EE est de plus en plus présent dans les entreprise. Et tout ce qui est positif pour l'opensource sous J2EE l'est aussi quelque part pour l'opensource en général mais aussi Linux en particulier. Tout simplement car une fois que l'on est tout en Java, on peut clairement se poser la pertinence de conserver ses serveurs sous des OS proprios ;-)
Le problème est qu'il y a divergence fondamentale entre les besoins des utilisateurs et les impératifs des administrateurs d'un firewall.
L'administrateur veut une configuration qui fournisse une infrastucture sécurisée. Le principe est que par défaut ils interdisent tout ce qu'il n'est pas nécessaire comme protocol (ou plutôt interdire l'usage des ports associés aux services).
Ceci est complètement opposé au besoins de l'utilisateur. Qui peut varier avec le temps. Et nécessiter divers protocole non-autorisés par l'administrateur :(
Par exemple, il est courant de constater que les administrateurs interdisent tous les protocols vers l'extérieur sauf HTTP / HTTPS. En conséquence de quoi, les utilisateurs au lieu de pouvoir accéder aux différents services escomptés (FTP, POP, IMAP, ...) se retrouvent limités à des interfaces web. Et ne peuvent utiliser leurs logiciels habituels.
Pour palier à ces problèmes est arrivé la solution de tout encaspuler dans des trames HTTP, par exemple on peut citer : SOAP (le plus souvent utilisé sur HTTP), WebDAV, ou bien encore les tunnels HTTP.
Ceci est une réponse qui n'est pas satisfaisante car elle consiste à confiner une protocols au niveau de l'application, et à rajouter une couche dans la couche applicative qui sera la véritable couche applicative. En clair, on remet une couche inutile pour palier à une limitation des configuration.
Quelle est la solution ?
Il faudrait que les firewall et les applications puissent dialoguer ensemble. L'application devrait être sécurisée, et fournir son certificat d'autenticité ainsi que ça demande de "laisser-passer" au firewall. Le laisser-passer devrait définir les besois en terme de ressources résaux distantes (protocole utilisé, référence aux standards suivit, identificaiton formelle des resources) Suite à quoi, le firewall devrait laiser passer la communication si celle-ci est digne de confiance (possibilité de paramètrer dans le firewall).
Il appartiendra alors au firewall de vérifier (suivant sa capacité de ontrole du protocole) à tout moment que l'utilisation faite par l'application des resources allouées est bien conforme aux déclarations indiquées par le laisser-passer.
De plus il faudrait supprimer le concept de "proxy" et le remplacer par des "proxy transparents", le firewall étant une fonctionalité de ce proxy transparent.
L'utilisation en parallèle de plage IPv6 simplifierai aussi le paramètrage de firewall grâce à l'identification de bout en bout de la chaine d'appel au niveau IP.
Bref, comme tout ceci n'exite pas, les protocols sur HTTP ont un avenir radieu ;-)
Si ton amis à internet, c'est déjà le cas et je ne peux te conseiller de tester skype (gratuit pour des appel pur VoIP. Ok, c'est pas du LL, mais ça marche).
Sinon, si il a pas de connexion internet, tu peux passer par SkypeOut pour des bons Prix. Sauf que sur l'inde c'est plutot cher.
Dans ce cas, tu peux tester les "habituels telco à bas coût" type telerabais : pour appel vers un fixe c'est facturé au prix local (pas d'abonnement), et pour un mobile c'est 15c/min, moins cher que vers un portable français ;)
Et ceci est valable vers la pluspart des pays.
Franchement, c'est pas gratuit, mais vu les prix, à moins que tu passes tous les jours 2h (soit moins de 3¤) tu va pas te ruiner.
Désolé, mais il faudrait peut être sortir des publications comerciales de MS.
MS .net ne permet PAS d'avoir les languages de son choix. Si on nomme les languages de .net des "flavor" ce n'est pas pour rien.
Ok, je m'explique: Les languages supportés par la CLR (je parle ici de code managed bien sur), ont tous un parent en commun, et sa plus fidèle incarnation est C#. Ceci est dû au fait que tous fonctionnent sur des bases communes : utilisation de la CLR et les classes de références (structuration et comportement).
En clair, tous les flavor de languages sont C#ifiés. Pour preuve il suffit de regarder le VB à la sauce .net: non comptent d'avoir introduit une centaine de changement majeur dans le language on a maintenant un langage : orienté objet, utilisant les classes de .net et disposant de fonction de ramasse miète, ....
Et on peut faire la même analogie pour tous les autres languages "soit disant" portés sur .net. Dans la pratique, comme ils font tous contraint à un commun dénominateur, ils ont tous semblables et n'ont plus rien à voir avec les originaux.
Si tu n'est toujours pas convaincu, va voir du cobol sauce .net et discute ça avec un coboliste.
Alors clairement, le multilanguage dans ces conditions n'a aucun interret. D'ailleur le fait est qu'il est que c'est bien C# qui est utilisé pour développer la majorité des applications, et qu'il existe des outils qui permettent de passer d'un langage à un autre ...
Enfin, techniquement parlant la plateforme de base de .net la plateforme Java sont quasiment identique tant en fonctionalité qu'en comportement. Alors je ne vois pas en quoi, l'un permetrait plus d'implementer un language que l'autre ne permet pas.
Et si c'etait le cas pourquoi pense tu qu'il existe une JSR intitullé "JSR 45: Debugging Support for Other Languages" ?
La plus part sont également des "flavors", mais certains ont ajoutés suffisament de concepts pour que l'on puisse les considerer comme indépendants : Kiev ou OpenJava par exemple.
En conclusion, oui, désolé, mais il faudrait peut être sortir des publications comerciales de MS ;-)
Ensuite, il faut rappeler que cette version va être la première à bénéficier du nouveau JSPA qui intègre les demandes de l'Apache Group. Celles-ci rendent possible une implémentation opensource tout en conservant le nom "Java" et assure la compatibilité de l'ensemble gràce à la mise ) disposition gratuite pour les organisation à but non-lucratif de l'outil "couperet": le TCK.
Merci à l'Apache Group pour son super travail sur ce sujet :)
Maintenant, si tout le monde se bouge le c*l et va aider le projet GNU Classpath, au lieu de faire du FUD encore et encore sur la soit-disante impossibilité d'avoir du Java libre, alors GNU Classpath pourrait assez rapidement être la premère VM qui soit opensource et 100% Compatible :)
Au passage : Ici réside la grande différence avec des tentatives style mono, qui ne seront jamais que des essais de duplication de fonctionalités d'une plateforme non-spécifiées et dont on ne pourra jamais assurer l'exactitude et le niveau de compatibilité réel tant du fait que MS garde l'ensemble des specs bien au chaud sous son coude, sauf quelques miettes qui ont été données à la "plèbe" via l'ECMA histoire de mettre un semblant de teinte d'ouverture à leur solution, qui n'a aucune prétention d'etre multi-OS (càd foncitonner sur autre chose que les OS MS), dixit les pontes de MS.
Bien sur ça suppose que Classpath reçoive un peu plus de soutiens des principaux acteurs de la FSF... aller un petit effort Mr RMS, il manque juste ça et on à la solution 100% libre souhaité par tous les adeptes de la GPL.
Pour finir, si vous voullez un truc en Java et sous GPL qui "trou le c*l", pour moi, c'est Looking Glass
Si les besoins de la visions strategie à long terme de MS l'imposent je peux t'assurer qu'il vont produire un morceau de code sous GPL qui patchera Java pour lui permettre une plus grand adhérence à .net et à windows. Et en plus ils le feront avec le pipotage marketing basé sur le "embrace and extend".
Or c'est justement le but de Java (contrairement à .net) de s'assurer de l'indépendance de la plateforme.
Le rêve de MS est de ramener la "brebis égarée" à son "berger", car le danger est grand de voir la brebis tuer le chien du berger au long terme ;-)
Et le loup dans tout ça ... il faut demander à Larry E :))
Plus serieusement, il faut vraiment que vous compreniez que le but de MS c'est de faire de la thune. Il ne sont pas spécialement "méchant", ni ne représente le "coté obscur de l'informatique". Juste ils ont comme toute société l'objectif de faire un maximum de bénéfice. Sauf qu'eux, ils ont des moyens hors du communs pour le réaliser.
Abus de position dominante, peut-être ... mais quand on contrôle également le système de controle, et les médias qui doivent le dénoncer qui s'en soucis encore.
Tu dis "IBM contrairement à SUN ne discrédite pas le logiciel libre. SUN a déjà à plusieurs reprises attaqués la GPL et/ou Red Hat :".
C'est faux, et je pense que tu as mal comprit la position de Sun.
Il ne s'aggit pas d'une "attaque", mais d'un constat. Sun a simplement indiqué que la GPL n'hévite pas du tout le problème du fork. Or Sun recherche depuis longtemps une lincense opensource "reconnue" qui lui permettrait de s'assurer qu'il y a un respects des standards établit dans le cadre du JCP.
Ce n'est pas d'ailleur le fork lui même que Sun chercher à éviter, mais le fork qui passe outre la nécessaire compatibilité avec la source initiale lorsqu'elle a comme référence un standard définit.
Ainsi, le probleme pour mettre l'implementation de référence sous Opensource (on rappelle qu'il n'y a rien!! qui empeche de faire une version de Java opensource et c'est le but de GNU Classpath au passage) est que si elle est réalisé, rien n'empechera MS de récuperer le code et de l'améliorer. Bien sur si il est sous GPL, les modifications devront être aussi sous GPL, mais la nouvelle version (devenue non compatible avec la source) existera belle et bien, et MS aura le champ libre pour faire une pub du style ".net est compatible Java, .net est la nouvelle plateforme de référence de l'entreprise. pourquoi utiliser Java alors que l'on fait les deux ?". Alors que leur "Java" ne sera plus compatible avec celui existant.
Il y a en ce moment pas mal de tractations, pour essayer de trouver une solution qui permettrait à Sun de mettre l'implementation de référence en libre et éviter cette situation, mais c'est pas simple.
Il est toujours difficile de limiter la "liberté" sans la remettre en cause, pourtant certains l'ont fait :
"La liberté des uns s'arrete ou celle des autres commence"
Franchement, je commence à en avoir marre du FUD contre Sun.
Oui, ils sont une société, oui, leur but est de faire de la thune, oui, leur but n'est pas de devenir la FSF.
Je suis un super fervant des solutions libres, mais comme au temps du communisme, il ne faudrait pas pas confondre liberté et totalitarisme.
Ce sont les mêmes qui d'ailleur au passage continuent à pousser du FUD sur Java, alors qu'on le rappelle, le projet GNU Classpath manque curellement de fond de la FSF et de mains de la communauté pour finaliser une version complète de la platforme Java sous GPL et lui faire paser le TCK qui lui permetra de clamer une complète compatibilité.
Ce sont les mêmes qui pipotent sur les supposés alliances Sun/MS contre IBM en ce moment sur les forums.
Pendant ce temps, on oublit les vrai objectifs.
Si vous voyez une salle remplie de PC de burreau sous Solaris, vous m'appelez ! Le vrai ennemi de Linux n'est pas Solaris, car il est relativement facile de convaincre un utilisateur de Solaris de migrer sous Linux. Mais le vrai ennemi est autre : Microsoft !
Car grâces à ses montagnes de dollars, MS peut racheter, communiquer, fusionner, controler ... qui bon lui semble. MS vient d'annoncer que son nouvel ennemi est le monde opensource. Afin de le contrer ils préparent des quantités de FUD à base de "licences pseudo opensources pour les clients importants" et autres ristournes exceptionnelles pours gros clients, histoire de décourrager leurs captifs de regarder vers des solutions plus libres.
Il faut regarder la vériter en face, MS est le maitre des lieus, et au lieu de taper sans cesse sur un petit mal en point (qui parfois le merite), pourquoi ne pas s'attaquer avec autant de vehémence au gros mastodonte qui truste tout les domaines ?
Je rappelle qu'au niveau des parts de marché, Linux a principalement "mangé" les parts des Unix, et finalement trés peu touché les parts des Windows de MS.
Il est temps de remettre tout ça en perspective SVP.
Elle a été déjà été employée pour Java dans les applet ou les applications webstart :
Ajouter un bandeau en bas impossible à supprimer qui précise "Application Web utilisant XUL" sur toute composant de type fenetre ou boite de dialogue.
La difficulté est dans le "impossible à supprimer" sous XUL, est qu'en Java, il y a un méchanisme de sécurité fort qui met en place un bac à sable qui epêche tout application non certifié d'accèder à toutes les fonctionalités critiques (c'est vraiment très solide comme concept car c'est un des fondement de la VM).
J'ai pas vraiment vu de concept de bac à sable en Gecko ... encore fraudrait-il que la spec de XUL le définisse bien sur ;-)
Aller pour conclure, je trouve que ni XUL, ni XAML ne sont vraiment une avancée décisive. Bien sur, ils apportent dans une certaine mesure un découpage MVC, mais l'abstraction par rapport à l'interface est loint d'être parfaite. Devoir passer son temps à "mettre en page" les composant est un travail fastidieux, et il aurait été souhaitable d'avoir une technique qui facilite celà ...
Crois-tu que MS va "bien vouloir" sortir un TCK et publier complètement ses specs ?
Car c'est bien là le noeud du PB. Prend les fonctionalités entreprises de .net comme elle sont basés sur COM+ et qu'il n'y a aucune spec de dispo, il est impossible à mono de les supporter. Or toute platforme qui veut vraiment faire un truc qui monte en charge va passer par ces fonctionalités. Finit la "compatibilité" promise. De plus, avoir des API identique est une chose mais offrir un comportement identique en est un autre. Et le TCK est là pour ça !
Tant que MS ne fournira pas de TCK, il n'y aura pas d'avenir pour mono.
Le lien "Points communs et différences avec la plateforme Java" est de mauvaise fois, car on compare ici principalement les langages et certainement pas les possibilités offertes par les plateformes ! Sans compter que l'on parle de .net sur cette page et pas du tout des possibilités de mono (sauf comme référence). Le jour au mono sera certifié .net je veux bien reconsiderer ce point. En attendant, mono n'a rien a voir avec .net ;-)
De plus, que je sache Java est disponible dans sa toute derniere version sur Linux et avec une compatibilité de 100% (merci au TCK). Alors passer aussi rapidement sur un "détail" à son importance.
Pour moi c'est de la mauvaise fois pure et simple.
Franchement, quite a faire du "portable à tout prix" autant faire du python !
Maintenant si, la portabilité doit être conservé et l'environement souple, alors Java reste le meilleur compromit. Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.
Mieux vaut laiser icaza jouer avec son mono, moi pendant ce temps je joue avec Looking Glasses :
Franchement, l'avenir de mono est loint d'être assuré.
AMHA, croire que MS va laisser copier leur plateforme de référence sans broncher est faire preuve de crédulité vu les sommes investies en R&D et marketing par MS sur la marque.
Tant que mono sert à MS pour faire avaler la pilule du "multi-plateforme" concernant .net, il n'y a aucun problème. En ça, je serais interessé par connaitre les motivation exactent de DeIcaza, vu ses relations troubles avec MS.
Concernant le "pseudo" standard ECMA, franchement MS est de mauvaise fois, car non seulement elle n'a soumis qu'une partie de la spec de .net, mais ensuite, il faut rappeler lorsque Java avait été poussé à l'ECMA les arguments qui lui avait valu d'être rejeté ... ici on se rend compte des pressions qui ont du se produire en coulisse dans les deux cas. Je ne reviendrait pas non plus sur la soumission de Java à l'ISO, qui était plus du domaine de la série Dallas ;-) Ce sont ces lobying répétés de MS qui ont obligé Sun a créé un procéssus de standardisation des specs Java décorrélé de toute influence de MS.
De plus, pour rappel, MS était il y a qqe années à fond impliqué dans Java, Visual J++ étant l'IDE n°1 et JView la VM la plus performante de plus l'ensemble des API de windows était disponible via des API Java !!! Bien sur, ensuite est arrivé la "crise" lorsque MS a essayé d'introduire une spécificité à Java pour le rendre interdépendant avec windows.
Concernant .net, toute personne qui connait les deux mondes sait bien qu'il n'y a que peu de différence. Et que basculer de l'un à l'autre est une question de jour.
Je préciserait simplement que ton point sur la généricité est ridicule, regarde les débats et JSR dans les forums Java et regarde quand MS a commancé à en parlé ... et ensuite reviens discuter serieusement (vraiment ce point prouve particulierement que tu ne fais que répeter les publi-annonces de MS).
La seule question pertinente pour moi est la pérénité des deux solutions.
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de mono, car il y aura toujours un point valable pourdire que .net est mieux ... entre un obscur groupe, et Microsoft, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire mono, c'est apporté de l'eau au moulin de MS et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Si vraiment tu es un apotre du libre, je te conseille vivement de rejoindre la FSF et de consacrer ton temps au projet Classpath dont le but est de passer le TCK Java et fournir une implementation intégrale de la spec J2SE. Et là au moins pas de risque de voir un quelconque éditeur balayer ton ouvrage d'un simple revers de la main (non, même pas Sun, pour t'en convaincre, je te propose de relire les licences appliqués à J2SE 5.0 par exemple, ainsi que la position claire et définitive sur les brevest potentiels autours de Java).
Oui, vraiment je pense que l'avenir de mono est assez sombre. Quand à celui de .net il est assuré ... enfin, du moins pour le nom, quand au framework, les API de longhorn sont sur le point de le mettre en pièce ....adieu veaux, vaches et winforms ;-)
Dans la série des choix stupide de nom, je pense que mozilla à la palme.
Non content d'avoir vampirisé le nom de "Firebird" l'excelente base de données opensource, ils utilisent comme nom de fichier l'extension .jar qui est le format des librairies et executables Java !
Si qqn peut me dire pourquoi les extensions de Mozilla sont nommés .jar ça m'interesse ... du coté de Java le .jar existe depuis des lustres, c'etait à l'epoque du JDK1.2 ( et .jar pour Java ARchive tout simplement). Merci ;-)
La nouvelle version de Java2 Standard Edition (de son nom de code "tiger"), devrait sortir en version finale dans les semaines qui viennent ...
D'ailleur au passage, je ne saurrais que trop vous conseiller de tester vos appli avec les toutes dernières build qui sont disponibles sur http://java.sun.com/j2se/1.5.0/snapshots/(...)
Celà permet de se rendre compte des perfs obtenues et en cas de pépin de reporter le bogue au plus vite afin qu'il soit corrigé avant la version finale.
Dans cette nouvelle mouture, il y a tellement de nouvelle fonctionalité que la tête peut en tourner. Parmis tout celà, les nouvelles fonctionalités du langages tant attendues, telle la généricité ... le site http://www.3plus4.de/eclipse/cheetah.html(...) (en anglais mais avec des zimages!) explique pas à pas comment faire bénéficier eclipse 3.0 des toutes dernieres avancées du langage.
On espère la version finale de cette mise à jour majeure de la JDT Eclipse pour bientôt ;-)
Vive le J2SDK 5.0 ... j'ai dit 5.0 ? tiens comme c'est bizare ;-)
Tant qu tu y es Doly était le clone de scharzy :))
Faut vraiment arreter de dire n'importe quoi autour de mono. Ce n'est pas parce que la grenouille veut se faire plus grosse que le boeuf qu'elle va y arriver. Surtout quand le boeuf est transgenique et qu'il continue de grossir à vue d'oeil <:o)
Plus serieusement, je me demande toujours pourquoi des acharnés continuent de copier MS au lieu d'innover sur des bases saines. Franchement on n'as pas besoin de cloner MS pour prouver que l'innovation est plus vivace dans le monde opensource !
Quite à donner du temps à la communauté pour des projets visant à offrir un equivalent libre à des solutions propriétaires, autant le faire sur des trucs dont on a une visibilité complète sur les specs par exemple pour le projet GNU Classpath par exemple ou encore pour le projet Geronimo d'Apache. C'est clairement plus productif car là au moins on sait aprés quoi on court : concurencer directement les productions commerciales par une certification sans ambiguité ;-)
... les IDE ont été lents et on nécesité une config musclé, c'est pas nouveau, et cça n'a rien à voir avec tux ou java, meme pour VS c pareil (ou vraiment pire encore pour la derniere version VS).
Tu veux pas faire du Java, c toi que ça regarde ... mais essaye de lancer un IDE digne de ce nom sur ta machine et on en reparle ensuite ;-) Et non vi, emacs & co c'est pas des IDE dignes de ce nom :D (vilain troll pas beau)
Au fait, les trolls sur la rapidité de Java, ils ont été "exterminés" depuis longtemps alors tu retardes d'un sciècle :o) Voir les derniers débats sur slashdot...
Bon plus serrieusement, tux souffrait d'une PB, la faiblesse des performances de ces thread (l'overhead qu'il leur applique et tout bonnement démesuré !), mais avec le kernel 2.6 arrivent des thread tout beaux :D Pkoi tant de haine ? Tout simplement, Java utilise un max le multi-thread, d'ou un overhead max sur tux, et une différence de perf en multithread avec winxx ou d'autres OS (sous condition d'utilisation d'un JIT identique).
Enfin je rapelle que si tu lance la VM, il y a deux modes : en mode "serveur" (optimisation maximum, mais temps de lancement tres long) ou en mode "client" (lancement plus rapide, mais optimisation moindre). C'est encore plus flagrant avec les optim du JDK 1.5 !
Au fait, refuser le débat et avoir des préjugés, ce n'est pas bo ;-)
(pire encore quand il s'agit d'un vilain troll tout vilain)
Java est déjà une techno incontournable dans un CV, et elle est présente sur bon nombre de projet dans les monde de l'entreprise. Viendra un jour ou comme tout autre techno Java sera eclipsé par une nouvelle génération de concepts.
Perso, je dirais bien que la prochaine revolution sera ptet plus du coté du stockage de donnée ... (je suis le seul à trouver débile l'utilisation en 2000 de SGBD/R alors que tout le reste du monde est passé à l'objet ?)
C'est qu'il y a trop de doctrine et pas assez de pragmatisme :(
Et c domage ...
Franchement ObjectiveC c t vraiment top, et il n'y a guerre que Java qui a fait mieux pour moi (sniff ... je veux "mes" categories dans java !!!!) ... bien sur je ne parle pas ici de "mieux ideal" mais de "mieux pragmatique". En clair, pas de celui qui ne sert à une élite mais de celui qui peut servir au plus grand nombre tous les jours.
La FSF de toute façon ils sont C++iens (et Perl !) jusqu'a la moelle ... et ptet que dans 30 ou dans 40 ans ça changera, mais d'ici là avant de les voirs investir dans d'autres langages pour le bien de la communauté il se passera de l'eau sur les ponts.
Si vous me croyais pas, regardez l'histoire de GNUStep et GNU Classpath ;-)
# Et depuis quand mono est l'implémentation de .net ?
Posté par Hive Arc . En réponse à la dépêche Fedora Core en mutation. Évalué à 3.
Un petit coup de gueule, car les "copier/coller" de phrase marketing ont le don de me faire réagir :
Jusqu'à preuve du contraire : test de compatibilité officiel et indépendant couvrant toutes les fonctionalités de .net,
mono n'est pas l'implementation de .net !
Mono est une tentative d'implémentation de .net.
La différence ? ennorme ! par exemple, je tente de gagner au loto, mais est-ce que je gagne ? et est-ce que je gagnerai ? quelle est la probabilité que j'arrive à gagner ?
Comme le prouve le projet Classpath de la FSF, tenter de ré-implementer plateforme en perpétuel mouvement est quelquechose de très délicat (même ce dernier projet semble maintenant en capacité de rattraper sous peu la cible, cf. taux de compatibilité recement annoncé).
D'autant plus pour .net dont on n'a que peu d'information (seule la partie centrale ayant été publiquement spécifiée). Ainsi, .net reste un ensemble propriétaire, en grande partie non spécifié publiquement ainsi que intégralement sous controle de microsoft. Comment faire une "copie fonctionnelle" et s'assurer de sa pérénité dans de telle conditions ? (aveugle, et soumis au bon vouloir du "guide omnipotent")
Tant que MS refusera de livrer les spécifications complètes ou de publier avec une license ouverte les codes sources, quel est l'interet de mono, mise à part de montrer ce que l'on sait déjà : on peut toujours tenter de copier MS ;-) Mais ça je pense que Wine l'a fait de façon beaucoup plus probante ...
Au final, rappelons que les responsables de MS l'ont clairement rappelé lors de diverses allocutions: .net ne sera disponible que pour les OS de Microsoft. Pour l'instant, il ne compte pas attaquer tout contrevenant mais leur position face aux "copieurs" de .net n'est pas aussi clairement exposé.
Car MS est parti de Java c'est bien pour ne pas reproduire ce qu'ils considerent comme "erreurs" : possibilité à un tier de réimplémenter mais sous condition de compatibilité, manque de controle sur la plateforme car liés à des processus de spécifications (et bien sur à un éditeur tiers).
Sachant que la vrai plateforme MS est Windows, .net pour moi reste un "avatar" qui devrait dans l'avenir disparaitre en tant que tel et se voir intégré dans windows sous peine de mettre en danger MS. Qui dit plus d'intégration dit plus grande difficulté à dupliquer !!! Tout celà enlevant un quelconque interret à une plateforme qui n'est disponible au final que sous windows et pour x86.
Avec tout celà on est loint du « Mono, l'implémentation libre de l'environnement .NET de Microsoft »....non ;-)
[^] # Pour remplacer Oracle ...
Posté par Hive Arc . En réponse à la dépêche MySQL 5.0 est sorti. Évalué à 2.
Personellement, si tu veux remplacer tes base Oracle par une solution libre, je te conseille Firebird et le module Fyracle http://www.janus-software.com/fb_fyracle.html
Firebird est une base opensource sous license dérivée de la MPL, donc plutôt généreuse ...
Son gros avantage est de disposé de tonnes de fonctionalités : transations avancées, triggers, procedures stockées, unicode ... et tout ça fonctionant sous les principaux OS.
Fyracle est un ensemble de scripts/procedures et diverses améliorations qui va se greffer sur Firebird et permet à une immence partie du code Oracle de fonctionner directement sans modification !
Pour preuve, Fyracle permet de faire tourner Compiere http://www.compiere.org/ le célèbre outil ERP + CRM opensource sous MPL qui ne marchait que sous Oracle !!! Vraiment impressionant comme réussite.
Je ne m'explique clairement pas pourquoi MySQL a pendant si longtemps dominé le marché des bases libre étant donné son manque de fonctionalité chronique.... mais finalement tout vient à point qui sait attendre on a enfin les views sous MySQL .... sauf que perso, je les ait sous Firebird depuis plus de 5 ans ;-)
Si vous ne connaissez pas cette base fort sympatique, je vous invite à suivre http://www.firebird-fr.eu.org/
# Unicode oblige, ça doit marcher ...
Posté par Hive Arc . En réponse au message [debutant] Accents dans application Swing. Évalué à 2.
Celà te permettra de vérifier que la VM de ton mac est bien configurée coté police de caractères :)
Petit rappel, comme sous Java tout est en unicode, normalement le stockage des caractères ne posent pas de PB, par contre le rendu peut poser les problèmes suivants :
- aucune police unicode complète n'est disponible (et vu la taille d'une police complète on peut comprendre)
- aucune police n'est disponible pour la zone unicode ciblée
- la police utilisée à la volée (vu que tu peux par exemple livrer la police à utiliser avec ton appli) ne contient pas de caractères pour la zone unicode ciblée
Dans tous les cas, vérifier à l'aide du Font2DTest que tout est bien OK et que la fonte contient bien les bons glyphes.
[^] # Re: Demo flash
Posté par Hive Arc . En réponse à la dépêche Un nouvel outil de gestion documentaire : Alfresco. Évalué à 4.
MyFaces pour la présentation,
Spring pour le framework d'integration,
Hibernate pour le mapping Objet Relationel,
Apache Lucene pour la recherche
Et de ce que j'en comprend il doit utiliser Apache Slide pour la gestion WebDAV ;-)
Et vraisemblablement d'autres ....
JBoss et Tomcat pour le serveur applicatif proposé par défaut comme implémentation J2EE, mais je me demande le niveau d'adhérence par raport à ces deux composants.
Celà serait interressant de tester un passage sous Apache Geronimo :)
Ce genre de produit peut faire un malheur si la qualité d'implémentation est au rendez vous car J2EE est de plus en plus présent dans les entreprise. Et tout ce qui est positif pour l'opensource sous J2EE l'est aussi quelque part pour l'opensource en général mais aussi Linux en particulier. Tout simplement car une fois que l'on est tout en Java, on peut clairement se poser la pertinence de conserver ses serveurs sous des OS proprios ;-)
Bonne chance à Alfresco.
[^] # Nickel, mais ...
Posté par Hive Arc . En réponse à la dépêche Inkscape 0.42. Évalué à 4.
VITICULTEUR A SAINT-ÉMILION
Selon toute vraisemblance, ce n'est pas le verbe avoir qui est nécessaire, il faudrait écrire à la place :
VITICULTEUR À SAINT-ÉMILION
En espérant que tu n'as pas déjà fait imprimé un stock ....
En tout cas fellicitation pour le travail, je trouve ça très propre.
Pour mon info, tu as prévu de donner quoi comme format à ton imprimeur ? du SVG ?
[^] # Justement !
Posté par Hive Arc . En réponse à la dépêche Firefox 1.0 RC1 et autres nouvelles de Mozilla. Évalué à 9.
L'administrateur veut une configuration qui fournisse une infrastucture sécurisée. Le principe est que par défaut ils interdisent tout ce qu'il n'est pas nécessaire comme protocol (ou plutôt interdire l'usage des ports associés aux services).
Ceci est complètement opposé au besoins de l'utilisateur. Qui peut varier avec le temps. Et nécessiter divers protocole non-autorisés par l'administrateur :(
Par exemple, il est courant de constater que les administrateurs interdisent tous les protocols vers l'extérieur sauf HTTP / HTTPS. En conséquence de quoi, les utilisateurs au lieu de pouvoir accéder aux différents services escomptés (FTP, POP, IMAP, ...) se retrouvent limités à des interfaces web. Et ne peuvent utiliser leurs logiciels habituels.
Pour palier à ces problèmes est arrivé la solution de tout encaspuler dans des trames HTTP, par exemple on peut citer : SOAP (le plus souvent utilisé sur HTTP), WebDAV, ou bien encore les tunnels HTTP.
Ceci est une réponse qui n'est pas satisfaisante car elle consiste à confiner une protocols au niveau de l'application, et à rajouter une couche dans la couche applicative qui sera la véritable couche applicative. En clair, on remet une couche inutile pour palier à une limitation des configuration.
Quelle est la solution ?
Il faudrait que les firewall et les applications puissent dialoguer ensemble. L'application devrait être sécurisée, et fournir son certificat d'autenticité ainsi que ça demande de "laisser-passer" au firewall. Le laisser-passer devrait définir les besois en terme de ressources résaux distantes (protocole utilisé, référence aux standards suivit, identificaiton formelle des resources) Suite à quoi, le firewall devrait laiser passer la communication si celle-ci est digne de confiance (possibilité de paramètrer dans le firewall).
Il appartiendra alors au firewall de vérifier (suivant sa capacité de ontrole du protocole) à tout moment que l'utilisation faite par l'application des resources allouées est bien conforme aux déclarations indiquées par le laisser-passer.
De plus il faudrait supprimer le concept de "proxy" et le remplacer par des "proxy transparents", le firewall étant une fonctionalité de ce proxy transparent.
L'utilisation en parallèle de plage IPv6 simplifierai aussi le paramètrage de firewall grâce à l'identification de bout en bout de la chaine d'appel au niveau IP.
Bref, comme tout ceci n'exite pas, les protocols sur HTTP ont un avenir radieu ;-)
[^] # C'est déjà le cas il me semble ?
Posté par Hive Arc . En réponse à la dépêche De la fibre optique jusqu'au pas de la porte. Évalué à 1.
Sinon, si il a pas de connexion internet, tu peux passer par SkypeOut pour des bons Prix. Sauf que sur l'inde c'est plutot cher.
Dans ce cas, tu peux tester les "habituels telco à bas coût" type telerabais : pour appel vers un fixe c'est facturé au prix local (pas d'abonnement), et pour un mobile c'est 15c/min, moins cher que vers un portable français ;)
Et ceci est valable vers la pluspart des pays.
Franchement, c'est pas gratuit, mais vu les prix, à moins que tu passes tous les jours 2h (soit moins de 3¤) tu va pas te ruiner.
A+
[^] # Où est passé le SVG Slide toolit ?
Posté par Hive Arc . En réponse à la dépêche S5 : système de présentation utilisant les standards Web. Évalué à 1.
On en retrouve également des références sur :
http://www.xmlhack.com/read.php?item=690(...)
Pourtant la page http://www.sun.com/xml/developers/svg-slidetoolkit/(...) n'existe plus :(
Domage ... à moi qu'il est été contributé à Apache Batik ?
[^] # Vive le marketing !
Posté par Hive Arc . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 5.
MS .net ne permet PAS d'avoir les languages de son choix. Si on nomme les languages de .net des "flavor" ce n'est pas pour rien.
Ok, je m'explique: Les languages supportés par la CLR (je parle ici de code managed bien sur), ont tous un parent en commun, et sa plus fidèle incarnation est C#. Ceci est dû au fait que tous fonctionnent sur des bases communes : utilisation de la CLR et les classes de références (structuration et comportement).
En clair, tous les flavor de languages sont C#ifiés. Pour preuve il suffit de regarder le VB à la sauce .net: non comptent d'avoir introduit une centaine de changement majeur dans le language on a maintenant un langage : orienté objet, utilisant les classes de .net et disposant de fonction de ramasse miète, ....
Et on peut faire la même analogie pour tous les autres languages "soit disant" portés sur .net. Dans la pratique, comme ils font tous contraint à un commun dénominateur, ils ont tous semblables et n'ont plus rien à voir avec les originaux.
Si tu n'est toujours pas convaincu, va voir du cobol sauce .net et discute ça avec un coboliste.
Alors clairement, le multilanguage dans ces conditions n'a aucun interret. D'ailleur le fait est qu'il est que c'est bien C# qui est utilisé pour développer la majorité des applications, et qu'il existe des outils qui permettent de passer d'un langage à un autre ...
Enfin, techniquement parlant la plateforme de base de .net la plateforme Java sont quasiment identique tant en fonctionalité qu'en comportement. Alors je ne vois pas en quoi, l'un permetrait plus d'implementer un language que l'autre ne permet pas.
Et si c'etait le cas pourquoi pense tu qu'il existe une JSR intitullé "JSR 45: Debugging Support for Other Languages" ?
http://www.jcp.org/en/jsr/detail?id=45(...)
En fait languages, il y en a clairement largement plus qui existent sur Java que que .net :
http://www.robert-tolksdorf.de/vmlanguages.html(...)
La plus part sont également des "flavors", mais certains ont ajoutés suffisament de concepts pour que l'on puisse les considerer comme indépendants : Kiev ou OpenJava par exemple.
En conclusion, oui, désolé, mais il faudrait peut être sortir des publications comerciales de MS ;-)
# Pour en finir avec le FUD autour de Java ...
Posté par Hive Arc . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 5.
http://www.jcp.org/en/jsr/detail?id=176(...)
Ensuite, il faut rappeler que cette version va être la première à bénéficier du nouveau JSPA qui intègre les demandes de l'Apache Group. Celles-ci rendent possible une implémentation opensource tout en conservant le nom "Java" et assure la compatibilité de l'ensemble gràce à la mise ) disposition gratuite pour les organisation à but non-lucratif de l'outil "couperet": le TCK.
Merci à l'Apache Group pour son super travail sur ce sujet :)
Maintenant, si tout le monde se bouge le c*l et va aider le projet GNU Classpath, au lieu de faire du FUD encore et encore sur la soit-disante impossibilité d'avoir du Java libre, alors GNU Classpath pourrait assez rapidement être la premère VM qui soit opensource et 100% Compatible :)
Au passage : Ici réside la grande différence avec des tentatives style mono, qui ne seront jamais que des essais de duplication de fonctionalités d'une plateforme non-spécifiées et dont on ne pourra jamais assurer l'exactitude et le niveau de compatibilité réel tant du fait que MS garde l'ensemble des specs bien au chaud sous son coude, sauf quelques miettes qui ont été données à la "plèbe" via l'ECMA histoire de mettre un semblant de teinte d'ouverture à leur solution, qui n'a aucune prétention d'etre multi-OS (càd foncitonner sur autre chose que les OS MS), dixit les pontes de MS.
Bien sur ça suppose que Classpath reçoive un peu plus de soutiens des principaux acteurs de la FSF... aller un petit effort Mr RMS, il manque juste ça et on à la solution 100% libre souhaité par tous les adeptes de la GPL.
Pour finir, si vous voullez un truc en Java et sous GPL qui "trou le c*l", pour moi, c'est Looking Glass
https://lg3d.dev.java.net/(...)
Là aussi ya pleins de trucs cool à faire ....
[^] # Invraisemblable mais pas improbable
Posté par Hive Arc . En réponse à la dépêche Bruce Perens appelle les développeurs d'OpenOffice.org à ne plus fournir de code à Sun. Évalué à 2.
Or c'est justement le but de Java (contrairement à .net) de s'assurer de l'indépendance de la plateforme.
Le rêve de MS est de ramener la "brebis égarée" à son "berger", car le danger est grand de voir la brebis tuer le chien du berger au long terme ;-)
Et le loup dans tout ça ... il faut demander à Larry E :))
Plus serieusement, il faut vraiment que vous compreniez que le but de MS c'est de faire de la thune. Il ne sont pas spécialement "méchant", ni ne représente le "coté obscur de l'informatique". Juste ils ont comme toute société l'objectif de faire un maximum de bénéfice. Sauf qu'eux, ils ont des moyens hors du communs pour le réaliser.
Abus de position dominante, peut-être ... mais quand on contrôle également le système de controle, et les médias qui doivent le dénoncer qui s'en soucis encore.
[^] # Sun n'a pas attaqué le libre ni Redhat !
Posté par Hive Arc . En réponse à la dépêche Bruce Perens appelle les développeurs d'OpenOffice.org à ne plus fournir de code à Sun. Évalué à 9.
C'est faux, et je pense que tu as mal comprit la position de Sun.
Il ne s'aggit pas d'une "attaque", mais d'un constat. Sun a simplement indiqué que la GPL n'hévite pas du tout le problème du fork. Or Sun recherche depuis longtemps une lincense opensource "reconnue" qui lui permettrait de s'assurer qu'il y a un respects des standards établit dans le cadre du JCP.
Ce n'est pas d'ailleur le fork lui même que Sun chercher à éviter, mais le fork qui passe outre la nécessaire compatibilité avec la source initiale lorsqu'elle a comme référence un standard définit.
Ainsi, le probleme pour mettre l'implementation de référence sous Opensource (on rappelle qu'il n'y a rien!! qui empeche de faire une version de Java opensource et c'est le but de GNU Classpath au passage) est que si elle est réalisé, rien n'empechera MS de récuperer le code et de l'améliorer. Bien sur si il est sous GPL, les modifications devront être aussi sous GPL, mais la nouvelle version (devenue non compatible avec la source) existera belle et bien, et MS aura le champ libre pour faire une pub du style ".net est compatible Java, .net est la nouvelle plateforme de référence de l'entreprise. pourquoi utiliser Java alors que l'on fait les deux ?". Alors que leur "Java" ne sera plus compatible avec celui existant.
Il y a en ce moment pas mal de tractations, pour essayer de trouver une solution qui permettrait à Sun de mettre l'implementation de référence en libre et éviter cette situation, mais c'est pas simple.
Il est toujours difficile de limiter la "liberté" sans la remettre en cause, pourtant certains l'ont fait :
"La liberté des uns s'arrete ou celle des autres commence"
Reste à traduire celà en license ;-)
# Et aller une couche de FUD contre Sun !!!!
Posté par Hive Arc . En réponse à la dépêche Bruce Perens appelle les développeurs d'OpenOffice.org à ne plus fournir de code à Sun. Évalué à 10.
Oui, ils sont une société, oui, leur but est de faire de la thune, oui, leur but n'est pas de devenir la FSF.
Je suis un super fervant des solutions libres, mais comme au temps du communisme, il ne faudrait pas pas confondre liberté et totalitarisme.
Ce sont les mêmes qui d'ailleur au passage continuent à pousser du FUD sur Java, alors qu'on le rappelle, le projet GNU Classpath manque curellement de fond de la FSF et de mains de la communauté pour finaliser une version complète de la platforme Java sous GPL et lui faire paser le TCK qui lui permetra de clamer une complète compatibilité.
Ce sont les mêmes qui pipotent sur les supposés alliances Sun/MS contre IBM en ce moment sur les forums.
Pendant ce temps, on oublit les vrai objectifs.
Si vous voyez une salle remplie de PC de burreau sous Solaris, vous m'appelez ! Le vrai ennemi de Linux n'est pas Solaris, car il est relativement facile de convaincre un utilisateur de Solaris de migrer sous Linux. Mais le vrai ennemi est autre : Microsoft !
Car grâces à ses montagnes de dollars, MS peut racheter, communiquer, fusionner, controler ... qui bon lui semble. MS vient d'annoncer que son nouvel ennemi est le monde opensource. Afin de le contrer ils préparent des quantités de FUD à base de "licences pseudo opensources pour les clients importants" et autres ristournes exceptionnelles pours gros clients, histoire de décourrager leurs captifs de regarder vers des solutions plus libres.
Il faut regarder la vériter en face, MS est le maitre des lieus, et au lieu de taper sans cesse sur un petit mal en point (qui parfois le merite), pourquoi ne pas s'attaquer avec autant de vehémence au gros mastodonte qui truste tout les domaines ?
Je rappelle qu'au niveau des parts de marché, Linux a principalement "mangé" les parts des Unix, et finalement trés peu touché les parts des Windows de MS.
Il est temps de remettre tout ça en perspective SVP.
# La solution est simple !?!
Posté par Hive Arc . En réponse à la dépêche Nouvelle forme d'arnaque : l'usurpation d'identité de site web via XUL. Évalué à 3.
Ajouter un bandeau en bas impossible à supprimer qui précise "Application Web utilisant XUL" sur toute composant de type fenetre ou boite de dialogue.
La difficulté est dans le "impossible à supprimer" sous XUL, est qu'en Java, il y a un méchanisme de sécurité fort qui met en place un bac à sable qui epêche tout application non certifié d'accèder à toutes les fonctionalités critiques (c'est vraiment très solide comme concept car c'est un des fondement de la VM).
J'ai pas vraiment vu de concept de bac à sable en Gecko ... encore fraudrait-il que la spec de XUL le définisse bien sur ;-)
Aller pour conclure, je trouve que ni XUL, ni XAML ne sont vraiment une avancée décisive. Bien sur, ils apportent dans une certaine mesure un découpage MVC, mais l'abstraction par rapport à l'interface est loint d'être parfaite. Devoir passer son temps à "mettre en page" les composant est un travail fastidieux, et il aurait été souhaitable d'avoir une technique qui facilite celà ...
[^] # Compatibilité ... oui justement !
Posté par Hive Arc . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 3.
Car c'est bien là le noeud du PB. Prend les fonctionalités entreprises de .net comme elle sont basés sur COM+ et qu'il n'y a aucune spec de dispo, il est impossible à mono de les supporter. Or toute platforme qui veut vraiment faire un truc qui monte en charge va passer par ces fonctionalités. Finit la "compatibilité" promise. De plus, avoir des API identique est une chose mais offrir un comportement identique en est un autre. Et le TCK est là pour ça !
Tant que MS ne fournira pas de TCK, il n'y aura pas d'avenir pour mono.
# De mauvaise foi !
Posté par Hive Arc . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 5.
De plus, que je sache Java est disponible dans sa toute derniere version sur Linux et avec une compatibilité de 100% (merci au TCK). Alors passer aussi rapidement sur un "détail" à son importance.
Pour moi c'est de la mauvaise fois pure et simple.
Franchement, quite a faire du "portable à tout prix" autant faire du python !
Maintenant si, la portabilité doit être conservé et l'environement souple, alors Java reste le meilleur compromit. Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.
Mieux vaut laiser icaza jouer avec son mono, moi pendant ce temps je joue avec Looking Glasses :
https://lg3d-core.dev.java.net/lg3dgettingstarted.html(...)
A chacun ces "jeux" ;-)
[^] # Quel avenir pour mono ?
Posté par Hive Arc . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 7.
AMHA, croire que MS va laisser copier leur plateforme de référence sans broncher est faire preuve de crédulité vu les sommes investies en R&D et marketing par MS sur la marque.
Tant que mono sert à MS pour faire avaler la pilule du "multi-plateforme" concernant .net, il n'y a aucun problème. En ça, je serais interessé par connaitre les motivation exactent de DeIcaza, vu ses relations troubles avec MS.
Concernant le "pseudo" standard ECMA, franchement MS est de mauvaise fois, car non seulement elle n'a soumis qu'une partie de la spec de .net, mais ensuite, il faut rappeler lorsque Java avait été poussé à l'ECMA les arguments qui lui avait valu d'être rejeté ... ici on se rend compte des pressions qui ont du se produire en coulisse dans les deux cas. Je ne reviendrait pas non plus sur la soumission de Java à l'ISO, qui était plus du domaine de la série Dallas ;-) Ce sont ces lobying répétés de MS qui ont obligé Sun a créé un procéssus de standardisation des specs Java décorrélé de toute influence de MS.
De plus, pour rappel, MS était il y a qqe années à fond impliqué dans Java, Visual J++ étant l'IDE n°1 et JView la VM la plus performante de plus l'ensemble des API de windows était disponible via des API Java !!! Bien sur, ensuite est arrivé la "crise" lorsque MS a essayé d'introduire une spécificité à Java pour le rendre interdépendant avec windows.
Concernant .net, toute personne qui connait les deux mondes sait bien qu'il n'y a que peu de différence. Et que basculer de l'un à l'autre est une question de jour.
Je préciserait simplement que ton point sur la généricité est ridicule, regarde les débats et JSR dans les forums Java et regarde quand MS a commancé à en parlé ... et ensuite reviens discuter serieusement (vraiment ce point prouve particulierement que tu ne fais que répeter les publi-annonces de MS).
La seule question pertinente pour moi est la pérénité des deux solutions.
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de mono, car il y aura toujours un point valable pourdire que .net est mieux ... entre un obscur groupe, et Microsoft, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire mono, c'est apporté de l'eau au moulin de MS et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Si vraiment tu es un apotre du libre, je te conseille vivement de rejoindre la FSF et de consacrer ton temps au projet Classpath dont le but est de passer le TCK Java et fournir une implementation intégrale de la spec J2SE. Et là au moins pas de risque de voir un quelconque éditeur balayer ton ouvrage d'un simple revers de la main (non, même pas Sun, pour t'en convaincre, je te propose de relire les licences appliqués à J2SE 5.0 par exemple, ainsi que la position claire et définitive sur les brevest potentiels autours de Java).
Oui, vraiment je pense que l'avenir de mono est assez sombre. Quand à celui de .net il est assuré ... enfin, du moins pour le nom, quand au framework, les API de longhorn sont sur le point de le mettre en pièce ....adieu veaux, vaches et winforms ;-)
[^] # Aller tant qu'on y est ...
Posté par Hive Arc . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 0.
Non content d'avoir vampirisé le nom de "Firebird" l'excelente base de données opensource, ils utilisent comme nom de fichier l'extension .jar qui est le format des librairies et executables Java !
Si qqn peut me dire pourquoi les extensions de Mozilla sont nommés .jar ça m'interesse ... du coté de Java le .jar existe depuis des lustres, c'etait à l'epoque du JDK1.2 ( et .jar pour Java ARchive tout simplement). Merci ;-)
[^] # Ben non ;-)
Posté par Hive Arc . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 1.
Cheetah est le nom de code de la future version d'éclipse qui supportera les fonctionalités de tiger.
T'es sur que t'as regardé sur la page :
http://java.sun.com/j2se/1.5.0/snapshots/(...)
Si tu vois une guenon, cours vite voir ton ophtalmo ... ou ton psy :))
Plus serieusement, je pense que le nom de code du 1.5 (tiger) est antérieur au choix de Apple. Mais faudrait creuser ce point.
Sinon, j'ai pas de Mac OSX, mais si tu veux m'acheter une pomme portable 17" écran large, je veux bien en avoir un :))
# Pour dompter le tigre ...
Posté par Hive Arc . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 2.
D'ailleur au passage, je ne saurrais que trop vous conseiller de tester vos appli avec les toutes dernières build qui sont disponibles sur http://java.sun.com/j2se/1.5.0/snapshots/(...)
Celà permet de se rendre compte des perfs obtenues et en cas de pépin de reporter le bogue au plus vite afin qu'il soit corrigé avant la version finale.
Dans cette nouvelle mouture, il y a tellement de nouvelle fonctionalité que la tête peut en tourner. Parmis tout celà, les nouvelles fonctionalités du langages tant attendues, telle la généricité ... le site http://www.3plus4.de/eclipse/cheetah.html(...) (en anglais mais avec des zimages!) explique pas à pas comment faire bénéficier eclipse 3.0 des toutes dernieres avancées du langage.
On espère la version finale de cette mise à jour majeure de la JDT Eclipse pour bientôt ;-)
Vive le J2SDK 5.0 ... j'ai dit 5.0 ? tiens comme c'est bizare ;-)
# Mono un clone de .net ... ben tient !
Posté par Hive Arc . En réponse à la dépêche Appel à l'aide pour la documentation de GTK#. Évalué à 2.
Faut vraiment arreter de dire n'importe quoi autour de mono. Ce n'est pas parce que la grenouille veut se faire plus grosse que le boeuf qu'elle va y arriver. Surtout quand le boeuf est transgenique et qu'il continue de grossir à vue d'oeil <:o)
Plus serieusement, je me demande toujours pourquoi des acharnés continuent de copier MS au lieu d'innover sur des bases saines. Franchement on n'as pas besoin de cloner MS pour prouver que l'innovation est plus vivace dans le monde opensource !
Quite à donner du temps à la communauté pour des projets visant à offrir un equivalent libre à des solutions propriétaires, autant le faire sur des trucs dont on a une visibilité complète sur les specs par exemple pour le projet GNU Classpath par exemple ou encore pour le projet Geronimo d'Apache. C'est clairement plus productif car là au moins on sait aprés quoi on court : concurencer directement les productions commerciales par une certification sans ambiguité ;-)
[^] # De tout temps ...
Posté par Hive Arc . En réponse à la dépêche Sortie d'Eclipse 3.0 finale. Évalué à 7.
Tu veux pas faire du Java, c toi que ça regarde ... mais essaye de lancer un IDE digne de ce nom sur ta machine et on en reparle ensuite ;-) Et non vi, emacs & co c'est pas des IDE dignes de ce nom :D (vilain troll pas beau)
Au fait, les trolls sur la rapidité de Java, ils ont été "exterminés" depuis longtemps alors tu retardes d'un sciècle :o) Voir les derniers débats sur slashdot...
Bon plus serrieusement, tux souffrait d'une PB, la faiblesse des performances de ces thread (l'overhead qu'il leur applique et tout bonnement démesuré !), mais avec le kernel 2.6 arrivent des thread tout beaux :D Pkoi tant de haine ? Tout simplement, Java utilise un max le multi-thread, d'ou un overhead max sur tux, et une différence de perf en multithread avec winxx ou d'autres OS (sous condition d'utilisation d'un JIT identique).
Enfin je rapelle que si tu lance la VM, il y a deux modes : en mode "serveur" (optimisation maximum, mais temps de lancement tres long) ou en mode "client" (lancement plus rapide, mais optimisation moindre). C'est encore plus flagrant avec les optim du JDK 1.5 !
Au fait, refuser le débat et avoir des préjugés, ce n'est pas bo ;-)
(pire encore quand il s'agit d'un vilain troll tout vilain)
Java est déjà une techno incontournable dans un CV, et elle est présente sur bon nombre de projet dans les monde de l'entreprise. Viendra un jour ou comme tout autre techno Java sera eclipsé par une nouvelle génération de concepts.
Perso, je dirais bien que la prochaine revolution sera ptet plus du coté du stockage de donnée ... (je suis le seul à trouver débile l'utilisation en 2000 de SGBD/R alors que tout le reste du monde est passé à l'objet ?)
Qui vivra ... codera.
[^] # Perso, je patche IE ;-)
Posté par Hive Arc . En réponse à la dépêche Le brevet sur le format GIF est arrivé à expiration. Évalué à 6.
http://dean.edwards.name/IE7/(...)
Il patche IE pour qu'il supporte plein de trucs qui marche sous Firefox ;-) Genre, les PNG, les position fixées, les survols ...
Ansuite je rajoute ce petit amusement :
http://dean.edwards.name/my/misbehaviors/#noIE-popup(...)
Comme ça les utilisateurs de IE sont informés !
Vive XHTML1.1 , vive CSS2&3 ! à bas les navigateurs pas compatibles :)
[^] # Le problème avec la FSF ...
Posté par Hive Arc . En réponse à la dépêche Nouvelles versions de GNUstep. Évalué à 2.
Et c domage ...
Franchement ObjectiveC c t vraiment top, et il n'y a guerre que Java qui a fait mieux pour moi (sniff ... je veux "mes" categories dans java !!!!) ... bien sur je ne parle pas ici de "mieux ideal" mais de "mieux pragmatique". En clair, pas de celui qui ne sert à une élite mais de celui qui peut servir au plus grand nombre tous les jours.
La FSF de toute façon ils sont C++iens (et Perl !) jusqu'a la moelle ... et ptet que dans 30 ou dans 40 ans ça changera, mais d'ici là avant de les voirs investir dans d'autres langages pour le bien de la communauté il se passera de l'eau sur les ponts.
Si vous me croyais pas, regardez l'histoire de GNUStep et GNU Classpath ;-)
# a quand du webdav sur TB ?
Posté par Hive Arc . En réponse à la dépêche Thunderbird 0.6 en français. Évalué à 2.