Pourquoi Borland émancipe (un peu) ses outils de développement

CodeGear en route pour Eclipse et .Net

Dans la filiale outils de développement, le ton se veut rassurant. Depuis l'annonce de la scission en février, l'équipe n'a eu de cesse de répéter que rien n'allait changer pour les clients, que les feuilles de route annoncées il y a un an seraient respectées.
Du côté de Java, une version de JBuilder basée sur Eclipse était prévue pour fin 2006. Promesse tenue, JBuilder abandonne le socle technique PrimeTime (écrit en Java et qui perdurait depuis la version 3.5 de 1997) et bascule aujourd'hui sur la plate-forme Eclipse avec JBuilder 2007.
Selon la feuille de route, une version JBuilder 2008 devrait voir le jour fin 2007 incluant des outils RAD pour le développement Web et le support de frameworks Open Source (Spring, Hibernate, Shale...). Une version JBuilder 2009 est également prévue pour fin 2008. Les futures versions de JBuilder devraient inclure des outils facilitant le développement d'application SOA, l'intégration avec les produits ALM de Borland et d'autres solutions Open Source.
De toute évidence JBuilder perdait des parts de marché face à Eclipse. Le choix de basculer sur la plate-forme Open Source est sans aucun doute un choix raisonnable.
Du côté Delphi, maintenir le cap est également à l'ordre du jour. Delphi, en tant que produit, a été renommé Borland Developer Studio (BDS). BDS (que l'on continue à appeler Delphi par abus de langage) intègre les langages Delphi, C++ et C# et se veut une alternative à Visual Studio de Microsoft. BDS s'appuie actuellement sur un socle technique appelé Galileo qui lui permet de développer à la fois pour Win32 (Delphi Win32, C++) et pour la plate-forme .NET (Delphi .NET, C#).
Contrairement à ce qu'il avait été écrit dans une précédente version de cet article, CodeGear n'a pas l'intention d'abandonner ce socle technique pour les prochaines versions de Delphi et dément toute intention d'utiliser le socle technique de Visual Studio (source : Ludovic Neveu, CodeGear EMEA).
La prochaine version de Delphi, nom de code Highlander, est prévue pour début 2007 et sera axée sur le support complet de .NET 2.0.
Pour l'été 2007, on attend un Highlander pour Vista supportant les technologies Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), les API WinFX de Microsoft ainsi que le support de C++ managé.
Pour sa part, Delphi lui aussi commençait à perdre des parts de marché. Les versions postérieures à Delphi 6 n'ont pas convaincu les utilisateurs, certains ont migré vers Java, d'autres vers Visual Studio .NET... Cette feuille de route est censée attirer de nouveaux les développeurs Delphi. Mais elle ne fait pas l'unanimité dans la communauté des développeurs Delphi.
Dans une lettre ouverte à Borland/DevCo et à la communauté Delphi, Simon Kissel, utilisateur de Delphi et auteur de CrossKylix, démontre clairement qu'avec cette feuille de route, Borland va droit dans le mur et propose une feuille de route alternative. Borland n'a pas les moyens de concurrencer Microsoft sur le terrain .NET et les efforts gigantesques déployés pour tenter de le faire se font au détriment des fonctionnalités primordiales que réclament les utilisateurs depuis longtemps, telles que le support de Win64 et de Unicode. Pour Michael Swindell de CodeGear, les données avancées par Kessel, qui s'appuient sur la communauté des newsgroups, ne tiennent pas compte de la clientèle entreprise constituant la majorité des revenus de Delphi.

Comment gérer le décalage avec les versions du framework .Net ?

En 2007, Delphi proposera le support de .NET 2.0, alors que chez Microsoft, la version 3.0 du framework est sortie. Avec Vista, le saut technologique est encore plus énorme. On ne voit pas bien comment, avec ses 200 employés, CodeGear pourrait perpétuellement réinventer l'eau chaude pour concurrencer l'armada des développeurs à Redmond, pour au final se retrouver toujours en retard d'un train technologique.
CodeGear devrait peut-être se concentrer sur ce qu'il sait le mieux faire, un langage Pascal objet avec une bonne bibliothèque VCL qui a fait ses preuves et envisager d'utiliser le socle technique de Visual Studio pour tout l'aspect .NET. D'autant que Borland et Microsoft ont signé des accords d'échanges technologiques. D'autres produits ont déjà franchi le pas, citons par exemple Chrome de RemObjects, une implémentation de Pascal objet sous .NET et Mono qui propose une version autonome embarquant l'IDE de Visual Studio. Pour autant, il n'y a rien de honteux pour un produit de se retrouver en tant que plugin de Visual Studio ou d'Eclipse, en témoigne la carrière florissante de Together. D'autant que cela pourrait redonner un coup de fouet à l'écosystème Delphi qui trouverait sur la plate-forme .NET de nouveaux débouchés.
Passer Delphi sur le socle Visual Studio entre dans la même logique que passer JBuilder sur le socle Eclipse. Une démarche pragmatique dictée par la loi du marché et qui pourrait sans doute sauver CodeGear d'un éventuel naufrage.