Prenons par exemple une classe Adresse pour java : Elle contient deux attributs, leurs geters et seters ainsi qu’une méthode de formatage getAdresseComplete et un petit main pour afficher les données.
Et bien elle compile directement dans groovy mais nous allons bien sur voir comment elle peut être transformée pour une meilleure lisibilité.

Tout d’abord et comme la dernière fois : les ; sont inutiles, et en groovy, les classes et méthodes sont par défaut public. On peut donc se passer de ces artefacts inutiles dans le code.

Vous avez peut-être vu que pour java7, il est proposé un système déclaration des propriétés, en groovy, c’est déjà la. Un attribut sans aucun modificateur est considéré comme une propriété. Vous pouvez donc vous passer des geters et seters. Par contre le byte code généré comporte ces méthodes, donc si vous utilisez ce bean via java, vous pourrez bien utiliser les méthodes getVille() et autres.

Dans groovy, dernier statement d’une méthode est automatiquement retourné, on peut donc se passer du return de la méthode getAdresseComplete(). On en profite pour utiliser les possibilités de concaténation de variables des String groovy (GString de leur petit nom).

Et comme On l’a vu, il n’est pas obligatoire de tout mettre dans une classe, ni de typer les variables. On utilise le raccourci println pour System.out.prinln() histoire d’alleger au maximum.

Au final, on a du code très simple, très expressif, et facile a lire pour un habitué de java. C’est je crois le gros point fort de groovy, très expressif, tout en étant facile a appréhender.
Par contre, je reste partagé sur le fait de typer ou non les variables, et je pense que ça dépends du type de code que l’on produit. Si c’est plutôt du script, def c’est plutôt pratique. Sur un projet plus gros, le typage apporte quand même une sécurité a la compilation appréciable.

Et bien sur, vous disposez avec ce bean de Java et de toute ses api, comme par exemple JPA. Voila par exemple ce que donne ce bean rendu persistant via JPA.

Il existe un plugin pour Eclipse, et un autre pour Netbeans est en approche. Sinon, la console groovy marche aussi

Bon, nous venons de java, et un hello world java qui donnerait ceci fonctionne sans aucun changement sous groovy.

Il faut savoir que par défaut dans groovy, une classe ou une méthode est public, donc on peut se passer de ce mot clé, et que les ; sont optionnels.

De plus, comme on utilise souvent les sorties standards, la méthode println de System.out est disponible en permanence, et petit plus, si il n’y a pas d’ambiguïté, les accolades sont optionnelles.

Enfin, en groovy, il n’est pas obligatoire de tout inclure dans une classe : on arrive donc a un très simple.

cet exemple bien sur un peu caricatural vous montre quand même bien la philosophie de Groovy ! Le code doit être utile et lisible. tout ce qui est inutile doit disparaitre ! On verra par la suite la même passe sur un java bean.

Ce que j’apprécie dans groovy, c’est le fait qu’il soit proche de java, tout en amenant un nettoyage du langage très bien pensé. On peut passer facilement et naturellement vers ce langage en s’appuyant sur ce qu’on connait déjà de java et de ses API.

je vais dans les semaines qui suivent (si j’ai le temps /o\ ) essayer de publier différents billets sur groovy et ses points forts.
Par exemple son excellente interaction et intégration dans java, sur les Builders intégrés, sur les accès base de données etc…

Un premier gros point fort de groovy sur java, c’est le fait qu’il peut être compilé a la volée. c’est-à-dire que le passage par l’étape de compilation est optionnel. C’est vraiment très agréable de pouvoir exécuter facilement et modifier du code comme en php (ou d’autres). Le classpath peut contenir des .class (oui groovy se compile en .class, mais on y reviendra) ou des .groovy indifféremment.

Du coup, groovy peut être utilisé très facilement en langage de scripting.

Cette capacité à faire des appels ajax vers d’autres domaines que le domaine de la page active va permettre a terme de créer une véritable api de widget pour le web.

En effet comme déjà vu, on aura deux possibilités : placer un header http pour autoriser un domaine, et pour l’inclusion de xml une entête dans ce fichier.
En combinant les deux, on va pouvoir créer des widgets sur un serveur, et proposer leur inclusion dans une autre page cliente.
Ce widget pourra lui même faire des appels ajax vers des fichiers xml pour se mettre à jour.

On va pouvoir proposer, hebergé sur developpez.com un widget à inclure en ajax qui permet de rechercher dans les forums par exemple et qui va afficher les résultats.
Pas mal ! Le mashup va passer du serveur au client web. ca va simplifier les choses.

ca se concentre !

Bien sur, afin que ce ne soit pas une faille de sécurité, il faudra autoriser la page web à le faire avec un header http.

Par exemple en php
<?php header('Access-Control: allow <*>'); ?>
Autorisera votre page à appeler n’importe quel site distant en ajax.

plus de détails ici -> Cross-Site_XMLHttpRequest

je prédis l’explosion des api REST pour l’année qui vient !

L’objectif est de se simplifier la vie, le code et la maintenance en allegeant le code au maximum. Imaginons un objet Commande qui a pas mal d’attributs, et contient une liste de lignes de commandes.

au lieu d’écrire le classique

on voudrait pouvoir ecrire (exemple simple)

Il sagit de chain programming, déjà utilisé dans certaines api java par exemple dans l’api nio (regardez les methodes des buffers, elles renvoient toutes l’objet).

Plus leger, plus simple, potentiellement lisible par un profane en programmation. On peut pousser le concept beaucoup plus loin que sur cet exemple un peu naïf en creant un veritable petit « langage » dédié a cet objet ou a un ensemble d’objets. Imaginez par exemple manipuler l’ horrible api Date/Calendar de java en tappant

ou bien

Un exemple plus complexe de l’api JMock, ou finalement on approche le concept de Domain Specific Language.

mock.expects(once()).method("m").with( or(stringContains("hello"), stringContains("howdy")));

Un autre exemple est le projet Quaere, un genre de linq pour java.

Ca vous donne des idées ? (y’a aussi jrules, l’api criteria de hibernate etc… )

La façon la plus evidente pour faire cela est d’ajouter ces methodes a l’objet sur lequel on veut travailler.
En plus des geter/seters, on peut y ajouter les methodes supplementaires pour avoir cette syntaxe.

Simple, mais bon, le nombre de methodes va exploser, on va melanger les methodes, en gros c’est le bordel ! On s’éloigne de l’objectif, et on ne peut pas ajouter simplement le return this; au seter, car ce n’est plus conforme aux normes du java bean

La méthode proposée par martinfowler.com consiste a avoir un sous objet qui lui dispose de ces methodes.
On crée cette classe.

on arrive a un code du type

Pas mal, mais cette méthode a selon moi de gros defauts. Déjà on modifie du code existant pour avoir des « facilités » syntaxiques, ce qui pour un gros projet n’est pas forcement possible. Du code stable et terminé, on n’y touche plus. On mélange code de type Model avec du code de Factory/builder. Enfin on ajoute un attribut a tous les objets que l’on veut traiter de cette facon, ce qui peut ne pas etre acceptable (si par exemple cette objet est beaucoup instanciée dans l’application, ca peut jouer sur les perfs etc…)

Oh, mais j’ai parlé de Builder, c’est un design pattern connu ca ! on a qu’a essayer avec. En gros, CommandeFluentInterface devient un CommandeBuilder externe.

du coup, on va coder

Ca commence a etre pas mal. joli, simple, code de construction decouplé de l’objet lui-même, donc on peut ajouter ce genre de choses a un projet existant, sans modifier le code deja présent.

Mais en mélangeant tout ca, avec les satic imports de java 5, on fini par avoir un truc vraiment tres bien (ca vient de ce blog)

et la on peut faire

evidement, l’exemple choisi (la commande si vous suivez) est simpliste, mais cela permet de s’attquer a une api complete

http://stephan.reposita.org/archives/2007/10/17/creating-a-fluent-interface-for-google-collections/

voila voila. Vous en pensez quoi vous ? c’est totalement inutile ? vous preferez une solution a une autre ? En tous cas, c’est un sujet a la mode, probablement parce que les DSL sont interessants, mais que leur construire un outillage approprié n’est pas facile (support dans un ide etc…) : du coup les implementer dans un langage existant est tres utile.
D’ailleurs de nombreuses propositions pour java 7, si elles sont retenues vont permettre beaucoup de choses dans le domaine
Closures, les méthodes d’extension, chained methods

multiples sources qui sont la base de ce blog (beaucoup de copié collé dans ce post )
martinfowler Bliki
static imports fluent interfaces/
fluent-interfaceand-reflection
creating-a-fluent-interface-for-google-collections
HowTo DesignA FluentInterface

http://andersnoras.com/blogs/anoras/default.aspx

Je galère sur un truc tout bête par exemple : j’ai un projet sous CVS, et je veux le déconnecter de ce repository pour le mettre sous un autre (voir sous subversion).

Sous Eclipse : -> bouton droit sur le projet -> team -> disconnect et Eclipse demande même si il doit effacer les meta-information (les répertoires CVS) ou pas.

Sous Netbeans : impossible de trouver quelque chose d’équivalent. c’est franchement moyen. J’envisage d’aller dégager les répertoires cvs a la main et de voir ce que ça donne.

Je reviendrais sur le support de cvs et de subversion dans Netbeans, parce que c’est vraiment un gros point noir pour cet IDE. (pas moyen de naviguer facilement dans un repository, le diff est pas terrible, pas de moyen simple pour comparer son fichier avec une version/release antérieure)… sans parler des locks sous subversion qui bloquent tout et qu’il faut aller virer en ligne de commande. bof bof bof

sources Cnn [edit] oups, c’est cRn.

slashdot

Au menu de nombreuses nouveautés :

• Modification de Spring pour que les beans puissent etre codés en n’importe quel langage supporté par la jvm (Python, Ruby, Beanshell…)
• Modularisation plus grande, avec un spring-core reduit a son strict minimum
• De nouveaux scopes pour les beans : avant il n’y avait que Singleton, maintenant il y a les scopes ServletContext et session, et la possibilité de créer ses propres scopes.
• Le fichier de configuration de Spring passe a xml-schéma, et permet l’inclusion d’autres namespaces (voir l’article de Erik Gollot) pour se faire une idée
• L’utilisation des annotations (metadata) de java5 pour gerer les transactions
• L’utilisation de Java Persistence API (JPA) est possible
• L’inclusion d’un Portlet MVC framework
• L’inclusion d’une bibliotheque de tags pour Spring MVC et la gestion des formulaires html

Et encore beaucoup d’autres le tout en restant retro-compatible dans la grande majorité des cas, ce qui est quand même impressionant (je vous donnerai des nouvelles de mes migrations).

Pour plus d’informations : Le detail des nouveautés sur le site de Spring

Bonne migration(s)