Sortie de Grails 1.0

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
1
5
fév.
2008
Java
Grails est un framework orienté web écrit en Java et Groovy et placé sous licence Apache. Il s'inspire fortement du framework Rails (Ruby on Rails) avec notamment la notion de convention (vs configuration) permettant de n'avoir que le minimum de configuration nécessaire, un vrai bonheur pour le développeur. Mais contrairement à Rails, Grails est complètement dans l'univers Java, le framework se repose ainsi sur des frameworks "stars" de Java comme Spring ou Hibernate lui donnant d'office une maturité évidente (sans parler du fait qu'il devient par la même occasion complètement "crédible" en entreprise).

La sortie de la version 1.0 risque de donner une nouvelle dimension au projet, et il suffit de regarder l'activité de la liste de diffusion pour réaliser à quel point ce framework a de beaux jours devant lui.

Le seul bémol concernerait la prise en charge des IDE. Il existe des greffons pour Eclipse et NetBeans mais encore trop jeunes. Le seul greffon vraiment avancé à l'heure actuelle est celui pour IDEA IntelliJ (IDE excellent mais qui n'est malheureusement pas OpenSource).

Aller plus loin

  • # Hum...

    Posté par  . Évalué à 8.

    Grails est complètement dans l'univers Java, le framework se repose ainsi sur des frameworks "stars" de Java comme Spring ou Hibernate lui donnant d'office une maturité évidente

    Trop gros, passera pas.

    • [^] # Re: Hum...

      Posté par  (site web personnel) . Évalué à 0.

      | sed -e 's/maturité/lourdeur/' ? ;-)

      • [^] # Re: Hum...

        Posté par  . Évalué à 6.

        en même temps on compare a ruby on rails, donc pour la lourdeur, ca devrait tenir la comparaison.

        • [^] # Re: Hum...

          Posté par  (site web personnel) . Évalué à 6.

          Je capte pas, vous parlez de lourdeur ? Vous avez déjà travailler avec Spring ? AOP IOC ?

          http://about.me/straumat

          • [^] # Re: Hum...

            Posté par  (site web personnel) . Évalué à 7.

            On peut effectivement considérer que généralement les stacks Java EE sont lourdes. Mais les frameworks comme Spring permettent justement d'avoir de la légèreté (terme qui reste à définir). Et c'est encore plus "léger" avec l'utilisation de Grails et du langage Groovy (à la place de Java): en gros on écrit beaucoup de moins de lignes de code, mais alors vraiment moins...

            Mais si vous avez d'autres frameworks web qui offrent autant de fonctionnalités que (G)rails tout en étant bien plus léger, n'hésitez surtout pas à nous en faire part ici..

    • [^] # Re: Hum...

      Posté par  (site web personnel) . Évalué à 1.

      Moi c'est cette partie que je préfère :

      >>> (sans parler du fait qu'il devient par la même occasion complètement "crédible" en entreprise)

  • # Pour les ide

    Posté par  . Évalué à 1.

    Rails n'est pas très bien loti non plus, NetBeans 6 est jeune et lourd, et bien que maintenant le plugin rails très débuggué comparé ce que c'était a la sortie de NetBeans 6, il faut toujours faire preuve de patience sur une machine dual core avec 2Go de ram (enfin je trouve, ca reste un avis personnel).

    Sans compter un bug bloquant pour moi : Swing n'arrive pas a utiliser le presse papier lorsque synergys est en route, donc tous les copier coller entre les machines sont en vrac, plutôt pénible quand on utilise une machine pour le dev et l'autre pour les docs.

    Aptana aussi n'est pas fini non plus, je me suis rabattu sur kdevelop, beaucoup moins intégré mais j'y trouve plus mon compte.

    Il reste bien le plugin vim pour rails qui apparemment est excellent, mais ca reste pour les amateurs, dont malheureusement je ne fait pas partie.

  • # Merci!

    Posté par  (site web personnel, Mastodon) . Évalué à 1.

    Oui, merci: une telle tranche de rire à 22:25 en plein debug, ça fait du bien. :)

    La gelée de coings est une chose à ne pas avaler de travers.

  • # Oui mais Grails c'est aussi Groovy...

    Posté par  . Évalué à 5.

    Salut,

    Grails est sans doute déjà un progrès par rapport à du Struts 1 et des JSP, mais personnellement je crois que JRuby on Rails a plus de sens. En effet, ça fait tourner le vrai Rails inchangé avec vraiment presque tous ces plugins (sauf de rares ayant des dépendances natives pas encore portées en Java), Rails 2.0 et ses nested resources URL si restful...

    On peut bien y utiliser une persistence Hibernate (avec ActiveHibernate par exemple ou directement) si vraiment on ne trouve pas son bonheur avec ActiveRecord sur les drivers JDBC. On peut aussi facilement appeler tout beans Spring pour y intégrer du J2EE à papa. On peut aussi bien sur appeler n'importe quel javabeans directement depuis le code JRuby et échanger avec, disons que Spring c'est just pour mieux gérer l'IOC legacy, en Ruby on peut faire plus simple et plus élégant.

    Grails c'est aussi la language Groovy dont les rumeurs sur les performances ne sont pas très bonnes; je crois que JRuby head fume bien Groovy. Sans compter que la génération de bytecode de Groovy est lente. Par ailleurs je ne crois pas que Groovy ait de compilation Just In Time comme JRuby dont c'est la force principale...

    Un des rares avantages transitoire de Groovy est qu'on peut appeler depuis Java des classes implémenter en Groovy et qu'elles sont de vraies classes Java. Mais un compilateur extra de JRuby vers Java va aussi se rapprocher de ceci très rapidemment. En gros il va aussi permettre de type (optionnellement) des objets Ruby pour le cas ou on les utilise depuis Java...

    Bref JRuby on Rails vaut le coup d'oeil, on se rapproche d'une maturité suffisante pour de la prod. Venez trainer sur #jruby si vous voulez en savoir plus, ça foisonne d'idées et de talents...

    Raphaël Valyi.

    • [^] # Re: Oui mais Grails c'est aussi Groovy...

      Posté par  . Évalué à 1.

      Oui, Groovy avec ses scripts qui mettent 3 minutes à s'exécuter ... et Groovy avec sa syntaxe certes compatible avec Java, mais aussi incompatible avec la beauté .... :)


      Et JRuby on Rails 2.0 est extrêmement abouti. D'ailleurs Raphaël, tu avais commenté sur mon (ancien) blog là dessus : http://www.cestari.info/2007/7/2/jruby-1-0-premi-egrave-re-e(...)

      Et depuis, la performance et la consommation mémoire s'est beaucoup améliorée.

      Cette appli JRoR devrait sortir très bientôt, contenue dans GlassFish. Et les performances sont là.

      Bref, y a de la place pour Grails, mais entre JRoR et Django on Jython, va falloir la jouer fine ;)

  • # Lift

    Posté par  . Évalué à 3.

    Je tiens à signaler un autre web-framework générant des Servlets Java à savoir : Lift.
    Ce projet est pour l'instant assez jeune mais progresse très rapidement, voici le site officiel : http://liftweb.net/

    PS: Je sais que les micro-benchmarks ne sont pas forcément significatifs mais ça fait quand même peur : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)

    • [^] # Re: Lift

      Posté par  . Évalué à 2.

      À noter que le framework lift se base sur le language Scala qui est un langage fonctionnel conçu pour la jvm. Apparemment (je ne me suis pas encore penché dessu) l'intégration des concepts FP<->OOP est vraiment excellente, pas un truc batard à la F#. Bref, à surveiller de très près...

  • # Grails ... bof

    Posté par  (site web personnel) . Évalué à 3.

    Nous utilisons en ce moment Grails.
    Ce que je peux dire, c'est que, comparé à RoR, je le trouve moins bien avancé/pensé. Exemple de la convention de mapping entre base de données et classes du domaine : dans RoR, un many-to-many à représenter par une table de jointure peut-être défini en tant que migration dans db/ ; donc pas de pollution du domaine... Dans Grails la jointure doit être représentée par une classe du domaine (ou alors faut se palucher les .hbm d'hibernate, donc on perd de l'intérêt de grails). Ceci n'est qu'un petit exemple parmi tant d'autre.

    De plus, je confirme nettement rvalyi sur la lourdeur de groovy et sur les perfs de JRuby (pour l'avoir aussi utilisé) comparé à groovy. J'ai bien peur que la montée en charge d'une application Grails soit pour l'instant bien en deçà d'une application RoR et donc d'une application Web Java (JEE / spring).

    Je voudrais aussi écrire que Grails, comme RoR, se positionne sur un marché différent des applications serveurs/web java "classiques" (JEE / spring). Ces derniers se positionnent sur la mise en oeuvre d'applications serveurs de classe entreprise (les grosses appli en résumé). Grails et RoR se positionnent plus sur le marché des petites et moyennes applications web ; ils sont, je pense, idéal pour concevoir une appli web perso (en lieu et place de PHP) qui prend pas la tête et qui soit facile à faire évoluer. Aujourd'hui, si je devais choisir entre RoR et Grails, je choisirais RoR (je trouve, pour les avoir utilisé tous les deux, que le langage Ruby est bien supérieur à Groovy, et de même le framework RoR vis à vis de Grails).

    Maintenant, pour ceux qui recherchent un langage de script pour la JVM et que ne veulent pas utiliser Ruby (JRuby), je conseillerai de regarder plus du côté de Scala que de Groovy.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.