Administrateur Système Linux / Java / Cloud Vous devrez assurer l’administration système et réseau courante de notre infrastructure et de celle dédiée à nos clients. Vous serez impliqué dans la résolution de problèmes pointus liés à l’exploitation de ces infrastructures. En savoir plus à propos de Administrateur Système Linux / Java / Cloud » Experts […]

Détail du poste : Un peu en  interne, souvent en mission, vous partagerez votre temps entre des activités directement liées à l’image d’Ippon Technologies et des projets de services mobiles pour les clients d’Ippon Technologies. En interne: Après un travail sur l’identité de marque de l’entreprise (charte graphique et déclinaison sur les différents supports de […]

Cet article fait partie d’une série sur les technologies incluses dans Java EE 6. Vous pouvez également lire l’article d’introduction de cette série : Java EE 6 ici et maintenant et celui sur JSF : JSF je t’aime, moi non plus

L’une des technologies les plus populaires dans le monde Java EE est sans aucun doute JPA. Il suffit de voir le nombre de livres et d’articles sur le sujet. Toutefois, si JPA est très répandu, il s’agit aussi de l’une des spécifications Java EE les moins bien maîtrisées par les développeurs et donc une source récurrente d’échecs des projets. Fort de ce constat je ne vais pas m’apesentir sur les nouveauté de JPA 2.0 dans ce post (en dehors de l’API criteria, celles-ci sont pluôt à la marge) pour me permettre de faire un retour aux sources sur JPA qui pourra profiter à certains. Ceux qui pensent maîtriser ces concepts pourraient être quand même intéressés par la fin de la’article qui traite de l’extended persistence context et de ses mérites.

Logo JavaUtilisateur de Java EE 6 depuis quelques mois et de certaines technologies comme EJB 3 et JSF depuis plusieurs années, j’ai décidé de faire un petit retour d’expérience et de me lancer dans une série de posts sur les principales spécifications de Java EE 6.
J’étais en train de concevoir une ébauche de plan pour mes articles lorsqu’une question s’imposa à moi : “comment se faisait-il qu’en 2011, après plus d’un an d’existence, on en soit encore à essayer de convaincre la majorité des développeurs à prendre connaissance de cette technologie ?”. Cette question constitue un point d’entrée intéressant pour l’ensemble des spécifications en particulier et pour la spécification Java EE en général. C’est donc en évoquant les multiples freins, idées reçues et obstacles réels à l’adoption de Java EE que je me propose de vous présenter ce standard (encore) confidentiel.

Le 10 décembre 2009, après plus de 3 ans de travail du JCP, les spécifications Java Enterprise Edition 6 sont sorties de leur longue maturation. Cette dernière mouture très prometteuse apporte enfin une solution d’injection de dépendance légère et élégante pour des architectures modernes : la spécification CDI (Context and Dependance Injection) qui permet de travailler avec des « managed beans » (pojos gérés par un conteneur léger) et des EJB 3.1.

Une révolution ? Pas vraiment, puisque depuis près de 6 ans le Framework Spring proposait déjà une solution de ce type. Sachant que Spring source (VMware) est un membre actif du JCP et a participé à l’élaboration certaines JSR, il est légitime de se demander pourquoi l’implémentation de référence de la solution de CDI de Java EE 6 n’est pas Spring. S’agit-il d’une erreur de stratégie de la part de l’éditeur ou d’un calcul délibéré pour rester le challenger d’un standard très proche en terme de simplicité et de fonctionnalités ?