La question du développement rapide divise la communauté Java

Les grands fournisseurs comme Sun, IBM, Oracle et Compuware cherchent à rendre le développement d'applications Java plus productif. Une initiative qui ne fait pas l'unanimité.

Comment faire du développement rapide tout en préservant la qualité des applications ? Cette éternelle question divise actuellement la communauté Java. Oracle affirmait récemment sa volonté de recréer en Java le confort des outils graphiques client-serveur. Et l'éditeur tente d'y parvenir avec son framework ADF (Application Development Framework) intégré à sa nouvelle base de données 10g. Au printemps dernier, IBM et Sun avaient déjà affiché leur volonté de promouvoir des solutions destinées à simplifier le développement Java. Et donc à maximiser la productivité.Pour Big Blue, Rapid Developer, produit de type Arad (Architected Rapid Application Development) issu de sa division Rational, vise à générer du code Java à partir de modèles ­ diagrammes UML, schémas de bases de données, frameworks, etc. Sun, quant à lui, a profité de sa conférence annuelle Java One en juin dernier pour étayer sa nouvelle stratégie vis-à-vis des développeurs. Objectif : atteindre, à terme, dix millions d'adeptes en séduisant l'énorme communauté des développeurs en entreprise.

Le RAD, à réserver pour les applications jetables .?

Pour y parvenir, Sun compte sur la future commercialisation d'un outil de développement, dont le nom de code est Rave ­ avec, en ligne de mire, la communauté des développeurs Visual Basic. Il mise également sur l'évolution de sa plate-forme Java avec notamment JSF (Java Server Faces), une technologie destinée à bâtir des interfaces graphiques riches pour le web par le biais de l'accélération du développement des contrôles graphiques.Mais l'approche par la productivité, ou RAD (Rapid Application Development), est loin de faire l'unanimité dans la communauté Java. Ainsi, Marc-Antoine Garrigue, architecte chez Octo Technology, estime que ' l'approche RAD répond au besoin des applications jetables. C'est-à-dire des applications que l'on ne souhaite ni maintenir ni réutiliser. L'objectif du RAD n'est pas de capitaliser. ' Conséquence de cette approche exclusivement productiviste : avec des outils de type RAD, les développements ne sont pas ' encadrés ' ; et, donc, leur qualité s'en ressent.Pire : la nature même de Java, langage objet, rend difficile une approche de type développement rapide. En effet, les développeurs qui font du RAD sont plutôt habitués à une approche procédurale. ' Ces développeurs apprécient les langages objet, mais sans pour autant faire de l'objet avec ', estime Marc-Antoine Garrigue.Autre son de cloche, celui du spécialiste du développement Borland. Selon Bruno de Combiens, responsable marketing produits de l'éditeur, ' l'approche du développement rapide pour Java va à contre-courant des besoins des entreprises. Ces dernières demandent, au contraire, de prendre le contrôle sur le développement et l'exploitation des applications. Ce qui n'est pas le cas lorsqu'on automatise à tout va la production du code lié à l'infrastructure. Car cette approche rend opaque le comportement de l'infrastructure. 'Enfin, les outils RAD ont une connotation propriétaire. ' Même si le code produit fonctionne sur n'importe quel serveur d'applications, ils peuvent imposer de se lier à un éditeur, car l'outil de développement utilise généralement un jeu de bibliothèques propriétaires ', souligne Bruno Paul, consultant chez Improve. La communauté Java s'accorde donc sur la nature complexe de Java, mais pas sur le fait que ce soit un problème.