Archive for the ‘java’ Tag

Java language end of life (aka. Java as a platform)?

Deve fazer mais um menos uns 5 anos que a maioria de nós ouvimos falar em Ruby on Rails. De lá pra cá, a adoção da linguagem Ruby e do framework Rails subiu de uma forma surpreendente, ajudando a quebrar um pouco a polarização Java<->.Net que tínhamos antes. É claro que Ruby ainda não atingiu a popularidade Java ou de .Net, principalmente aqui no Brasil, mas mesmo assim ajudou a comunidade como um todo a repensar vários aspectos do desenvolvimento de software, principalmente de aplicações web.

Uma das coisas que a revolução do Ruby on Rails fortaleceu é o uso de outras linguagens na Java Virtual Machine. É claro que antes de surgir o Rails já existiam várias iniciativas para rodar outras linguagens dentro da JVM, mas depois de uns anos pra cá esse assunto ficou cada vez mais importante, pois existe muito interesse em rodar aplicações desenvolvidas usando ferramentas produtivas como Ruby on Rails numa plataforma robusta como Java. Hoje tempos diversas engines que permitem rodar muito bem várias linguagens na JVM, como JRuby, Jython, Clojure, Rhino, Groovy, entre outras… Com essa quantidade de linguagens rodando na JVM, já faz alguns anos que se tem falado em Java como plataforma e não como linguagem.

Eu gosto muito dessa idéia, acho que as vantagens dessa abordagem já foram amplamente discutidas, mas resumindo:

  • Java possui uma das mais avançadas máquinas virtuais do mercado. O just-in-time compiler e o garbage collector da JVM, mesmo não sendo perfeitos, são frutos de anos de pesquisa e desenvolvimento, seria muito difícil implementar uma VM igual do zero para outras linguagens.
  • Existe um enorme legado de aplicações desenvolvidas em Java, utilizando Java como plataforma, novas aplicações em outras linguagens podem aproveitar muito do código já existente.
  • Java também possui excelentes servidores web e application servers bem estabelecidos no mercado

Infelizmente, já se passarem alguns anos que esse tipo de abordagem vem sendo discutida, mas não temos tantas empresas adotando Java como linguagem e não como plataforma. Quase todo mundo que desenvolve na plataforma Java usa a própria linguagem Java. Temos sim muitas empresas desenvolvendo novos projetos em Ruby on Rails, mas na maioria dos casos não estão rodando eles em Java. Pelo menos é o que eu tenho visto na nossa comunidade local.

Um dos motivos para isso é a dobradinha Passenger + Nginx (ou mesmo Apache) tem tido muito sucesso para rodar aplicações Rails. As pessoas não precisam recorrer ao JRuby para rodar aplicações Rails num ambiente com uma performance aceitável. O Passenger tem dado conta do recado.

Eu gostaria muito de ver mais empresas adotando Ruby on Rails, acho que poder reaproveitar código já existe e poder rodar numa infra-estrutura (VM + Application Server) já bem estabelecida são dois fatores que podem facilitar a adoção de Ruby on Rails em empresas que utilizam Java, mas não é algo fácil de ser feito. Ruby tem uma sintaxe diferente, um estilo de programação diferente. Leva algum tempo pegar uma equipe que trabalha muito bem com Java e deixar ela produtiva trabalhando com Ruby on Rails.

Recentemente, a ThoughtWorks recomendou que as empresas comecem a avaliar o “Java language end of life”, ou seja, usar outras linguagens na plataforma Java. Quando eu li essa recomendação achei meio precipitado, mas no fim é uma opção tecnicamente viável e pode trazer muitos ganhos de produtividade.

Eu acho que vai demorar muito até a grande maioria das empresas adotarem outras linguagens mais produtivas que Java, mas se você trabalha com Java tem a liberdade de escolher a tecnologia que você vai usar para desenvolver seus aplicativos, já passou da hora de considerar usar outras linguagens que rodam na JVM.

Anúncios

Reload automático de classes com JavaRebel, da ZeroTurnAround

Are you feeling lucky?Uma das coisas mais legais para um cara que desenvolve em Java e depois começa a desenvolver em uma linguagem como Ruby é o feedback instantâneo – basta você alterar o código-fonte e a alteração já é refletida imediatamente na Aplicacão em runtime. Programando em Java tem que passar pelo processo de compilação. Programando Java EE tem que esperar reiniciar o servidor. E isso leva muito tempo.

Um dos primeiros projetos que eu participei foi um software de billing utilizando a boa e velha “arquitetura J2EE”: um monte de EJB sendo utilizado para praticamente todas as operações. Nada contra a arquitetura montada em si (digo, neste post em particular não vou discutir isso, fica para um outro post EJB vs Spring/etc) mas um grande problema era o processo de build e deploy: ele era simplesmente muito demorado! Na melhor das hipóteses, levava uns 5 minutos para executar a build e o deploy no ambiente local de desenvolvimento, mas geralmente levava bem mais tempo. Ou seja, para cada alteração você tinha que esperar pelo menos 5 minutos para poder testar localmente o que você tinha feito.

Esse tipo de situação é muito comum nos projetos desenvolvidos em Java por aí. Como se não bastasse termos perder tempo compilando e empacotarndo o código, temos que reiniciar o servidor e esperar mais algum tempo… É claro que podemos minimizar o problema por usar um pacote expandido e o sistema de debug do Java para recarregar o corpo dos metodos, mas não é o suficiente, você ainda perderá preciosos minutos (ou horas) por dia só com build e deploy.

Eu acho fantástico ter a rapidez de codificar e logo em seguida, sem demorar um segundo sequer a mais, poder testar\executar o código criado ou alterado. É muito chato você ter que esperar todo esse tempo, você acaba com o tempo perdendo a paciência e juntando um monte de alterações para depois fazer a build e o deploy da aplicação. Eu particularmente não gosto disso, quanto mais rápido for o feedback, melhor.

esperando

Para amenizar essa situação, você pode usar a excelente ferramenta Javarebel, da Zeroturnaround. Javarebel é um plugin para a JVM (usando aquele esquema maluco do -javaagent) que faz o reload dos arquivos .class alterados sem precisar reiniciar a JVM! É quase que milagroso, basta apontar qual diretórioas suas classes estão localizadas que ele vai automagicamente aplicar as alterações feitas na aplicação em runtime!
Nada de parar a JVM, nada de reiniciar o servidor, nada de perder vários minutos esperando a aplicação voltar ao ar, as alterações são feitas e aplicadas na hora. Sempre que eu falo do JavaRebel pra alguém, me perguntam: “mas funciona mesmo?”. Faz uns 8 meses que eu estou usando o JavaRebel sem grandes problemas.

Infelizmente é uma ferramenta paga, não é muito caro, mas algumas pessoas evitam todas as ferramentas pagas, mesmo que custem barato. Eu mesmo só estou usando o JavaRebel por que eu ganhei uma licença numa promoção do tipo “primeiras pessoas que mandarem um e-mail ganham uma licença” 🙂 Mas eu acho que vale a pena fazer um test-drive na ferramenta (tem um trial e um eles devolvem o dinheiro caso não esteja satisfeito em 30 dias).

A instalação e configuração é bem simples, o site deles tem uma documetação bem bacana, mas vai aí um resumão: Coloque o jar do javarebel na mesma pasta que o arquivo de licença do JavaRebel e adicione dois parâmetros na hora de subir a JVM:

  • -javaagent:caminho-do-jar-do-javarebel/javarebel.jar
  • -Drebel.dirs=diretório-com-os-arquivos-.class

E é basicamente isso 🙂 Com esses dois parâmetros o JavaRebel vai automaticamente recarregar todas as alteraçõs feitas nos arquivos .class localizados na pasta passada no parâmetro -Drebel.dirs.

Algumas pessoas me perguntam pra que pagar e configurar se o sistema do debugger do Java já tem um jeito para recarregar classes alteradas. O problema do debugger do Java é que ele só recarrega o corpo dos métodos, se você criar uma classe, adicionar um método, remover um método, adicionar um parâmetro, etc, a sua classe não vai ser recarregada. No site do JavaRebel tem uma comparação bem interessante sobre esse assunto.

Infelizmente a ferramenta não é perfeita, tem uma ou outra incompatibilidade, por isso não acho uma boa idéia usar em ambiente de produção. Além disso, muitas vezes o reload da classe alterada não vai ter efeito algum,  por que os frameworks Java em geral se configuram no startup da aplicação e não são reconfigurados quando uma classe é recarreada. Por exemplo, criar uma classe anotada com @Entity não vai fazer o EntityManager enxerge a classe, só depois de ele ser reconfigurado (que geralmente ocorre quando a aplicação é reiniciada), no caso do JPA. O JavaRebel tem algumas gambiarras alguns plug-ins para alguns frameworks como Struts2 e Spring (recomendo não olhar o código para não se assustar).

Eu já usei no Tomcat, JBoss e no Jetty, usando a JVM da Sun, nas versões 1.4, 1.5 e 1.6, tanto no Windows como no Linux. No site deles, eles alegam ser compatíveis com várias VMs e containers:

Supported JVM’s
Sun Java 1.4.xi, 5.x, 6.x
JRockit JVM 8.1sp6 or later
JRockit JVM 9.x 1.5.0_06 or later
JRockit JVM 1.6.x
IBM J9 1.4.x, 5.x, 6.x
Apple MRJ 1.4.x, 5.x, 6.x

Supported JVM’s

  • Sun Java 1.4.xi, 5.x, 6.x
  • JRockit JVM 8.1sp6 or later
  • JRockit JVM 9.x 1.5.0_06 or later
  • JRockit JVM 1.6.x
  • IBM J9 1.4.x, 5.x, 6.x
  • Apple MRJ 1.4.x, 5.x, 6.x

Supported Containers

  • IBM WebSphere 6.x
  • BEA Weblogic 8.x, 9.x, 10.x
  • GlassFish 2.x
  • Oracle OC4J 9.x, 10.x
  • Tomcat 4.x, 5.x, 6.x
  • JBoss 3.x, 4.x, 5.x
  • Jetty 5.x, 6.x, 7.x
  • Caucho Resin 3.0.x
  • Jonas 4.x
  • Equinox OSGi (including Eclipse plugins)
  • IntelliJ IDEA plugins
  • Atlassian Confluence plugins

Não sei se em todos os casos vale a pena usar a ferramenta, desde que eu comecei a usar o JavaRebel não tive nenhum problema sério, só elogios á ferrementa, aumento consideravelmente a produtividade. Eu acredito que pelo menos uma teste vale a pena fazer, criei esse post por que percebi que muita gente ainda não teve a oportunidade ou a curiosidade de conhecer essa excelente ferramenta 🙂

Falando em Java 2009

Domingo eu estive presente na terceira edição do Falando em Java, organizado pela Caelum. Como nas outras edições, o evento foi bem legal, com palestras interessantes e foi uma oportunidade de rever o pessoal do GUJ.
Infelizmente eu não pude participar do evento na parte da manhã e cheguei só na hora do almoço.

A palestra sobre o VRaptor 3 foi ministrada pelo Guilherme Silveira e pelo Filipe Sabella (aka Lipe). Pelo que eu entendi, a versão 3 é uma evolução do framework com várias melhorias que a comunidade foi percebendo com o tempo, visando a flexibilidade e a facilidade de uso. Eles realmente querem deixar as “actions” do VRaptor bem limpas mesmo! Isso é um dos pontos positivos do framework, as “actions” nem parece que são “actions”, são POJOs de verdade. É muito bom ver um projeto nascido e mantido dentro da comunidade brasileira evoluindo. Não, eu não tenho problemas com o VRaptor por ter participado um “concorrente“, para mim, como desenvolvedor, é excelente ter boas alternativas para cada projeto. Parabéns para a equipe, boa sorte no processo de documentação (que é um saco fazer :P)

Depois eu assisti a palestra Arquitetura para aplicações Java de médio porte, apresentada pelo Sérgio Lopes e pelo Guilherme Moreira. A palestra apresentou algumas dicas legais que podemos usar no nosso dia-a-dia, alguns lembretes legais sobre como usar Hibernate de maneira eficiente, cluster, entre outras.

Uma palestra campeã foi a do Anderson Leite e Fabio Kung, Para onde vai a Plataforma Java? Linguages dinâmicas, JavaTV, JavaFX e além! Eles explicaram alguns detalhes da atual JVM, como são as instruções da JVM para invocação dos métodos em diversas situações e como será a próxima versão do Java estará melhor preparada para lidar com linguagens dinâmicas, com mecanismos como o invoke dynamic. Os “arquitetos J2EE” que se preparem… veremos cada vez mais projetos usando Java como plataforma e não como linguagem 🙂

Depois o Dr. Jim Webber falou sobre Restful e  Mediatypes. A palestra foi excelente e aumentou muito a minha visão sobre REST. O Jim tem um conhecimento muito bom sobre Restful e Http. Falou sobre muitas coisas interessantes e me deu idéias bem legais para os meus projetos. Com certeza vale a pena dar uma atenção mais forte ao REST como uma alternativa ao SOAP/WS-*. Fazendo uma rápida retrospectiva, todos os Webservices SOAP que eu fiz até hoje poderiam muito bem ser Restful Webservices.

O mais legal com que quem não foi no evento pôde acompanhar pelo Twitter. O pessoal do evento (eu incluso) ficava twittando em real-time o que acontecia no evento. Até hoje o pessoal faz muitos tweets sobre o evento (eu mesmo vou fazer um tweet quando terminar esse post apontando para o blog hehehehe).

Enfim, evento muito legal, como sempre 🙂

Eventos: Ruby no Mundo Real

Evento Ruby e Rails no mundo Real 2009 organizado pelo Guru-SP

Evento Ruby e Rails no mundo Real 2009 organizado pelo Guru-SP

Dia 4 de abril de 2009 ocorrerá em São Paulo, na FIAP, o evento Ruby e Rails no Mundo Real. O conteúdo técnico do evento está sendo organizado pelo grupo Guru-sp.

O evento com certeza é de interesse para todos os desenvolvedores, inclusive os que desenvolvem em Java, devido a importância que a linguagem Ruby vem adquirindo de uns anos para cá e que hoje é possível utilizar Ruby nas plataformas Java e .Net com projetos como JRuby  (que será apresentado no evento) e IronRuby.

Muito se fala hoje em Java como plataforma e não mais como linguagem. Podemos dizer que a linguagem Java não esta evoluindo na velocidade que a comunidade espera (eu particularmente gostaria muito de ver closures entrando na linguagem) e muitos tem dúvidas se a Sun (que  é a principal mantenedora da linguagem Java) tem condições de continuar evoluindo a linguagem devido a sua delicada situação financeira.

Eu uso muito a linguagem Groovy no meu dia-a-dia e acompanho com muito interesse a impressionante evolução do JRuby. Depois que você se acostuma com a agilidade destas linguagens, fica até chato voltar a usar uma linguagem, digamos, tradicional 🙂

lula_plantando_uma_rvore

Mesmo que você não acredite em outras linguagens na JVM, Ruby e Ruby on Rails tem tido um crescimento muito interessante no mundo inteiro, e inclusive tem gente prevendo um grande crescimento para o Ruby no Brasil.

Enfim, as palestras parecem muito interessantes, os palestrantes são bons, o evento é num final de semana, num local bem acessível em São Paulo e com um custo relativamente baixo. Eu acho que vale a pena dar um pulo no evento 🙂