BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Actualités Q&A avec le vice-président Oracle du développement logiciel Anil Gaur sur la version Java EE 7

Q&A avec le vice-président Oracle du développement logiciel Anil Gaur sur la version Java EE 7

Favoris

Oracle lance officiellement Java EE 7 avec un webcast. Avant sa publication, InfoQ a rencontré Anil Gaur, vice-président du développement logiciel chez Oracle, pour en savoir plus sur ce communiqué et les futurs projets.

InfoQ : Etant donné qu'il s'agit de la première version de Java EE depuis que Oracle a repris les rênes, est-ce que le processus a été différent de la version EE 6 ?

Nous avons développé l'implémentation de référence de Java EE comme projet open source depuis la Java EE 5, dans le cadre du projet Glassfish. Sous la direction d'Oracle, le processus JCP est également devenu plus transparent. Oracle et les membres du JCP souhaitent fortement travailler avec la grande communauté de développeur Java dès le début du processus, afin qu'ils puissent examiner et commenter les spécifications qui sont développées. Nous avons déposé la JSR 348 pour définir les règles selon lesquelles une JSR doit être exécutée d'une manière transparente. Toutes les JSR dirigées par Oracle suivent maintenant ce processus. Les groupes d'experts ont des alias d'e-mail ouverts pour les discussions et les projets de spécifications provisoires sont visibles sur les pages du projet. Toutes les spécifications Java EE 7 ont été développées selon la JSR 348 avec la participation de la communauté au sens large, en plus des groupes d'expert JCP et des vendeurs Java EE. Je suis heureux de dire que cette transparence a vraiment bien fonctionné et nous avons constaté une augmentation significative de la participation communautaire pour cette version.

InfoQ : Avec l'abandon du support du cloud, y a-t-il un autre thème global pour Java EE 7 ?

Il y a en fait 3 thèmes importants que nous avons suivis pour Java EE 7 :

1) Délivrer des applications HTML5 dynamiques et scalables

Les développeurs ont rapidement adopté HLML5 pour créer une expérience utilisateur plus riche dans les navigateurs. Pour faciliter ça, nous avons introduit le support des WebSockets comme un moyen de créer un canal de communication bi-directionnel à faible latence entre le serveur Java EE et le navigateur sur lequel l'utilisateur possède le protocole de communication. Pour les services RESTful sur HTTP, en revanche, nous avons lancé une API pour améliorer la scalabilité permettant l'exécution de la logique métier en tâche de fond, ainsi cela évite qu'elle soit bloquée sur un thread. La plupart du temps les services RESTful échangent les informations en se servant du JSON. Java EE 7 introduit JSON Processing API pour parser les données au format JSON en utilisant comme approche StAX et "DOM object-model". Enfin, JSF a adopté le balisage JSF-friendly, cela signifie que les pages JSF peuvent désormais être rendues directement dans un navigateur web, sans avoir à exécuter une application JSF juste pour voir à quoi ressemble la page rendue.

2) Augmenter la productivité des développeurs

Java EE 7 apporte des améliorations de productivité importantes pour les développeurs. Par exemple, nous avons réduit la quantité de code réutilisable requise avant que les développeurs puissent se concentrer sur la logique métier. Par exemple, JMS 2.0 exploite les annotations, l'injection de dépendance, AutoCloseable, une API simplifiée, et des ressources fournies par défaut afin de réduire l'effort nécessaire pour simplement placer un message dans une file d'attente, avec seulement quelques lignes de code. Les ressources par défaut comme les fabriques de connexions et les sources de données ont une définition par défaut, afin que le déploiement d'une application à un runtime Java EE nécessite moins de configuration. Une fonctionnalité très demandée, que nous avons ajoutée, est une API cliente RESTfull standard pour que les développeurs puissent faire des appels RESTfull de façon productive sans avoir besoin d'une API cliente propriétaire. Nous avons également fait beaucoup de travail pour améliorer l'intégration des JSRs, et pour faire de Java EE 7 une plate-forme encore plus intégrée. Bean Validation, par exemple, peut maintenant être utilisé dans la signature d'une méthode pour valider un paramètre et les valeurs retournées. Et les transactions gérées par le conteneur sont maintenant disponibles en dehors des EJBs. Les intercepteurs transactionnels et la nouvelle annotation @Transactionnal permettent aux transactions d’être appliquées à n'importe quelle méthode managée, ce qui la rend transactionnelle. Enfin, CDI est activé par défaut, ce qui rend un fichier bean.xml inutile pour simplement utiliser un bean CDI.

3) Satisfaire les exigences d’entreprises les plus difficiles.

Deux nouvelles JSRs répondent à certaines exigences d'entreprises assez importantes. La première est une API de batch, qui était dirigée par IBM. L'API de Batch est la mieux adaptée pour les taches non interactives, bulk-oriented et de longue durée ou qui effectuent des calculs intensifs. Nous pensons que cette API va beaucoup plaire aux entreprises. En plus de l'API de Batch, nous avons également ajouté l'API utilitaire pour la concurrence (Concurrency Utilities API) pour exécuter plusieurs tâches en parallèle. Java EE est un environnent managé, afin que les applications ne soient pas autorisées à créer leurs propres threads. La Concurrency Utility API permets de créer des pools de threads exécutant des taches simultanément.

InfoQ : JCache a raté la deadline de EE 7. Est-ce que ça signifie que vous devrons attendre EE 8, ou peut-il être potentiellement abandonné et utilisé sur un serveur standard Java EE 7 ?

Nous travaillons à finaliser l'API JCache bien avant Java EE 8 et prévoyons une amélioration progressive de la plate-forme pour permettre aux développeurs d'utiliser la nouvelle API au-dessus de Java EE 7.

InfoQ : La combinaison des beans managés de Java EE 6 et du modèle de programmation basé sur les annotations introduit dans la version 5 de la plate-forme EE permettait aux développeurs de choisir parmi l'un des services proposés par le conteneur EE sur n'importe quel composant. EE 7 a-t-il continué à miser sur cette idée ?

Oui, nous continuons à aller dans cette direction. Le meilleur exemple est l'alignement global des bean managés dans Java EE. Les intercepteurs transactionnels, dont j'ai déjà parlé, sont un exemple pour lequel vous pouvez appliquer des transactions d'une manière beaucoup plus souple. Bean Validation est plus répandu - utilisez-les si vous en avez besoin. La spécification JSF recommande fortement d'utiliser les beans CDI par exemple, au lieu d'utiliser des managed beans. Et les beans CDI sont activés par défaut, et là encore, il suffit de les utiliser si vous en avez besoin.

InfoQ : Une autre fonctionnalité clé de Java EE 6 était les extensions portables. Ont-elles été plus exploitées dans EE 7 ?

Les extensions portables sont utilisées partout, à la fois à l'intérieur de Java EE et dans les applications utilisateur. Dans Java EE 7, JMS, Bean Validation, et JTA ont toutes des extensions portables. Il y a aussi un projet Apache appelé DeltaSpike qui est exclusivement consacré aux extensions portables. HK2 (dans Glassfish) utilise une extension portable qui permet au code client d'utiliser CDI pour injecter des services HK2.

Il y a eu inévitablement une certaine controverse autour de Java EE 7. JCache et les fonctionnalités de cloud étant retardées, la London Java Community a accusé la spécification Java Message Service 2.0 d'être peu ambitieuse, lors de la publication du bulletin de la version finale.

La LJC soutient le travail technique effectué dans le cadre de cette JSR, mais estime que, compte tenu des innovations apportées en termes de messagerie depuis la sortie de JMS 1.1, cette JSR aurait pu être plus ambitieuse et avoir une portée plus large. La LJC considère qu'en termes de messagerie une normalisation plus poussée est possible et souhaitable, et demande instamment aux membres JCP intéressés d'explorer les possibilités dans ce domaine.

InfoQ a contacté Ben Evans et Martijn Verburg pour en savoir plus. Evans nous a confié :

J'avais à l'esprit des idées comme :

  • des topologies de messagerie peer-peer
  • des formats de messagerie compatibles "wire"
  • AMQP
  • des progrès sur une latence ultra faible

De plus, j'ai senti que l'EG était trop timide dans son approche pour mettre à jour l'API, avec par exemple l'absence de générification.

Verburg a ajouté :

Une chose qui est extrêmement appréciée dans l’industrie d'aujourd'hui, ce sont les protocoles de communications qui ne vous enferment pas dans un langage particulier ou une plate-forme particulière. Ceci est particulièrement important dans l'écosystème de plus en plus fragmenté du monde de la programmation. Dans de nombreux cas, une file d'attente ou un bus de message est conçu pour avoir une séparation architecturale et c'est en les verrouillant dans une démarche Java spécifique que vous donnez aux gens une vraie raison technique d'éviter complètement la technologie.

Donc les éléments comme l’interopérabilité sont un des aspects que nous aimerions voir améliorés.

Il y a aussi d'autres variétés d'architectures de messagerie plus légère dans le monde de la JVM et il serait utile de voir une version dégrossie de JMS qui ne contienne pas tout l'attirail existant.

Cela dit, nous pensons qu'il y a des améliorations importantes de la productivité pour les développeurs avec JMS 2.0, et nous leur conseillons vivement de migrer le plus rapidement possible.

Voici ce que Gaur nous a expliqué :

JMS 2.0 a subi une importante cure de jeunesse dans Java EE 7. Nous croyons qu'il y a toujours de la place pour l'amélioration, et nous allons continuer à travailler à l'évolution de la spéc JMS. Les points différés seront réévalués par le Groupe d'Expert pour la prochaine version. En outre, lorsque la feuille de route de Java EE 8 sera un peu plus claire, nous inviterons les membres de la communauté à faire part de leurs propres propositions pour la prochaine version de JMS. J'espère que la London Java Community sera en mesure d'y participer dès le début.

Enfin, nous avons demandé à Gaur quelles fonctionnalités sont envisageables dans Java EE 8, en suggérant le NoSQL et un framework web orienté action (action-orientated).

Bien que les fonctionnalités de Cloud de Java EE 7 ont été principalement reportées aux prochaines versions, il y en a certaines qui sont incluses. Par exemple, une application peut maintenant définir les autorisations de sécurité dont elle a besoin dans un fichier permissions.xml qui est embarqué avec l'application. Si le runtime Java EE ne peut honorer ces autorisations, le déploiement échouera. C'est une bien meilleure option que de simplement crasher au runtime ! Les ressources définies par défaut, que je mentionnais plus tôt, sont également utiles dans un environnement de cloud computing, où l'application déployée peut simplement s'appuyer sur ces définitions par défaut établies par le prestataire PaaS, comme un mapping en tant que ressources pour une base de données. La génération de schémas a été ajoutée dans JPA 2.1, ainsi le déploiement d'une application dans un environnement cloud peut aussi générer le schéma de la base de données et la pré-remplir. Nous continuons nos recherches pour que les applications qui seront déployées sur Java EE dans des environnements cloud soient plus portables à mesure que nous avançons sur Java EE 8.

Pour le NoSQL, nous voulons éviter de standardiser prématurément une zone qui est toujours en cours d'innovation et de changement, c'est donc à déterminer. Nous allons continuer à travailler sur certaines JSR qui progressent déjà, comme JCache, la gestion d'état et le binding JSON. Nous envisageons un service de configuration qui améliore l'expérience DevOps sur ce que propose déjà Java EE. A haut niveau, il s'agit de séparer les artefacts de configuration des artefacts de développement, afin que par exemple, une configuration différente puisse être appliquée à des environnements de développement, de test et de production sans affecter les artefacts de développements. Nous gardons vraiment le cloud à l'esprit puisque nous voulons pouvoir "écrire une fois, exécuter partout" (Write Once Run Anywhere), et appliquer au cloud ce que faisons déjà dans les datacenters. Je pense que l'autre partie que nous allons étudier, vous venez d'y faire allusion, concerne l'amélioration de l'expérience pour les développeurs web. Nous avons fait des progrès significatifs dans Java EE 7 et nous savons qu'il y a encore du travail pour améliorer l'expérience de développement de bout en bout des applications mobiles / desktop développées avec Java EE.

Vous pouvez en savoir plus sur Java EE dans ce webcast.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT