Si ça peut donner des idées à certains... ;-)
Note du modérateur : la JVM et les classes de base de Sun/IBM/Blackdown ne sont pas non plus libres. Il faut voir du côté de Kaffe/ORP/Kissme ou gcj et de Classpath pour avoir une solution java 100% libre. Les liens vers ces projets sont dispos sur la page de Classpath
Aller plus loin
- L'article sur JDNet développeurs (4 clics)
- JDNet développeurs (7 clics)
- Classpath (2 clics)
# Mazette
Posté par kadreg . Évalué à 10.
Les frameworks d'éditeurs, même réputés, constituent un choix plus risqué. Bien qu'il présente certaines imperfections, le framework maison reste la propriété de l'entreprise qui le déploie. Elle en possède les sources, donc elle est assurée de pouvoir au minimum recompiler les programmes de son patrimoine applicatif sans limite de durée. Les frameworks d'éditeurs, lorsqu'ils ont des bibliothèques livrées sans sources, n'offrent pas cette garantie fondamentale et présentent ainsi un risque réel pour le patrimoine applicatif de l'entreprise.
Le framework d'éditeur a toujours un objectif caché : celui de verrouiller l'entreprise sur les outils de l'éditeur. Ansi, les applications liées au framework - comme on l'a vu cela est inévitable - tendent à devenir indissociables de tel ou tel serveur d'application. Formidable régression !
C'est RMS qui a écrit l'article ?
PS : en fait, c'est quelqu'un de cette boite : http://www.smile.fr/content/smile2/technologie/opensource/(...)
# La Javanaise en question
Posté par tekool . Évalué à 2.
Certes Sun n'est pas Microsoft et OpenOffice est un signe de bonne volonté mais techniquement cela n'enlève en rien que Java était d'abord prévu pour des clients et pas pour des serveurs.
Pour aller jusqu'au bout de ce post-troll, je pense que "write once, run everywhere" est une erreur. Comme dirait un programmeur C, C++ ou Object Pascal, c'est write once, compile everywhere. Les performances et les besoins mémoires s'en ressentent d'autant.
Si je dois utiliser un langage interprété, je préfère de loin Python, plus libre et plus agréable, du moins à mon goût.
[^] # Re: La Javanaise en question
Posté par Anonyme . Évalué à 10.
[^] # Re: La Javanaise en question
Posté par tekool . Évalué à 10.
Actuellement, on vend la technologie EJB pour des serveurs dits "E-Bizness" et devant supporter de fortes charges et de nombreux threads. J'emets un doute sur le fait que ce type de techno soit en corrélation avec ce pour quoi Java avait été fait au départ. Ca sent plutôt le marketing à plein nez. On est passé de l'applet au servlet, puis du servlet à l'EJB, en suivant les gueguerres d'éditeurs (browsers, scripts serveurs puis composants métiers).
Les benchs existants, du moins ce que j'a trouvé, se contente de comparer des opérations de base. Entre des FFT, des calculs mathématiques et un framework complet d'applications web avec processus métier, il y a un réelle différence.
[^] # Re: La Javanaise en question
Posté par Val Erie . Évalué à 10.
heu ... sans vouloir te contrarier ... un langage évolue ... pour te prendre des exemple du monde libre ...
php était prévue pour faire un site perso dynamique,
perl était un jeu de linguiste (orthographe ???),
linux était un tutorial pour étudiant,
emacs était un éiditeur de text ...
tout évolue ...
<humour>même MS-Windows
(tm)avait été basé sur le QDOS (quick and dirty OS) avant que l'on retire le quick ...</humour>[^] # Re: La Javanaise en question
Posté par tekool . Évalué à -3.
Java joue le jeu de la course à l'armement au niveau du matos et favorise une société dans laquelle je n'ai pas plus confiance que ça. C'était juste ce que je voulais dire par mon premier post.
Bon, je reconnais que j'ai aussi un peu trollé mais j'avais bien écrit "post-troll" dans mon premier post :-)
<troll>Et puis, chacun est libre d'enfoncer des clous avec une scie ;-)</troll>
Pour la peine -1
[^] # Re: La Javanaise en question
Posté par boubou (site web personnel) . Évalué à 2.
Oui, Java est moins efficace que de l'assembleur. Pour le reste, je demande à juger sur pièce. Le seul bench valable dans mon domaine est celui proposé par colt (http://tilde-hoschek.home.cern.ch/~hoschek/colt/(...)) qui met en oeuvre du calcul matriciel évolué. Le code de colt, 100% pur Java, tourne environ 2.5 fois plus lentement que la bibliothèque de calcul matriciel MKL d'Intel, bibli qui est partiellement écrite en assembleur et qui utilise toutes les possibilités du Hardware (MMX 2, prefetch, etc.). Vu la facilité du développement en Java, je trouve que les 2.5 sont parfaitement acceptables.
D'autre part, effectivement pour l'instant il n'y a pas de solution totalement open source pour faire du Java. Mais il me semble que pour l'instant aucun compilateur libre n'implante complètement la norme C++ (ou alors c'est très récent). Donc, un peu de patience...
[^] # Re: La Javanaise en question
Posté par PLuG . Évalué à 7.
Le langage java - je ne me permettrai pas d'en penser quoi que ce soit, c'est un langage qui a ses atouts, ses inconvenients, et je suis mal placé pour en parler (pas assez pratiqué).
Par contre l'architecture associée - JAVA et son mode de pseudo-interpretation (pseudo code, ...)- a clairement été pensée pour les applets. Avant cette achitecture JAVA, il etait impossible de distribuer via le web des "binaires" a faire tourner sur les clients.
JAVA répondais a un besoin précis, un besoin qui n'avait pas d'autres solutions.
Maintenant, utiliser l'architecture JAVA du coté du serveur, a mon avis c'est pas optimal du tout. Certes cela permet d'installer la meme applis sur n'importe quel serveur, mais cet avantage a un coup a chaque execution, alors qu'un soft bien developpé [meme en C] est facilement recompilable sur tous les systèmes.
JAVA sur le serveur c'est:
-un avantage pour l'editeur du soft [un seul packaging/livrable quel que soit la plateforme du client. Donc moins de frais pour l'editeur qui fait payer la note au client (en perfs)]
-un lobbying des developpeurs JAVA [mais on pourrait developper avec le langage JAVA et compiler du code natif ...]
-un effet de mode [qui passera plus vite que celui du C, rendez vous dans 30 ans]
Alors les pro-java vont repondre que les perfs sont la, que blablabla ... moi je leur dit:
utiliser JAVA cote serveur, c'est comme heberger un serveur WEB avec IIS/WIN 2000. On ne peut pas dire que cela ne marche pas, il y en a meme qui s'en servent ... par contre d'un point de vue technique ...
[^] # Re: La Javanaise en question
Posté par Anonyme . Évalué à -2.
-1 parce que j'ai pas grand chose de plus a dire
[^] # Re: La Javanaise en question
Posté par anonyme512 . Évalué à 4.
bon, passons sur le fait que le modèle "sandbox" (un des éléments majeurs de l'architecture JAVA) a ENORMEMENT évolué depuis Java 1, et que maintenant il ne se limite plus à faire tourner des applets, etc, pour offrir une vraie couche de sécurité pour les applications. ça au fond, c'est un point de détails, on peut arriver au même autrement.
en revanche, il y a deux choses:
1- le langage Java et le système de machine virtuel donnent un langage objet extrêmement bien conçu, très séduisant, et qui plus est où l'on a pas à gérer la gestion mémoire (encore qu'on peut le faire si on veut). ceci accroit la maintenabilité des applications (design patterns quelqu'un ? ;-))
2- la portabilité est quelque chose d'absolument MAJEUR pour le langage. En effet, bien souvent, les sites sont développés sur des machines de bureau (PC Linux ou Windows), sans aucun rapport avec celles sur lesquelles elles tourneront (rarement du Windows, parfois du Linux, souvent du Solaris, et de temps à autre, du Mainframe).
c'est précisément ces deux raisons qui ont fait le succès de Java du coté serveur.
depuis l'arrivée du JIT, la vitesse d'exécution est telle que les derniers obstacles ont été levés.
quand aux serveurs d'applications OpenSource Java, je connais bien, et franchement, c'est génial (JBOSS et Enhydra -ya aussi Jonas, mais je connais moins-)
[^] # Re: La Javanaise en question
Posté par pthivent . Évalué à 3.
Les qualités de Java côté serveur, les nombreuses API dont la majorité sont libres et la maturité atteinte par les serveurs d'applications font de J2EE un modèle que l'on ne peut ignorer.
Il ne manque d'ailleurs pas "grand chose" au monde du logiciel libre pour disposer de son propre serveur d'application. Si on prennait un Tomcat, qu'on lui ajoutait un mécanisme de réplication de session en mémoire pour le fail-over, qu'on lui collait un J0nAS (je renvoie l'auteur du post précédent à cette news http://linuxfr.org/section/Articles/7750,0,1,0,1.php3(...) pour le chois de JOnAS), yauraipuka bricoler un peu le support du clustering et affiner le load-balancing et on l'aurait notre plateforme J2EE performante, fiable, scalable (je trouve pas d'équivalent en français) et libre.
[^] # Re: La Javanaise en question
Posté par Anonyme . Évalué à 0.
Bon d'accord, je te l'accorde, c'est pas super repandu les EJB... j'ai l'impression que les gens prennent ça pour de la muscapédication...
Si je me souviens bien, Tomcat, c'est Servlet + JSP, non ? (flemme d'aller voir le site à cette heure ;) )
[^] # Re: La Javanaise en question
Posté par pthivent . Évalué à 1.
[^] # Re: La Javanaise en question
Posté par PLuG . Évalué à -1.
Comme le dit un post plus bas, si on compare JAVA et PHP, y a pas photo.
Mais cela ne prouve rien quand a l'architecture de la solution. La portabilite cote serveur est un leurre. On peut très bien developper du C sur un linux et le compiler / tester sur une plateforme autre (solaris) avec un peu d'experience.
Donc oui les solutions JAVA actuelles sont sexy.
et Non cela ne prouve rien sur son architecture completement dédiée a la portabilite binaire. Cela prouve juste que JAVA a interessé suffisement de monde pour que des solutions web soient développées. Et cela surement parce que java apporte la compatibilite en mode source aussi. Pour un developpeur, c'est agréable de savoir que son code risque de marcher de partout => succès, alors que la compatibilité binaire n'est pas necessaire.
les objets, le GC, ... tout le reste est applicable a d'autres langages reposant sur d'autres architectures, donc ces "avantages" ne sont pas dédiés à java.
[^] # Re: La Javanaise en question
Posté par boubou (site web personnel) . Évalué à 2.
langages reposant sur d'autres architectures, donc ces
"avantages" ne sont pas dédiés à java.
Exemple(s) ? Effectivement Eiffel, Caml, etc. proposent des objets et du GC, et même de la portabilité type JVM (on peut compiler Eiffel vers du bytecode Java). Maintenant est-ce que ces (très bon) langages sont utilisés en vrai ? La réponse est non. Le seul langage accepté actuellement de façon très large qui propose GC, objets, portabilité quasi-parfaite, etc. c'est Java. Le seul concurrent à court terme, c'est C#.
[^] # Re: La Javanaise en question
Posté par Gérald Quintana . Évalué à 3.
http://www.jboss.org/online-manual/HTML/ch13s144.html(...)
[^] # Re: La Javanaise en question
Posté par vrm (site web personnel) . Évalué à 2.
java c'est tres bien coté serveur, surtout la gestion de la memoire, tu defini la taille de ton spoule et hop le GC se demerde.
pensé pour faire des applets ? tu rigole ? tu sais vraiment de quoi tu parle ?
meme orcale permet de mettre du java dans ses procédures stockés ..
de plus tu peux compiler java si ça te plais pas la jvm
enfin l'effet de mode il va bientot avoir 10ans non ?
<troll> et puis avec le bytecode, tu ramme pas comme dfu perl et tu evite les segfault & buffer overflow du C++</troll>
puis va faire un bench entre un serveur d'application avec tomcat sur solaris contre apache/php avant d"ecrire des bétises
[^] # Re: La Javanaise en question
Posté par boubou (site web personnel) . Évalué à 1.
[^] # Re: La Javanaise en question
Posté par boubou (site web personnel) . Évalué à 3.
Et bien alors arrête de la ramener. C'est vraiment incroyable cette mentalité "je n'y connais rien mais j'ai quand même mon opinion". Java n'a jamais été pensé pour les applets. Ton affirmation est historiquement fausse (la cible de départ était l'embarqué). De plus, la notion de machine virtuelle et de bytecode est très antérieure à Java (ça date des années 70).
Quant à l'aspect Java sur le serveur, le principal atout est la rapidité du développement en Java. Le fait que Java soit portable est un atout annexe par rapport au gain de temps qu'apporte le modèle objet et les design patterns (et ne me parle pas de DP en C, c'est n'importe quoi).
La mention de IIS/Win 2000 est pitoyable. Dans le genre, je n'ai pas d'argument technique alors je fais appel au grand satan pour faire peur...
[^] # Re: La Javanaise en question
Posté par PLuG . Évalué à 0.
Mais dans ta citation tu te gardes bien d'inclure ma phrase complete ... pas très honnete comme comportement !
Je n'ai jamais prétendu que JAVA avait inventé le bytecode ni le GC. Dans l'embarqué JAVA devait tourner sur des processeurs JAVA donc exit les problemes d'architecture JAVA que je dénonce dans mon message.
Ensuite tu me réponds "facilité de développement en JAVA".
Cela ne me pose pas de problèmes, mais je pense que tu t'enerves tout seul et que tu ne parles pas des mêmes aspects que moi (facilité de developpement == langage or j'ai averti que je ne parlais pas du langage).
Quand a mon allusion a IIS, regardes la de plus près:
-techniquement windows+IIS ont AMHA moins d'atout qu'un unix + apache notement en termes de sécurité, de licenses, etc.
Un defenseur acharné de Microsoft répondrait a ta manière, facilité d'installation, disponible et supporté par plein de gens ...
CE N'EST PAS MON PROPOS.
Je dis qu'il est domage de payer en performance alors que ce qui plait dans JAVA c'est le langage.
le GC, les DP et les frameworks pour faire des serveurs d'applications. On pourrait avoir tout cela sans le surcout lié au bytecode. Ce qui fait l'interet de JAVA c'est le nombre de developpeurs et les produits/bibliotheques qui existent, plus que son architecture.
Reste a compiler le langage java que tu aimes tant, ainsi que tous ses frameworks ... Quand GCJ sera pret !!
[^] # Re: La Javanaise en question
Posté par Nelis (site web personnel) . Évalué à 1.
[^] # Re: La Javanaise en question
Posté par Gérald Quintana . Évalué à 3.
Je pense que la pénurie de développeurs a poussé beaucoup d'entreprises à employer des personnes non informaticiennes et à les former sur des langages plus accessibles (comme Java, PHP ou Visual Basic).
[^] # Re: La Javanaise en question
Posté par Nelis (site web personnel) . Évalué à 4.
Java ? Un langage plus accessible ? En apparence peut-être (librairies standards, syntaxe lisible, ...), mais autant il est facile de programmer en Java, autant très facile de mal programmer en Java, et autant il est très difficile de BIEN programmer en Java ... C'est peut-être d'ailleurs un des aspects qui porte préjudice à Java ... Les gens ont vite l'impression de savoir programmer en Java alors qu'ils font pas mal de choses de travers, ce qui aura pour conséquence un logiciel qui tourne lentement/mal, et le réflèxe sera de dire : "Pouah, Java ça pue, c'est lent et buggé", alors que le problème sera dans le code ...
Je programme tous les jours en Java depuis deux ans, je progresse sans cesse, quand je regarde le code que je faisais à mes débuts, je me dis "oh la ... j'ai fait ça comme ça ?? M'enfin quelle idée ! Il aurait fallu le faire ainsi ...". Et je ne me considère pas encore comme un expert (loin de là) ...
[^] # Re: La Javanaise en question
Posté par boubou (site web personnel) . Évalué à 1.
Je suis d'accord avec toi sur le fait que pour maîtrise complètement Java, il faut des années. Il faut dire que les "innovations" du langage sont très importantes et assez pointues : reflexivité très poussée, chargement dynamique, serialisation, RMI, etc. En plus, l'API est gigantesque. Mais il n'en reste pas moins que le langage lui-même est assez simple et facile à apprendre (pour un langage de cette richesse).
[^] # Re: La Javanaise en question
Posté par Nelis (site web personnel) . Évalué à 2.
Enfin, on est d'accord, la plateforme Java est formidable :-)
[^] # Re: La Javanaise en question
Posté par Timbert Benoît . Évalué à 2.
Ca dépend ce que tu appelles "forte charges". Dans des conditions bourrin les serveur EJB on du mal à suivre, là ou un produit full custom en C (bien plus long à dévelloper que quelquechose avec EJBs) réagira bien mieux. Pour faire tourner dans les même conditions des serveurs avec les EJBs, il faudra des serveurs plus gros (et souvent ça n'est pas trop un problème)...
[^] # Re: La Javanaise en question
Posté par Guillaume Laurent (site web personnel) . Évalué à 2.
Ça n'est même pratiquement jamais un problème : les machines continuent d'augmenter en puissance, donc prendre de plus gros serveurs c'est une dépense relativement faible (sauf pour les très gros sites), facile à chiffrer, et sans trop d'influence sur les délais.
Alors que la dépense en temps de développement pour rendre ton serveur en C aussi fiable qu'en Java et avec les mêmes features... bon courage.
[^] # Re: La Javanaise en question
Posté par Timbert Benoît . Évalué à 2.
Il est clair que from scratch c'est souvent plus rapide de développer en Java. Mais si tu dispose déja d'un bon framework de départ (c'est l'avantage du Java, d'autant plus qu'il est en standard), ça peut avancer aussi vite dans un autre language.
[^] # Re: La Javanaise en question
Posté par VACHOR (site web personnel) . Évalué à 4.
Apprenez à programmer et vous verrez que le Java ca roulaize.
[^] # Re: La Javanaise en question
Posté par kangs . Évalué à 1.
en Java :)
[^] # Re: La Javanaise en question
Posté par Guillaume POIRIER . Évalué à 10.
Est-ce un probleme puisque Linux est GPL? Sun sera oblige de rendre les sources disponibles, et si ses modifications ne sont pas integrees (comme l'est le Patch Xfs pour le moment, bien qu'il devrait etre inclut dans le kernel 2.5.x), Sun va tout simplement s'enfermer dans un Solaris II tout en produisant du code peut-etre interessant pour la communaute (GPL-contaminated).
Je pense pas tellement que ce soit rentable financierement pour Sun de faire son propre Linux, incompatible avec les autres.
Qu'il produise sa distrib, pourquoi pas apres tout? Il y a bien deja des distribs "proprio", alors une de plus...
-1 car rien a voir avec Java, mais a voir avec l'OpenSource...
[^] # Re: La Javanaise en question
Posté par tekool . Évalué à 0.
Peut être suis-je simplement parano ? :-)
- 1 pour ma folie
[^] # Re: La Javanaise en question
Posté par Neryel . Évalué à 10.
A mon avis, voir Richard Stallman débarquer et se mettre à jouer du pipo est plus effrayant et efficace qu'un gros procès :+)
[-1, parce que je blasphème sur Saint IGNUcius, et que c'est Mal(Tm)]
[^] # Re: La Javanaise en question
Posté par tekool . Évalué à 3.
-1 par mimétisme religieux
# Classpath
Posté par Gérald Quintana . Évalué à 3.
- Il ne contient que des classes de bas niveau liées uniquement aux aspects techniques
- On ne peut décemment pas utiliser java sans des packages comme java.lang, java.util...
L'article mentionne Turbine, Velocity et Struts qui s'apparente davantage (à mon sens) à des frameworks.
http://jakarta.apache.org/turbine/index.html(...)
http://jakarta.apache.org/velocity/index.html(...)
http://jakarta.apache.org/struts/index.html(...)
# Warning: troll detected !
Posté par Timbert Benoît . Évalué à 0.
Ceci dit, même sans Java l'article reste très pertinent sur le "Pourquoi faut-il choisir des frameworks opensource ?" (Java ou pas Java)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.