Vamos bater em rali e desleixo do Java EE! Entrevista com Sebastian Dashner, Comissário de EE de Jacarta

Hoje em nosso estúdio virtual é Sebastian Dashner. Em suma, quem é esse:

• Líder Java Developer Advocate na IBM;
• Muitos relatórios e vídeos interessantes no YouTube ;
• O autor de Architecting Modern Java EE Applications ,
• Membro do Java Community Process: grupos de especialistas JAX-RS, JSON-P, Config;
• Confirmador em vários projetos de código aberto, incluindo tudo relacionado ao Java EE / Jakarta EE / MicroProfile.

Nesta entrevista, falaremos sobre os seguintes tópicos:

As entrevistas são, como sempre, por Evgeny Trifonov ( phillennium ) e Oleg Chirukhin ( olegchir ) do Grupo JUG.ru.

Eugene: Vamos começar com uma questão não técnica. No seu Twitter, vi uma foto sua em Novosibirsk com um moletom JAVA. Qual é a sua impressão desta viagem?

Sebastian: Que bom que você reconheceu a foto, eu tenho essa camiseta com o Joker 2017. Eu definitivamente me lembro da conferência do JBreak. Eu nunca teria imaginado que iria a um canto tão distante da Sibéria - acho que do meu círculo de amigos sou um dos poucos que já esteve lá. Além disso, no dia anterior à conferência, comemorei meu aniversário e fomos andar de snowmobile, depois nos sentamos em uma casa de banhos e comemos kebabs. Em geral, existem muitas lembranças agradáveis. A natureza ao redor de Novosibirsk é muito bonita. E o fato de que, se você contar com Krasnoyarsk e Tomsk, por mil quilômetros ao seu redor, não há outras cidades importantes, é muito impressionante.

Eugene: Você é Java Developer Advocate na IBM. Essa não é uma posição muito comum. Outros advogados que conheço tendem a promover os produtos da empresa. Quais são suas responsabilidades exatas na IBM? Você está tentando maximizar a distribuição e o uso eficiente de Java de todas as maneiras possíveis?

Sebastian: Sim, esta é uma descrição bastante precisa do que faço. Devo acrescentar que, em primeiro lugar, sou do interesse não tanto da empresa ou do produto, mas dos desenvolvedores. Esforço-me para facilitar o trabalho deles e ensinar coisas de uma maneira ou de outra relacionadas ao Java Enterprise. Compartilho meu conhecimento em blogs, podcasts, seminários e conferências. Não vendo produtos específicos, mas vendo a tecnologia como um todo.

Eugene: Você é um grande defensor do código aberto, mas trabalha para a IBM, que para a maioria das pessoas não está associado ao código aberto. Ao mesmo tempo, eu sei que a IBM às vezes participa ativamente de muitos projetos de código aberto, por exemplo, no OpenJ9. Como a IBM se relaciona com o código aberto?

Sebastian: Você observou corretamente que muitas vezes subestimam a participação da IBM em projetos de código aberto - eu mesmo não fazia ideia disso até começar a trabalhar nesta empresa. Por exemplo, a IBM trabalha muito no Cloud Native e no Java e é um dos principais contribuidores do Kubernetes e do Istio. O acesso à fonte OpenJ9 foi aberto pela Eclipse Foundation, que, por sua vez, foi criada pela IBM. A empresa também contribuiu para o desenvolvimento de tecnologias sem servidor, como o Apache OpenWhisk. Em geral, os programadores da IBM são muito abertos - quase tudo o que está sendo feito nesta empresa tem um aspecto de código aberto ou uma versão aberta. Até agora, as pessoas realmente não estão familiarizadas o suficiente com os esforços da IBM nessa direção, e meu trabalho como Advogado de Desenvolvedor é, entre outras coisas, manter a comunidade informada.

Oleg: Li recentemente no Twitter que você fez uma viagem especial de moto JUG no Japão com Steve Chin. JUG em motocicletas, o que? Você poderia elaborar isso?

Sebastian: Foi uma ótima viagem. Steve Chin e eu já viajamos de motocicleta várias vezes, e cada vez que tentamos combinar isso com discursos em conferências e em grupos de usuários. Várias dessas viagens foram na Alemanha e três no Japão. À primeira vista, pode parecer que estamos fazendo isso apenas por diversão - e, é claro, não podemos negar que nos divertimos muito nessas viagens. Mas, do ponto de vista puramente prático, uma motocicleta é uma forma muito conveniente de transporte para o Japão ou a Europa Central, porque existem cidades com grupos de usuários e uma comunidade de TI localizadas a apenas cem ou dois quilômetros de distância e você pode evitar engarrafamentos em uma motocicleta. Em cada uma dessas viagens, tentamos encontrar o número máximo de pessoas e compartilhar nosso conhecimento com elas.

Oleg: Você viaja muito e até foi para a Rússia, embora não seja tão fácil obter nosso visto. Há uma opinião de que o Developer Advocate não é uma ocupação séria. Como se você estivesse viajando pelo mundo, se divertindo em conferências - qualquer coisa, apenas para não escrever código. Você acha que tem muito trabalho? Parece que voar todos os dias deve ser cansativo.

Sebastian: Eu acho que os dois pontos de vista estão um pouco certos. Gosto do meu trabalho, mas está longe de ser sempre simples. Um não interfere no outro. De fato, as viagens podem ser cansativas, principalmente se você não descansar logo após a mudança, mas falar em uma conferência ou organizar um seminário. E logo após a conferência, você precisa embarcar no avião novamente, para que o dia inteiro seja ocupado. Por outro lado, se essa atividade não fosse levada adiante, o teto sairia muito rapidamente desse ritmo, e uma pessoa simplesmente queimaria. Em geral, se eu conseguir ensinar alguma coisa às pessoas e conduzir um seminário de sucesso em um dia, até o cansaço se torna agradável.

Eugene: Até onde eu sei, este trabalho exige muito esforço para manter-se atualizado com as mais recentes tecnologias em campo. Devido às cargas de trabalho adicionais do Developer Advocates, isso é mais difícil do que para aqueles que programam constantemente. Sei que você escreve regularmente códigos para o Jakarta EE, portanto, obviamente, não se afastou da tecnologia. É difícil ser um advogado do desenvolvedor e um desenvolvedor ao mesmo tempo?

Sebastian: Sim, é claro, para o meu trabalho é muito importante continuar programador, caso contrário você perderá o contato com a realidade. Para falar sobre tecnologia com competência, você precisa de experiência constante trabalhando com ela. E o tempo de programação é realmente muito menor devido às conferências. Além disso, você precisa ser verdadeiramente fascinado pelo lado técnico das coisas e estará pronto para passar as noites e fins de semana nele. Em geral, é necessário um certo equilíbrio entre os dois lados da atividade.

Oleg: Vamos para questões técnicas. Há uma epígrafe na primeira página do seu blog:

A TI deve ser simples e produtiva.
A TI deve resolver problemas, não criar problemas.
Acredito que a TI é uma chance, não um fator de custo.

Na sua opinião, quais são os fatores mais importantes para determinar a produtividade de um desenvolvedor Java? Existem dicas de como ser mais produtivo, hackers, nishtyaki técnicos específicos e utilitários como jcmd ou sdkman, qualquer coisa?

Sebastian: Sim, existem muitos programas desse tipo. Quanto à simplicidade, estamos falando sobre a necessidade de nos livrarmos da complexidade excessiva, tanto nas ferramentas que desenvolvemos como nas implementações em que usamos essas ferramentas. Muitas vezes, os desenvolvedores são atraídos pela complexidade em si, mais e mais recursos são adicionados ao produto apenas por interesse esportivo. Você sempre precisa se perguntar: o mundo ficará melhor com esse recurso? Ajudará a resolver qualquer problema? Isso nos aproximará da conclusão do produto?

Se falarmos sobre a produtividade do próprio desenvolvedor, eu realmente posso recomendar recursos para isso. Pesquise no Google meu nome e a frase "produtividade do desenvolvedor". Gravei um curso em vídeo, que é postado no Youtube , e lá dou conselhos apenas sobre esse tópico. Ele fala sobre o uso da linha de comando, teclas de atalho e como usar o teclado. O ponto geral é como fazer mais trabalho em menos tempo. E se você começar a se aprofundar neste tópico, o processo de automação e otimização do trabalho será atrasado. Você terá mais tempo para pensar na solução do problema e bater menos estupidamente nas teclas. Em geral, o desempenho da programação é um tópico muito próximo de mim.

Oleg: Pelo que entendi, você é um colaborador do MicroProfile e, portanto, pode saber tudo relacionado a ele. Por favor, conte-nos o que está acontecendo em torno do Java EE e Jacarta? Eu li um pouco sobre isso, mas para mim, como pessoa do mundo da primavera, tudo isso é muito confuso.

Sebastian: Como você provavelmente sabe, Jakarta EE é o sucessor do Java EE, que agora está sendo transferido para a Eclipse Foundation. Este é um processo bastante complicado, e ainda não foi concluído, portanto os desenvolvedores ainda não podem usar o Jakarta EE. No entanto, a base ainda é baseada nos padrões Java EE, o ponto de partida será o Java EE 8. É claro que, no futuro, o Jakarta EE continuará a evoluir da mesma maneira que o Java EE evoluiu através do JCP (Java Community Process). Isso significa que uma comunidade de várias empresas, corporações e desenvolvedores individuais desenvolverá conjuntamente padrões para a nova versão corporativa do Java.

Devido a essas mudanças no Java EE, o MicroProfile surgiu. Foi criado por vários fornecedores que executam servidores Java EE. O objetivo aqui é garantir um desenvolvimento mais rápido da tecnologia, menos vinculado a padrões rigorosos. Parece-me muito interessante que o MicroProfile esteja tentando compensar as deficiências do Java EE em relação aos modernos microsserviços nativos da nuvem. Por exemplo, o Java EE ainda não possui sistemas para configuração injetável, tolerância a falhas, monitoramento, todos os tipos de OpenTracing e similares. O MicroProfile fornece acesso a todas essas coisas, para que você não precise implementá-las todas. Além disso, em quase todos os casos, a compatibilidade com o Java EE é respeitada. Os padrões Java EE (como JAX-RS e CDI), com os quais a maioria dos desenvolvedores JavaEE já estão familiarizados, são tomados como base. Portanto, quando encontro tolerância a falhas no meu aplicativo Java EE, por exemplo, não escrevo tudo isso manualmente, mas integro o MicroProfile ao meu aplicativo. Esses dois ecossistemas se misturam muito bem. Para muitos aplicativos, como Open Liberty ou Payara, os tempos de execução suportam o MicroProfile e o Java EE. Tudo o que resta fazer neste caso é incluir certos recursos no tempo de execução e, em seguida, adicionar os projetos MicroProfile necessários ao aplicativo Java EE. Enquanto aguardamos a transição final do Java EE para a Eclipse Foundation, você pode usar esta solução.

Oleg: Você acha que o MicroProfile deve fazer parte de Jacarta?

Sebastian: Essa é uma ótima pergunta, e ainda não há uma decisão final. Pessoalmente, acho que o MicroProfile funciona melhor como um tipo de incubadora para Jakarta EE. O novo padrão é adicionado primeiro ao MicroProfile (como foi feito com o OpenTracing ou a configuração injetável) e, em seguida, analisamos como o sistema se comporta na produção. Quando ela atinge a maturidade, os elementos dela que provaram ser padrões completos. Assim, nos livramos de algumas incertezas, porque já sabemos se o sistema funciona bem na produção ou não.

Oleg: Como estávamos falando sobre padrões, vi os Processos de especificação do Eclipse, era um grande googlodok, que era muito difícil de entender. Documentos com especificações preliminares do Jakarta EE pareciam um emaranhado infernal. Você poderia ajudar esta bola a relaxar? Por exemplo, como isso difere do Java Community Process?

Sebastian: Eclipse Foundation é uma organização de código aberto. No momento, estamos tentando determinar a forma desses processos segundo os quais o Jakarta EE se desenvolverá no futuro. Você mencionou o JCP - então, eu concordo plenamente com a opinião de que os padrões para Jakarta EE devem ser modelados no JCP. Eu acredito que este modelo se mostrou muito bem. Deve-se ter em mente que nenhuma empresa possui o monopólio do desenvolvimento de padrões para Jacarta EE. Várias empresas com mais ou menos os mesmos direitos participam desse processo, para que ele não fique preso no desenvolvimento se uma delas não puder mais participar dele. Eu acho que essa é uma vantagem importante, porque essa tecnologia é muito importante e é mais seguro se desenvolver em uma comunidade aberta.

Oleg: Uma tecnologia tão sofisticada precisa ser testada em algo. Você usa kits de compatibilidade de tecnologia para Java e Jacarta? Ou você tem seu próprio conjunto de testes?

Sebastian: Este também é um tópico muito importante. No JCP, todos esses TCKs geralmente tinham código fechado. Essa foi uma vantagem bastante duvidosa. Por um lado, a especificação poderia fornecer testes que mostrassem se alguma implementação era válida ou não. Mas o desenvolvedor comum não sabia exatamente o que foi testado lá dentro, qual era a cobertura desses testes etc. Agora, o TCK se tornou código aberto. Todas as empresas e desenvolvedores agora podem participar de seu desenvolvimento e aprimoramento. Se o produto de uma empresa não funcionar como indicado na especificação, você poderá não apenas indicar isso à empresa, mas também deixar uma solicitação no próprio TCK. Ou melhor ainda, você pode enviar algumas solicitações pull e melhorar o próprio TCK. Portanto, você aprimora não apenas o software de um fornecedor, mas todo o ecossistema.

Oleg: Há outro produto que possui a palavra "Perfil" em seu nome: IBM WebSphere Liberty Profile. Como você está trabalhando na IBM, pode nos dizer o que é e qual é a diferença do Open Liberty?

Sebastian: O WebSphere Liberty Profile é uma versão comercial do Open Liberty. Este é o servidor de aplicativos Java EE para o qual a IBM fornece suporte comercial. Eu poderia estar errado, mas, na minha opinião, o Open Liberty se tornou código aberto há um ano e meio. Graças a isso, os desenvolvedores corporativos agora têm um servidor de aplicativos gratuito e testado em produção. Se uma empresa precisar de suporte comercial ou de alguns recursos comerciais, poderá usar o WebSphere Liberty Profile. É 2019 e acredito que agora todas as empresas devem fornecer uma versão de código aberto do seu produto para que os desenvolvedores tenham a oportunidade de experimentar o produto gratuitamente. O OpenSource é muito importante e fico feliz que a IBM agora tenha várias opções para o antigo WebSphere Liberty Server.

Oleg: Ouvi dizer que está escrito em cima do OSGi. Você poderia nos contar mais sobre como é organizado dentro?

Sebastian: Eu pessoalmente não desenvolvi o Open Liberty, mas até onde eu sei, ele realmente está sob o OSGi. É interessante que lá você possa simplesmente configurar quais recursos serão incluídos. Se você deseja usar apenas o MicroProfile, que cobre apenas um pequeno número de padrões Java EE, poderá configurar o sistema adequadamente. Ou você pode fazer isso para ter um aplicativo Java EE completo. Devido ao fato de que apenas o que é realmente necessário é incluído em uma instância em execução, é atingido o tempo ideal de inicialização e o consumo mínimo de recursos.

Oleg: A configuração e o uso do Liberty Profile são diferentes do perfil completo? As mesmas ferramentas são usadas nos dois casos?

Sebastian: Não há diferenças significativas no uso. Em relação à escolha dos recursos, os dois servidores podem ser configurados igualmente. Se você tiver um aplicativo Java EE ou MicroProfile, a configuração será a mesma para os dois tipos.

Oleg: as empresas usam o perfil completo há muito tempo. Quão justificado é o uso do Liberty Profile em grandes organizações?

Sebastian: Absolutamente justificado. Mesmo que a empresa tenha comprado suporte comercial, isso não significa que ele deva usar o perfil completo, é bastante razoável usar uma versão mais leve. Se o produto da corporação for baseado em microsserviços modernos e tempos de execução leves, talvez seja melhor escolher o WebSphere Liberty e configurá-lo para que funcione, digamos, apenas com o MicroProfile. Felizmente, o suporte comercial e os recursos comerciais não têm nada a ver com o mundo antigo do WebSphere, portanto, o próprio tempo de execução é surpreendentemente leve e compacto, é iniciado muito rapidamente e pode ser implementado em segundos. Portanto, se você tiver um aplicativo moderno baseado em Java EE, poderá configurar seus recursos adequadamente e incluir apenas os padrões realmente necessários. Independentemente de você usar recursos comerciais, você ainda tem acesso a esse tempo de execução rápido e moderno.

Oleg: Em outubro, a Oracle lançou o Helidon, uma estrutura leve de microsserviço em Java. Até onde eu sei, ele não usa nenhum dos servidores de aplicativos existentes, ele é construído sobre seu próprio conjunto de bibliotecas. Juntos, eles fornecem a base para a criação de microsserviços - recursos para configuração, configurações de segurança, aumento do servidor da web e assim por diante. No topo desse sistema, o MicroProfile foi implementado. Tive a impressão de que os desenvolvedores do Helidon pensam que o Java EE tem muito legado e precisa ser descartado e reescrito. O que você acha disso?

Sebastian: Helidon é um projeto muito interessante. Mas, para ser sincero, me parece ingênuo pensar que o Java EE precisa ser completamente reescrito. De fato, a maioria dos aplicativos não precisa do Java EE como um todo. Como regra, é necessário um conjunto dedicado de recursos / padrões, usado com mais freqüência em aplicativos corporativos. Por exemplo, um MicroProfile comum ainda não fornece JPA ou scripts complexos para multithreading. Isso requer pelo menos alguns componentes Java EE. Em geral, agora vejo o processo de criação de um aplicativo dessa maneira. Com base nos componentes mais importantes e modernos do Java EE, por exemplo, CDI, JPA, JAX-RS, JTA e assim por diante, selecionamos o conjunto de padrões que precisamos, ignorando as muitas coisas herdadas presentes no Java EE. Com base nessa escolha, utilizamos o tempo de execução que suporta todos esses recursos. Se estivermos fazendo algo relacionado aos microsserviços nativos da nuvem, adicionamos os padrões MicroProfile, por exemplo, tolerância a falhas. Mas um tempo de execução como o Helidon não suporta recursos que pertencem exclusivamente ao Java EE e, enquanto isso, multithreading ou JPA são recursos que, na minha experiência, são muito necessários. Eu preferiria um tempo de execução que suporte Java EE / Jakarta EE e Microprofile e, ao mesmo tempo, dê a oportunidade de escolher os recursos necessários para um aplicativo específico. Por exemplo, se você precisar de persistência e tiver um banco de dados, poderá ativar o JPA. Em geral, você terá um conjunto de recursos muito semelhante ao MicroProfile, mas algo do Java EE também será necessário. Esses tipos de tempos de execução são Open Liberty, Payara, WildFly e assim por diante.

Oleg: Até onde eu sei, um dos recursos mais interessantes que serão implementados em Jacarta em um futuro próximo é o suporte às modernas tecnologias de nuvem. E o Java em contêineres agora? Pelo que me lembro, há vários anos, no rastreador de erros do OpenJDK, havia vários erros relacionados à compatibilidade, tamanho de heap, sinais e assim por diante. É possível usar Java em contêineres agora, em 2019?

Sebastian: Sim, definitivamente é. A razão para a maioria dos problemas associados a isso não era o próprio Java, mas a maneira como o Linux trabalhava com contêineres. Frequentemente, o contêiner simplesmente não sabia das várias restrições de recursos que podiam ser definidas. Nas versões recentes, esses problemas foram resolvidos. Agora você pode simplesmente executar Java no contêiner, e essas opções serão ativadas por padrão. E se você solicitar o tamanho da memória no sistema ou o tamanho de heap padrão, esses valores serão especificados corretamente. O Java EE funciona muito bem em contêineres do Docker e, em geral, integra-se bem às tecnologias nativas da nuvem.

Oleg: E a infraestrutura? Você usa algo como Kubernetes ou Istio?

Sebastian: Sim, bastante ativo. 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, . .
.