Discussion :

[fxrobin]

imaginons une seule seconde que dans les 6 mois avenir il n'y ait plus de plateforme JAVA OpenSource et gratuite. Que Eclipse devienne payant et que NetBeans s'arrête. Que GlassFish soit abandonné au profit de WebLogic etc.

mais voilà, "What else" comme dirait George C. ?
PHP ? c'est pas franchement mieux et le spectre technique est loin d'être aussi complet que JAVA ?
.Net ? non merci ... trop propriétaire ...
Flex ? bof.

On se remet à faire du C++ sous Linux ? Pourquoi pas ... mais retour 15 ans en arrière.

Je ne trouve ça pas très responsable de la part de APACHE de quitter le navire. Justement, on attendait d'eux qu'ils soient la voix de la "communauté". En partant, la communauté est muette. Ce n'est donc pas un bonne nouvelle. Et ce "coup d'éclat" est pour moi complètement anti-productif.

je vais être exprès caricatural, mais ça ressemble plus à une cours d'école maternelle avec le gamin qui est parti boudé dans son coin dans l'espoir qu'on vienne le chercher ...

[kedare]

Ruby si tu veux rester dans le libre comme alternative à Java.
Tu a généralement des equivalents style rake pour ant, capistrano pour hudson, ferret pour lucene, rails pour le web, activerecord pour hibernate, etc.
J'ai pas trouvé d'autres solutions aussi complete et professionnelle en restant dans le libre.

[fxrobin]

Merci pour ces réponses kedare.

Mais ce n'est pas multi-plateformes. Personnellement ke développe sous linux ET sous Windows.

et mes build en intégration continue et tâches ant perso ? je les mets à la poubelle ? Non franchement, je ne vois rien à la cheville de la plateforme JAVA de nos jours. (est-ce un mal ou un bien, j'en ai fichtre aucune idée ...)

Tes solutions restent des alternatives intéressantes, mais trop "underground" à mon goût. Je ne connais pas encore d'applications stratégiques faites en Ruby dans les grandes entreprises. Ca reste du "lab" encore à mon sens.
Mais bon, Ruby pourquoi pas ... prometteur.

Seul défaut pour moi : interprété.
et je prends quoi comme éditeur Ruby ? NetBeans / Eclipse ??? : on se mord la queue. Et qu'on ne me dise pas Notepad++ ...

[kedare]

Mais ce n'est pas multi-plateformes. Personnellement ke développe sous linux ET sous Windows.

Heu, Ruby est multiplateforme, tu peu même le faire tourner sur la jvm ou la clr, si tu veux.
En IDE, les deux meilleurs que je connais pour ruby et rails sont Netbeans, et ceux de Jetbrain (IntelliJ Idea et Rubymine)

et mes build en intégration continue et tâches ant perso ? je les mets à la poubelle ? Non franchement, je ne vois rien à la cheville de la plateforme JAVA de nos jours. (est-ce un mal ou un bien, j'en ai fichtre aucune idée ...)

Rake et Capistrano font tout ça.
Hudson est compatible ruby
ainsi que CruiseControl par exemple.

Tes solutions restent des alternatives intéressantes, mais trop "underground" à mon goût. Je ne connais pas encore d'applications stratégiques faites en Ruby dans les grandes entreprises. Ca reste du "lab" encore à mon sens.

Ca n'a rien d'underground, c'est une des solutions les plus utilisés pour le web depuis quelques années.. (Symantec, Linkedin, Pixar, New York Times, github, twitter, et j'en passe)
Si tout le monde pensait comme toi on ferais encore tous nos sites en perl via CGI.

[Traroth2]

Si Oracle met du fric dans le développement de java , le choix d'apache n'aura que peu de conséquence sur les entreprises ayant choisit java , tant que ce dernier reste open source.
Si le langage a pris du retard c'est peut être parce que trop de monde avait son mot à dire dessus.
Si java suit le modèle Csharp dotnet tout en restant multiplateforme et ouvert , il aura de gros avantages sur la solution microsoft.

Mieux vaut savoir de quoi on parle. Si Apache abandonne réellement Java, ça sera une véritable catastrophe. Je crois que tu n'es pas conscient de l'importance des projets Apache dans le monde Java : ActiveMQ, Ant, Axis, Camel, Cassandra, Commons, Continuum, Derby, Geronimo, Hadoop, Harmony, Jackrabbit, James, Log4J, Lucene, Maven, MyFaces, OpenEJB, OpenJPA, Pivot, POI, Roller, Shindig, Struts, Tapestry, Tomcat, Turbine, Velocity, Wicket, Xalan, Xerces, Batik, FOP... Pour ne citer que les plus importants (àmha) . En fait, il y en a tellement qu'une telle décision de la part d'Apache est peu probable, puisque ça voudrait dire qu'ils devraient abandonner les 9/10emes de leurs projets. Bon, je ne pense pas qu'ils disparaitraient, de toutes façons, mais ils devraient tous se trouver une autre forge logicielle, comme iBatis récemment, ça risque de forker dans tous les sens, etc. Des mois et des mois de bordel ! En plus, à la suite d'Apache, il y a un risque pour que d'autres acteurs suivent : Google, peut-être (GWT, Guice, Guava), mais devant la plaisanterie que représente l'open-source et le libre pour Oracle, il va falloir regarder ce que vont faire les autres acteurs du domaine : la FSF (Classpath et GCJ, et par ricochet IcedTea), ObjectWeb (Jonas, ASM, Spago, XWiki), VMWare (Spring, Groovy), RedHat (JBoss). Il est parfaitement possible que tout ou partie de ces acteurs voient en la politique d'Oracle une menace. La réaction logique n'est évidemment pas de stopper tous les projets en Java, mais de regarder les autres choix pour les nouveaux projets, et de voir s'il est possible de migrer les projets existants sur d'autres technologies. Bref, ce qui est en train de se passer peut très bien marquer le début d'un lent déclin pour Java.

Et tout ça sans aucun bénéfice en retour. Ceux qui accusent Apache d'être responsable du retard pris par Java se plantent complètement. Ce retard n'était dû qu'à l'incapacité de Sun de mener le projet à terme, et la capacité d'Oracle à faire mieux (ou pas) n'a rien à voir avec Apache !

[fxrobin]

Non non, il y a une mauvaise compréhension de ce que je veux dire.

Je veux dire que je fais du JAVA, JSF2, EJB 3, Spring Security, Spring IOC.
Certes "définir" ce genre de "stack" n'est pas forcément très simple mais une fois tout cablé, on est très productif.

Je sais parfaitement que ruby est multiplateforme (mais toutes tes solutions ne le sont pas, CORRECTION : okay vu je viens de voir que ces solutions étaient écrites en Ruby ... donc Multi-Pl, désolé), bien que j'avoue ne pas avoir totalement pris le temps de "tenter" de m'y mettre. On gomme pas 13 ans de dev Java comme ça (j'ai commencé JAVA en 1997 et le dev tout court en 1985).

Tiens, puis au fait, j'suis en train de faire un p"tit shoot'em up en JAVA ...
J'peux faire ça aussi en Ruby ? je crois pas. Et non j'en referais
plus en C++ Assembleur comme je le faisais avant.

Et à part Ruby ? (d'ailleurs ton lien est hyper intéressant merci !)

Bah rien.

non franchement, si on a plus JAVA, on fait quoi ?
Pas qu'il n'existe pas qqch d'autre, mais d'aussi polyvalent je ne vois rien d'autre à l'heure actuelle encore.


Tout ça pour dire que je trouve la réaction de "Apache" un peu immature. On quitte pas le navire comme ça. Surtout quand on a raison.

[kedare]

Et à part Ruby ? (d'ailleurs ton lien est hyper intéressant merci ! mais ça reste payant : je n'adhère plus depuis longtemps aux langages / frameworks payants)

Quoi donc de payant ? Tous est Open-Source sur Ruby..
Si tu parle des solutions Jetbrains, tu peux t'en passer sans problème et prendre Netbeans.
Si non je vois pas de problème pour faire un shoot'm'top en ruby, même si c'est pas son domaine de prédilection

[fxrobin]

Quoi donc de payant ? Tous est Open-Source sur Ruby..
Si non je vois pas de problème pour faire un shoot'm'top en ruby, même si c'est pas son domaine de prédilection

oui je viens de voir ça en creusant un peu plus.
(edit : euh Capistrano : Operating system POSIX (Linux, OpenBSD, Mac OS X, c'est pas vraiment "multiplateforme" quand même, manque Windows ;-) )

pour une appli type Shoot'em up (ça reste un exemple), il faut quand même qqch de performant et "temps réel". Un langage interprété s'y prête guère, normalement (maintenant ... tout change)

Moi y'a juste un truc qui me rebute sur Ruby, c'est sa syntaxe.
C'est laid. J'ai l'impression de faire du Basic 128 sur mon vieux Thomson TO8.
Cela reste subjectif, je te l'accorde.

[kedare]

pour une appli type Shoot'em up (ça reste un exemple), il faut quand même qqch de performant et "temps réel". Un langage interprété s'y prête guère, normalement (maintenant ... tout change)

Il y a aucun problème, les dernières versions de Ruby (1.9+) sont très performantes (plus que Python par exemple)
Puis de toute façon si c'est un binding, tous le code intensif est langage natif (C ou C++), donc ca pose pas de problème. (Ca fonctionne aussi comme ça aussi avec les binding JOGL, LWJGL, etc)

Pour le syntaxe oui c'est une question de gout, mais ça à l'avantage d'être extrêmement flexible (pratique pour les DSL)

[fxrobin]

Pour recentrer le sujet, quand même depuis les rachats successifs de BEA puis de SUN, c'est un vrai footware dans le monde "JAVA". Et je reste très inquiet, même avec des alternatives ponctuelles ...

[Firwen]

Il y a aucun problème, les dernières versions de Ruby (1.9+) sont très performantes (plus que Python par exemple)
Puis de toute façon si c'est un binding, tous le code intensif est langage natif (C ou C++), donc ca pose pas de problème. (Ca fonctionne aussi comme ça aussi avec les binding JOGL, LWJGL, etc)

J'utilise Ruby pour mon site personnel, et c'est pas non plus un foudre de guerre, même en version 1.9 n'exagérons rien :p

les benchs parlent d'eux même : http://shootout.alioth.debian.org/u3...arv&lang2=java

Son gros avantage, réside dans le mapping des libs C qui se fait trés facilement, beaucoup plus que python, et sa facilité d'intégration des webservices.

[fxrobin]

merci firwen pour ce super lien de "benchmarks"

A la limite je pense que Scala répondrait mieux à ce besoin de solution alternative.

D'ailleurs on peut lire ça :
"For example, at Twitter, the social networking service, Robey Pointer moved their core message queue from Ruby to Scala. This change was driven by the company's need to reliably scale their operation to meet fast growing Tweet rates, already reaching 5000 per minute during the Obama Inauguration. Robeys thinking behind the Twitter Kestrel project is explained in the developers live journal. His concise 1500 lines of Scala code can be seen as he has generously made them available as an open source project."

Et je trouve le code beaucoup plus élégant.

[kedare]

J'utilise Ruby pour mon site personnel, et c'est pas non plus un foudre de guerre, même en version 1.9 n'exagérons rien :p

les benchs parlent d'eux même : http://shootout.alioth.debian.org/u3...arv&lang2=java

Son gros avantage, réside dans le mapping des libs C qui se fait trés facilement, beaucoup plus que python, et sa facilité d'intégration des webservices.

Je parlais des performances en comparaison aux anciennes versions..
T'a pas grand chose de plus rapide qu'un java en mode serveur..

fxrobin: Scala, ça reste du Java, donc bon il y a pas trop d'interet de migrer dans ce cas la..

[fxrobin]

Oui, effectivement. Mais rien ne lie je langage à sa plateforme d'exécution. Aujourd'hui le moteur Scala est en Java. Mais rien n'empêche de faire une autre implémentation, tout comme Quercus est capable d'interpréter du PHP sous JAVA, par exemple.

Mais je te l'accorde, c'est pas dans les cartons.

[camus3]

Et tout ça sans aucun bénéfice en retour. Ceux qui accusent Apache d'être responsable du retard pris par Java se plantent complètement. Ce retard n'était dû qu'à l'incapacité de Sun de mener le projet à terme, et la capacité d'Oracle à faire mieux (ou pas) n'a rien à voir avec Apache !

la plupart des solutions listées ont des alternatives commerciales. A un moment il faut arrêter de croire que tout doit être gratuit. L'open source est important , mais le "libre" a couté de l'argent à quelqu'un à un moment donné.
De tout façon on s'oriente vers un modèle purement payant pour Java , à moyen terme , c'est évident. Oracle veut faire de l'argent avec , et vu les prix de leur SGBD ...
Solutions alternatives ? C++

[air-dex]

Ceux qui accusent Apache d'être responsable du retard pris par Java se plantent complètement. Ce retard n'était dû qu'à l'incapacité de Sun de mener le projet à terme, et la capacité d'Oracle à faire mieux (ou pas) n'a rien à voir avec Apache !

Oui, Apache n'est pas responsable de ce retard, à la vue de ses contributions.

Sauf que maintenant le rôle du boulet est en train de changer de camp. C'est désormais Apache qui ne veut pas des nouvelles versions de Java tant désirées sous prétexte que "Oracle, c'est caca car ils n'aiment pas le libre et ils veulent le tuer comme M$ ". Si Apache ne met pas ses contributions "Java 7 ready", alors ils se tirent une balle dans le ventre. En effet, l'obsolecence des outils d'Apache déprécierait Java (imaginez Ant incapable de compiler pour Java 5 ou 6 , par exemple) et la chute de Java sera aussi la leur (sauf s'ils vont vendre leur âme à Google).

Bien des fois le libre a fait avancer les choses (cf. Firefox et Apache). Mais là ses aspirations philanthropiques sont en train de freiner une technologie majeure de l'informatique.

[B.AF]

Peut être que ce sera aussi le moment de faire rentrer d'autres membres tout aussi bons.

Apache a fait son temps, quelques outils sont bons, mais bon ils ont aussi fait struts.


En même temps rien n'est immuable dans l'informatique, et finalement on aura vu Microsoft s'ouvrir à l'open source et au communautaire, ou du moins passer de la monarchie à la démocratie républicaine et on a vu Java devenir un alter ego commercial d'un produit Microsoft.
Je pense que quand J# fut pensé, c'était la plus belle des dystopies au fond...:-)

Bref, je prends la chose avec humour, mais personnellement ce qui m'intéresse le plus c'est de savoir que Java va perdurer. Je rejoins _skip sur le fait que je me fous qu'il y a 1 ou n JVM, 1 ou n ORM, 1 ou n IDE.
Java à démocratisé le développement en offrant un paradigme objet simple et intelligent. Il s'est complexifié grace à une communauté active, mais je ne sais pas s'il est possible de vraiment simple d'aborder Java aujourd'hui.
Pour l'aborder on parle d'un ensemble de Framework à assembler et à manipuler. Et ça c'est entre autres pour moi le vrai problème.

Déjà la communauté a généralisé des patrons dangereux (typiquement Hibernate reste quand même la plus grande bombe à retardement architecturale inventée par ses mauvais usages) voir inutiles (typiquement Spring, devenu un grand fourre tout bourré de code ignoble).
Pourtant il y a aussi des petites merveilles (les enums java j'adore, les annotations, Guice, Eclipse RCP, Jdbc, Velocity, et Lucene pour citer ceux que j'aime au quotidien).

Oui on peut faire une application performante, testable et bien architecturée en Java sans Spring, sans Tomcat et sans Nhibernate. Oui on peut.

Et puis Java fut inventé, pourquoi serait-ce impossible qu'autre chose apparaisse aujourd'hui ?

On voit bien aujourd'hui sur d'autres technos (ruby entres autres) que la question qui se pose est plutôt comment gérer une productivité libre d'éléments d'une pile technologique sans la mettre en péril. Moi je crois qu'une techno doit conserver une petite capitainerie pour éviter la cacophonie. Là j'ai envie de dire que je perçois tout ça comme la conséquence d'absences de décisions pendant des années (dont tout le monde s'est plus ou moins étonné) et là boum un preneur de décision qui fait le chien dans le jeu de quille....et tout le monde s'est plus ou moins étonné.

[_skip]

Java à démocratisé le développement en offrant un paradigme objet simple et intelligent. Il s'est complexifié grace à une communauté active, mais je ne sais pas s'il est possible de vraiment simple d'aborder Java aujourd'hui.
Pour l'aborder on parle d'un ensemble de Framework à assembler et à manipuler. Et ça c'est entre autres pour moi le vrai problème.

Déjà la communauté a généralisé des patrons dangereux (typiquement Hibernate reste quand même la plus grande bombe à retardement architecturale inventée par ses mauvais usages) voir inutiles (typiquement Spring, devenu un grand fourre tout bourré de code ignoble).
Pourtant il y a aussi des petites merveilles (les enums java j'adore, les annotations, Guice, Eclipse RCP, Jdbc, Velocity, et Lucene pour citer ceux que j'aime au quotidien).

Oui on peut faire une application performante, testable et bien architecturée en Java sans Spring, sans Tomcat et sans Nhibernate. Oui on peut.

Normalement on devrait savoir que quelque chose cloche dans le choix d'une techno quand, pour un simple site de blog minable, des tutoriaux de 15 pages sont nécessaires . Avec au final autant de lignes de XML que de code java, un mode de fonctionnement limite incompréhensible et des POJO qui vous explosent soudainement à la figure.

[B.AF]

Normalement on devrait savoir que quelque chose cloche dans le choix d'une techno quand, pour un simple site de blog minable, des tutoriaux de 15 pages sont nécessaires . Avec au final autant de lignes de XML que de code java, un mode de fonctionnement limite incompréhensible et des POJO qui vous explosent soudainement à la figure.

Il y a les mêmes en .Net, Ruby et Php. Un mauvais concepteur, ça reste un mauvais concepteur même avec une bonne techno.

Mais effectivement là ton truc, c'est du "code smell"...En même temps, j'étais curieux de savoir de quoi tu parlais et je suis tombé là dessus :
Blog + java

Spring et seam pour faire un blog...Arf...Mais le mieux, c'est struts 1 à la fin....lol

De quoi tu as besoin de plus ??????????

[Philippe Bastiani]

Ils sont pas fous chez Apache: ils ne vont qu'en même pas se tirer un balle dans les pieds en retirant leur soutien à 90% de leurs produits ! C'est bien ces produits qui font l'image d'Apache, non ? C'est bien ces produits qui permettent à Apache d'être soutenu financièrement par des groupes comme Microsoft, Yahoo, Google, IBM, HP, ..., et même je crois FaceBook !

Peut être que ce sera aussi le moment de faire rentrer d'autres membres tout aussi bons.

Oui mais qui est suffisamment représentatif dans le communauté ?

Apache a fait son temps, quelques outils sont bons, mais bon ils ont aussi fait struts.

Sauf que Struts n'est pas un produit Apache... mais, qu'il a été donné à la fondation... comme la plupart des autres outils d'ailleurs.
Et soit disant... passant en 2000 qu'elle était l'alternative ?