Technologies

A la recherche de JEE (3) : suite et fin !

Publié le : Auteur: vhanniet Laisser un commentaire
technologies

Dans les épisodes précédents (1 et 2) j’essayais de comprendre comment JEE se traduisait matériellement sur un poste de travail. En partant du site d’Oracle sur Java, je suis arrivé à quelques librairies Glassfish portant la mention JEE, et notamment glassfish3glassfishlibjavaee.jar.

En cherchant ce que représente cette librairie, je suis tombé sur… ma question en anglais sur stackoverflow (c’est banal). Et sur une réponse claire :
« Java EE is an abstract API. The application server (e.g. Glassfish, JBoss AS, Tomcat, etc) is the concrete implementation. The Java EE download link on oracle.com contains the concrete reference implementation of the Java EE API, which happens to be Glassfish »

En bref : JEE est une spécification dont les instances concrètes sont à chercher dans les serveurs d’applications qui se revendiquent JEE. Ça c’est clair ! Les serveurs en question pour Java 6 sont listés « officiellement »(*) ici.
(*) Il resterait à déterminer s’il existe un processus de certification accepté par tous les membres des JSR/JCP, et si Oracle en est un (le seul ?) responsable

Donc, finalement, quand après avoir navigué sur un site Oracle je me vois proposer l’installation du SDK JEE 6 c’est une (petite) arnaque ! Il n’y a pas de SDK JEE : pour développer en JEE j’ai besoin d’installer un serveur d’application. Il me permettra de développer en JEE certes, mais servira également au run-time. En embarquant bien sûr plein de petites subtilités propres qui font que ce sera probablement toujours du JEE+. Le fait pour un serveur d’application d’être certifié JEE ne veut pas dire qu’il ne propose pas aussi d’autres fonctionnalités complémentaires… Sauf pour Glassfish normalement puisqu’il est l’Implémentation de Référence pour JEE.

Au delà de ces subtilités, JEE propose donc des fonctionnalités clairement spécifiées ici. Et depuis Java 6, JEE introduit la notion de profil qui permet d’isoler un sous-ensemble des fonctionnalités de JEE pour réduire la taille de la plate-forme au plus juste en fonction de l’usage. Un seul profil a été défini en JEE 6 : le profil web (Web profile). Ce qui explique la sous-liste « Web profile » dans la liste des serveurs certifiés JEE.

Au fait, en suivant la trace de JEE chez Oracle j’étais tombé sur le JDK qui permet de développer en Java standard (Java SE). C’était un JDK « Oracle ». D’où ma recherche initiale d’un SDK JEE (sur ensemble de Java SE) chez Oracle. En fait, depuis Java 7, l’implémentation de référence pour Java est… OpenJDK. Un JDK open source est devenu l’implémentation de référence (RI en anglais) pour Java SE ! Lire ici.
Voir aussi l’entrée OpenJDK sur Wikipedia, et quelques considérations sur cet aspect open source de Java.

On peut aussi noter à propos des JDK qu’il est arrivé que certains serveurs d’application proposent leur propre JDK (JBoss par exemple). Java EE 6 essaie de détailler suffisamment les choses pour proposer une API standard pour les EJB dans EJB 3.1. Est-ce suffisant ? Je n’ai pas la réponse…

Voilà donc qui clos la quête de JEE dans les contrées où l’on parle Java. Mais au fait, on n’a pas du tout rencontré Spring au cours de cette balade. Et il paraîtrait qu’on peut opposer Spring et JEE ?! … C’est une autre histoire que vous retrouverez prochainement dans l’épisode « La menace Spring » !

 

Illustration empruntée sur http://www.mikejones.tv/journal/2010/10/4/star-wars-is-not-science-fiction-mad-max-is-not-a-road-movie.html