Frappons le rallye hors route Java EE et la négligence! Entretien avec Sebastian Dashner, commissaire EE de Jakarta

Aujourd'hui dans notre studio virtuel est Sebastian Dashner. En bref, qui est-ce:

• Lead Java Developer Advocate chez IBM;
• De nombreux rapports et vidéos intéressants sur YouTube ;
• L'auteur de Architecting Modern Java EE Applications ,
• Membre du Java Community Process: groupes d'experts JAX-RS, JSON-P, Config;
• Un contributeur dans un tas de projets open source, y compris tout ce qui concerne Java EE / Jakarta EE / MicroProfile.

Dans cette interview, nous parlerons des sujets suivants:

Les interviews sont, comme toujours, réalisées par Evgeny Trifonov ( phillennium ) et Oleg Chirukhin ( olegchir ) du groupe JUG.ru.

Eugene: Commençons par un problème non technique. Sur votre Twitter, j'ai vu une photo de vous à Novossibirsk dans un sweat-shirt JAVA. Quelle est votre impression de ce voyage?

Sebastian: Heureux que vous ayez reconnu la photo, j'ai ce sweat avec Joker 2017. Je me souviens vraiment de la conférence JBreak. Je n'aurais jamais imaginé que j'irais dans un coin aussi éloigné de la Sibérie - je pense que de mon cercle d'amis, je suis l'un des rares à y être allé. De plus, la veille de la conférence, j'ai fêté mon anniversaire et nous sommes allés faire de la motoneige, après quoi nous nous sommes assis dans un bain et avons mangé des brochettes. En général, il y a beaucoup de souvenirs agréables. La nature autour de Novossibirsk est très belle. Et le fait que, si vous comptez Krasnoyarsk et Tomsk, pour un millier de kilomètres autour de vous, il n'y a pas d'autres grandes villes, est très impressionnant.

Eugene: Vous êtes Java Developer Advocate chez IBM. Ce n'est pas une position très courante - les autres défenseurs des développeurs que je connais ont tendance à promouvoir les produits de leur entreprise. Quelles sont vos responsabilités exactes chez IBM? Essayez-vous de maximiser la distribution et l'utilisation efficace de Java de toutes les manières possibles?

Sebastian: Oui, c'est une description assez précise de ce que je fais. Je dois ajouter qu'en premier lieu, je suis dans l'intérêt non pas tant de l'entreprise ou du produit que des développeurs. Je m'efforce de faciliter leur travail et d'enseigner les choses d'une manière ou d'une autre liées à Java Enterprise. Je partage mes connaissances dans des blogs, podcasts, séminaires et conférences. Je ne vends aucun produit en particulier, je vends plutôt la technologie dans son ensemble.

Eugene: Vous êtes un grand partisan de l'open source, mais travaillez pour IBM, qui pour la plupart des gens n'est pas associé à l'open source. Dans le même temps, je sais qu'IBM prend parfois une part assez active dans de nombreux projets open source, par exemple, dans OpenJ9. Quel est le lien entre IBM et l'open source?

Sebastian: Vous avez correctement noté que beaucoup sous-estiment souvent la participation d'IBM à des projets open source - je n'en avais moi-même aucune idée avant de commencer à travailler dans cette entreprise. Par exemple, IBM fait beaucoup de travail dans Cloud Native et Java et est l'un des principaux contributeurs de Kubernetes et Istio. L'accès à la source OpenJ9 a été ouvert par la Fondation Eclipse, qui, à son tour, a été créée par IBM. L'entreprise a également contribué au développement de technologies sans serveur, comme Apache OpenWhisk. En général, les programmeurs IBM sont très ouverts d'esprit - presque tout ce qui se fait dans cette entreprise a un aspect open source ou une version ouverte. Jusqu'à présent, les gens ne sont vraiment pas assez familiers avec les efforts d'IBM dans cette direction, et mon travail en tant que développeur avocat est, entre autres, de tenir la communauté informée.

Oleg: J'ai récemment lu sur Twitter que vous étiez parti en voyage moto spécial JUG au Japon avec Steve Chin. JUG sur les motos, whaaaat? Pourriez-vous nous en dire plus?

Sebastian: C'était un super voyage. Steve Chin et moi avons déjà voyagé à plusieurs reprises sur des motos, et chaque fois nous essayons de combiner cela avec des discours lors de conférences et dans des groupes d'utilisateurs. Plusieurs de ces voyages ont eu lieu en Allemagne et trois au Japon. À première vue, il peut sembler que nous le faisons juste pour le plaisir - et, bien sûr, nous ne pouvons pas nier que nous avons passé un bon moment lors de ces voyages. Mais d'un point de vue purement pratique, une moto est un moyen de transport très pratique pour le Japon ou l'Europe centrale, car les villes avec des groupes d'utilisateurs et une communauté informatique sont situées à seulement cent ou deux kilomètres l'une de l'autre, et vous pouvez éviter les embouteillages sur une moto. Dans chacun de ces voyages, nous avons essayé de rencontrer le maximum de personnes et de partager nos connaissances avec elles.

Oleg: Vous voyagez beaucoup et vous êtes même allé en Russie, même si ce n'est pas si facile d'obtenir notre visa. Il y a une opinion que Developer Advocate n'est pas une profession sérieuse. Comme si vous voyagiez à travers le monde, en vous amusant lors de conférences - n'importe quoi, juste pour ne pas écrire de code. Pensez-vous que vous avez vraiment travaillé dur? Il semble que voler tous les jours devrait être épuisant.

Sebastian: Je pense que les deux points de vue sont un peu juste. J'aime mon travail, mais il est loin d'être toujours simple. L'un n'interfère pas avec l'autre. En effet, les voyages peuvent être épuisants, surtout si vous ne vous reposez pas juste après le déménagement, mais que vous parlez lors d'une conférence ou organisez un séminaire. Et juste après la conférence, vous devez à nouveau monter dans l'avion, donc toute la journée est occupée. D'un autre côté, si cette activité n'était pas emportée, alors le toit irait très vite à un tel rythme, et une personne brûlerait tout simplement. En général, si j'arrive à enseigner quelque chose aux gens et à diriger un séminaire réussi en une journée, alors même la fatigue devient agréable.

Eugene: Pour autant que je sache, ce travail nécessite beaucoup d'efforts afin de rester à jour avec les dernières technologies dans le domaine. En raison des charges de travail supplémentaires pour les promoteurs de développement, cela est plus difficile que pour ceux qui programment constamment. Je sais que vous écrivez régulièrement du code pour Jakarta EE, donc vous ne vous êtes évidemment pas arraché à la technologie. Est-il difficile d'être à la fois un promoteur des développeurs et un développeur?

Sebastian: Oui, bien sûr, pour mon travail, il est très important de rester programmeur, sinon vous perdrez contact avec la réalité. Pour parler de la technologie avec compétence, vous avez besoin d'une expérience constante de travail avec elle. Et le temps de programmation est vraiment beaucoup moins dû aux conférences. De plus, vous devez être vraiment fasciné par l'aspect technique des choses et vous serez prêt à y passer des soirées et des week-ends. En général, un certain équilibre est nécessaire entre les deux côtés de l'activité.

Oleg: Passons aux problèmes techniques. Il y a une épigraphe sur la première page de votre blog:

L'informatique doit être simple et productive.
Le service informatique doit résoudre les problèmes, pas en créer.
Je crois que l'informatique est une chance, pas un facteur de coût.

Quels sont, à votre avis, les facteurs les plus importants déterminant la productivité d'un développeur Java? Y a-t-il des conseils sur la façon d'être plus productif, des hacks de vie, des nishtyaki techniques spécifiques et des utilitaires comme jcmd ou sdkman, quoi que ce soit?

Sebastian: Oui, il existe de nombreux programmes de ce type. Quant à la simplicité, nous parlons de la nécessité de nous efforcer de nous débarrasser de la complexité excessive à la fois dans les outils que nous développons et dans les implémentations où nous utilisons ces outils. Souvent, les développeurs sont attirés par la complexité en soi, de plus en plus de fonctionnalités sont ajoutées au produit uniquement par intérêt sportif. Vous devez toujours vous demander: le monde s'améliorera-t-il grâce à cette fonctionnalité? Aidera-t-il à résoudre tout problème? Cela nous rapprochera-t-il de l'achèvement du produit?

Si nous parlons de la productivité du développeur lui-même, je peux vraiment recommander des ressources pour cela. Google mon nom et l'expression «productivité des développeurs». J'ai enregistré un cours vidéo, qui est publié sur Youtube , et là je donne des conseils uniquement sur ce sujet. Il explique comment utiliser la ligne de commande, les touches de raccourci et comment utiliser le clavier. Le point général est de savoir comment faire plus de travail en moins de temps. Et si vous commencez à approfondir ce sujet, le processus d'automatisation et d'optimisation du travail sera retardé. Vous aurez plus de temps pour réfléchir à la solution du problème et moins - frapperez bêtement aux touches. En général, les performances de programmation sont un sujet très proche de moi.

Oleg: Si je comprends bien, vous êtes un committer dans MicroProfile, et donc vous pouvez tout savoir sur ce sujet. Veuillez nous dire ce qui se passe autour de Java EE et Jakarta? J'ai lu un peu à ce sujet, mais pour moi, en tant que personne du monde printanier, tout cela est trop déroutant.

Sebastian: Comme vous le savez probablement, Jakarta EE est le successeur de Java EE, qui est maintenant transféré à la Fondation Eclipse. C'est un processus assez compliqué, et il n'est pas encore terminé, donc les développeurs ne peuvent pas encore utiliser Jakarta EE. Cependant, la fondation est toujours basée sur les normes Java EE, le point de départ sera Java EE 8. Bien sûr, à l'avenir, Jakarta EE continuera d'évoluer de la même manière que Java EE a évolué à travers le JCP (Java Community Process). Cela signifie qu'une communauté de plusieurs sociétés, sociétés et développeurs individuels développera conjointement des normes pour la nouvelle version d'entreprise de Java.

En raison de ces changements dans Java EE, MicroProfile est né. Il a été créé par plusieurs fournisseurs qui exécutent des serveurs Java EE. L'objectif ici est d'assurer un développement technologique plus rapide, moins lié à des normes strictes. Il me semble très intéressant que MicroProfile essaie de combler les lacunes de Java EE en ce qui concerne les microservices natifs du cloud modernes. Par exemple, Java EE ne dispose pas encore de systèmes pour la configuration injectable, la tolérance aux pannes, la surveillance, toutes sortes d'OpenTracing, etc. MicroProfile vous donne accès à toutes ces choses, vous n'avez donc pas besoin de toutes les implémenter vous-même. De plus, dans presque tous les cas, la compatibilité avec Java EE est respectée. Les normes Java EE (comme JAX-RS et CDI), que la plupart des développeurs JavaEE connaissent déjà, sont prises comme base. Par conséquent, lorsque je trouve la tolérance aux pannes dans mon application Java EE, par exemple, je n'écris pas tout cela manuellement, mais j'intègre MicroProfile à mon application. Ces deux écosystèmes se mélangent très bien. Pour de nombreuses applications, telles que Open Liberty ou Payara, les runtimes prennent en charge à la fois MicroProfile et Java EE. Dans ce cas, il ne reste plus qu'à inclure certaines fonctionnalités dans le runtime, puis à ajouter les projets MicroProfile nécessaires à l'application Java EE. En attendant la transition finale de Java EE vers la fondation Eclipse, vous pouvez utiliser cette solution.

Oleg: Pensez-vous que MicroProfile devrait faire partie de Jakarta?

Sebastian: C'est une excellente question, et il n'y a pas encore de décision finale à ce sujet. Personnellement, je pense que MicroProfile fonctionne mieux comme une sorte d'incubateur pour Jakarta EE. Le nouveau standard est d'abord ajouté à MicroProfile (comme cela a été fait avec OpenTracing ou la configuration injectable), puis nous regardons comment le système se comporte en production. Quand elle atteint la maturité, ces éléments d'elle qui ont fait leurs preuves sont devenus des standards à part entière. Ainsi, nous nous débarrassons de certaines incertitudes, car nous savons déjà si le système fonctionne bien en production ou non.

Oleg: Puisque nous parlions de normes, j'ai vu des processus de spécification Eclipse, c'était un énorme googlodok, qui était très difficile à comprendre. Les documents avec un projet de spécifications de Jakarta EE ressemblaient à un enchevêtrement infernal. Pourriez-vous aider cette balle à se dérouler? Par exemple, en quoi cela diffère-t-il du processus de communauté Java?

Sebastian: Eclipse Foundation est une organisation open source. À l'heure actuelle, nous essayons de déterminer la forme de ces processus selon lesquels Jakarta EE se développera à l'avenir. Vous avez mentionné JCP - donc, je suis entièrement d'accord avec l'opinion selon laquelle les normes de Jakarta EE devraient être calquées sur JCP. Je pense que ce modèle s'est très bien montré. Il convient de garder à l'esprit qu'aucune entreprise n'a le monopole de l'élaboration de normes pour Jakarta EE. Plusieurs entreprises ayant plus ou moins les mêmes droits participent à ce processus, de sorte qu'il ne sera pas bloqué dans le développement si l'une d'entre elles ne peut plus y participer. Je pense que c'est un avantage important, car cette technologie est très importante et il est plus sûr de se développer dans une communauté ouverte.

Oleg: Une technologie aussi sophistiquée doit être testée sur quelque chose. Utilisez-vous des kits de compatibilité technologique pour Java et Jakarta? Ou avez-vous votre propre suite de tests?

Sebastian: C'est aussi un sujet très important. Dans le JCP, tous ces TCK avaient généralement une source fermée. C'était un avantage assez douteux. D'une part, la spécification pouvait fournir des tests qui montraient si une implémentation était valide ou non. Mais le développeur ordinaire ne savait pas exactement ce qui était testé à l'intérieur, quelle était la couverture de ces tests, etc. Maintenant, TCK est devenu open source. Toutes les entreprises et développeurs peuvent désormais participer à leur développement et à leur amélioration. S'il s'avère que le produit d'une entreprise ne fonctionne pas comme indiqué dans le cahier des charges, vous pouvez non seulement l'indiquer à l'entreprise, mais également laisser une demande dans TCK lui-même. Ou encore mieux, vous pouvez envoyer quelques pull-requests et améliorer le TCK lui-même. Vous améliorez ainsi non seulement le logiciel d'un fournisseur, mais l'ensemble de l'écosystème.

Oleg: Il existe un autre produit qui a le mot «Profile» dans son nom: IBM WebSphere Liberty Profile. Puisque vous travaillez chez IBM, pouvez-vous nous dire de quoi il s'agit et quelle est la différence avec Open Liberty?

Sebastian: WebSphere Liberty Profile est une version commerciale d'Open Liberty. Il s'agit du serveur d'applications Java EE pour lequel IBM fournit un support commercial. Je peux me tromper, mais, à mon avis, Open Liberty est devenu open source il y a un an et demi. Grâce à cela, les développeurs d'entreprise disposent désormais d'un serveur d'applications gratuit et testé en production. Si une entreprise a besoin d'une assistance commerciale ou de certaines fonctionnalités commerciales, elle peut utiliser le profil WebSphere Liberty. Nous sommes en 2019, et je pense que maintenant, chaque entreprise devrait fournir une version open source de son produit afin que les développeurs aient la possibilité d'essayer le produit gratuitement. OpenSource est très important et je suis heureux qu'IBM ait maintenant plusieurs options pour l'ancien WebSphere Liberty Server.

Oleg: J'ai entendu dire qu'il est écrit sur OSGi. Pourriez-vous nous en dire plus sur la façon dont il est organisé à l'intérieur?

Sebastian: Personnellement, je n'ai pas développé Open Liberty, mais pour autant que je sache, cela appartient vraiment à OSGi. Il est intéressant de voir que vous pouvez tout simplement configurer les fonctionnalités qui seront incluses. Si vous souhaitez utiliser uniquement MicroProfile, qui ne couvre qu'un petit nombre de normes Java EE, vous pouvez configurer le système en conséquence. Ou vous pouvez faire en sorte que vous ayez une application Java EE complète. Étant donné que seul ce qui est vraiment nécessaire est inclus dans une instance en cours d'exécution, un temps de démarrage optimal et une consommation de ressources minimale sont atteints.

Oleg: La configuration et l'utilisation de Liberty Profile sont-elles différentes de Full Profile? Les mêmes outils sont-ils utilisés dans les deux cas?

Sebastian: Il n'y a pas de différences significatives d'utilisation. Concernant le choix des fonctionnalités, les deux serveurs peuvent être configurés de manière égale. Si vous avez une application Java EE ou MicroProfile, la configuration sera la même pour les deux types.

Oleg: Les entreprises utilisent le profil complet depuis longtemps. Dans quelle mesure l'utilisation de Liberty Profile est-elle justifiée dans les grandes organisations?

Sebastian: Absolument justifié. Même si l'entreprise a acheté un support commercial, cela ne signifie pas qu'elle doit utiliser le profil complet, il est tout à fait raisonnable d'utiliser une version plus légère. Si le produit de la société est basé sur des microservices modernes et des durées d'exécution légères, il pourrait être préférable pour eux de choisir WebSphere Liberty et de le configurer pour qu'il fonctionne, disons, uniquement avec MicroProfile. Heureusement, le support commercial et les fonctionnalités commerciales n'ont rien à voir avec l'ancien monde de WebSphere, donc le runtime lui-même est étonnamment léger et compact, il démarre très rapidement et peut être déployé en quelques secondes. Donc, si vous avez une application moderne basée sur Java EE, vous pouvez configurer vos fonctionnalités en conséquence et inclure uniquement les normes qui sont vraiment nécessaires. Que vous utilisiez ou non des fonctionnalités commerciales, vous avez toujours accès à ce runtime moderne et rapide.

Oleg: En octobre, Oracle a publié Helidon, un cadre de microservices léger en Java. Pour autant que je sache, il n'utilise aucun des serveurs d'applications existants, il est construit au-dessus de son propre ensemble de bibliothèques. Ensemble, ils constituent la base de la création de microservices - fonctionnalités de configuration, paramètres de sécurité, augmentation du serveur Web, etc. En plus de ce système, MicroProfile a même été implémenté. J'ai eu l'impression que les développeurs d'Helidon pensent que Java EE a trop d'héritage et doit être rejeté et réécrit. Qu'en pensez-vous?

Sebastian: Helidon est un projet très intéressant. Mais pour être honnête, il me semble naïf de penser que Java EE doit être complètement réécrit. En effet, la plupart des applications n'ont pas besoin de Java EE dans son ensemble. En règle générale, un ensemble dédié de fonctionnalités / normes est requis, le plus souvent utilisé dans les applications d'entreprise. Par exemple, un MicroProfile standard ne fournit pas encore de JPA ou de scripts complexes pour le multithreading. Cela nécessite au moins certains composants Java EE. En général, je vois maintenant le processus de création d'une application de cette façon. Sur la base des composants les plus importants et modernes de Java EE, par exemple, CDI, JPA, JAX-RS, JTA et ainsi de suite, nous choisissons l'ensemble de normes dont nous avons besoin, tout en ignorant les nombreuses choses héritées qui sont présentes dans Java EE. Sur la base de ce choix, nous prenons le runtime qui prend en charge toutes ces fonctionnalités. Si nous faisons quoi que ce soit lié aux microservices natifs du cloud, nous ajoutons des normes MicroProfile, par exemple, la tolérance aux pannes. Mais un runtime comme Helidon ne prend pas en charge les fonctionnalités qui appartiennent uniquement à Java EE, et en attendant, le multithreading ou JPA sont des fonctionnalités qui, selon mon expérience, sont très nécessaires. Je préférerais un runtime qui prend en charge Java EE / Jakarta EE et Microprofile, et donne en même temps la possibilité de choisir les fonctionnalités nécessaires pour une application particulière. Par exemple, si vous avez besoin de persistance et que vous avez une base de données, vous pouvez activer JPA. En général, vous aurez un ensemble de fonctionnalités très similaire à MicroProfile, mais quelque chose de Java EE sera également nécessaire. Ces types de runtimes sont Open Liberty, Payara, WildFly et ainsi de suite.

Oleg: Pour autant que je sache, l'une des fonctionnalités les plus intéressantes qui seront mises en œuvre à Jakarta dans un avenir proche est la prise en charge des technologies cloud modernes. Et Java dans les conteneurs en ce moment? Pour autant que je m'en souvienne, il y a plusieurs années sur le traqueur de bogues d'OpenJDK, il y avait plusieurs bogues liés à la compatibilité, à la taille du tas, aux signaux, etc. Est-il possible d'utiliser Java dans des conteneurs maintenant, en 2019?

Sebastian: Oui, certainement. La raison de la plupart des problèmes associés à cela n'était pas Java lui-même, mais la façon dont Linux fonctionnait avec les conteneurs. Souvent, le conteneur n'était tout simplement pas au courant des diverses restrictions de ressources qui pouvaient être définies. Dans les versions récentes, ces problèmes ont été résolus. Maintenant, vous pouvez simplement exécuter Java dans le conteneur, et ces options seront activées par défaut. Et si vous demandez la taille de la mémoire dans le système ou la taille de segment par défaut, ces valeurs seront spécifiées correctement. Java EE fonctionne très bien dans les conteneurs Docker et, en général, s'intègre bien aux technologies natives du cloud.

Oleg: Et l'infrastructure? Utilisez-vous quelque chose comme Kubernetes ou Istio?

Sebastian: Oui, assez actif. Docker, Kubernetes, — Istio. Java EE. Cloud-native , , , — , , , ..

: Java EE Kubernetes ? API ?

: Kubernetes Istio . cloud-native . . , Docker, Kubernetes. , - URL, . Kubernetes DNS Istio. . , — -, .

: Java ?

: — Java , . , enterprise- — MicroProfile, cloud-native (Istio, Kubernetes). MicroProfile , . , .

: JPoint « Java Enterprise». ?

: , enterprise-, . — - ; — . Java EE-, , , , .

JPoint. , — . Java-, — .

: . (, «» ). Linux, : ?

: . Linux , , , , . , , . , , . , , . Arch Linux — , . Linux . Ubuntu UI, . — Linux , , , . , , , .

: !

, 5-6 , JPoint «Bulletproof Java Enterprise applications for the hard production life» . Simon Ritter, Kohsuke Kawaguchi, . .
.