Java-J2EE est-il menacé de disparition ?

A travers ce titre provocateur, je veux mettre en évidence le fait que la plateforme Java subit des changements profonds, qui à terme, pourraient remettre en cause sa position de technologie dominante. Au lendemain du rachat de BEA par Oracle, le paysage des éditeurs de logiciels Java se retrouve profondément bouleversé. En effet, Oracle qui était à la traîne sur le marché des serveurs d’applications J2EE se retrouve propulsé par ce rachat au rang d’acteur de tout premier plan.

Au début des années 2000, le marché du serveur d’application était émergent. La spécification J2EE répondait parfaitement aux attentes lorsqu’il s’agissait de mettre en place le socle des futures applications Internet. Aujourd’hui, la plupart des entreprises ont déjà choisi leurs serveurs J2EE, parmi les principaux acteurs du marché (IBM Websphere, BEA Weblogic, Oracle Application Server, …) et nombreuses sont celles qui commencent à considérer ces produits comme une simple commodité. Cela explique le nombre significatif de sociétés qui envisagent de migrer vers des solutions Open-Source nettement moins coûteuses.

Dans ce contexte, le rachat de BEA par Oracle, attise les convoitises et certains éditeurs de plateforme concurrente à J2EE n’ont pas hésité à saisir l’occasion pour faire parler de leurs outils. On peut par exemple citer :

Cependant les utilisateurs de BEA sont généralement satisfaits des produits de la gamme WebLogic. Mais cela va-t-il continuer ? Certains d’entre eux ne vont-il pas profiter du rachat pour reposer la question du choix de serveur J2EE ? Cela dépendra sans doute pour une large part de la stratégie retenue par Oracle. Les paris sont ouverts, WebLogic Server pourrait par exemple être conservé tandis que les produits d’intégration et de portail pourraient être davantage menacés.

Quelques soient les conséquences du rachat de BEA par Oracle, on constate déjà des tendances lourdes dans l’évolution de la plateforme Java / J2EE :

  • Une version 7 de J2SE qui va intègrer des concepts d’avant-garde tels que les closures alors même que les développeurs peinent à mettre à profit les nouveautés de la version 5 (generics, enumerations, boxing),
  • Une norme J2EE v5 qui tarde à être adoptée par certains éditeurs (IBM prend tout son temps pour l’implémenter) alors même que les solutions proposées en matière d’IHM Web (JSF) ne satisfont pas grand monde et que Java est loin de combler son retard sur .NET dans ce domaine,
  • Une communauté OpenSource qui propose des solutions bien souvent plus pragmatiques et plus rapides à développer (Spring, Wicket, GWT, SEAM) que celles préconisées dans la norme J2EE.

La plateforme J2EE, bien qu’à son zénith, voit s’accumuler de nombreux nuages à l’horizon, sans pour autant que SUN ne semble en tenir compte pour le moment. De toute évidence, le principe du conteneur lourd sur lequel la plateforme a été bâtie est en train de devenir une faiblesse, sans pour autant que nous puissions dire dès aujourd’hui quels seront les frameworks gagnants de demain.

Dans tous les cas, les principes de la plateforme J2EE ont du mal à se renouveler et ne satisferont bientôt plus les besoins des DSI. Les équipes d’architecture vont donc devoir commencer à regarder les nouvelles plateformes (Spaces, SCA, OSGi, …) pour assurer, à terme, l’évolution de leurs socles applicatifs.

7 Responses to “Java-J2EE est-il menacé de disparition ?”


  1. 1 Gabriel K. 30/01/2008 à 17:41

    Pourquoi voir la communauté open source comme des nuages sur J2EE? En théorie admettons, Spring vient "contre" j2ee, hibernate contre les entities etc. Mais en pratique c’est bien l’open source qui fait avancer j2ee. Voir jsf 2, les WebBeans, l’introduction de l’IoC dans ejb3 etc.
    De plus il me semble que j5 ne se résume pas à jsf. C’est très vite oublier l’apport important (mais pas nouveau, cf. dot net) des annotations.
    Enfin concrètement comme à peu près tous les projets partent sur hibernate ou un outil de mapping OR, c’est dire qu’ils sont proches de la norme j2ee. Je ne pense pas qu’il faille voir de la même manière qu’avant la plateforme j2ee. Les clients aussi sont plus mûres d’ailleurs et savent mieux calibrer leur désir. Cela ne rend personne malade de ne pas utiliser toute la pile de services. J’ai plutôt l’impression qu’on est rentré dans une phase de plus grande maturité dans l’utilisation et le développement de j2ee.

  2. 2 plem 31/01/2008 à 11:30

    Je ne partage pas l’affirmation que "La plateforme J2EE, bien qu’à son zénith". Ni hélas qu’on entre dans une phase de maturité. Pour avoir suivi cette plateform depuis le début, j’estime que le zenith était la version 1.4. Depuis c’est le déclin. Nombre pléthorique d’API qui personne ne maîtris dans sons ensemble. Inovation douteuse et contradictoire avec le principe des annotations qui contredit l’externalisation du paramétrage pronée jusque là. Pour moi, le vrai prograis, consisterait de la part de la communauté Java à reconnaître l’obésité de la plateforme et de revenir à une pratique de la programmation plus sobre. Moins d’API mais plus de patterns véritablement maîtrisés. Abandonner l’idée, quand même assez simpliste, que l’encapsulation en couche finira par réduire la complexité. Je n’y crois pas. Pour moi le progrès consisterais en 2 points essentiels: 1. Abandonner l’accumulation des Spring, Hibernate, JSF, JAAS, EJB, Struts, j’en passe et des meilleurs pour le remplacer par une approche plus sobre de la programmation. Une approche où l’énergie investie dans un apprentissage de technos volatiles serait remplacée par une compréhension profonde de quelques principes simples (injection de dépendance, pattern d’accès aux données, transactions, etc…) qui seraient véritablement maitrisé par les techos. 2. Le deuxième point de progrès serait de reconnaitre que les abstractions de bases d’un langage comme Java (issu largement de C++) ne sont pas les bonnes et qu’une encapsulation sans fin de ces mauvaises abstractions ne constitue pas une solution. La solution nécessite selon plus d’imagination qu’encapsuler des API. Elle nécessite l’invention de nouveau concepts. Peut être quelque chose comme les DSL. Ou des concepts de nature plus graphiques. A ce titre je troue un peu consternant qu’un concept aussi important qu’une transaction soit encapsulée dans un concept aussi obscure qu’un UserTransaction. Non: une transaction devrait être représentée graphiquement en parrallèle avec d’autres. On pourrait faire des remarques similaires pour l’expression de règles métier ou la définition d’IHM. En 2008 définir des backing beans avec des mappins XML pour lesquels ils faut 3 plugins 5 wizzard qui on une chance sur 10’000 d’être compatibles entre eux ? Soyons sérieux ! Mon slogan : des idées plutôt que de l’encapsulation !

  3. 3 Gabriel K. 31/01/2008 à 14:33

    Pour appuyer mes propos voir l’article de ce matin dans http://www.javaworld.com http://www.javaworld.com/javaworld/… Et la présentation qui en est faite:
    JavaWorld’s Enterprise Java Alert The biggest story for many Java developers this week has been the acquisition of Covalent Technologies by SpringSource. Covalent is a support provider for developers using Apache Software Foundation software, including Tomcat and Apache HTTP. The merge, which combines the support infrastructure for the two open source projects, should be a boon to developers already committed to the Spring stack approach to Java enterprise development. It could also increase the number of developers adopting Spring as an alternative to Java EE and opting to use Tomcat as a lightweight application server. The evolution of Spring has taken an interesting turn this week — one that few had anticipated. Some, including SpringSource CEO Rod Johnson, have pointed to more twists down the road, when (and if) profiles become a reality in Java EE 6. Profiles, which would allow developers to utilize particular subsets of the Java EE stack, point to a change of direction for the platform. The gradual shift away from the one-size fits all approach, which demands a complete Java EE implementation for every occasion, would instead allow developers to build on top of the Java EE infrastructure. The first profile proposed for Java EE 6 is aimed at Web application developers, inviting speculation about potential combinations of the Spring Framework and Java EE.

  4. 4 Frédéric TU 31/01/2008 à 23:00

    Bonjour à tous, Je suis content que cette tribune succite des commentaires car je suis intéressé par la vision que les gens ont de la plateforme de demain.
    Ou plus exactement, les compétences de demain car même si JavaEE reste toujours une compétence nécessaire sur le CV, il n’est plus suffisant au jour le jour sur les projets! Evidemment que l’open source ou des initiatives externes ont toujours mener en avant les évolutions de J2EE, mais il y avait encore la notion sacro sainte de J2EE était LA plateforme. Actuellement, beaucoup d’initiative crédible pour une mise en prod font SANS J2EE et là est la nouveauté… Concernant la plateforme 1.4 qui est le zenith de J2EE, en effet, la précision est bonne car c’est bien la version 1.5 ou plutot JavaEE 5.0 qui est à la traine au point de vue adoption par les clients et même par IBM?
    Sur ton point 1, évidemment les principes de bases sur l’injection de dépendance, separation of concern, segregation, open close principles, … concerne les bonnes pratiques du développement, mais je pense que les demandes passeront tj par le besoin d’apprendre les librairies car c’est ce qui se retrouve sur le CV donnant une visibilité pour les recruteurs d’identifier des mots clés… Sur le point 2, tu as bien raison, cacher la poussière sous le tapis ne permet pas de continuer et il faut changer ces pratiques.

  5. 5 plem 01/02/2008 à 09:31

    Je rembondis sur le commentaire de Frédéric "Actuellement, beaucoup d’initiative crédible pour une mise en prod font SANS J2EE et là est la nouveauté…" C’est à mon sens un peu excessif car je vois mal comment il serait possible de se passer de la notion de servlet par exemple. Il y a deux ans j’ai écrit un petit essai sur une solution un peu moins radicale que j’ai intitulé "Essential Java". L’idée était de définir une sorte de label de qualité qui garantirait qu’un projet n’utilise dans sa conception qu’un nombre minimal et déterminés d’API jugée essentielles. J’ai fait des propositions concrêtes et analyse un peu l’incessante "obésification" de J2EE. L’article toute fois est trop long pour figurer dans un commentaire.

  6. 6 Gabriel K. 02/02/2008 à 13:03

    "Evidemment que l’open source ou des initiatives externes ont toujours mener en avant les évolutions de J2EE, mais il y avait encore la notion sacro sainte de J2EE était LA plateforme. Actuellement, beaucoup d’initiative crédible pour une mise en prod font SANS J2EE et là est la nouveauté…" une question et une remarque:
    – Est-ce que tu veux parler de "toute la pile" j2ee? ejb (y compris entities), jms, javamail etc ? Ou simplement un deux éléments de j2ee? Est-ce que pour toi un tomcat qui embarque jms ou ejb3 est un projet j2ee? Est-ce que tu fais une différence entre un war qui tourne sur tomcat ou le même war qui tourne sur jboss? Pourtant l’un est un serveur full j2ee et l’autre pas. La définition d’un projet j2ee est à mon sens un peu vague. C’est la modularité et la complémentarité qui est un des avantages cachés de j2ee. (et c’est un spring-addicted qui écrit ça). ceci dit, l’apport d’un contexte d’exécution est et reste plus qu’intéressant. – Deuxio: ce qui est marquant c’est que java accepte maintenant que de bonnes idées vienne de l’open source. De la négation ou le mépris ils sont passés à la collaboration. Auparavant c’était j2ee qui menait la danse et pas l’OS. Il y a peu de temps on parlait de l’open source comme des "médicaments génériques" comparé aux vrais médicaments, et aux vrais produits, qui sont propriétaires. Cela a mis beaucoup de temps à changer. On est passé par l’acceptation de struts, puis longtemps après spring, hibernate etc etc. et hors j2ee : linux oracle sur linux, etc.

  7. 7 Frédéric Tu 05/02/2008 à 15:15

    Il est vrai que la notion de J2EE est pas clair et elle permet d’être vue sous différents angles : Package de déploiement, API, norme d’implémentation des serveurs d’application, … La notion de packaging est excellente, un WAR, EAR ou JAR; la granularité des applications est claire et les choses bien définies. De plus, l’existant permet aux applications d’être déployés sur des architectures en cluster, et de bénéficier des synchronisations déclaratives (et même sur ce point des plateformes OSGi commencent à devenir crédible). Actuellement, la question se pose un peu plus au niveau de la plateforme de développement, je sous entend l’API qui est sensée offrir les éléments nécessaires à un bon développement. Je ne dis pas qu’il se prétend exhaustif (iText.jar inclus pour faire du PDF est une trés bonne idée), CEPENDANT en ce qui concerne la gestion des transactions, des connexions, la plateforme EJB (Session, Entity), on était sensé s’appuyer sur la norme afin de formaliser les services. Déjà à l’époque, l’utilisation des EJB provoquait un surcoût de développement, car il se basait sur un modèle intrusif. L’utilisation des transactions maintenu par le contener obligeait l’utilisation des EJBs, … Comme tu dis, c’était une plateforme complète mais je trouve que les techno étaient un peu trop couplées (avec mon oeil actuelle, tj plus facile de voir après coup). Actuellement, avec tous les nouvelles fonctionnalités non intrusives, il est parfois préférable d’utiliser les mini contenaires comme Spring, pour résoudre les problématiques de manière plus "moderne" : gestion des transactions par déclaration, gestion des connexions JDBC ou de mapping O/R à travers spring (gestion des exceptions en runtime exception), OU même couplée avec d’autre librairies modernes Acegi pour la sécurité appliquée à travers le contener Spring, …Sinon le seul vrai cas d’utilisation indéniable est l’utlisation des servlets qui est qu’une petite partie de la norme J2EE et qui cache un mamouth… 😉


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s




Mises à jour Twitter

Erreur : Twitter ne répond pas. Veuillez patienter quelques minutes avant d'actualiser cette page.

Entrer votre adresse e-mail pour vous inscrire a ce blog et recevoir les notifications des nouveaux articles par e-mail.

Rejoignez 29 autres abonnés

Catégories

Statistiques

  • 64 124 hits

%d blogueurs aiment cette page :