Análise: Compra da SUN pela Oracle

Bruno Braga on April 20th, 2009

Como muitos já sabem, as Oracle anunciou hoje que está comprando a SUN Microsystems.

No GUJ as pessoas estão trocando opiniões com o objetivo de avaliar se isso é ou não uma boa notícia e comparando com a tentativa anterior de compra por parte da IBM.

Como postei no GUJ, sem ver as estrategias de cada empresa a médio / longo prazo não da para dizer que vai ser melhor com a Oracle, IBM ou outra companhia.
Qualquer preferencia seria chute ou opinião pessoal. Existem muitas coisas envolvidas em um negocio deste tipo.

Mas eu espero que o Java tenha uma atenção maior da nova empresa, mais investimento e que isso torne mais rápido nas decisões e implementações do JCP.

O que me preocupa no momento é que a Oracle não tem perfil Open Source como a SUN (java, solaris) / IBM (eclipse, team concert, dojo, geronimo, etc…).

O caminho para o Java crescer na minha opinião não é com a logo da Oracle ou de qualquer outra empresa. O caminho é criando / mantendo uma estrutura separada “Java Foundation” ao estilo “Eclipse Foundation” que seja mantida / gerenciada por uma grande companhia mas que ao mesmo tempo esteja aberta a contribuição de outras empresas / pessoas.
É isso que a Oracle precisa aprender a fazer e espero que comece buscando experiências dentro da SUN.

Se em algum momento da transição começarem a levar a SUN para dentro do site da Oracle como “produto / tecnologia Oracle”, já ferrou com as outras empresas. Na minha opinião, não é disso que Java precisa.

Por questão de ego/concorrência uma empresa que investia em Java pode passar a investir em PHP, outra em Ruby e ai os players podem acabar divididos em relação a linguagem.
Se isso acontecer quem vai rir é a Microsoft que vai ter mais moleza ainda com o .Net e tecnologias para desenvolvimento corporativo.

Portanto a minha “dica” é: o foco em Open Source e em uma estrutura separada é importante.
Espero que a Oracle tenha ainda comprometimento e investimento neste modelo :)

Agora é esperar para ver o que vai acontecer a médio prazo.

Subscribe to this blog's RSS feed

Oracle vs Java

Bruno Braga on July 1st, 2008

Atualmente estou atuando em um projeto onde é necessário a integração do Oracle com Java. Ou seja: é necessário executar código Java dentro do Oracle para uma determinada funcionalidade.

Esse projeto faz parte de um treinamento/consultoria sobre Websphere MQ (antigamente chamado de MQSeries) para um cliente, e vai ser o primeiro tema / “puxão de orelha” depois da reformulação do blog.

Puxão de orelha porque alguns itens referentes a integração do Oracle com Java não são legais. Mas para entender o problema e o funcionamento da integração vamos a um rápido cenário do aplicativo:

Além do treinamento de Websphere MQ o cliente solicitou que fosse desenvolvido um conector MQ em Java para posteriormente ser utilizado pelo sistema deles. Então optamos por desenvolver o conector MQ usando JMS e abstrair toda a complexidade da comunicação. Ele iria enviar mensagens com um comando e receber mensagens com um comando a partir do aplicativo Java. Até esse ponto estava excelente.

A dificuldade começou quando o cliente solicitou que o Conector MQ fosse executado dentro do Oracle através de uma trigger já que o Oracle suportava Java. Realmente o Oracle suporta Java, mas não tão bem como era esperado.
Somente para deixar claro: classes Java simples (recursos nativos da JVM) rodam muito bem no Oracle, isso foi um ponto bem positivo. O problema é executar uma aplicação ou conector que tem vários jars como API.

Objetivamente seguem detalhes sobre pontos problemáticos do Oracle versão 10.2:

  • ele não aceita jar’s externos. Todos os jar’s devem ser carregados para o banco usando o comando loadjava.
  • o comando loadjava carrega as classes do jar mas deixa todas com status INVALID !?!?… a maneria de resolver isso é usar o comando loadjava com o parâmetro “-resolve”.
  • o problema do parâmetro “-resolve” é que ele tenta “re-compilar” todas as classes do jar (sendo que um jar já é algo pronto para utilizar). Para cada classe o Oracle solicita as dependências (classes que estão no import). Então para incluir um jar de um driver do MQ preciso de N outros jars para satisfazer as dependências de compilação;
  • uma forma de resolver o problema acima podemos até utilizar o parâmetro “-genmissing” do comando loadjava, ele vai gerar uma classe fake para cada dependência e evita problemas de compilação, mas é obvio que se a classe fake for usada em qualquer ponto do processo (direta ou indiretamente) vai dar erro (ORA-29532: Java call terminated by uncaught Java exception: java.lang.NoClassDefFoundError:
    !!!ERROR!!! generated by genmissing) – então o genmissing não é muito útil, somos obrigados a ter as dependências para compilar / resolver quase tudo usando o “-resolve”;
  • o Oracle carrega para dentro do banco a classe que queremos importar + todos os jars necessários para execução + todas as dependências. Então temos um excesso de classes desnecessariamente;

Por causa dessas limitações a integração do Oracle com Java não é tão transparente. Não acredito que isso tenha um tratamento melhor no Oracle 11. Apesar do banco Oracle não ser um Application Server, poderia pelo menos seguir a arquitetura Java e ler as libs de um CLASSPATH. A parte de ter que carregar os jar para dentro do Oracle e re-compilar matou parte do suporte a Java do banco. Esse trabalho todo não vale a pena :)

Então esse foi o puxão de orelha, e todos esses problemas foram suportados pelo suporte oficial Oracle (http://metalink.oracle.com).

Mas em tempo, o SQLJ é bastante poderoso: podemos escrever uma classe Java (usando recursos nativos) e em determinados pontos utilizar #sql() (querys) com váriaveis Java. Então considerando somente esta necessidade a utilização é válida.