Etant donné que je ne suis pas homme à gueuler sans preuve, voici la démonstration de ce que j’avance.

Je vous laisse le temps de lire ce petit bout de code et deviner le résultat logique d’une exécution…
Si vous pensez comme moi, vous vous attendez à ce résultat:

Object: java.lang.String

Integer

Float

Réfléchissons deux minutes.

Nous avons une liste qui contient différents objets, une chaîne de caractère, un entier et un nombre décimal. Notre classe Main présente une méthode polymorphique prenant en paramètre un Object, un Integer ou un Float.
Pour le premier objet la méthode la plus approchante est la méthode avec le paramètre Object.
Pour les deux autres la méthode avec le paramètre de type exact va être appelé du fait que la liaison en java est dynamique et décidée à l’exécution. Le fameux « VIRTUAL » des programmeurs C++.

Voyons le résultat de l’exécution (JVM 1.6 sur MacOS 10.6 dit « Snow Leopard »):

Object: java.lang.String
Object: java.lang.Integer
Object: java.lang.Float

Mais ????!!!! Voilà un résultat qui ferait lacher à nos amis anglo-saxons un virulent « WTF ?! ». Que c’est-il passé ?

Et bien c’est extrêmement facile. Nous nous trouvons devant un manique échec de Java et ses méthodes liées à l’exécution… Le compilateur voit que l’ArrayList contient des instances de Object, il voit une méthode prenant en paramètre un Object, il fait la liaison à la compilation. Dans le langage courant on dirait simplement: JAVA FAIL !

Si vous ne me croyez pas, vous pouvez simplement télécharger le fichier de test ici (en renommant le fichier Main.java évidemment). Pour le principe j’ai changé Object en Number (superclasse de Integer, Float, Double, …) et le résultat est bien sûr le même, comme vous le constaterez là.

WebObjects est un framework initialement développé en Objective C par la société NeXT de Steve Jobs qui sera ensuite rachetée par Apple. Il est constitué d’une couche basse d’abstraction de la base de donnée appelée EOModel, d’une architecture de gestion de cache et de persistance et d’un moteur de template. WebObjects passera progressivement d’Objective C à Java vers l’an 2000. Bien que différents par de nombreux points, il est comparable aux technologies J2EE.

Je tiens à signaler que mes commentaires sont faits sur la version 5.3 de WebObjects et je ne sais pas si certaines choses n’ont pas été corrigées en version 5.4.

Coût de formation et cadre de développement

Soyons assez clair, le coup d’entrée de WebObjects est assez élevé. Le framework a été pensé pour réaliser des projets d’entreprise et vous ne pourrez pas sortir une page de démonstration en moins d’une heure comme le proposent des plateformes de développement comme Google App Engine. En revanche, une fois formé à l’architecture logiciel vous disposerez d’un cadre de programmation assez stricte dans la forme, mais souple dans les possibilités. Comprenez que vous pourrez faire à peu près n’importe quoi, mais pas n’importe comment. À mon sens, c’est un avantage puisque vous êtes à peu près certain que les personnes utilisant WebObjects vont travailler relativement proprement, contrairement à d’autres technologies où il est possible de faire tout et n’importe quoi, surtout n’importe quoi.

Tenue de charge et modularité

WebObjects est designé pour être capable de gérer de grandes charges, aussi les données sont toujours chargées progressivement au moment où elles sont réellement nécessaires. Au niveau du fonctionnement lui-même, le framework est construit autour de dictionnaires de données. Par exemple pour les attributs d’un objet, les getters vont simplement chercher la valeur dans un dictionnaire à partir du nom de l’attribut. C’est de ce mécanisme que vient toute la souplesse de WebObjects puisqu’il est possible de faire évoluer dynamiquement le modèle pendant l’exécution. Même si les occasions d’utiliser une telle possibilité sont assez rares, elles sont quasiment impossible à réaliser autrement.

Mélange d’API

Comme je l’ai dis dans mon introduction, WebObjects reposait initialement sur le langage Objective C, mais a été migré vers le langage Java depuis plusieurs années maintenant. Cependant les choix qui ont été faits me laissent quelque peu sceptiques. En effet afin que les personnes ayant travaillé avec l’Objective C ne perdent pas leurs connaissances acquises, les classes de  base de NeXT ont été portées en Java. Un ingénieur d’expérience sur l’API Java sera donc un peu perdu face aux NSArray, NSMutableArray et autres NSDictionnary. Pire encore, ces classes implémentent des interfaces de l’API Java, mais n’implémentent pas les méthodes qu’elles apportent, se contentant de propager une exception ! Assez perturbant donc et pouvant se révéler source de surprises.

[MISE A JOUR]
On me signale que le problème des exceptions sur les méthodes ont été corrigé en version 5.4 sauf dans les cas où il y avait une raison. Je m’explique, en WebObjects il éxiste deux types de tableaux, les NSArray en lecture seul et les NSMutableArray en lecture écriture. Bien évidemment la méthode ADD n’a aucun sens dans un NSArray qui ne supporte que des GET. En revanche la méthode ADD ne NSMutableArray ne demande plus d’utiliser à la place la méthode addObject.
Il reste toutefois que quelqu’un ayant utilisé un certain temps les classes de la JRE de base, ArrayList et autres, aura besoin d’un petit temps d’adaptation.

Trouver des personnes

Abordons finalement un point assez critique: les ressources. Il sera difficile à la plupart des personnes ayant des années d’expérience sur des plateformes J2EE de se former à WebObjects en raison des différences conceptuelles et à l’API s’écartant de celle de Java. Le coup de formation est assez élevé et l’intégration à des processus d’entreprises comme Maven, bien qu’existant, peut s’avérer coûteuse en temps.
En comparaison d’autres framework, WebObjects souffre d’une très faible documentation. Le site d’Apple propose une documentation technique, mais très peu d’autres sites proposent des exemples ou des explications différentes de la version officielle. On se retrouve donc facilement le bec dans l’eau devant un problème dont la solution n’est pas documentée sur le site d’Apple. Une solution existe: la mailing list qui est fréquentée par des experts de la technologie, mais on ne peut évidemment pas abuser et questionner ces personnes en permanence.
Il est très profitable d’avoir au sein de son entreprise une personne expérimentée en WebObjects donc, cependant il s’agit d’une ressource rare. Lors d’un recensement récent, 800 développeurs ont été dénombrés dans le Monde, dont 40 en France. Autant dire qu’il est difficile de se procurer un « expert » dans le domaine, sachant que connaissant la technologie, je ne me considère pas du tout comme un expert, mais un simple utilisateur.

En conclusion, voici un petit récapitulatif de ce billet en avantages/inconvénients.

Avantages

• Framework avec architecture
• Développement propre
• Flexible
• Pensé pour tenir la charge

Inconvénients

• Peu de ressources et très peu d’experts
• Mélange d’API Java/Objective C
• Manque de documentation tierce