Articles précédents : Articles
- [9] ODEBI : une ligue pour le haut débit
- [11] Lindows.com gagne contre Microsoft
- [148] La Belgique initie les Wallons aux logiciels libres
- [10] Foot.fr (Linux powered)
- [0] Logiciels libre dans "La Recherche"
- [0] StarOffice 6.0 fourni avec Ximian
- [11] Jeux Windows sous Linux avec WineX 2.0
- [9] Backdoors chez monkey.org (dsniff et fragroute)
- [7] Une distribution orientée éducation
- [34] Dreamworks' continue l'esprit Linux
Liens connexes
- L'article sur JDNet développeurs (890 hits)
- JDNet développeurs (478 hits)
- Classpath (346 hits)
Dépêche modérée par
Articles : Pourquoi faut-il choisir des frameworks Java opensource ?
Posté par Pierre Tane (). Modéré le 01 juin 2002.
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
![[fr]](../../../images/fr.png)
L'article sur JDNet développeurs (890 hits)-
JDNet développeurs (478 hits)
![[en]](../../../images/en.png)
Classpath (346 hits)
> Lire les commentaires (36 commentaires, moyenne: 4,6).
Mazette
Je cite l'article :
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
Personnellement, j'ai du mal avec Java. Je trouve que utiliser Java fait le jeu de Sun qui pousse ce langage au sein de son désormais célèbre bundle "matériel+langage+logiciel". Et visiblement bientôt OS puisque Sun compte développer une distrib linux ne fonctionnant que sur ces machines et a annoncé la convergence de ses stratégies Solaris/Linux.
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 () le 01/06/2002 à 13:42. (lien). Évalué à 13.Ouais enfin aujourd'hui avec les jvm "just in time", le java, c'est comme du compilé...
-
[^]Re: La Javanaise en question
Posté par tekool (page perso, ) le 01/06/2002 à 14:21. (lien). Évalué à 21.C'est un peu rapide comme affirmation et j'aurais ajouté "dans certains cas". Tout dépend de ta JVM (d'ailleurs souvent écrite en C), des biblio utilisées et des opérations que tu executes.
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 (page perso, ) le 01/06/2002 à 15:29. (lien). Évalué à 30.avec ce pour quoi Java avait été fait au départ
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 (page perso, ) le 01/06/2002 à 16:08. (lien). Évalué à -3.Effectivement, Java évolue et c'est très bien pour ses utilisateurs mais Java n'est peut-être pas le langage à promouvoir tant "philosophiquement" que techniquement car on peut ajouter toutes les libs du monde, on ne changera pas le concept de départ (JVM).
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 (page perso, ) le 04/06/2002 à 09:10. (lien). Évalué à 2.Ce qu'il y a de génial dans ce genre de post, c'est l'absence totale de référence à des faits, le FUD par excellence.
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 () le 02/06/2002 à 16:41. (lien). Évalué à 7.heu ... sans vouloir te contrarier ... un langage évolue .
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 anonyme512 () le 03/06/2002 à 15:00. (lien). Évalué à 4.en effet, tu ne connais rien à Java ni à JAVA...
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 () le 03/06/2002 à 23:26. (lien). Évalué à 3.Si demain je devais préconiser une solution performante, fiable, scalable (horizontalement et verticalement), devant s'intégrer dans un existant non homogène et être deployée dans un environnement haute dispo (clustering, load-balancing, fail-over), je ne vois pas bien (sauf par incompétence) comment ne pas envisager la solution Java. Telle est la réalité du monde de l'entreprise. Alors pourquoi pas ne pas profiter plutôt de l'occasion pour essayer de sensibiliser les décideurs aux initiatives du libre ? L'évangélisation est un processus lent :)
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.
- Réplication de session en mémoire http://www.theserverside.com/resources/article.jsp?l=Tomcat(...)
-
[^]Re: La Javanaise en question
Posté par Anonyme () le 03/06/2002 à 23:33. (lien). Évalué à 0.Y a un conteneur d'EJB libre ?
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 () le 04/06/2002 à 09:01. (lien). Évalué à 1.Ben bien sûr qu'il y a des conteneurs d'EJB libres : JOnAS et JBoss sont tous deux sous licence LGPL. Quant à Tomcat, il s'agit effectivement uniquement d'un moteur de servlet. Et c'est bien pour cela que je parlais de lui adjoindre JOnAS...
- Jakarta Tomcat http://jakarta.apache.org/tomcat/(...)
- JBoss http://www.objectweb.org/jonas/(...)
- JOnAS http://www.objectweb.org/jonas/(...)
- Intégrer Tomcat et JOnAS http://www.objectweb.org/jonas/doc/howto/Tomcat.html(...)
-
-
[+] [^]Re: La Javanaise en question
Posté par PLuG () le 04/06/2002 à 07:26. (lien). Évalué à -1.Je suis d'accord avec toi, la maturité des solutions a base JAVA disponibles aujourd'hui font que ces solutions sont incontournables.
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 (page perso, ) le 04/06/2002 à 09:25. (lien). Évalué à 2.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.
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 () le 04/06/2002 à 09:16. (lien). Évalué à 3.Si je ne m'abuse la v3 de JBOSS (conteneur d'EJB et plus si affinités) supporte déjà le clustering:
http://www.jboss.org/online-manual/HTML/ch13s144.html(...)
-
-
[^]Re: La Javanaise en question
Posté par vrm (page perso, ) le 04/06/2002 à 07:05. (lien). Évalué à 2.hehe :)
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 (page perso, ) le 04/06/2002 à 09:30. (lien). Évalué à 1.Pour un bench php vs servlet, cf les papiers disponibles sur http://www.cs.rice.edu/CS/Systems/DynaServer/index.html(...)
-
-
[^]Re: La Javanaise en question
Posté par boubou (page perso, ) le 04/06/2002 à 09:22. (lien). Évalué à 3.je suis mal placé pour en parler (pas assez pratiqué)
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 () le 05/06/2002 à 08:20. (lien). Évalué à 0.Je parle de l'architecture JAVA que je connais, pas du langage que je n'ai pas assez pratiqué.
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 (page perso, ) le 05/06/2002 à 09:31. (lien). Évalué à 1.Je ne veux pas me mêler de votre discussion, mais ta réponse ici c'est un peu n'importe quoi ... Je l'ai relue trois fois mais je ne vois pas ou tu veux en venir ... Et je ne comprends toujours pas la comparaison avec W2K/IIS ... Ah oui, dernière chose, c'est Java pas JAVA, ce n'est pas un acronyme ;-)
--
Vache qui rit, à moitié dans son lit
-
-
-
-
-
[^]Re: La Javanaise en question
Posté par Gérald Quintana () le 03/06/2002 à 10:21. (lien). Évalué à 3.Il vrai que Java n'est pas la panacée en matière de performances. Mais je constate qu'aujourd'hui beaucoup de sites web sont réalisés avec du PHP (ou ASP ou JSP) qui est, si je ne m'abuse, interprété.
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 (page perso, ) le 03/06/2002 à 10:50. (lien). Évalué à 4.Aaargh !!! J'ai failli m'étouffer en lisant ça ... Ca m'apprendra à manger en lisant LinuxFr ... Je ne peux pas laisser passer ça ...
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à) ...--
Vache qui rit, à moitié dans son lit-
[^]Re: La Javanaise en question
Posté par boubou (page perso, ) le 04/06/2002 à 09:38. (lien). Évalué à 1.Parmi les langages orienté objets qui permettent de faire des choses très évoluées, Java est plus facile d'accès. Voilà maintenant 5 ans que j'enseigne la programmation avec Java comme premier langage (cf http://cours.ufrmd.dauphine.fr/java(...) ) et les élèves apprennent clairement plus rapidement que quand on faisait du Pascal Object. De plus, on faisait dans ma fac la formation aux concepts objets en C++ il y a quelques années. Depuis qu'on est passé à Java, ça se passe beaucoup mieux.
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 (page perso, ) le 05/06/2002 à 09:37. (lien). Évalué à 2.Oui le langage est parfait pour apprendre l'OO car très haut niveau et très orienté objet (pas de problèmes de pointeurs ni de "bricolages" comme en contient le C++). Mais pour maitriser son utilisation (les threads, les classloaders, la sécurité, ... ne sont pas tjrs facile à comprendre d'un 1er abord) et la plateforme, ça demande bcp de connaissance qui demandent bien entendu bcp de temps.
Enfin, on est d'accord, la plateforme Java est formidable :-)--
Vache qui rit, à moitié dans son lit
-
-
-
-
[^]Re: La Javanaise en question
Posté par Timbert Benoît () le 03/06/2002 à 10:24. (lien). Évalué à 2.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 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 (page perso, ) le 03/06/2002 à 14:50. (lien). Évalué à 2.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)
Ç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 () le 03/06/2002 à 15:15. (lien). Évalué à 2.Quand t'as besoin de temps de réaction très courts, tout en gérant plein de clients en même temps, des fois en Java (par rapport à d'autres technologies) tu as du mal à suivre . Des grosses application genre la bourse (sur des gros sites) sur internet par exemple tu peu avoir des problèmes de performance si tout est en Java. Bon en fait ça fait pas beaucoup de sites qui seraient vraiment génés par ça. C'est quand même dans des conditions extrêmes...
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 (page perso, ) le 04/06/2002 à 07:30. (lien). Évalué à 4.Que ceux qui ne veulent pas faire l'effort d'apprendre le Java fassent du python et laissent les autres tranquilles SVP ! Marre de ces trolls à la con.
Apprenez à programmer et vous verrez que le Java ca roulaize.
-
-
[^]Re: La Javanaise en question
-
-
[^]Re: La Javanaise en question
Posté par Guillaume POIRIER (page perso, ) le 01/06/2002 à 16:07. (lien). Évalué à 10.Personnellement, j'ai du mal avec Java. Je trouve que utiliser Java fait le jeu de Sun qui pousse ce langage au sein de son désormais célèbre bundle "matériel+langage+logiciel". Et visiblement bientôt OS puisque Sun compte développer une distrib linux ne fonctionnant que sur ces machines et a annoncé la convergence de ses stratégies Solaris/Linux.
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 (page perso, ) le 01/06/2002 à 16:18. (lien). Évalué à 0.Je ne peux te répondre concernant ces nouvelles distribs/OS car je n'ai pas trop creusé ce sujet. J'observe juste avec un peu d'angoisse toutes ces annonces de la part de grands groupes maitrisant plutôt bien leur communication et ce alors que Linux devient un OS d'entreprise de plus en plus polyvalent et donc dépassant largement l'utilisation classique de fire-wall, serveurs web ou serveurs de fichiers. J'espère que la FSF a les moyens financiers et juridiques : au cas où.
Peut être suis-je simplement parano ? :-)
- 1 pour ma folie-
[^]Re: La Javanaise en question
Posté par Neryel () le 01/06/2002 à 16:35. (lien). Évalué à 15.«J'espère que la FSF a les moyens financiers et juridiques : au cas où.»
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 (page perso, ) le 01/06/2002 à 17:22. (lien). Évalué à 3.Et si cela ne marche pas, il pourra toujours envoyer Cox avec une bonne vodka polonaise, voire éventuellement ESR avec un bon shotgun de derrière les fagots ;-)
-1 par mimétisme religieux
-
-
-
Classpath
Je ne comprends pas très bien pourquoi GNU Classpath et mentionné dans la news. Je ne le considère pas comme un framework parce que:
- 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 !
Rien que le titre, et on tombe dans un gros nid à troll entre Java/Non Java, ce qu'on retrouve un peu au début de l'article.
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)
Cette page a été générée par Templeet en 0.1415s (dont 0.0146 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.