Aventuras apresentando Java EE a mim mesmo

Cuidado: o texto a seguir contém níveis perigosos de nerdice, acrônimos e javeiragem em geral.

Não sou nenhum fã de Java: a linguagem eu realmente não curto (não tenho culpa de ter conhecido Python e Ruby antes :P), todavia a plataforma tem os seus apelos. Só que eu estava ficando com vergonha de ainda desconhecer o stack do Java EE, ao passo que uso diariamente várias tecnologias relacionadas no meu trabalho. Por isso, decidi que iria tomar vergonha na cara e estudar um pouco mais da parada (e tentar reclamar menos). Comprei o livro do Antonio Goncalves sobre Java EE 6, e caí em cima. Tendo recentemente terminado sua leitura, registro aqui minhas impressões a respeito.

Read the original, dude!

Read the original, dude!

Antes de começar, porém, já adianto uma coisa: apesar do conteúdo do livro ser bem decente, a tradução dele é péssima. Me encontrei frequentemente tendo que adivinhar como seria o texto original em inglês para poder compreender o traduzido, pois este não fazia nenhum sentido. A impressão é que o livro foi traduzido por várias pessoas diferentes (estagiários?), que não sabem muito sobre orientação a objetos e muito menos da plataforma Java EE, resultando numa confusão de palavreado mal-traduzido bem difícil de entender. Resumindo: a tradução atrapalha muito mais do que ajuda! Se soubesse que seria tão desleixada, jamais teria comprado o livro traduzido. Portanto, se você já lê inglês, obtenha a versão original (mesmo que saia mais caro): você vai poupar sofrimento e a leitura será mais tranquila. Se você não lê inglês, leia a versão original também e aproveite pra começar a aprender inglês logo: será mais saudável pra sua carreira não depender de traduções fajutas! OK, fim da reclamação.

O livro fornece uma visão geral da plataforma, e também tenta mostrar o contexto histórico e motivações para o surgimento dos protocolos e APIs. Após apresentar rapidamente o que consiste a plataforma e os programas necessários para rodar os exemplos (JDK, Maven, Glassfish 3, Junit 4 and Derby), o livro começa a apresentar as APIs e conceitos da plataforma numa abordagem meio bottom-up: alguns capítulos sobre mapeamento objeto-relacional com JPA — a API especificada para persistência com Java, depois alguns capítulos sobre as partes de Java EE usadas principalmente para a lógica de negócio (EJBs, Transações, AOP no estilo Java EE com Callbacks e Interceptors), seguidos de uma visão rápida das tecnologias usadas para a parte de apresentação na Web (JSF, JSP, e assuntos relacionados), e culmina com os últimos 3 capítulos dedicados a comunicação entre sistemas: mensageria com JMS, Web Services SOAP e RESTful.

O conteúdo é bom pra “designorantar-se” dos conceitos e tecnologias disponíveis na plataforma, acho que dá pra recomendar pra qualquer pessoa envolvida com Java e ainda não conferiu o Java EE, ou que vem de outras linguagens/frameworks e quer conhecer o padrão. Todavia, pelo que tenho lido no StackOverflow e em alguns outros lugares, a API especificada de Java EE sobre Contextos e Injeção de Dependência (CDI, na sigla em inglês) vem ganhando cada vez mais importância na plataforma, então é um certo pecado o livro simplesmente ignorá-la — em nenhum lugar do texto é sinalizado a omissão de uma parte importante da coisa.

Gostei bastante da cobertura de JPA, relativamente bem completa para um livro de introdução à plataforma. Rapidamente encontrei material pra uso no meu trabalho. A seção sobre EJBs pra mim foi interessante para comparar com a minha experiência com os recursos substitutos do Spring. (Parece que os meus SLSBs são beans do Spring com @Transactional. :) As partes exclusivamente sobre JSF não me reservaram muitas surpresas, mas curti aprender mais sobre o contexto histórico do framework, com a seção descrevendo o surgimento de JSP, JSTL, Facelets, EL, etc. Achei muito boa também a exposição sobre a API Javascript que ganhou especificação no JSF 2, usada para as requisições Ajax.

Por fim, os 3 últimos capítulos sobre interoperabilidade também estão interessantes, embora eu me arrastei na leitura deles. Sobre JMS, não tinha muita novidade (a API andou meio parada por algum tempo, e deverá ter novidades no Java EE 7 com o JMS 2). Fato curioso: o capítulo sobre serviços REST conseguiu ser mais enfadonho do que o de serviços SOAP (e olha que eu tendo a favorecer REST). Começou entrando demais nos conceitos dos protocolos antes de mostrar um exemplo prático que demonstrasse as vantagens da coisa — o que provavelmente teria criado um engajamento melhor com a exposição da API. Mas bem, o estilo REST é relativamente novo no mundo Java, talvez à medida que mais gente compre a idéia, ele deve receber mais atenção no futuro.

Os exemplos do livro servem apenas como um chute inicial mesmo, é só pra você ter uma idéia mesmo do que é possível de atingir com as APIs que estão sendo explicadas. Quase nada dos códigos de exemplo parecem aproveitáveis para uma aplicação real — muito longe de código de produção. Nesse sentido, o livro provavelmente não está longe da vasta maioria das documentações técnicas para programadores, infelizmente.

Apesar de tudo, ler esse livro foi muito bom pra mim, pois expandiu um bocado minha compreensão sobre algumas tecnologias que trabalho e sobre as possibilidades da tal plataforma Java EE. E como uso bastante JPA e JSF no meu trabalho atual, fiquei por dentro de vários recursos úteis dessas APIs que eu desconhecia. Por exemplo, apesar de usar JPA há já uns 2 anos, eu desconhecia os mecanismos de mapeamento com @ElementCollection e @Embeddable. Também, mesmo usando JSF há um bom tempo, desconhecia o composite:insertChildren (meus olhos devem ter pulado essa tag na listagem da documentação mais de uma vez). Essas e outras coisas encontraram uso bem rapidinho no código da aplicação que estou trabalhando. Meio besta eu não saber disso antes, né? Mas bem, isso é pra ser um dos benefícios esperados ao se sentar pra ler uma josca dessas até o final. :)

No final, fiquei com uma sensação um pouco mais positiva em relação ao Java EE (ou devo dizer, menos negativa?). Enfim, parece que do seu próprio modo a plataforma está evoluindo, e as APIs estão ficando bem decentes. E a próxima versão Java EE 7 parece que sairá em breve (essa página tenta registrar o progresso), com mais melhorias em todas as áreas. Contudo, às vezes tenho a impressão que o meu sentimento positivo é mais devido ao péssimo estado anterior das APIs do que aos recursos verdadeiros das versões atuais.

Pessoalmente, das tecnologias para aplicações Web do “mundo Java”, tendo a gostar mais de coisas como o Grails, que oferece várias facilidades semelhantes aos da plataforma Java EE, mas com usabilidade bem melhorada para mim como programador. Sei que não é muito justo comparar, já que Java EE é um conjunto de especificações (tem muita gente que valoriza isso), mas em termos de recursos disponíveis para um programador construir um app, pode fazer bastante sentido compará-los.

Finalmente, tem algumas coisas que me importam bastante num toolkit, e que Java EE ainda precisa melhorar:

  • Facilidade de fazer bootstrap duma aplicação Web (IDEs e o Maven ajudam, mas ainda estão longe de grails create-app NOME_DO_APP)
  • Facilidade de instalar/publicar uma aplicação — em especial, minimizando a quantidade de configuração a ser feita para os recursos que ela vai usar.
    • Envolve colocar o máximo de configuração possível embutido na aplicação. Isso meio que bate de frente com a idéia prevalente do Java EE de que as configurações devem ser feitas no servidor de aplicação.
  • Suporte de primeira-classe a uma linguagem dinâmica nas partes em que faz mais sentido. (Groovy, Python, Ruby ou JavaScript já resolveriam pra mim, mas outras também serviriam).
  • Independência de IDE — quero poder acionar facilmente a execução dos testes e geração de builds pela linha de comando. (Aqui usar uma ferramenta como o Maven ajuda bastante, mas ainda depende de muita configuração boilerplate — e frequentemente, bastante esforço).

Concluindo, acho que é bem interessante conhecer o que o Java EE tem a oferecer. Mas é bom não parar por aí: ainda tem bastante coisa interessante por pra investigar.

Esse post foi publicado em General e marcado , , , , , , , . Guardar link permanente.

13 respostas para Aventuras apresentando Java EE a mim mesmo

  1. Puxa, nem sabia que havia uma versão em Português do meu livro :o( Obrigado por este resumo, feliz em saber que tenhas gostado. Para tua informação, eu estou a escrever a versão Java EE 7, com novos capítulos (CDI e Bean Validation) e os outros capítulos atualizados.

    • eljunior disse:

      Caramba, comentário do próprio autor, quanta honra! \o/

      Valeu, Antonio, parabéns pelo livro, muito útil!
      Fico no aguardo da nova versão. :)

      Infelizmente a editora brasileira não caprichou muito na revisão da tradução, torçamos que a próxima edição receba a atenção merecida.

  2. E aí, Elias! Foi também esse livro que eu li agora no final de 2012 que “me designorantou”. Também li a documentação do Weld (implementação de referência do CDI) e aí finalmente fiquei com a sensação de realmente conhecer o Java EE como um todo. Antes meu conhecimento era muito capenga. Você pelo menos já tinha usado JPA, e o semiconcorrente Spring.

    A tradução eu não achei horrível, mas realmente é “menos que mediana”, por assim dizer. Uma coisa que me irritou foram alguns errinhos freqüentes de digitação e a tipografia, que usava uma ligadura “fi” até em trechos que deveriam ser monoespaçados: a palavra “fill” ficava parecendo “fi l l”.

    Apesar disso, fiquei completamente grudado no livro até terminar, gostei muito. Fazia tempo que não me interessava tanto em aprender algo a fundo. Até baixei as especificações do jcp.org para ter a referência oficial sempre que precisasse.

    Legal o Antonio ter comentado também! :-)
    Nesta altura do campeonato acho que o livro do Java EE 7 deve estar quase pronto, mas também gostaria de reforçar que os exemplos poderiam ser mais realistas. Especialmente na área de locks do JPA e controle de concorrência no @Singleton, que são coisas difíceis de fazer certo e comprovar que o código está correto, é bom ter uma referência com boas práticas.

    • eljunior disse:

      E aí, Marcus! :)
      Olha só, rapaz, estávamos lendo o mesmo livro!

      Boa, será interessante eu dar uma olhada no Weld também.
      Você leu a especificação?
      Outro dia li o Gavin King falando que a especificação do CDI é relativamente bem acessível… Ainda não me encorajei a ler nenhuma especificação, só dei uma espiadela fugidia na JSF 2.1 e dei meia-volta logo em seguida de fininho — bota leitura árida!

      Uso Spring no trampo há pouco mais de um ano, e agora tô querendo usar mais o Grails (se você ainda não conferiu, reserve um tempinho uma hora dessas, vale a pena — é Groovy em cima de Spring + Hibernate :).

      Realmente seria excelente ter uma referência com códigos mais realistas pra esses assuntos (JPA locks, configuração de mapeamentos Cascade/FetchType, @Singleton, Autenticação e Autorização, etc). Sobre JPA, por um bom tempo o único material que usei foi o livro inacabado Java Persistence no Wikibooks: http://en.wikibooks.org/wiki/Java_Persistence
      Não é perfeito, mas já me ajudou repetidas vezes, especialmente pelas descrições das coisas que podem dar errado.

      Falou, Marcus, valeu a visita! :)

  3. A documentação do Weld é muito boa: http://docs.jboss.org/weld/reference/latest/en-US/html/

    Depois de ler só tive duas surpresas: objetos instanciados com new não recebem @Injects (é óbvio depois que se sabe, mas essa informação poderia estar mais explícita na documentação) e a integração com JAX-RS exige um @RequestScoped que parece redundante: http://docs.oracle.com/javaee/6/tutorial/doc/gkncy.html

    A especificação http://jcp.org/en/jsr/detail?id=299 também é boa, e alguns trechos do texto parecem ser os mesmos da documentação do Weld.

    Este carinha aqui: http://blog.ringerc.id.au/2011/03/javaserver-faces-jsf2-and-jax-rs.html fala como é difícil de ler a especificação do JSF 2. Ele tem também outros posts interessantes sobre Java EE e os problemas que ele teve para entender e usar. Achei legal que ele ia fundo nos problemas e reportava os bugs… Já eu provavelmente ia pensar que se tratava de uma falha no meu entendimento e seguiria adiante, hahahaha.

    Outra coisa bem ruim de entender é quando falam de JNDI (na especificação do EJB, na do Java EE como um todo, no próprio tutorial oficial, etc.): sempre há um vazio de informações quanto à configuração do contêiner, já que a documentação e especificação fala só da configuração da aplicação, e ainda não entendi muito bem a diferença entre @Resource(name=”…”), @Resource(lookup=”…”), e @Resource(mappedName=”…”). Mas tudo bem, não deixei de conseguir fazer o que precisava, mas fica aquela duvidazinha no canto incomodando.

    Por último, fazendo um gancho com o comentário lá no meu blog, você usa algo como pseudo-REPL para Java? Eu já usei Scala (apesar da sintaxe maluca) e Groovy para fazer uns testes interativos com algumas classes Java (principalmente sobre data, hora e TimeZones). Mas era um REPL na linha de comando do Windows mesmo, e a edição de texto era meio incômoda. Não sei se atualmente existe algo mais amigável com recursos melhores de edição…

    • eljunior disse:

      Boa, vou reservar um tempinho pra ler os docs do Weld então. :)
      Faz sentido os objetos instanciados manualmente não serem candidatos a injeção, imagino que só os instanciados pelo container sejam.

      Rapaz, você não pára de roubar minhas leituras! Tô há alguns dias com abas abertas com posts desse mesmo carinha aí do “Beware of Soapy Frogs”! :P

      Sobre REPLs pra Java, usei por um tempo o bsh (http://www.beanshell.org – tem uma versão gráfico escota e uma de linha de comando passável), até que resolvi aprender Groovy e nunca mais voltei atrás. Groovy tem o shell basicão pra linha de comando (groovysh e também o groovyConsole, que é gráfico, bem legalzinho: http://groovy.codehaus.org/Groovy+Console

      • Hmmm, acho que esse groovyConsole parou de funcionar (alguma atualização do Java, será?) no computador do trabalho, ou nunca funcionou mesmo, daí eu usava o groovysh. Acho que vou baixar uma nova versão, já deve fazer mais de um ou dois anos que baixei aquele Groovy e quase não usei.

      • Bah, fui testar e groovyConsole estava funcionando direitinho… Não sei de onde tirei que não funcionava. Já peguei e fiz alguns testes nele.

        Deve ser o mesmo fenômeno que ocorre quando a gente procura uma coisa e não acha, daí nos dizem “Mas está lá, sim, olha direito”; e então a gente vai ver de novo e o objeto está lá mesmo, hahahahahaha.

      • eljunior disse:

        hauh! boa! :D
        massa, boa diversão ae! :)

        ah, um aviso (que demorei uns dias pra descobrir, quando comecei com Groovy), específico do shell/console:

        def variavel = ‘coisa’ // nao guarda no escopo global…
        println variavel // falha com MissingPropertyException

        variavel = ‘coisa’ // assim funciona
        println variavel // ‘coisa’

        // src: http://groovy.codehaus.org/Groovy+Shell#GroovyShell-Variables

  4. Reblogged this on Visions of hope and commented:
    E então, não era só eu que estava lendo o livro do Antonio Goncalves sobre Java EE 6 no final de 2012/ início de 2013!

  5. E aí, Elias! Te adicionei no Google+, e aproveitei para convidar para um HangOut. Na verdade eu mal sei como é um HangOut, mas já que me convidaram e o tema é justamente “frameworks de desenvolvimento web”, passei o convite adiante, hahaha. :-)

  6. Pingback: Trabalho Eficaz com Código Legado | hopeful ramble

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s