Play!, un autre framework web Java

Posté par (page perso) . Modéré par j.
Tags :
18
4
sept.
2008
Java
Play! est un framework de développement d'application Web en Java un peu à contre-courant des framework Java classiques.

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 ;
Le framework est bien sûr Open Source, distribué sous licence Apache 2 et hébergé sur Launchpad.

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!
  • # asyncweb & streaming

    Posté par (page perso) . Évalué à 4.

    Connaissant bien Asyncweb, j'imagine qu'une page est entièrement généré en mémoire puis envoyées d'une seul bloc (pas d'envoi par chunk). Donc la génération de contenu un peu gros (plusieurs méga) doit être problématique ? De même que l'upload de gros fichiers à partir de formulaires ? En tout cas si vous avez du feeback a faire remonter sur Asyncweb (même si vous n'utiliser que la partie codec http) n'hésitez pas :)

    Sinon au sujet des templates, pourquoi groovy plutôt qu'un langage dédié template type velocity/freemarker ?
    • [^] # Re: asyncweb & streaming

      Posté par (page perso) . Évalué à 5.

      Dans le cas classique la génération d'une page se fait effectivement en mémoire. Pour des gros contenus, Play! passe par un mode spécial où le contenu est d'abord écrit sur disque. Puis le worker HTTP se débrouille pour l'envoyer sur le réseau ensuite.

      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 (page perso) . Évalué à 5.

        En regardant le code, lorsqu'un fichier est envoyé au client je vois que le fichier est chargé et wrappé dans un IoBuffer, du coup, si le fichier fait 10MB, tu alloue 10MB dans le heap.

        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 . Évalué à 5.

          Yep,

          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 (page perso) . Évalué à 1.

    petite question, vu que cela utilise un classloader spécial pour la compilation des sources a la volé en utilisant le compilo d'eclipse, est-ce que c'est donné pour fonctionner dans un environement OSGi ?
    • [^] # Re: OSGi

      Posté par (page perso) . Évalué à 2.

      Oui on utilise le compilateur d'eclipse car il est facilement "embeddable". Mais c'est la chose que nous utilisons d'eclipse et pour l'instant Play! n'a aucun rapport avec OSGI (même si je vois bien l'idée au niveau de l'extensibilité du framework par module, mais pour l'instant nous avons un système d'extension très simple qui rempli parfaitement son rôle).
      • [^] # Re: OSGi

        Posté par (page perso) . Évalué à 1.

        La question c'était plutôt est-ce que votre classloader va merder complétement avec OSGi, je pense que le plus ismple pour moi c'est de le tester :)
  • # Pas mal...

    Posté par (page perso) . Évalué à -10.

    Mais plutôt que d'utiliser une pâle copie, autant utiliser l'original (http://www.rubyonrails.com).
    • [^] # Re: Pas mal...

      Posté par (page perso) . Évalué à 7.

      C'est vrai que Play! s'inspire franchement des frameworks que sont RubyOnRails ou Django. Mais Play! est un framework Java et des fois c'est important.

      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 (page perso) . Évalué à 0.

        "Python qui est clairement un langage bien meilleur."

        un peu d'argumentation svp serait bien...

        www.solutions-norenda.com

        • [^] # Re: Pas mal...

          Posté par (page perso) . Évalué à 3.

          il l'a donnée juste après ;-)
          si Java [...] il a aussi ses avantages [...] excellents debuggeurs, excellente virtual machine et performances ...
        • [^] # Re: Pas mal...

          Posté par (page perso) . Évalué à 4.

          l'objet de la news c'est pas non plus de troller sur java vs python, je vois bien ou tu veux en venir ;)
        • [^] # Re: Pas mal...

          Posté par (page perso) . Évalué à 6.

          Effectivement le but n'est pas de troller sur Java vs. Python. En plus c'est une discussion sans fin.

          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 . Évalué à 2.

        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 ....

        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 (page perso) . Évalué à 3.

          C'est vrai. Et ça a longtemps été un dilemme. Mais finalement si on veut faire quelque chose de plus simple que le J2EE standard finalement on est bien obligé de faire ce choix.

          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 (page perso) . Évalué à -2.

        Bon allez... pour les développeurs Java on peut toujours trouver un peu de saine lecture...

        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 (page perso) . Évalué à 2.

      Mais plutôt que d'utiliser une pâle copie, autant utiliser l'original (http://www.rubyonrails.com).

      Sauf que java est déjà utilisé/utilisable en production. Rails pas encore.
      • [^] # Re: Je marche dedant

        Posté par . Évalué à 7.

        Ah genre Rails est pas utilisé en prod ?
        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 (page perso) . Évalué à 3.

          Va essayer de vendre du Rails pour faire des applis intranet 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 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 (page perso) . Évalué à 6.

            Je la refais :

            "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 (page perso) . Évalué à 4.

          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
          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 (page perso) . Évalué à 2.

    quelle est l'avantage de ce framework par rapport à un framework tel que wicket ?
    cf http://wicket.apache.org
    • [^] # Re: Wicket

      Posté par . Évalué à 1.

      Essaye-donc les 2, tu verras. Pour installer Play! + faire tourner ta première appli c'est 5min chrono si tu es fatigué. Si tu mets plus de temps avec Wicket, tu as déjà un élément de réponse...
      • [^] # Re: Wicket

        Posté par (page perso) . Évalué à 4.

        Installer Wicket + faire sa première appli, c'est 1 minute maximum.
        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 (page perso) . Évalué à 4.

      En fait Play! et Wicket ne font pas exactement la même chose. Si dans les 2 cas le but est de créer une application Web les style d'architecture sont complètement différents.

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.