Goufablog

Geek, nouvelles technologies, société et jeux vidéos!
14
févr.
2012
Comment j'ai été dégoûté des nouvelles technos Java
Technique - par Goufalite - 3327 hits


Maven, JUnit, Hibernate, Hudson, GWT, JBoss,... Tant de termes qui font rêver quand on les entend et qui ont un goût de mode en cette période de programmation vouée à l'intégration rapide et à l'extrême développement. C'est donc vers ces technologies que je me suis dirigé lors de ma mutation à Toulouse pour pouvoir mettre quelques lignes de plus sur mon CV et rédiger ce petit article.

Résumé

Un petit lexique des termes utilisés ci-dessus pour comprendre le contexte

  • Maven : utilitaire permettant d'interfacer une multitude de plugins nécessaires au projet, il permet aussi de compiler le code en fonction de ce que l'on veut en faire (tests, déploiement, installation,...).
  • Hudson : serveur qui récupère tout ce qui est en gestion de configuration pour le compiler en utilisant Maven et faire un rapport des constructions récentes.
  • Hibernate : librairies pour gérer l'accès à une base de données, plus de détails ci-dessous.
  • GWT : Google Web Toolkit, plateforme de travail permettant de créer des application web. Les pages générées sont mises à jour automatiquement avec du code Javascript.
  • JUnit : plateforme permettant d'effectuer des tests unitaires automatiquement, pratique quand on modifie certains modules pour détecter les régressions
  • JBoss : serveur applicatif pouvant héberger des applications Java.
  • Sonar : utilitaire permettant de faire du contrôle de code, notamment la couverture des tests et les styles de programmation.
  • Spring : framework permettant de décorréler les objets en passant par des annotations
  • Tout s'annonce bien, chaque plugin semble avoir ses propres avantages. Mais...

    On prend tout et on déploie en local!

    Je cherche une image pour montrer l'équilibre de mon projet
    Je cherche une image pour montrer l'équilibre de mon projet

    Je suis donc sur un projet dont on se sert de Maven pour assurer les dépendances entre Hibernate, JUnit,... en passant par des annotations Spring à déployer sur un serveur JBoss avec la partie GWT le tout commandé par Hudson qui envoie un rapport à Sonar...STOOOOOP!! Déjà que je ne connais presque aucune technologie, je dois en apprendre une dizaine en quelques instants avec pour seul appui Google ou mes collègues qui sont occupés sur d'autres modules!

    De plus il s'agit d'une application Web, par conséquent on doit déployer le projet sur un serveur JBoss afin de le rendre disponible, et pour ne pas se marcher sur les pieds chacun installe un JBoss sur son poste. Heu... attendez :

  • Windows : 1000Mo de RAM
  • SpringSource : 1Mo
  • La JVM pour Eclipse : 300Mo
  • La JVM pour JBoss : 512Mo
  • Le serveur applicatif de code GWT : 300Mo
  • Firefox : 100Mo (oui je sais il y a chrome mais c'est pour la compatibilité entre navigateurs)
  • Vous avez demandé plus de RAM? Ne quittez pas!
    Vous avez demandé plus de RAM? Ne quittez pas!

    Bilan, plus de 2,5Go de RAM pulvérisés pour une application locale. Sympa pour un simple ordinateur bureautique! De plus il faut déployer, redémarrer le serveur JBoss, redémarrer le plugin de développement GWT, s'assurer que le code a bien été repris et construit, résoudre les problèmes de conflits et de fichiers existants, recommencer tout puisque ça n'a pas été pris en compte,... une bonne heure pour enfin insérer ce "N" oublié dans une chaîne de caractères! Au fait, le serveur JBoss prend 5 minutes à (re)démarrer, beaucoup plus que de déployer sous Android...

    Hibernate ou la chasse à l'objet

    Bon, il y a deux écoles pour la manipulation de données dans les bases. La première est d'utiliser des requêtes SQL précises pour récupérer uniquement ce dont on a besoin et le stocker dans des variables :

    Query q = new Query("UPDATE user SET name = '"+newName+"' where id = '"+userId+"'"); q.executeStatement();

    La deuxième consiste à créer un objet contenant tous les champs d'une table et l'interfacer avec tous les autres objets en y ajoutant quelques fonctions propriétaires :

    class User { String id; String name; String getId() { return this.id; } String getName() { return this.name; } void setName(String _name) { this.name = _name; } } User user = entityManager.getUser(userId); user.setName(newName); entityManager.flush();

    Les deux méthodes se valent : la première permet simplement de récupérer les informations nécessaires en maîtrisant les jointures entre les tables, et la deuxième permet de passer outre l'implémentation SQL pour manipuler directement l'objet.

    Hélas, dans des projets avec des spécifications précises, les objets sont incontournables, trop nombreux et beaucoup trop spécifiques! Je me retrouve donc à mettre des objets dans les objets en cas de jointure (au lieu d'un simple identifiant), certes le moteur d'hibernate gère tout tout seul mais pour récupérer un pauvre champ je dois passer par tout une arborescence d'objets pour juste obtenir le champ qu'il me faut, si ce n'était que ça... il faut que je passe par une montagne de protocoles juste pour avoir l'information :

    • Objet : l'objet en question (appelée entité), il contient tous les champs de la table en question avec des getters et des setters
    • ObjetDAO : Data Access Object, interface permettant d'implémenter des fonctions spécifiques pour récupérer des données (requêtes, toutes les lignes,...)
    • ObjetMockFactory : permet de simuler l'insertion de données dans l'entité
    • ObjetDaoTest : permet de faire des tests sur les deux éléments ci-dessus
    • ObjetWS : caractéristiques du fichier XML, JSON,... permettant de faire transiter les données en appel du Web Service
    • ObjetService : web service contenant les fonctions à appeler
    • ObjetDTO : Data Transfert Object, objet permettant de faire le transfert de l'entité (comme si l'entité ne suffisait pas)
    • ObjetDataProvider : comme son nom l'indique, fournisseur de données, il implémente un écouteur pour savoir quand les données on été reçues
    • ObjectDTOMapper : interface avec le fournisseur de données
    • J'omets ici les modèles abstraits ou les interfaces génériques dont les objets héritent ou implémentent.

    Voilà tout le beau monde que je dois appeler juste pour récupérer un pauvre champ dans une table, alors qu'une requête SQL aurait pris moins d'une minute!

    Bon si ce n'était que ça... Les administrateurs de la base de données nous imposent l'appel à une procédure stockée retournant une variable en sortie, à exécuter au début de la session. Avec un connecteur simple ç'aurait été une simple formalité, mais hibernate ne gère pas facilement les sessions, vu qu'il instancie les objets à la volée.

    J'aurais préféré voir deux objets : un connecteur chez le client et une entité chez le serveur. Cela aurait déjà été mieux au lieu de devoir faire transiter une simple donnée dans un enchevêtrement d'objets!

    Le modèle GWT

    Je n'ai rien contre les design patterns (MVC, MVP,...) malgré le fait que je vienne de PHP, un monde où afficher une variable dans une TextBox tient dans une ligne. J'ai aussi l'habitude de travailler avec des modèles MVC surtout depuis que je me suis mis au développement Android, mais là je suis un peu sidéré par tout le code qu'il faut pisser PONDRE juste pour afficher un champ de saisie :

    • mettre son modèle dans l'objet modèle
    • mettre le champ dans un fichier xml
    • le déclarer dans l'objet vue GWT

    Déjà quand je vois les deux derniers points, je vois de la répétition! Bon d'un côté c'est pour permettre la vue HTML d'interfacer avec le Java. Jusque ici tout va bien avec le présentateur qui contrôle le modèle et la vue. ET BIM! L'architecte nous impose l'utilisation d'une interface supplémentaire pour lier la vue et le présentateur pour pouvoir faire des tests unitaires plus facilement. Le modèle est lié abstraitement à la vue et nous ne pouvons plus passer par le modèle pour récupérer nos données. Tous mes collègues ont choisi la solution ultime : mettre tous les composants du modèle dans la vue! Et ça marche!

    LE TOUT SOUS ECLIPSE

    On préferera quand même la console, elle marche mieux que le compilateur Eclipse -_-"
    On préferera quand même la console, elle marche mieux que le compilateur Eclipse -_-"

    Ah Eclipse, l'environnement de développement qui fait de l'ombre au soleil (à Sun). Cet IDE est surchargé de plugins, de fonctionnalités, de "perspectives" (il s'agit de configurations d'écran) qui le rend très difficile d'utilisation :

    • quand le programme change d'état (configuration SVN, déboguage,...) la perspective change et donc toutes les fenêtres changent de place et on se perd complètement!
    • il faut souvent "rafraîchir" l'espace de travail, il s'agit d'une sécurité pour voir si les fichiers ont été modifiés en externe mais Notepad++ le fait de façon transparente. Une option peut être activée pour rendre le rafraîchissement automatique en allant dans "Window > Préférences > Général > Workspace". Pour l'éditeur c'est bon, par contre il faut aussi faire ça pour compiler le projet, avec donc un risque de ne pas avoir les dernières modifications.
    • je passe sur l'interaction entre les différents modules et plugins décrits ci-dessus, et le fait qu'il sont complètement indépendants d'Eclipse malgré leur interfaçage (par exemple erreurs dans Eclipse alors que la compilation Maven marche).

    Je disais dans un article précédent que l'acharnement est important, mais là on en est à un phénomène de simultanéité comme l'effet papillon ou l'enchaînement d'évènements en fonction de la météo ou des positions des feuilles sur mon bureau. Nous avons un wiki dans l'équipe mais il est progressivement complété par des manipulations phénoménales qui se résument généralement à réinstaller tout le système et donc de perdre une heure en manipulations. Donc pensez d'ores et déjà à bien répartir vos projets dans différents "workspaces" pour mieux les réinstaller.

    Tout n'est pas noir

    JUnit est mon module préféré parmi l'avalanche de plugins décrits ci-dessus. Il permet de faire des tests ponctuels sur les différentes fonctionnalités de notre programme, c'est très pratique pour analyser les régressions suite à de grandes modifications de code, une livraison ou un changement de la base de données. Un simple clic droit dans l'interface d'éclipse permet de lancer une série de tests et le débogage de ceux-ci se fait grâce à une trace de la pile d'erreur assez ergonomique.

    Par contre une fois posés ne les négligez pas! C'est un coup à se retrouver avec une multitude de tests qu'il faudra maintenir, corriger ou pire, feinter... N'oubliez pas que ces tests ne remplacent jamais un test de bout en bout avec l'IHM.

    Le bilan


    Je suis arrivé à un point où je dois promettre de vendre mon âme au diable pour qu'un programme puisse compiler, déployer, accéder, débogguer ET marcher correctement et je pense que tous mes collègues sont de mon avis. Encore une fois, chaque technologie prise à part peut être d'une richesse non négligeable dans un projet d'entreprise, mais les mettre toutes ensemble consisterait à construire un bâtiment en utilisant plusieurs ressources et méthodes à la fois.

    Pour ma part j'ai quand même bien appris l'utilisation de la plupart des technologies et certaines sont intéressantes, notamment les JUnit. Bien sûr il faut derrière un équipement de pointe (multi-écran, 12Go de RAM, un bon architecte,...) et j'aurais moins de pénibilité à faire avancer le projet.

    Bon, je vous laisse, je dois préparer la chèvre en vue du sacrifice sur le parking tout à l'heure pour que la livraison de ce soir se passe bien...

    + Sources des images


    Vous pouvez aussi lire :

    GoufaliteGoufalite - Site Web - Steam - Twitter
    Rédacteur et programmeur principal du Goufablog. Ingénieur de profession et avide de connaissances technologiques et scientifiques il partage son savoir à travers ces différents articles. Plus de renseignements sur la page de contact.
    RSS Voir ses articles...
    CC-BY-SACet article est protégé par une licence CC-BY-SA.


    Tags : eclipse, gwt, hibernate, hudson, j2ee, java, jboss, junit, maven, web service
    Delicious   Facebook   Commentaires(1) | Permalink
    RSS:Commentaires du billet Il y a 1 commentaire.
    Commentaire supprimé le 21 avril 2017
    Votre avis?
    (Obligatoire)

    Site et style réalisé par Goufalite
    Reproduction interdite sans l'accord de l'auteur.
    Valid XHTML 1.0 Transitional Optimisé pour FireFox 2
    avec une résolution 1024*768