Je vous recommande cette petite vidéo (1 min 30), pleine d’humour, pour voir comment les communautés poussent Java.
N’y attendez pas des concepts ou des conseils, mais juste des blagues de geek.

C’est intéressant de voir ce mouvement vers l’interopérabilité des frameworks. La fin d’une partie des débats sur les annotations de Guice qui vous rendent dépendant de Guice….

Par contre il reste à voir comment cette spécification va pouvoir s’accorder avec celle de la JSR 299, anciennement WebBeans qui est maintenant nommée : Java Context and Dependency Injection. Va-t-on revoir la même guerre que pour les spécifications sur la modularité? Bob répond à la question dans les commentaires sur son blog, en précisant qu’elles sont compatibles, il faut « juste » que le groupe d’expert de la JSR 299 adopte ces nouvelles annotations. La JSR 299 est une spécification Java EE qui préciserait la configuration alors que cette nouvelle spécification se veut Java SE et laisse libre l’implémentation de la configuration.

Suite à une discussion récente, j’ai repensé à un billet du blog de Adam Bien. Ce billet est une constatation sur les IDEs qu’il a pu voir en action lors de JavaOne 2008 : IntelliJ et NetBeans. La seule fois qu’il a vu Eclipse c’était pour une session traitant de Eclipse RCP.

Alors qu’en est-il de l’IDE leader dans les entreprises ? Quand on regarde les sondages du forum de Developpez, Eclipse est l’IDE le plus utilisé, il fait d’ailleurs souvent partie des prérequis dans les annonces pour des postes de développeurs. Dans les commentaires du billet d’Adam, la discussion en vient d’ailleurs au fait qu’il vaut mieux comparer dans les annonces plutôt que de comparer avec Google Trends.

Pour revenir au titre de ce blog, pourquoi pensez-vous que votre IDE est le meilleur ?

C’est le meilleur, parce que c’est celui que vous utilisez ? Parce qu’il a cette petite fonctionnalité qui va bien ?

La question à se poser est : avez-vous sérieusement essayer les autres IDEs ? Avez vous pris le peine de coder et cela plus de 5 minutes avec un autre IDE pour pouvoir comparer ?

Quand on parle de NetBeans, les gens disent souvent qu’il est lent et lourd, mais ces personnes ont-elles essayé les dernières versions de NetBeans avec son éditeur complètement réécrit ?

Quand on parle d’Eclipse, certains pensent immédiatement à l’enfer des plugins incompatibles, mais ont-ils essayé les dernières versions comme Europa ou Callisto, avec un effort de synchronisation sur les livraisons des plugins ?

Quand on parle d’IntelliJ, les gens pensent à un outil de geeks avec l’absence de wizards, mais ont-ils essayé plus avant cet IDE notamment pour le refactoring ?

Les IDEs offrent de plus en plus des fonctionnalités d’import des projets depuis un autre IDE. L’utilisation de Maven et sa prise en compte par les IDEs contribue aussi à rendre les projets indépendants des IDEs. Alors la solution ne serait-elle pas d’utiliser plusieurs IDEs selon ce que l’on fait?

Cette dernière solution me semble la bonne, peut être parce que c’est celle que j’utilise. Pour en avoir parler dans les conférences où j’ai eu la chance d’aller, je sais que de nombreuses personnes utilisent comme moi plusieurs IDEs.
J’aime bien NetBeans pour la création de GUI en WYSIWYG (Swing). J’utilise aussi son « visual web » pour le développement rapide de pages JSF (quand il s’agit d’un test de taglib). Par contre je préfère l’éditeur de code de IntelliJ pour tous ce qui est code. Pour les tests de technologies je me tourne aussi régulièrement vers NetBeans pour son support souvent en avance des dernières versions de spécifications.

En conclusion, comme j’utilise IntelliJ et NetBeans pour mon usage personnel, mais aussi Eclipse et BEA Workshop pour l’usage professionnel, je vais essayer de faire une série de billets comparant les fonctionnalités de ces différents IDEs

Et vous, êtes vous monoIDE ou polyIDEs?

La session n’est pas évidente à suivre (Joshua Bloch parle parfois vite) et il faut avoir déjà vu un peu les closures pour tout suivre (certains morceaux de code font peur au premier abord), mais comme l’interface du site est formidable, il est possible de naviguer de diapositive en diapositive et donc de revenir au début de la diapositives si vous avez raté quelque chose, ou encore de mettre en pause le temps de lire le code.

Pour ceux qui sont intéressés par les closures, ceux qui veulent savoir ce que Joshua Bloch reproche à la proposition BGGA, ce que sont CICE et ARM, et pourquoi il craint que « the feel of Java » ne disparaisse, réservez vous 42 minutes (ou moins si vous le regardez en plusieurs fois) et allez voir la présentation

Au passage, Stephan Janssen a présenté la nouvelle version de l’interface du site lors du Keynote et elle promet d’être formidable (plein écran, bookmark et commentaire sur une diapositive précise, gestion de mode offline…), par contre il faudra attendre encore un peu…

EDIT : la session de questions a été ajoutée après mon poste. Vous pouvez la voir à cette adresse.

Il y a trois catégories d’interfaces:

• celles qui n’affichent que les boutons utiles ou fonctionnels
• celles qui affichent une partie des boutons grisés
• celles qui affichent tous les boutons en permanence

La première catégorie est pratique on ne voit que ce que l’on peut faire, on ne se pose pas de question. Par contre dès que l’on veut faire des choses qui ne sont pas en accès direct, on peut chercher longtemps où et comment faire apparaitre les boutons. Il faut que les cinématiques soient bien pensées et intuitives. Généralement ces applications ne sont pas trop complexes.

La seconde catégorie, avec ses boutons grisés, vous fait voir tous ce que vous pourriez faire si vous aviez le droit ou aviez fait la bonne séquence d’actions. Par rapport à la première catégorie, comme on voit déjà les boutons, il ne reste plus qu’à trouver comment les activer. C’est un peu plus user-friendly que la précédente catégorie. Par contre quand on cherche depuis un moment comment rendre actif ces « satanés » boutons, cela devient frustrant et on a un peu l’impression que l’application nous dit

T’as vu un peu tout ce que tu pourrais faire si tu avais le droit…

La dernière catégorie est sans doute la pire. Vous avez tous les boutons actifs mais une fois sur deux quand vous cliquez dessus, au bout de quelques secondes, un message d’erreur vous annonce qu’il n’est pas possible de faire cela.
C’est l’application qui vous dit

Bien tenté mais tu n’as pas le droit !

Avec un peu de chance, le message est suffisamment clair pour comprendre ce qui n’allait pas, mais ce n’est pas toujours le cas….

Dans les trois types d’interface, je finis généralement par une phase d’exploration à tâtons qui une fois sur deux se solde par un echec ou mon incapacité à me souvenir de tous les endroits où j’ai cliqué/coché pour faire apparaitre/activer/fonctionner le fameux bouton.

Il y a des jours où l’on a l’impression que des développeurs sadiques préparent ces interfaces avec des rires de savants fous qui résonnent dans les bureaux…

Je sais, on va me dire que je devrais prendre plus de temps pour consulter l’aide ou lire les manuels au lieu de cliquer bêtement, mais avez-vous déjà vu un homme perdu en voiture demander son chemin….

Et vous quelle est le type d’interface qui vous fâche le plus?

Le deuxième point est Java 7 et toutes les discussions autour de ce qu’il doit contenir. Parmi les grands favoris, on trouve, entre autres, les closures et les properties. On trouve aussi tout un tas de propositions comme l’héritage multiple, la surcharge d’opérateurs,le support SQL au niveau du langage, ou votre fonctionnalité préférée d’un autre langage. L’argument

DotNet (et notamment C#) offre la fonctionnalité depuis la version 3, Java prend du retard

revient aussi régulièrement.

Chet Haase en a profité pour faire ses propositions sur le ton de l’humour, et ses lecteurs s’en donnent à coeur joie.
Pour un aperçu complet des discussions autour de Java 7, vous pouvez consulter l’excellent travail de recensement que fait Alex Miller sur son blog.

Plus sérieusement, un sondage montre que quand même plus d’un quart des développeurs ne veulent pas de changement. Là aussi les commentaires sont intéressants, ce qui a valu au sondage d’être deux fois de suite dans le blog journalier de l’éditeur de java.net (ici et là). Personnellement je ne suis pas contre le support des String dans les switch et un meilleur support du xml. Par contre certaines propositions comme l’héritage multiple ou la surcharge des opérateurs m’inquiètent un peu plus. Quand je vois certaines horreurs dans des codes, je me dis qu’on donnerai alors des outils bien dangereux aux développeurs pour un apport quand même minime.

Avant de me faire agresser, je vais tenter de m’expliquer…
Pour l’héritage multiple, j’ai du mal à comprendre le concept. L’héritage est souvent décrit comme une spécialisation d’une classe. Alors pourquoi spécialiser deux classes d’un coup en les réunissant dans une seule? Si elles sont suffisamment semblables pour cela, il y a, à mon avis un problème de conception, elle devrait avoir un lien…. Si vous avez un exemple clair, n’hésitez pas à laisser un commentaire….
Concernant la surcharge des opérateurs, cela me semble justifié pour les classes représentant des numériques ou pour des classes représentant des matrices. Mais pour les autres, la majorité des classes, cela me semble inutile. Si j’ajoute deux classes représentant des voitures, je n’obtiens pas une sorte de voiture à 10 places et 8 roues mais plutôt deux voitures que je mets dans un tableau ou une Collection, pas besoin de surcharge des opérateurs pour ces choses là.

Le succès de Java est du à sa simplicité. Je trouve que certaines de ces évolutions vont complexifier le langage et la lecture du code ou ne seront utiliser que par une « certaine élite » des développeurs. Avez vous déjà lu et compris du code avec des closures? Nous somme sans doute nombreux à utiliser les Generics pour typer nos Collections. Mais qui utilise ou même comprend cette syntaxe tirée de la page 18 du tutoriel de Sun sur les Générics?

interface Sink<T>{
flush(T,t);
}

public static <T> T writeAll(Collection<T> coll, Sink<? super T> snk){….}

Il serait sans doute plus intéressant de corriger les bugs les plus demandés ou d’implémenter les améliorations les plus demandées. Si SUN veut vraiment le retour de Java sur le Desktop, il ne faudra pas qu’un JRE plus léger et rapide, mais aussi un meilleur support du multimédia et de la connectivité de la machine (série, USB, FireWire…).

Dans ce billet, je ne traiterai pas des outils comme les scripts de Ruby on Rails ou encore AppFuse qui permettent de générer le squelette de l’application facilement et dont l’utilité, pour moi, ne fait aucun doute (tant qu’ils sont à jour et fonctionnent…). Dans ce billet, je veux parler des frameworks que l’on croise souvent dans une vie de prestataire et qui sont des surcouches ou wrappers de Struts, Hibernate, Spring, EJB ou autre frameworks classiques du marché, souvent disponibles en open source et gratuitement de surcroît. On trouve aussi l’autre version du framework maison qui n’est pas le wrapper, mais une sorte de clone boitant, juste la réinvention de la roue mais avec des bosses dessus….

Ne rigolez pas, vous avez certainement déjà vu un de ces frameworks. Certains ont même vu des wrappers de wrapper avec un framework de logging autour de Commons Logging (pour ceux qui ne connaissent pas, c’est un wrapper pour les frameworks de logging).
Que cela se soit fait au début de l’open source ne me choque pas. Auriez-vous fait reposer votre application directement sur quelque chose fait par des barbus sur leur temps libre? Vous aviez alors deux solutions. La première est de faire votre propre framework. La seconde est de faire un wrapper pour découpler votre application de ce code et vous donner la possibilité de changer ou refaire cette sous-couche en cas de problème.

Mais quelle est l’utilité maintenant que ces outils sont largement éprouvés?

Quand il s’agit d’une SSII, cela peut éventuellement se justifier. Le client qui achète une application développée sur le framework maison de la SSII se retrouve lié à cette SSII pour la maintenance et l’évolution de cette application. Je réprouve ce genre de pratique commerciale car elle permet de retenir le client, non pas par la qualité de la prestation ou la confiance, mais par la « contrainte ». Un peu comme une application qui enferme vos données dans un format propriétaire (non je ne donnerai pas de nom….) et vous obligent donc à continuer à l’utiliser…
Je pense qu’il est de l’intérêt du client de s’assurer qu’il aura accès aux sources de l’application et que cette application repose sur des standards du marché afin de garder toute sa liberté.

Dans le cadre d’une entreprise développant à son propre compte, j’ai plus de mal à comprendre l’intérêt. Généralement, l’argument est que le framework masque une partie de la complexité des développements Java, permettant au développeur de se concentrer sur la partie métier du code et non sur la machinerie.

Toutefois le développement et la maintenance de ces frameworks représentent un coût direct pour cette entreprise. De plus je vois un certain nombre de problèmes liés à ces frameworks :

• le risque d’avoir des bugs dans le framework
• dans le cas d’un wrapper, le masquage de l’API sous jacente peut faire que l’on se prive d’un certain nombre de fonctionnalités de cet outil
• pour le clone, on retrouve aussi le problème des fonctionnalités absentes
• pour un wrapper, il est nécessaire de faire évoluer ce framework pour profiter des évolutions de l’outil sous-jacent (il y a donc un coût supplémentaire et un retard à l’application)
• pour un clone, il faut le faire évoluer pour simuler les nouvelles fonctions intéressantes (là aussi, coût et retard sont présents, avec en plus des variations de comportement)
• la nécessité de former à ce framework les éventuels prestataires intervenant dans la société (un coût supplémentaire alors que les prestataires connaissent généralement l’outil standard qui a été encapsulé ou cloné par le framework)
• Enfin le dernier et non négligeable : se priver de la base de connaissance et d’entraide phénoménale que constitue le web et plus particulièrement les forums.

Donc d’après vous, quelle est l’utilité de ces frameworks maison ? Si vous voyez des arguments, n’hésitez pas à laisser un commentaire.

Je voudrais juste ajouter un appel aux sociétés : au lieu de payer vos développeurs pour réinventer la roue ou lui mettre des pneus plein de bosses, laissez les contribuer dans ces projets open-sources et reverser vos améliorations à la communauté. Ils gagneront en compétences sur ces frameworks et si toutes les sociétés le font, ces outils formidables seront encore meilleurs, ce n’est pas de l’argent perdu.

Concernant le démarrage, ce problème va changer avec les prochaines versions du JRE (voir mes billets précedents sur le consumer JRE ici et là). Au passage j’ai le même phénomène de gel du navigateur au lancement du plugin Acrobat Reader et là les gens en parle moins…
Pour l’aspect tristounet et gris des Applets, il est du au fait qu’elles sont souvent codées en utilisant AWT et en se limitant à la version 1.1 de Java, à cause de la JVM de Microsoft qui a fait cauchemarder de nombreux développeurs. Le problème de cette JVM devrait n’être plus qu’un mauvais souvenir à la fin de l’année.

Les applets ont donc eu mauvaise image face à des applications comme celle en flash ou même en Ajax.

Dans un message précédent depuis JavaOne, j’ai glissé que c’était le retour de l’applet sans donner plus de détail. Le truc était que la démonstration de Francois Orsini utilisait une applet cachée pour instancier une base Java DB en fond, et du javascript permettait à l’application web de stocker des informations dans cette base de données. Le tout résultait en une application Web 2.0 capable de fonctionner même si la connexion réseau était perdue.

D’un autre coté, la qualité des applications Java pour le desktop n’est plus à prouver. Il suffit de voir des applications comme Aerith, la démonstration de Romain Guy pour JavaOne 2006, ou encore Blue Marine, une application de gestion de photos. Les interfaces toutes grises et carrées sont donc maintenant du domaine du passé. De plus l’arrivée de Java FX devrait rendre la chose encore plus facile.

La grande question est donc qu’attendent les développeurs pour faire des applets qui laisseraient les autres applications web loin derrière?

La réponse est : rien du tout, c’est fait!

Toute cette grande introduction pour venir à IRIS (attention, Java 6 nécessaire). Avant que cela ne vienne dans les commentaires : je sais en flash on ne demande pas d’accepter le certificat ou de changer les réglages vidéos, mais attendez de voir le reste.
Cette application a été dévoilée pendant le Keynote technique de JavaOne. Elle utilise les webservice de FlickR, vous permettant de voir le contenu d’un compte, éditer des photos (elles sont modifiées sur FlickR si c’est votre compte), faire des diaporamas et uploader des photos par simple drag and drop depuis le bureau vers le navigateur (essayer ce dernier truc en flash….)

Vous pouvez lire les commentaires de Jasper Potts, l’un des auteurs, sur son blog et même y voir une vidéo de démonstration.

Alors est-ce que vous faites cela en Flash ou en Ajax?

Depuis le consumer JRE a été plébiscité comme « l’annonce la plus intéressante de JavaOne 2007″ avec 56% des voix sur 612 votes, loin devant JavaFX et JavaFX Mobile qui cumulent 15,1% à eux deux….

Pour ceux qui veulent toujours plus d’informations sur ce consumer JRE, Chet Haase revient dessus sur son blog et explique comment cela va fonctionner.
Pour les allergiques à la langue de Shakespeare, je fais un résumé rapide :

• Le problème du temps de lancement des applications Java, lié à la lecture des fichiers nécessaires à la JVM, sera réduit en plaçant ces fichiers dans le cache du disque dur
• La création du Java Kernell permettra de réduire à 4 Mo le téléchargement nécessaire pour une personne n’ayant pas de JRE sur sa machine. Les classes manquantes seront téléchargées en fonction des besoins.
• Un « Deployment Toolkit » permettra au développeur de détecter la version de Java installée sur une plateforme et éventuellement proposer l’installation d’une version plus récente avant de revenir sur la page contenant une applet
• Une refonte de l’installateur qui sera plus « sexy » (vous pouvez voir la capture de l’ancienne version et de la nouvelle dans le blog de Chet)
• Des améliorations sur les performances graphiques avec la réécriture du pipeline DirectX
• Le Look&Feel Nimbus qui remplacera le Look&Feel Metal

Toutes ces nouveautés devraient arriver par les updates de la version 6 début 2008, ce qui permet de ne pas attendre la version 7.

Je n’avais pas répondu car je n’avais pas trouvé d’infos sur le moment, et je n’avais pas saisi l’importance des deux minutes correspondant dans le keynote (au milieu du nombre d’annonce…).

Toutefois ce soir je commençais à regarder les sessions que j’ai raté et je suis tombé sur le session « Easy Deployment Is Finally Here » (pour les logins d’accès, voir mon post précédent)

Il y avait donc des sessions qui traitaient de ce sujet (on trouve des allusions dans d’autres sessions).

Je trouve l’interface d’installation moins intimidante et le patchage au lieu de l’installation multiple de JRE de bonnes choses. Le Java Deployement Toolkit devrait être un réel plus pour les développeurs.
Le Java QuickStart Service est une réel nécessité : la fin du navigateur figé au lancement de l’applet, que l’on ne sait pas s’il est planté, si c’est un virus ou si c’est normal….. Des applications qui se lancent plus rapidement contribueront à faire perdre à Java cette image d’applications lourdes et lentes.

Concernant le Java Kernel, je suis plus réservé. Autant on peut effectivement réduire la taille du JRE (par exemple Corba et RMI pourraient être des librairies externes, vu le peu d’applications les utilisant), autant le système de download dynamique me pose plus de problème. C’est vrai que les gens sont de plus en plus connectés à l’internet, mais qu’en est-il si l’on est déconnecté? Par exemple lors du vol vers San Francisco (plus de 11 heures d’avion) j’avais prévu de tester la version M9 de NetBeans 6. J’ai donc téléchargé le fichier d’installation avant de partir, mais je n’ai fait l’installation qu’une fois dans l’avion…. S’il m’avait manqué un package, je n’aurait pas pu en profiter…..
Ce que je veux dire c’est que le JRE fait 15 Mo, ce n’est pas tant que cela à télécharger et le fait de partager la chose risque d’amener plus de désagréments ponctuels que de réels bénéfices.
Je préfèrerai voir apparaitre un meilleur support du multimédia dans Java (ce qui est d’ailleurs prévu).
Alors c’est vrai que le runtime Flash ne fait que 2 Mo, mais de nos jours les gens téléchargent des films complets, alors que représentent 15 Mo?