Récemment, une énième discussion a enflammé les esprits sur les forums techniques. Vous savez bien, c’est une discussion qui démarre sur l’état de l’art et qui se termine en considérations sans fins sur les qualités comparées avec un “vieux langage” que-sur-des-cas-précis-il-ne-sera-jamais-dépassé…
C’est un fait que l’écosphère Java souffre actuellement d’une offre pléthorique (Struts/Stripes, Tapestry, JSF, Spring MVC, GWT, JavaFX… j’ai la tête qui tourne) et redondante (cf. débats actuels Java EE 6 vs. Spring 3.x ou la foule des portails, GED ou ESB apparus). Il est vrai aussi que :
- les débutants sont mal formés, notamment sur les paradigmes OOP, AOP et SOA
- les développeurs expérimentés s’épuisent à passer d’un framework à l’autre
- les architectes n’ont pas le temps d’évaluer les versions qui sortent en permanence
Sans parler des projets tellement évolutifs qu’ils embarquent plusieurs technologies Web Services en même temps ou pâtissent de toutes sortes de dettes techniques, faute de recevoir une maintenance planifiée…
Mais a contrario, en Java les standards évoluent tellement lentement qu’on leur préfère des solutions alternatives à forte obsolescence. On en est là. Avouez que c’est quand même dommage de faire preuve d’immaturité à cet âge ! De mon temps (hum) les bonnes idées étaient simplement reprises et transcendées au sein de la “meilleure” communauté créée.
Mais aujourd’hui il semblerait que notre industrie soit en guerre. jBoss vs Spring, Adobe vs Google, Hudson vs Jenkins… Faut-il pour autant prêcher la dictature comme remède à l’anarchie ? Nous ne voulons pas devenir .Net, si ? Bref, j’exagère (à peine).
Pourquoi le monde Java en est-il arrivé là ?
Selon moi, c’est à cause de son succès, justement. Le niveau d’activité de la communauté me semble tout à fait remarquable, notamment dans l’Open Source, mais pas que. Le revers de la médaille, c’est qu’un si grand nombre d’intervenants implique le ralentissement des prises de décision, favorisant ainsi l’adoption de solutions spécifiques ou inachevées.
Avant, c’était mieux (n’est-ce pas ?). Un serveur d’application Tomcat et quelques spin-off, un peu d’injection et de bonnes pratiques ORM et c’est parti pour le framework léger. Un IDE sympa, avec quelques plugins utiles. En plus, tout ça gratos ! Et l’enthousiasme du fait main se répandait dans les entreprises à la faveur des SCM. Ajoutez à cela les annotations, et l’on a pu croire un temps que nous serions productifs.
Bon… ça n’a pas vraiment suffit. N’est-ce pas ? Alors il y a eu Maven, l’intégration continue et même l’agilité. Et BOUM ; peut-être que ça marche trop bien, finalement : tout le monde s’est mis à parler/publier en même temps, la tête dans le guidon. Une vraie course à la nouvelle version.
Mais alors qu’est-ce qu’on va FAIRE (Mon Dieu) ?
Nous avons une responsabilité, en tant que communauté et en tant que professionnels. Cette responsabilité est de suivre un cap réfléchi pour assurer à nos utilisateurs et à nos clients une certaine forme de pérennité. Je ne parle pas de 10 ou 15 ans, bien sûr. En technologies de l’information et de la communication (comme on dit), c’est l’éternité ! Et c’est enfoncer une porte ouverte que de proposer un socle commun stable. Nous SAVONS ce qu’il nous faut. La question est COMMENT l’obtenir.
Et bien je pense personnellement que la République des Experts, c’est fini. Il nous faut une Démocratie Participative (notez les majuscules, je vous prie). Nous vivons actuellement une période transitoire qui pourrait très bien aboutir à un verrouillage par quelques grands acteurs (parmi Adobe, Google, jBoss ou d’autres), au détriment de la créativité et de la réactivité. Pour éviter cela, je pense que les développeurs devraient pouvoir influer sur les orientations du marché pas seulement par plébiscite, a posteriori, mais aussi en amont sur la base d’une information éclairante.
The Apache Software Foundation nous a montré la voie (par le truchement de l’incubation et d’un processus électif). Mais la méritocratie (qui a dit bureaucratie ?) n’est pas suffisante. Avez-vous compté le nombre de projets que la fondation héberge, récemment ? Là aussi, le débordement fait plus que nous guetter : il nous attend au tournant. Certaines idées méritent plus qu’un avis technique, il leur faut un coup de pouce (comme dans l’expression “Je poussoies”, bien sûr) afin de leur assurer l’effort requis. Et chacun, comme pour une primaire politique, devrait pouvoir donner sa voix sur la teneur des projets à privilégier.
Nous n’avons pas besoin d’une dizaine de bases NoSQL ; nous avons besoin d’une (aller, deux) solutions qui fonctionnent et garantissent une réponse à une problématique réelle (mais je garde pour moi mon opinion, concernant cet exemple précis). Les outils existent, je regarde vers GitHub (en tant que plateforme collaborative, peu importe que le support soit Git ou SVN, au fond). Nous savons fédérer la motivation ; mais il nous reste à exprimer l’intérêt plus tôt au cours du processus de développement afin d’éviter le gâchis actuel qui consiste à jeter nos forces dans des projets concurrents, parfois complètement équivalents, mais dont personne ne veut abandonner la paternité.
Un processus démocratique, ouvert, devrait permettre aux solutions d’avenir de recevoir suffisamment de moyens pour percer, prendre le temps de se stabiliser, et enfin s’imposer. Non pas sur une mode qui aurait duré, mais sur la qualité d’une réalisation ayant reçu toute l’attention nécessaire.
