Hoje em nosso estúdio virtual, o orador mais famoso do mundo para a primavera é Josh Long.

Seus relatórios abrem conferências Java em todo o mundo. É ele quem responde às perguntas da comunidade, faz o Spring Tips no YouTube, é o seu "Esta semana na primavera" que lemos toda semana e muito mais.

A propósito, Josh permitiu usar todos os materiais em nossa própria "Esta semana em Java" , mas ele o faz em tal volume e profundidade que esses dados nunca foram capazes de ser compactados no formato "resumo de 15 minutos".

Às vezes, parece que ele está em todas as cidades ao mesmo tempo, lê relatórios e escreve artigos em um momento. Hoje vamos descobrir como ele faz isso. Aprendemos sobre a "jurisdição do código", as razões da incrível vitalidade de Spring e como ele conseguiu viver tantos anos sem reescrever global do zero e outros truques interessantes.

Deputados

Josh Long, Advogado de Desenvolvedor de Primavera na Pivotal

Evgeny Trifonov, Oleg Chirukhin - editores do grupo JUG.ru

Todo mundo sabe que você viaja muito, mas seria interessante se você pudesse dar algumas estatísticas - quantas conferências você participou no ano passado, quantos voos você fez e coisas do gênero.

Boa pergunta Eu tenho uma mesa que registra todas as reuniões em que participo no ano. Minha assistente, Tasha, me ajuda a organizar a programação e esta tabela. Então, vamos abrir este tablet no telefone ... Duzentos e quarenta. Em 2018, no momento, participei de 240 eventos diferentes. Algumas dessas reuniões ocorrem on-line (como a nossa), mas eu tenho que voar para a maioria. Ao longo deste ano, voei mais de meio milhão de quilômetros. Deixe-me verificar a distância da Terra à Lua ... São 239 mil milhas, para que eu possa voar para a Lua e voltar.

"Para a lua e voltando da primavera." Bom título para o livro de Tolkien.

As companhias aéreas oferecem ofertas especiais porque você voa muito?

Bem, não reclamo do serviço. Costumo voar com a United Airlines e eles têm um programa de serviços globais. Você pode chegar lá apenas recebendo um convite - você mesmo não pode solicitá-lo, e os critérios que ele tem são desconhecidos. Todos os anos, eles convidam pessoas que voam com mais frequência. No ano passado, alguém disse que selecionava 1% dos clientes mais frequentes em todo o mundo. Ou talvez eles filtrem pela quantidade de custos. De um jeito ou de outro, eles me tratam muito bem. Isso é legal. Mas mesmo neste caso, acho que, para a maioria das pessoas, os vôos são um fardo. Definitivamente me preocupa. Não viajo para os voos, mas para conhecer pessoas que usam o Spring. Eu me teletransportaria se houvesse essa oportunidade. A vida seria muito mais simples e mais interessante.

Bom motivo para esperar pelo Hyperloop.

Sim, mas isso terá que esperar muito tempo.

Vamos falar sobre um tópico mais próximo do Spring. Você fala sobre isso com pessoas em todo o mundo - existem diferenças regionais em sua prevalência?

Eu não diria. O Spring sempre foi 100% de código aberto e, enquanto as pessoas escrevem software que funciona na Internet, o Spring continuará sendo bem-sucedido em todo o mundo. É verdade que existem outros projetos de código aberto nos quais a especificidade regional é perceptível. Não posso confirmar as estatísticas agora, mas parece-me que o GridGain é muito comum na Rússia.

Sim, é verdade.

E na China, o MyBatis é muito popular. Nos EUA e na Europa, eu não o vejo há 10 anos, e na China é tão comum quanto a primavera. E, de fato, não há nada errado com o MyBatis, ele é rápido e poderoso - então por que não usá-lo?

Fizemos um projeto no qual o MyBatis trabalha com o GridGain, ele está lá dentro.

(risos) Então você usa os dois - ótimo! Eu gosto dessas duas tecnologias. Não havia suporte normal para o MyBatis, e eu constantemente perguntava a várias grandes empresas na China que estavam fazendo coisas incríveis - por que eles precisavam do MyBatis com a Spring? Existem muitas outras opções, o Hibernate funciona muito bem e o MyBatis praticamente não é usado no Ocidente. Como resultado, eu decidi que, uma vez que o programa é usado, é necessário garantir seu funcionamento normal. Se você der uma olhada nas fontes do Spring Boot Starter para o MyBatis agora, verá meu nome lá. Eu queria que aqueles que precisam desse programa no leste possam trabalhar normalmente com ele. Em geral, uma parte significativa do meu trabalho decorre do tipo de descobertas que faço em diferentes países durante minhas viagens.

Você é o Pivotal Developer Advocate for Spring projetos. O que isso significa na prática? O que exatamente você está fazendo?

Uma pergunta difícil. O conceito de Developer Advocate se espalhou graças à Apple e, em particular, à Microsoft. Tudo começou há cerca de 30 anos, quando a Microsoft percebeu que eram os desenvolvedores que tinham força real. Se você deseja que sua plataforma seja bem-sucedida e útil, é necessário que os desenvolvedores criem coisas valiosas nessa plataforma. Portanto, você deve convencê-los dos benefícios de sua plataforma. A Microsoft começou a tentar motivar os desenvolvedores de várias maneiras diferentes. Eles tornaram o Visual Studio muito barato, ou seja, forneceram ferramentas acessíveis. Eles criaram muitas APIs muito interessantes com as quais você pode trabalhar no Windows. Em geral, a Microsoft percebeu que era necessário colaborar com a comunidade. As pessoas não confiam em software, mas em outras pessoas. As pessoas não têm apego emocional ao software. Você pode imaginar o quanto quiser que se tornará famoso simplesmente escrevendo um programa em solidão no seu quarto de hotel, e quem precisar dele encontrará a documentação. Mas, na realidade, isso geralmente não acontece. Uma parte significativa de minhas responsabilidades é a comunicação com pessoas da comunidade. Ouço o que as pessoas dizem e o trago para os desenvolvedores, e depois transmito à comunidade o que os desenvolvedores dizem. Em outras palavras, eu sou um tipo de veículo.

A equipe da Primavera é estranha e bonita. Ela já tem mais de uma década e meia. No começo, ela era muito pequena e os próprios desenvolvedores estavam envolvidos em consultoria. Eles trabalhavam constantemente com outras equipes, ajudando-os a criar seu próprio software, ou seja, resolviam problemas reais e não ficavam trancados em uma torre de marfim. Eles não fingiram que sabiam de antemão que software era necessário, mas escreveram o que os outros realmente precisavam, e seus benefícios sempre foram o principal critério. Eles compartilharam com seus clientes o sofrimento na solução de problemas. Nós não criamos coisas inúteis. E isso, como você sabe, costuma ser um problema ao criar software. De fato, a primeira equipe do Spring já era formada por advogados do desenvolvedor. Eles não eram semelhantes ao que os programadores geralmente representam. Sim, eles eram desenvolvedores talentosos, mas, ao mesmo tempo, discutiam suas idéias com outras pessoas, participavam de apresentações, conheceram pessoas, conheceram-se e conduziram diálogos. Graças a isso, o Spring rapidamente ganhou grande popularidade.

O problema é que essa abordagem não escala bem. É impossível para todos os desenvolvedores gastar metade do tempo viajando, conversando e se encontrando. No momento em que entrei para a equipe, eu já estava escrevendo código para o Spring, pois é um projeto de código aberto. Além disso, eu já publiquei livros, escrevi artigos e fiz apresentações. Então, eu já tentei apresentar o Spring à comunidade da melhor maneira possível e dar ao maior número possível de pessoas a oportunidade de conhecê-lo. Portanto, a equipe do Spring me convidou para fazer o mesmo, mas de forma contínua e por dinheiro. Eu acho que sou 80% Developer Advocate e 20% programador, enquanto o restante da equipe Developer Advocate é 20% e 80% programadores.

Em suma, meu trabalho é manter contato com a comunidade, e há muitas maneiras diferentes de fazer isso. Estou escrevendo meu sexto livro, chamado The Reactive Spring Book; o anterior foi publicado por O'Reilly chamado Cloud Native Java. Fiz vários tutoriais em vídeo que você pode assistir no Safari Books Online , cada um com 4-5 horas. Além disso, toda quarta-feira eu publico vídeos do Spring Tips no YouTube , cada um dos quais dedicado a um aspecto específico do ecossistema. Eles geralmente duram de 45 minutos a uma hora, todos os anos eu faço pelo menos duas temporadas, às vezes três. Assim, de ano para ano, a cada duas semanas, preparo material suficiente para um relatório completo na conferência. A partir de janeiro de 2011, toda terça-feira, sem exceção, faço uma nova entrada no blog, "Esta semana na primavera" , na qual reviso tudo o que há de mais interessante no ecossistema. Eu também tenho outros blogs, nas duas últimas noites que venho fazendo exatamente isso. Além disso, também escrevo códigos e falo em conferências. Portanto, meu trabalho inclui o máximo de uma ampla variedade de atividades - mas eu poderia me limitar a apenas uma coisa. Existem pessoas que apenas escrevem no blog ou apenas fazem vídeos, e fazem isso muito bem. Alguns nem viajam, mas realizam seminários on-line. Minha abordagem é diferente das outras, mas, finalmente, toda essa atividade persegue o mesmo objetivo.

A propósito, minhas responsabilidades também incluem criar tutoriais, blogs e assim por diante. Para mim, é muito difícil e pode levar um tempo arbitrário. Quão difícil é dado a você? Digamos quanto tempo leva para preparar um vídeo do Spring Tips?

Eu esqueci de dizer - eu tenho um novo podcast, nada saiu ainda, mas sete entrevistas já foram preparadas :-) Quanto ao tempo de preparação, isso acontece de maneiras diferentes. Se eu já estou familiarizado com o tópico que decidi abordar, basta sentar e gravar tudo duas ou três vezes - sempre cometo muitos erros. Demora cerca de quatro horas uma vez por semana, ou seja, um pouco. Mas em outros casos isso não é suficiente. Às vezes, estudo um problema e faço anotações por muitos meses e depois decido que, como esse trabalho já foi realizado, por que não fazer um vídeo dessas anotações. Estou constantemente aprendendo, como você provavelmente está. Mas situações em que preciso aprender algo específico para o vídeo são raras. A parte mais difícil aqui é decidir o que você precisa para se sentar e se aprofundar no tópico, e não no processo de estudo em si.

Às vezes, os programadores de nossa equipe lançam algo que ninguém jamais criou antes. Nesta situação, as pessoas, é claro, terão perguntas, e essas perguntas cairão por padrão nos programadores. E eu posso fazer um vídeo onde tudo será explicado e pré-carregá-lo na rede para que as pessoas tenham tempo para se conhecer. Obviamente, nessa situação, eu também tenho que aprender - já que estamos falando de algo completamente novo.

Quantos projetos existem atualmente na primavera?

Boa pergunta Eu acho que algumas dezenas. Existem módulos muito especializados, alguns dos quais são desenvolvidos pela comunidade, alguns pela equipe da Spring no Pivotal ou outras grandes empresas. Todo o suporte ao Google GCP foi feito no Google, suporte ao Microsoft Azure - na Microsoft. Mas muito - como o MyBatis, por exemplo - está sendo desenvolvido pela comunidade. Além disso, temos módulos separados, por exemplo, Spring Data Neo4j, um módulo para o banco de dados de gráficos Neo4j. Faz parte do projeto Spring Data, mas foi feito em colaboração com o Neo4j, eles fizeram o trabalho principal nesse projeto, ele acabou de morar em nosso repositório git. Existem muitos exemplos.

Quanto ao Spring Boot, temos um mecanismo maravilhoso trabalhando com ele chamado Auto-configuration. Ele fornece às pessoas uma maneira conveniente de agrupar o que elas irão trabalhar. A pessoa simplesmente baixa o arquivo JAR em seu caminho de classe e ele é automaticamente adicionado ao Spring Boot App em execução. Existem muitas dessas configurações automáticas no ecossistema, mas não conheço uma parte significativa. Eles funcionam como plugins.

E como entender os usuários em toda essa variedade de projetos? Existe alguma estrutura ou ideia geral?

Provavelmente, você não precisará de todos os projetos. Designe seu objetivo e selecione o projeto desejado com base nele. Não gosto quando as pessoas tentam "aprender a primavera" - este é um exercício sem sentido. A questão deve ser colocada assim: preciso escrever, por exemplo, uma API REST. Meu primeiro passo é ir para spring.io/guides , onde você pode encontrar um guia simples e acessível que leva de 10 a 15 minutos. Ele terá tudo o que você precisa saber: qual código escrever, em qual pasta, como fazê-lo no IntelliJ ou no Eclipse ou em outra coisa. Tentamos explicar tudo detalhadamente e não omitimos nada, porque queremos que esses guias sejam acessíveis a todos. Tudo o que você faz - JMS, Neo4j, segurança, disjuntores, Kafka -, temos um guia separado para cada tópico. Decida sua tarefa e selecione o guia apropriado. Você precisa pensar não no Spring, mas no que integrará seu sistema - o Spring é apenas uma ferramenta que permite essa integração. Portanto, não há sentido em “aprender o Spring” - você precisa usá-lo para simplificar sua tarefa específica.

Quais projetos na primavera são, na sua opinião, os mais promissores? Ou o mais subestimado?

A biblioteca Spring Retry é muito popular. Foi originalmente desenvolvido no Spring Batch. Não sei se você já usou o Spring Batch; ele permite processar grandes volumes de dados transmitidos seqüencialmente, por exemplo, documentos do sistema de arquivos, XML, arquivos CSP e assim por diante. Em um caso de uso para essa ferramenta, você lê um registro e o grava - por exemplo, de um serviço da Web para uma fila de mensagens. O processamento desses dados pode levar horas, e seria extremamente indesejável se o sistema, devido a um erro no final, revertesse todo o trabalho realizado durante a noite. Você não pode fazer isso. O Spring Batch trabalha com pacotes de dados; processa registros não um, mas dez ou mil. Mesmo se o processamento de milhares de registros for perdido, todo o resto será salvo. Além disso, ao escrever sistemas de pacotes, você deve ter em mente que precisa acessar outros serviços que podem falhar. Há uma nova tentativa de primavera para isso. Essa biblioteca permite fazer chamadas repetidas para os serviços. Além disso, você pode usar a velocidade do obturador exponencial. Além do Spring Batch, o Spring Retry também é usado em Spring Integration, Spring Cloud Stream, Spring Cloud Data Flow. Nos últimos dois, apoiamos o Spring Retry por causa de sua conexão com outras coisas. Portanto, essa biblioteca é usada em muitos projetos do Spring e não tenho certeza de que todos saibam disso. O Spring Retry é uma biblioteca usada com muita frequência que às vezes é simplesmente ignorada. Em geral, temos muitas coisas reativas diferentes. Eles são geralmente os mais interessantes.

Por que exatamente o reativismo?

Temos reatividade em todos os lugares. A vantagem do Spring é que você pode iniciar e finalizar um projeto com ele. Nesta semana, anunciamos que apoiaremos o projeto Facebook RSocket . Este é um análogo totalmente reativo do gRPC, mas significativamente mais flexível. Pode ser usado para publicação / publicação, transmissão de dados, solicitação / resposta do cliente - em geral, com ele você pode implementar muitos padrões de mensagens diferentes. E é usado no Facebook. Existem dois pacotes configuráveis, um em C ++ e outro em Java. O em Java é escrito usando o Reactor, nossa biblioteca reativa. Ela usa o Salesforce. Claro, existem outras opções. Você já ouviu falar de gRPC do Google? É de alta qualidade e interessante, mas não é reativo; por padrão, não funciona bem com tipos reativos. O Salesforce gRPC não tem essa desvantagem. Ele tem um compilador que cria serviços baseados no Spring Reactor. Portanto, o Facebook e o Salesforce conseguiram dimensionar o Reactor de acordo com suas necessidades.

O próprio reator é um dos nossos projetos mais interessantes. O RxJava saiu mais cedo, mas o Reactor foi o primeiro a fornecer suporte a threads reativos. Isso aconteceu em grande parte porque o maravilhoso programador David Karnock, gerente de projetos da RxJava, trabalhou conosco no Reactor. Portanto, uma parte significativa de todas as coisas novas e interessantes que aconteceram em nosso ecossistema de alguma forma tocou o Reactor. Graças a isso, o projeto tornou-se extremamente atraente para empresas que criam grandes sistemas. O reator também está subjacente à estrutura Spring WebFlux. Além disso, com base no Reactor, apoiamos mensagens reativas, soquetes reativos da Web, Spring Cloud Stream, disjuntores reativos etc. - todos esses componentes podem ser integrados a aplicativos reativos. Você pode, é claro, apenas usar o Spring, mas eu prefiro usar todo o ecossistema com esses tipos de reativos.

Além disso, recentemente anunciamos o R2DBC - nossa API para acessar dados baseados em SQL para drivers reativos. O JDBC reativo ainda não existe. O problema é que, se você usar código reativo, não poderá usar o bloqueio. Se o bloqueio for usado, essa interação deverá ser ampliada, aumentando o número de encadeamentos. E isso contradiz o objetivo original, já que queremos apenas evitar o dimensionamento aumentando o número de threads - isso é muito caro. Portanto, o R2DBC fornece uma abstração que fornece acesso a dados reativos. Existem drivers de banco de dados que são inicialmente reativos - por exemplo, Postgres. Portanto, você pode usar o R2DBC, entre outras coisas, com o Postgres e trabalhar com SQL reativo sem usar um bloqueio, pois você não possui threads. Todo esse tópico parece extremamente interessante para mim.

Talvez você possa responder a algumas perguntas técnicas mais frequentes? Um dos problemas é que, ao usar vários projetos do Spring, muitas anotações ocorrem simultaneamente. Torna-se difícil descobrir o que cada um deles faz. Você não pode clicar nele enquanto mantém pressionada a tecla Ctrl e ir para a definição. Como se comportar em tal situação?

Deve ser executado com a opção `--debug`. A maior parte do ecossistema do Spring agora existe como uma configuração automática. Alguma parte é como uma configuração importada; se, neste caso, você clicar na anotação, verá a inscrição `@ Import`, que indicará sua classe. Se você clicar nele, verá os objetos que foram criados para você. Às vezes, porém, o Spring age através do mecanismo de configuração automática - nessa situação, nenhuma anotação é criada. Existe apenas uma biblioteca e caminho de classe. Então é realmente difícil descobrir o que está acontecendo e por quê. Mas queremos tornar o mais fácil possível para as pessoas descobrirem isso. Para isso, existe o parâmetro `--debug`, que deve ser inserido quando o aplicativo iniciar. Você verá um relatório no qual todas as etapas executadas pelo aplicativo na inicialização serão descritas. O aplicativo verifica se existem campos ou classes e, dependendo disso, decide se deve criar alguns objetos para ele ou não. O relatório mostra quais condições foram atendidas, quais não são e quais configurações não dependiam de nenhuma verificação. Portanto, se, digamos, você simplesmente não consegue entender por que sua conexão com Kafka não funciona, você pode observar a condição correspondente - talvez você não tenha a classe necessária no caminho de classe.

Agora haverá uma pequena pergunta trolling. Os opositores do Spring costumam afirmar que é a causa da arquitetura de baixa qualidade, porque você pode simplesmente usar o @Autowired qualquer lugar e em qualquer lugar. Você concorda com esta opinião? Há dez anos, a arquitetura foi criada em três camadas, os valores foram transferidos do construtor para o construtor e os DTOs foram criados. Com o Spring, você pode se livrar de tudo isso. Isso é bom ou ruim?

A primavera é uma ferramenta. Isso permite que mais pessoas criem software que chegue à produção e funcione corretamente, então não acho que seja prejudicial. Nos últimos anos, milhões de pessoas criaram aplicativos usando-o e tudo funciona bem para eles. Considerar que a primavera como um todo é prejudicial é um absurdo, tal opinião não pode ser chamada de ignorante.

Na primavera, você pode criar uma fiação bastante explícita. Se você está preocupado que não fique claro de onde veio o objeto fornecido, vincule-o você mesmo. Você pode criar uma configuração java na qual um método chamará outro, e o valor de saída do método chamado será um bin - o Spring cuidará disso. Mesmo quando você chama a mesma lixeira repetidamente ou milhares de vezes, nunca terá mais de um link se esse objeto for um singleton. Você quer que tudo seja explícito - isso pode ser feito. Se desejar, você pode optar por uma opção ainda mais chata - XML. A conclusão é que, se você não quiser usar o `@ Autowired`, isso poderá ser completamente evitado.

Se você usar o Spring Boot da maneira mais comum, terá apenas um bean. Você sabe que precisa de um bean do tipo `ConnectionFactory` - nesse caso, não há problema em fazer uma injeção por tipo. Você ainda tem apenas um objeto, não possui dois `ConnectionFactory` para um` Connection`. Você não terá duas sessões do Hibernate, portanto, nada impede que você injete o `HibernateSession` - ele ainda existe em uma única instância. Se quiser que tudo seja explícito, você pode usar a anotação `@ Qualifier`. Com ele, você marca o que injeta por tipo. Isso tornará possível distinguir as várias implementações de compartimento uma da outra. Suponha que você tenha um serviço com o qual os aplicativos em um local possam se comunicar com o iTunes, em outro - com a Amazon, no terceiro - com a Android Play Store. Serão três beans diferentes de um tipo diferente, mas cada um terá a anotação `@ Qualifier`. Além disso, essa anotação pode ser sobreposta a outra anotação, garantindo assim a segurança do tipo. Você vinculará esse tipo e terá uma anotação em cima dele. Quando o bean for criado, ele terá a anotação `@ Qualifier`, inclusive no site do consumidor. Portanto, essas anotações fornecerão links e, mesmo se você tiver três implementações enquanto o programa estiver em execução, ainda poderá encontrar a que precisa.

Em geral, na sua opinião, a flexibilidade é uma característica positiva. Você e a equipe do Spring aderem a alguns princípios fundamentais como o Zen Zen?

Sim, aderir. A propósito, eu tenho programado em Python desde o final dos anos 90, e sou um grande defensor do Python Zen, ele tem uma idéia geral muito correta. Quanto à sua pergunta, aqui você precisa falar sobre Jürgen Höller, co-fundador da Spring e o segundo desenvolvedor que trabalhou no projeto. Este é um homem querido, muito quieto, um dos melhores com quem eu tive que me comunicar. É muito fácil conversar com ele se, por exemplo, você o conheceu em uma conferência. Ao mesmo tempo, ele tem um intelecto poderoso, e é difícil superestimar sua contribuição para a Spring. A conferência JAX - muito importante, embora, é claro, não chegue ao Coringa :) - concedeu a ele um prêmio especial pelo trabalho que ninguém mais havia recebido antes. Geralmente, os prêmios são concedidos em alguma categoria especial, mas esta não possui uma categoria e pertence apenas à Jürgen. Spring é o único projeto no ecossistema Java que nunca foi reescrito em 15 anos - porque não há necessidade. Jürgen tem uma idéia muito clara de como escrever módulos, como expressar tipos, em geral - como criar uma base de código de alta qualidade que pode viver por décadas e facilmente mudar, se necessário. Não existem outros projetos no ecossistema Java. Uma parte significativa dos projetos não existe mais e, mesmo entre os que foram reescritos do zero, muito poucos viveram 15 anos.

Sem ser reescrita, apenas a primavera durou 15 anos, porque foi escrita de maneira muito limpa desde o início. Jürgen nos ensinou alguns princípios fundamentais que seguimos: como criar módulos, como fazer pacotes de implementação (em oposição à parte pública), como descrever o nível de superfície da API e os tipos de design para ela, quais padrões devem ser usados. Com o Spring, você inevitavelmente se familiariza com os padrões de design, e sempre foi assim. Um exemplo do padrão Pattern vem à mente imediatamente. O Spring Integration apresenta os padrões de integração corporativa, o Spring MVC apresenta o MVC. Todos esses padrões fazem parte da estrutura e os usamos com base em práticas comprovadas. Nosso zen são os princípios que Jurgen nos ensinou. Nesse sentido, somos todos seus alunos. Jürgen é conhecido por sua abordagem um pouco estranha de como escrever código - devido à sua maneira até mesmo um termo especial, "jurgenize" surgiu. Nossa equipe tem muitas pessoas realmente inteligentes, com grande experiência, algumas já possuem diplomas e patches carecas. No entanto, Jürgen faz suas próprias alterações em seu código. Às vezes, são pequenas coisas como adicionar espaços, limpar e assim por diante, mas às vezes reescreve o código mil vezes melhor e, ao mesmo tempo, não altera a autoria do código, ou seja, é confirmada com o nome do autor original. Nesses casos, diz-se que o código foi "legalizado", ou seja, foi corrigido. Graças a Jürgen, nosso código é muito limpo. Para ferramentas de análise de código, é considerado uma marca de alta qualidade encontrar pelo menos algum tipo de mau funcionamento no Spring, porque existe um código muito limpo. Em geral, não posso definir nossos princípios em detalhes agora, mas eles estão lá, foram estabelecidos por Jürgen e todos os projetos da Spring os seguem. Quanto ao Spring Boot, temos regras muito precisas para a criação de módulos, que chamamos de iniciantes.

Ok, obrigado pela resposta. Minha última pergunta será sobre desempenho e Java 11. Até onde eu sei, o Spring sempre gera contexto em tempo de execução. Isso pode levar de minutos a várias horas em alguns programas bancários antigos.

Vamos lá? Eu não acredito nisso

Honestamente, visto com meus próprios olhos.

Mas não pode ser primavera. Provavelmente, algo terrível é feito lá com o Hibernate. O feijão pode ser gerado em milhões, um feijão vazio pode ser compilado e executado muito rapidamente. Leva tempo para carregar informações do banco de dados, validação etc., isso pode causar atraso no Spring. Mas a própria primavera é muito rápida.

Sim, acho que realmente houve algum tipo de horror com o Hibernate. No entanto, a primavera começa 30 segundos, às vezes um ou dois minutos - ainda é muito tempo, você não acha? Se, digamos, o rodarmos no Docker, precisamos que o contêiner inicie imediatamente. É possível reduzir o tempo de inicialização do Spring?

Demoro menos de dois segundos para iniciar o Spring. E com o Spring Cloud Function, esse tempo pode ser reduzido para meio segundo ou menos. Temos projetos que são executados sem problemas em meio segundo - por exemplo, Spring Boot no Spring Cloud Function. Então, novamente, o problema não está no Spring, mas no que você faz a eles, no que está acontecendo em segundo plano - você obtém acesso a outra fonte de dados na Internet, faz download de arquivos da Internet, faz upload de dados para a grade . Se tudo o que você faz são pequenos microsserviços, seu sistema deve funcionar muito rápido. Se seu aplicativo for executado por um período muito longo, algo está errado com ele.

Eu vejo. A propósito, você já ouviu falar do GraalVM e do AOT?

Sim Vou lhe contar mais: temos um projeto Spring Fu. Ele é experimental, eu gravei um vídeo da série Spring Tips sobre ele. Nós escrevemos no Kotlin, agora ele tem uma API Java. Este projeto foi criado para ambientes como o GraalVM. O Spring Fu não usa proxies gerados dinamicamente ou `@ Configuration`. O gerador de imagem nativo no GraalVM precisa saber quais classes serão carregadas. Mas se você tem carregamento dinâmico usando cglib ou Byte Buddy, isso dificulta o uso do GraalVM. O Hibernate, Spring e todas as outras bibliotecas que usam proxies gerados dinamicamente não são adequados para a criação de uma imagem nativa. Portanto, não há nada como isso no Spring Fu, isso é afirmado diretamente. Ele ainda usa o Spring, mas a abordagem para criar aplicativos é diferente. E uma das vantagens do Spring Fu é que ele funciona bem com o GraalVM. E agora o aplicativo inicia instantaneamente. Quero dizer, geralmente instantaneamente: uma vez que esteja completamente na memória! Deve-se lembrar que o gerador de imagem nativo no GraalVM ainda está em um estágio muito inicial de desenvolvimento. Por isso, às vezes surgem dificuldades, porque parece que o aplicativo iniciado pelo GraalVM começará a carregar imediatamente muito rapidamente e, em tempo de execução, a velocidade será a mesma de antes. Mas isso não acontece assim, porque no tempo de execução do GraalVM você não está mais usando a JVM, o comportamento do sistema será diferente. Portanto, teste este projeto quanto à saúde, mas lembre-se de que não é uma aceleração de lançamento gratuito. E, no entanto, estou muito satisfeito com o GraalVM, a equipe deles se esforçou muito para fazê-lo funcionar melhor com estruturas.

Minha última pergunta, é claro, será sobre o Java 11.

Sim ela é linda.

O que é útil para o Spring nele?

Para os desenvolvedores do Spring, existem dois critérios principais pelos quais escolhemos essa ou aquela tecnologia: 1. se é adequada às necessidades de negócios; 2. se é adequada para nós como programadores. Quanto ao primeiro critério, se essa tecnologia oferece maior velocidade, estabilidade, se possui suporte a longo prazo. Tudo isso está presente no Java 11. O suporte ao Java 8 terminará em breve, portanto, faz sentido atualizar para o próximo release com suporte a longo prazo. A propósito, meus amigos, se você atualizar para a próxima versão, use o assembly OpenJDK - ele é excelente em todos os aspectos. A versão correta é muito fácil de obter, eu já escrevi sobre isso no Twitter. Esta versão funciona muito bem com o Spring - é estável. Agora você pode pelo menos acessar https://start.spring.io , gerar um novo projeto, selecionar Java 11 e ele funcionará. O suporte ao Java 11 está disponível no IntelliJ e no Eclipse.

Quanto ao segundo critério, não há mudanças significativas para os desenvolvedores Spring no Java 11. É bom que o `var` e o cliente HTTP tenham aparecido, mas o Spring já tinha um WebClient reativo, por isso não tenho certeza de que nos beneficiaremos do cliente HTTP. Algumas coisas convenientes foram adicionadas no Java 10 e Java 9. Além disso, tornou-se possível executar o programa Java como um script - isso não é ruim. Não sei se faz sentido fazer isso com o Spring - embora, por outro lado, por que não. Como vai ficar, eu não sei.

Foi difícil para o Spring mudar para o Java 11?

Não. No coração da primavera, há bibliotecas de alta qualidade e o ecossistema. Lembre-se de que a estrutura do Spring suporta o caminho de classe e o modulepath, mas eu pessoalmente não recomendo o uso do modulepath. Para usá-lo corretamente, todo o resto também deve suportar modulepath. E isso ainda não é possível, agora há poucas pessoas fornecendo suporte ao modulepath nas bibliotecas. O modo classpath funciona muito bem. Tivemos problemas bastante comuns com as bibliotecas CGLib, AspectJ e JAXB XML que todos tinham ao migrar para o Java 9. Todos esses problemas foram resolvidos no último ano, facilitando a transição para o Java 11.

A propósito, estamos planejando muitas coisas interessantes para futuras versões do Java, por exemplo, o projeto Loom é uma fibra para Java.

Será em Java 12?

Provavelmente não, eles farão isso por algum tempo.

O Kotlin também usa corotinas, portanto esse projeto é muito interessante para nós. Sempre que ele sai, ele será de grande benefício. A capacidade de expressar pipelines reativos sem criar código reativo é muito importante. Pessoalmente, estou ansioso pelo aparecimento de String de várias linhas. Talvez essa não seja a melhor maneira de testemunhar para mim - eu tenho muito código que requer um grande número de linhas, por exemplo, consultas SQL e similares.

Isso ocorre porque você tem uma parte significativa do código otimizado para apresentação de slides. Nos slides durante os relatórios, será conveniente exibir a sequência inteira na tela.

Sim, caso contrário, fica difícil ler. No IDE, eles terão uma aparência muito melhor. Novamente, Python, Kotlin, Scala, Groovy - qualquer idioma nos últimos 20 anos forneceu suporte a String de várias linhas. Na minha opinião, isso é bastante natural.

Talvez você gostaria de deixar alguns conselhos para os nossos leitores? Pode dizer respeito ao Spring ou Pivotal e pode estar relacionado ao Java como um todo.

Como em qualquer tecnologia, a melhor parte do Spring é sua comunidade. Tecnicamente, o Spring é um conjunto de projetos extremamente interessante, mas o segredo de sua longevidade é uma comunidade maravilhosa. Ninguém precisa do seu maravilhoso software, se você precisar se comunicar com pessoas insuportáveis. Portanto, tentamos ser o mais amigáveis ​​possível. Nossos desenvolvedores, incluindo gerentes de projeto, respondem a perguntas no Stack Overflow e seguem várias tags lá. Temos salas de chat no Gitter, e cada sala de bate-papo corresponde a um repositório no GitHub. Por exemplo, https://gitter.im/spring-projects/spring-boot . Lá, você pode encontrar desenvolvedores do Spring e fazer as perguntas que mais lhe interessam.

As pessoas costumam me perguntar como ajudar o projeto, como começar a escrever código para o Spring. Temos muitos problemas com tags como "ideal para contribuição" no GitHub. Estamos felizes por todos, mas nem todos os projetos são adequados a todos, alguns bugs são mais complicados que outros. Portanto, se você quiser trabalhar conosco, procure essas tags e ajude com problemas. É assim que ocorre o reabastecimento de nossa comunidade. Valorizamos o trabalho de todos que ajudam a melhorar nosso ecossistema.

Minuto de publicidade. Josh Long chega à conferência Joker 2018 com uma palestra sobre a Primavera Reativa . Os ingressos podem ser adquiridos no site oficial da conferência .