Nous n'avons pas essayé de coller aux sacro-saints « standard J2EE entreprise », mais nous nous sommes plutôt demandé : « comment simplifier le développement d'application Web avec Java, d'ordinaire si lourd ? »
Nous sommes arrivés à un framework Java MVC simple avec quelques spécificités :
- Play! travaille directement avec les fichiers sources (.java) et non avec des classes compilées (.class). Les phases de compilation et de déploiement sont donc inexistantes ce qui simplifie réellement le cycle de développement ;
- Le framework n'utilise pas l'API Servlet. À la place nous avons utilisé un framework HTTP asynchrone basé sur mina (http://mina.apache.org). D'une part l'API est plus agréable à utiliser que l'API Servlet car elle donne directement accès à la pile HTTP, d'autre part, en terme de performances cela permet au moteur de traiter plus de requêtes avec moins de thread, donc de mieux utiliser les ressources ;
- Les rapports d'erreur essaient d'être le plus précis possible. À la place des traditionnelles StackTrace Java illisibles, Play! affiche directement l'erreur avec le code source associé et la ligne incriminée ;
- Un modèle entièrement Stateless (sans état sur le serveur) qui convient bien mieux au Web et permet par exemple de gérer plus simplement les traditionnels problèmes de boutons Back ou Refresh... En outre, cela permet de distribuer une application Play! sur plusieurs JVM ou plusieurs serveurs de manière naturelle ;
La version courante n'est pas encore finale mais largement assez stable pour créer de vraies applications et les mettre en production. Le tutoriel vous permettra de vous faire rapidement une idée de ce qu'est une application Play!
Aller plus loin
- Play! (223 clics)
- Vue d'ensemble (96 clics)
- Tutoriel (117 clics)
- Launchpad (22 clics)
- Java sur dmoz (130 clics)
# asyncweb & streaming
Posté par vrm (site web personnel) . Évalué à 4.
Sinon au sujet des templates, pourquoi groovy plutôt qu'un langage dédié template type velocity/freemarker ?
[^] # Re: asyncweb & streaming
Posté par ★★★ ★★ . Évalué à 5.
L'upload de gros fichiers ne pose aucun problème. Le fichier envoyé est d'abord écris sur disque avant d'être passé à l'application qui peut le manipuler comme elle veux.
Au sujet du langage de template, nous avions besoin d'avoir complètement la main sur la syntaxe et les possibilités. Nous avons donc réécris un langage de template ad-hoc. Mais pour ne pas repartir de trop bas, nous avons utilisé groovy comme langage de base. C'est également très facile d'implementer un langage à base de tag en utilisant les closures de groovy. Au final parser+compiler+renderer ne depassent pas quelques centaines de lignes de code ...
[^] # Re: asyncweb & streaming
Posté par vrm (site web personnel) . Évalué à 5.
response.setContent(IoBuffer.wrap(file.content()));
Pour l'upload pareil, à un moment Asyncweb va remplir le IoBuffer qui sert de content pour HttpRequest et donc manger un gros buffer de la taille du fichier.
Je préfère prévenir :) C'est un problème d'asyncweb que je pense essayer de résoudre avant décembre.
Sinon je vois que vous utilisez MINA-2.0.0M2, il y a une grosse régression au niveau des perfs (https://issues.apache.org/jira/browse/DIRMINA-609 ), je vous conseille de passer sur M3 avec le dernier snapshot d'asyncweb-common.
[^] # Re: asyncweb & streaming
Posté par taldius . Évalué à 5.
C'est un truc qu'on avait identifié rapidement. Donc, du coup on a fait 2-3 hacks dans asyncweb pour streamer dans des fichiers temporaires quand ça devient trop gros. Et il reste dans la todo-list de remonter ces hacks au projet si ça les interesse. Enfin je devrais peut-être dire "tu", vu ta page perso et ton message :) Sauf erreur/oubli, on a pas ce problème là.
Sinon oui, faut qu'on essaye le M3, mais déjà les performances entre la version précédente de play (tomcat embed) et celle ci (mina+asyncweb), ya pas photo. On peut y aller au "ab -c 100", ca encaisse sans broncher.
# OSGi
Posté par vrm (site web personnel) . Évalué à 1.
[^] # Re: OSGi
Posté par ★★★ ★★ . Évalué à 2.
[^] # Re: OSGi
Posté par vrm (site web personnel) . Évalué à 1.
# Pas mal...
Posté par Nicolas Blanco (site web personnel) . Évalué à -10.
[^] # Re: Pas mal...
Posté par ★★★ ★★ . Évalué à 7.
Je ne suis pas un intégriste Java et franchement si j'ai le choix je préfère travailler en Python qui est clairement un langage bien meilleur. Mais souvent on n'a pas le choix car Java est un langage très utilisé surtout dans le monde professionnel. Donc on avait vraiment besoin d'avoir un framework Java à la hauteur.
Après il faut être honnête, si Java a des défauts par rapport aux langages dynamiques style Ruby ou Python, il a aussi ses avantages : un excellent eco-système OpenSoure, de bons outils de développement, le typage statique n'a pas que des inconvénients (détection de nombreux problèmes à la compilation), excellents debuggeurs, excellente virtual machine et performances ...
Donc Play! ne s'oppose pas directement à RubyOnRails ou Django mais si vous devez développer en Java c'est une piste à explorer sérieusement ....
[^] # Re: Pas mal...
Posté par collinm (site web personnel) . Évalué à 0.
un peu d'argumentation svp serait bien...
www.solutions-norenda.com
[^] # Re: Pas mal...
Posté par BAud (site web personnel) . Évalué à 3.
si Java [...] il a aussi ses avantages [...] excellents debuggeurs, excellente virtual machine et performances ...
[^] # Re: Pas mal...
Posté par vrm (site web personnel) . Évalué à 4.
[^] # Re: Pas mal...
Posté par ★★★ ★★ . Évalué à 6.
Mais disons que personnellement juste au niveau langage, je trouve que Python et bien plus puissant et plus riche que Java. Après ça peut être un avantage ou un inconvénient... suivant dans les mains de qui on met le langage ...
Par exemple des choses qui sont très simple à implementer en Python comme retrouver le nom des variables locales ou binder directement les données HTTP aux paramètres de fonction ont été un casse tête à implémenter en Java. Mais avec de la manipulation de byteCode et un peu de magie noire ont s'en sort toujours ...
[^] # Re: Pas mal...
Posté par Larry Cow . Évalué à 2.
Le "hic", c'est que si l'on doit développer en Java, c'est généralement avec un environnement donné (Tomcat, ...). Le cas où l'on peut se permettre de faire ce qu'on veut en Java, mais forcément en Java, ça ne doit pas être le plus fréquent.
Mais ça reste sympa de voir un framework Java qui ne ressemble pas aux usines à gaz habituelles.
[^] # Re: Pas mal...
Posté par ★★★ ★★ . Évalué à 3.
Et en forçant un peu on peut quand même plus facilement convaincre un client qui a tout en J2EE d'utiliser un framework Java même si les APIs ne sont pas les mêmes que d'habitude, plutôt que de le convaincre d'utiliser un nouveau langage. Utiliser un nouveau langage ça change beaucoup de chose pour une équipe de développement. Là avec Play! on peut quand même capitaliser sur les compétences Java des développeurs, les IDEs (Netbeans ou Eclipse) les libs Java internes, une partie de l'infra d'execution ....
En plus on commence à voir quelques solutions Java dites "entreprise" qui s'éloignent de plus en plus de J2EE. Par exemple le Spring application Server ( http://www.springsource.com/products/suite/applicationplatfo(...) ), ou Websphere Smash ( http://www.projectzero.org/ ).
Pour moi si Java a une chance de s'en tirer c'est sans les piles J2EE historiques qui n'ont rien compris au Web ...
[^] # Re: Pas mal...
Posté par Nicolas Blanco (site web personnel) . Évalué à -2.
http://www.pragprog.com/titles/fr_j2r/from-java-to-ruby
http://www.pragprog.com/titles/fr_r4j/rails-for-java-develop(...)
[^] # Je marche dedant
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Sauf que java est déjà utilisé/utilisable en production. Rails pas encore.
[^] # Re: Je marche dedant
Posté par srm . Évalué à 7.
Et pas utilisable ?
Diantre, faut que j'aille dire ça à plein de monde alors, ils vont en faire une tête en sachant que leur site en prod sous Rails ne marche pas où n'est pas utilisable.
[^] # Re: Je marche dedant
Posté par Mithfindel (site web personnel) . Évalué à 3.
Attention, qu'on ne me fasse pas dire ce que je n'ai pas écrit: je conçois parfaitement qu'on puisse faire plein de choses bien avec Rails et qu'il en existe de parfaitement viables (voire rentables). Juste que je me vois mal décrocher des affaires en proposant ça alors que la concurrence propose du Java EE. Aux dernières nouvelles, les gens qui cherchent des compétences Rails sont des personnes éclairées (je n'ai pas dit illuminées ;) ), le client moyen il cherchera du Java - voire du .Net s'il est corrompu jusqu'à la moelle ou du PHP s'il ne jure que par (L|W)AMP.
[^] # Re: Je marche dedant
Posté par Nicolas Blanco (site web personnel) . Évalué à 6.
"Va essayer de vendre du Linux pour faire du poste client et on en reparle.
Attention, qu'on ne me fasse pas dire ce que je n'ai pas écrit: je conçois parfaitement qu'on puisse faire plein de choses bien avec un desktop Linux et qu'il en existe de parfaitement viables (voire rentables). Juste que je me vois mal décrocher des affaires en proposant ça alors que la concurrence propose du Microsoft Windows. Aux dernières nouvelles, les gens qui cherchent des compétences en desktop Linux sont des personnes éclairées (je n'ai pas dit illuminées ;) ), le client moyen il cherchera du Windows ou du Mac s'il ne jure que par Apple."
Pour résumé, c'est pas parce qu'en France, peu de boîte proposent encore du progiciel ou des applis intranet qu'il ne faut rien faire et fermer les yeux sur cette techno. Au contraire, aujourd'hui Rails à tout pour lui !
Le nombre d'intranet bien pourris en PHP fait main par un gars dans son garage sans aucune structure que j'ai pu voir en entreprise en témoigne. Le nombre de bibliothèques d'excellente qualité qui permettent une excellente intégration en entreprise écrites en Ruby aussi. Il commence a y avoir de plus en plus d'applis Rails libres, en plus des tonnes en SAS comme celles de 37signals.
http://www.opensourcerails.com/
Sans compter que récemment le fameux troll de : c'est dur de déployer une appli Rails est tombé à l'eau avec la sortie de mod_rails qui permet un déployement sécurisé sur Apache 2 en 2 lignes de conf.
[^] # Re: Je marche dedant
Posté par Joris Dedieu (site web personnel) . Évalué à 4.
Là c'est toi qui marche dedant.
C'était juste un moyen trollesque de faire remarquer qu'il y a un écosystème java qui n'existe pas encore avec rails.
# Wicket
Posté par franck villaume (site web personnel) . Évalué à 2.
cf http://wicket.apache.org
[^] # Re: Wicket
Posté par ⌨ ☕ . Évalué à 1.
[^] # Re: Wicket
Posté par franck villaume (site web personnel) . Évalué à 4.
Maintenant, ce n'est pas la rapidité de création de la première application presque vide qui m'intéresse mais la facilité de réutilisation des éléments et la simplification de la programmation.
Wicket = pure POJO + html + css.
Wicket = 0% xml
[^] # Re: Wicket
Posté par ★★★ ★★ . Évalué à 4.
Wicket a un modèle statefull dans lequel chaque page est représenté par un modèle objet en mémoire qu'on retrouve de requête en requête et qu'on manipule de manière complètement objet. En gros Wicket c'est JSF correctement implémenté.
Play! est un framework purement stateless, dans lequel chaque requête est complètement indépendantedes autres. C'est le même modèle que les frameworks type Rails, Django ou Symphony.
Je pense pour ma part que le modèle de framework stateless est bien mieux adapté au Web, notamment parceque HTTP lui même est stateless. La gestion du bouton back, du refresh, du load balancing sont des problèmes difficiles à résoudre avec un framework statefull. Mais il faut bien avouer que les développeurs de Wicket font un excellent travail en essayant de régler tous ces problèmes au niveau du framework pour soulager les développeurs. Bon évidemment avec un framework stateless on n'a pas à les régler car c'est fait par construction.
Alors après c'est une question de goût entre les 2 architectures ....
Par contre le cycle de développement avec Play! est bien plus agréable avec le rechargement transparent des modifications et de bons rapports d'erreurs.
Et sinon http://www.playframework.org/manual/contents/fivecoolthings .
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.