Boa notícia para a comunidade Java: a Oracle evitará estabelecer um clima de competição entre o Netbeans IDE e o Eclipse.

Leia matéria traduzida pelo Google translate.

Ou a matéria original em Inglês

Este artigo dá uma dica interessante de como combinar vários JARs em um só utilizando o NetBeans. (A tradução automática é um pouco sofrível, melhor se ler o original. )

Ao iniciar um novo projeto, é preciso determinar qual será a estratégia para implementação de persistência de dados. Esta decisão é crucial, pois ditará a qualificação e pré-requisitos dos desenvolvedores que o gerente deverá contratar. O sistema escolhido também terá grande influência sobre a produtividade da equipe, o custo total do projeto e, já na parte técnica, esta escolha trará muitas outras consequências que podem determinar o sucesso ou fracasso de um produto de software.

Caso a empresa tenha investido milhões de Reais em licenças de um certo sistema de bancos de dados, caberia perguntar se o driver do framework está sendo mantido contra falhas de segurança, bugs e possuindo todas as atualizações devidas. O framework de persistência está em desenvolvimento ativo? Há suficiente oferta de profissionais especializados neste framework no mercado?

JDO
Eis que, para um determinado sistema ainda no estágio de planejamento, minha escolha foi o JDO para implementar a camada de persistência de objetos.

Sempre trabalhei com Hibernate, no entanto tenho notado maior empenho da Sun(agora Oracle) em favorecer padrões independentes de terceiros. Não tenho qualquer crítica à JBoss, pelo contrário, nunca tive qualquer problema com o Hibernate e continuo fã deste ORM.

Como citado acima, esta escolha terá consequências remotas, tanto na manutenção do sistema quanto no desenvolvimento de versões futuras. Assim, acredito que, neste momento, o JDO é mais seguro em termos de “adoção institucional” pela Oracle, digamos assim.

O grande medo de qualquer gerente de projeto é inserir um COBOL no meio do sistema, um framework ou linguagem que, daqui a 5 ou 10 anos, só será compreendido por uma elite de programadores de alto custo.

Google App Engine
Um fator decisivo na escolha do JDO ao invés de Hibernate ou JPA foi a possibilidade de executar o aplicativo finalizado no Google App Engine.

Um dos prerequisitos colocados pelo meu cliente é que o sistema deva poder executar transparentemente, ou com poucas modificações, no Google App Engine. Portanto mais um fator à favor do JDO.

Implementações JDO
Tendo escolhido JDO como API de abstração de dados, passo a procurar uma implementação deste padrão que propicie persistência via RDBMS. A implementação da Apache JDO é apenas demonstrativa, e neste momento suporta apenas arquivos comuns como fontes de dados. Não possui, portanto, suporte a RDBMS.

DataNucleus AccessPlatform 2.0
Apesar do nome comercial, a implementação DataNucleus adota a licença Apache 2.0, livre de quaisquer amarras legais e autorizada para uso comercial. A implementação aparenta ser bem completa, incluindo suporte para incontáveis fontes de dados, entre arquivos, RDBMS, XML e outros.

Como já era esperado, a lista de dependências do AccessPlatform é imensa. Trata-se de um sistema completo, e complexo, de relação objeto-relacional(ORM). Como este tipo de aplicativo costuma ser empregado em estações de trabalho ou servidores com capacidade de sobra, a lista de pre-requisitos não é um problema. No entanto, se precisar uma solução para dispositivos móveis ou smartphones, esqueça o AccessPlatform.

Datastores
Nesta lista você encontra todas as fontes de dados que o AccessPlatform é capaz de utilizar. Vale ressaltar que o sistema suporta Google BigTable(do Google App Engine) e MongoDB – um sistema de banco de dados “noSQL”, ambos fortes candidatos a adoção em novas gerações de apps para WWW.

Instalação
Primeiramente, é preciso baixar uma versão do AccessPlatform. A versão 2.1 encontra-se em desenvolvimento na data deste post, portanto baixaremos a última versão 2.0 disponível.

Baixe Aqui – Este endereço possui link atualizado para o SourceForge.

Caso leia este post algum tempo depois, verifique a situação de versões posteriores, visto que a 2.1 estava praticamente pronta para lançamento nesta data.

O seguinte endereço possui diversos links para iniciantes, além de explicação do processo de desenvolvimento utilizando o JDO.

Basicamente, o processo de trabalho se resume a dois itens fundamentais:

1) Determinar que classes você irá armazenar permanentemente. Isto é trivial, basicamente é a parte do sistema que reflete o modelo de dados.
2) Utilizar o JDO para obter objetos do banco de dados, modificar objetos, salvá-los novamente, sempre através de um PersistenceManager fornecido pela implementação JDO(que é o “trabalho bruto” do AccessPlatform)

Cada ítem, é claro, possui detalhes técnicos. Como buscar objetos(utilizando JDOQL, a linguagem de consulta do JDO), como armazenar objetos, e por aí vai.

Sendo uma implementação 100% de acordo com o padrão JDO, a documentação da Oracle do JDO é válida para o AccessPlatform. Assim, não faltam fontes para estudo desta tecnologia online. O único problema é que a maior parte do material está em Inglês, e isso pode limitar o acesso de alguns.

Links
Como usar a JDO com o Google App Engine – Em Português
Iniciando com JDO – Oracle
Iniciando com JDO – DataNucleus, desenvolvedora do AccessPlatform
JDO definido na Wikipedia
Página principal do JDO na Oracle

Talvez você tenha passado batido(a) pela novidade do Firefox 3.6: o Java não é mais habilitado através das opcões de conteúdo(na tela onde o Javascript também era ativado/desativado).

E o plugin para a versão 3.6 deve seguir o padrão NPAPI.

Então, após apanhar algumas horas para colocar o sistema do Banco do Brasil funcionando novamente no Linux, finalmente conseguí.

Vá até /usr/lib/mozilla/plugins/ e rode:


ln -s /opt/jdk1.6.0_21/jre/lib/i386/libnpjp2.so libjavaplugin_oji.so


Substitua /opt/jdk…. pelo diretório onde instalou o JDK da Sun Oracle.

Por que o nome libjavaplugin_oji.so?? Não é obrigatório, e seu sistema pode estar configurado diferente: verifique no about:config se a variável java.java_plugin_library_name é javaplugin_oji. Lembrando que o nome da biblioteca no config vai sem o prefixo lib e o sufixo .so. Então javaplugin_oji traduz-se em libjavaplugin_oji.so – que foi o que usamos.

Reinicie o navegador, e visite a página about:plugins. O Java já deve constar na lista de plugins ativados.

PS. Tive este problema no Fedora Core 13, não testei esta dica em outras distros.

A quem interessar, lá vai um esboço de cliente JDBC para IBM DB2 Express-C. O nome do driver mudou de COM.ibm.db2.jdbc.app.DB2Driver para com.ibm.db2.jcc.DB2Driver

É importante, também, acertar o URL de conexão, visto que jdbc:db2:database puxará o driver nível 2, enquanto que jdbc:db2://localhost:50000/SEUBANCODEDADOS usará nível 4(documentado como nível 2 OU 4, porém é quase certo que use o último). Caso utilize o formato anterior, é possível que o sistema peça uma biblioteca não incluida no DB2 Express-C (jcc2).

Ajustando o CLASSPATH
No diretório de instalação da instância, procure o diretório java. No meu caso é /opt/db2/V9.7/java/. Lá encontrará os arquivos db2jcc.jar e db2jcc_license_cu.jar – inclua ambos no CLASSPATH. O primeiro inclui a base para clientes java, e o segundo inclui a licença de uso livre do DB2 Express-C.

package db2;

import java.sql.*;

public class db2query {

	public static void main(String args[]) {
		try {
	        Class.forName("com.ibm.db2.jcc.DB2Driver");
			Connection conn = DriverManager.getConnection("jdbc:db2://localhost:50000/SEUBANCODEDADOS", "usuario", "senha");
			Statement stmt = conn.createStatement();
			ResultSet rs   = stmt.executeQuery("SELECT COUNT(*) from schema.tabela");

			if (rs.next()) {
				System.out.println("Quantos registros: " + rs.getString(1));
			}
			else {
				System.out.println("Nenhum registro encontrado.");
			}

		} catch(Exception e) {
			e.printStackTrace();
			System.exit(1);
		}
	}

}

É claro que código de produção deve separar as Exceptions e tratar eventuais erros, o exemplo acima é apenas ilustrativo.