goncin@wordpress.com:~$ _

Linux, programação e toda sorte de nerdices

Java: a hora e a vez do OpenJDK

Antes de mais nada, corrijam-me se eu estiver errado. Não sou desenvolvedor Java, sou antes um usuário da plataforma.

Com a aquisição da Sun Microsystems pela Oracle, em janeiro de 2010, o rumo do desenvolvimento da plataforma Java, e de outros projetos open source antes patrocinados pela empresa adquirida, foi radicalmente alterado. Em linhas gerais, pode-se dizer que a Oracle subiu o tom com as comunidades e ecossistemas formados em torno daqueles projetos, levando-os a redefinir sua forma de colaboração. O fato mais notável decorrente dessa nova conjuntura, sem dúvidas, foi o surgimento da The Document Foundation, criada especificamente para gerir o LibreOffice, um fork do OpenOffice.org. A comunidade da suíte de escritório concluiu que não poderia continuar nos termos que a Oracle passou a impor, e preferiu iniciar um novo projeto, baseado no primeiro, mas sem esperar nada de Larry Ellison – nem patrocínio, muito menos ordens.

Em relação ao Java, a postura da Oracle foi ainda mais pedante. Acreditando que números de alta cifra (milhões de desenvolvedores e bilhões de dispositivos, segundo ela mesma) lhe conferem autoridade para tanto, a empresa arrogou para si – e somente para si – o direito de distribuir sua versão “proprietária” do Java, tanto o SDK (para desenvolvimento) o JRE (para executar as aplicações). Com isso, as inúmeras distribuições Linux ficam proibidas de distribuir o Java da Sun Oracle.

Num momento em que até a Microsoft, a partir do Windows 8, está adotando o conceito de app store no sistema operacional, é uma contratendência e tanto. A ideia, já adotada há anos pelas distros Linux e mais recentemente pelas plataformas móveis, é que o usuário não tenha que “correr atrás” das aplicações de que precisa, visitando inúmeros sites e fazendo downloads nem sempre confiáveis. Com as centrais de aplicativos, a instalação da solução está a um clique (ou dois, ou três…), dentro do próprio ambiente do SO. Nesse contexto, a Oracle obrigará quem precisar de sua versão do Java a visitar o respectivo site para baixá-lo. No mundo Linux, suspeito, só agirá assim quem realmente necessitar do Java “proprietário”.

A partir dessa (controversa) decisão, as distros passarão a entregar somente o OpenJDK/OpenJRE, a versão do Java 100% livre. O que muda com isso? Para o usuário médio, quase nada. O OpenJDK parece estar maduro o suficiente para a maioria dos usos. Desenvolvo em PHP utilizando Netbeans como IDE, e posso afirmar que o ambiente integrado funciona tão bem com o OpenJRE quanto era com o JRE proprietário.

Vale lembrar que a versão 7 da plataforma Java também já está disponível em implementação open source, e será padrão na próxima versão do Ubuntu, a Oneiric Ocelot (11.10), que será disponibilizada ainda este mês. Para aqueles que não quiserem ou não puderem esperar, é possível instalar o OpenJDK/OpenJRE no Natty utilizando um PPA, assim:

sudo add-apt-repository ppa:dlecan/openjdk
sudo apt-get update
sudo apt-get install openjdk-7-jdk

(No último comando, basta substituir openjdk-7-jre para instalar somente o JRE. Para instalar o código fonte, acrescente openjdk-7-source.)

Mas, por óbvio, nada é perfeito. Há aplicações (ou deveria eu escrever “internet banking de bancos brasileiros”?) que foram feitos com e somente para para o Java “proprietário”. Quem projeta e desenvolve essas soluções que ignoram o OpenJDK deve, agora, rever suas concepções. A alegação de suportar somente o Java da Oracle, no mais das vezes, é calcada nos termos “segurança” e “homologação”. Pode-se contra-argumentar que a Oracle, sentada sobre os impressionantes números que já citei, sente-se confortável o bastante para relegar as falhas de segurança da plataforma Java a segundo plano, não se empenhando em saná-las. Tanto é assim que a Fundação Mozilla está considerando seriamente desativar o plugin do Java nas próximas versões do Firefox. Isso sem mencionar as frequentes críticas que são feitas à arquitetura da plataforma, às quais a empresa parece não querer oferecer uma resposta à altura.

Por tudo isso, creio que poderemos ver, num médio prazo, o futuro do Java sendo decidido exclusivamente pela comunidade Java, num cisma semelhante àquele que deu origem à The Document Foundation. A chave para que isso aconteça é a adoção maciça do OpenJDK, entregue pelas distribuições Linux e, quiçá, pelos próprios desenvolvedores Java, em conjunto (bundled) com suas aplicações. Só assim, vendo diminuída sua base de usuários, a Oracle venha a sair de sua zona de conforto e mude de atitude.

Anúncios

6 Respostas para “Java: a hora e a vez do OpenJDK

  1. Bruno Codemann 06/10/2011 às 16\0412

    Eu sinceramente não vejo razões para utilizar java. O desempenho está longe de ser bom, o desenvolvimento é de uma complexidade desnecessária(zilhões de xml de configuração para o desenvolvimento web), webservices em java continuam a ser um problema, a linguagem em si é extremamente burocrática… Há muitas opções no mercado, todas melhores que o Java.

    • goncin 06/10/2011 às 16\0415

      Sim, hoje há opções melhores do que o Java. Mas há alguns anos não havia, e hoje existe uma enorme base de código Java rodando por aí, e temos que conviver com ela. Por exemplo, uso o Netbeans para programar em PHP porque (ainda) não apareceu nada melhor, open source e que rode em Linux para essa tarefa. Mas eu também não desenvolveria em Java.

  2. Francisco 18/10/2011 às 09\0945

    Não entendo muito sobre o Java, tanto porque nem é a minha praia. Mas não entendo: se a proposta da linguagem é de se desenvolver uma vez e rodar a aplicação em qualquer lugar, para quê isso, já que é possível usar outras linguagens e compilar uma aplicação para um determinado sistema, com um desempenho melhor? Usar Java para Web então me parece ainda mais sem sentido, nunca entendi realmente. :-S

    • handsOf 19/10/2011 às 06\0617

      Bom… levantar bandeiras na área de TI nem sempre costuma ser um bom negócio, podemos sempre acabar dando com a língua nos dentes. O java realmente possui um desempenho inferior comparado à “algumas” linguagens do mercado. Se quisermos comparar por exemplo à linguagem C, Python, Pascal e quaisquer autômatos que não dependam de interpretadores. O “tesão” da linguagem Java, se é que assim posso dizer parte do princípio de padrões de projeto. Um amigo acima citou a seguinte palavra, “burocrática”. Realmente, e é portanto o que faz do java uma linguagem fortemente Orientada à Objetos permitindo uma estrutura de código extremamente profissional no que tange à paradigmas e padrões de projeto. Comparar linguagens é uma tarefa complicada, controversa porém necessária. Se formos desenvolver um web-site cujas funcionalidades não estendam à uma lógica simples de acesso a dados em DBMS e que utilize como recursos visuais tecnologias orientadas à script como jQuery ou AJAX realmente não precisaríamos do Java e seria loucura deixar de desenvolver um projeto destes utilizando PHP. Porém se estivermos falando de um ERP, que contém módulos projetados para Desktop, Sistemas de Dados Distribuídos, DataMart, DataMiner seria muito mais conveniente , do ponto de vista de projeto utilizar-se apenas um recurso para implementação ao invés de ficar “encaixando” tecnologias que podem acabar gerando problemas de compatibilidade e ou configuração. Claro que: estamos vivendo a era “Clouding”, portanto a base de dados sendo centralizada, poderia ser indiferente o uso da tecnologia que faria o acesso ao mesmo. Levando estes pontos em consideração faz vermos que o java se “preocupa” com isto. A Sun e Oracle se comprometem em trazer os novos conceitos de desenvolvimento para dentro da JVM possibilitando à linguagem um ciclo de vida longo que mesmo nos dias de hoje se faz atual. Pensando nisso é que surgiu o J2EE e suas respectivas melhorias, especificações e frameworks… Sou meio suspeito para dizer isso, mas vejo por exemplo no mercado de desenvolvimento web, que php só é largamente utilizado por alguns aspectos:
      1º uma linguagem relativamente simples e intuitiva, que utiliza o paradigma de blocos/estruturados.
      2º fácil de aprender, ninguém precisa estudar estruturas de dados complexas, entender problemas de comunicação interprocesso e concorrência. O que faria do php um nível mais alto de linguagem.
      3º um código mais consciso, menos bibliotecas sendo carregadas para executar uma determinada tarefa ou processo.

      Agora… Por outro lado muito clamam questões quanto à tempo de desenvolvimento e recursos indisponíveis o que não é uma verdade. Existem inúmeros frameworks para desenvolvimento web realmente tão profissionais senão superiores aos desenvolvidos em php. Quem um dia tiver a oportunidade de comparar o WordPress(php) com o LifeRay(java) verá claramente que não existe em php recurso tão robusto e profissional para CMS empresarial. Do ponto de vista do desempenho, falado anteriormente: sendo aplicações web, que realizam tarefas que não dependam de processamento pesado, podemos seguramente colocar para rodar 2 aplicações semelhantes em tomcat(java) ou apache(php) e veremos que esta diferença é imperceptível, lembrando que quem acessa recursos que realmente poderiam ser prejudiciais em termos de desempenho são por exemplo: bases de dados, que por sua vez retornam seus resultados num tempo x, independentemente de quaisquer linguagens que estejam fazendo a consulta…

      A conclusão é que: Defender uma bandeira não vale a pena. O ideal é o profissional conhecer o mínimo de cada linguagem, ou deter um sólido conhecimento sobre programação em geral. Sintaxe e semântica são detalhes a cada linguagem, porém existem conceitos que não irão mudar de uma para outra. A melhor linguagem é sempre aquela que garante seu alimento. C#, Pearl, Python, Lua cada qual possuí seus atrativos. Porém a pergunta que deve ser feita é: Realmente vou gastar tempo para lidar com esta tecnologia? Compensa? Terei mercado profissional?

      Um exemplo disso seriam os bancos… desde 1900 e vovó morreu, softwares bancários em sua maioria foram desenvolvidos utilizando a plataforma COBOL (Common Bussness Oriented Language), Hoje do ponto de vista, estético, e tecnológico COBOL se tornou uma linguagem defasada, porém continua a funcionar como deveria. Os bancos não irão re-implementar uma coisa que ja está funcionando e de modo eficiente só por que as LP’s evoluíram. E neste balaio passaram-se anos, e ninguém mais quis aprender o velho COBOL. O déficit de profissionais no mercado com experiência nesta linguagem faz qualquer profissional COBOL que ficar desempregado atravessar a rua e arrumar outro emprego. Temos mercado para tudo. Vale frisar que um estudo minucioso se faz necessário. Quer trabalhar com .net, vá em frente. Mas vá sabendo que você não irá vender apenas o seu código. Mas irá vender também toda uma plataforma proprietária cujas licensas são caríssimas. Se quiser programar em Java, vai se deparar com milhões e recursos e frameworks open porém irá gastar muito tempo pra conciliar os conhecimentos…

      Cada qual tem seu valor, o importante é saber qual é a melhor (tempo, custo, recursos, projeto, prazo) para ser utilizada…

      Espero ter ajudado

Deixe um comentário

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

%d blogueiros gostam disto: