Artigo Java Magazine 23 - Tira-Dúvidas

Esse artigo faz parte da revista Java Magazine edição 23. Clique aqui para ler todos os artigos desta edição

Atenção: por essa edição ser muito antiga não há arquivo PDF para download.Os artigos dessa edição estão disponíveis somente através do formato HTML. 

Tira-dúvidas

Geração de PDF com JAsperReports

Estou utilizando o exemplo da edição 21 (“Relatórios Avançados”) como base para gerar relatórios com iReport e JaspReports a partir de um servlet que roda no Oracle9iAS. Notei que o código que exporta para PDFs está comentado no arquivo produto.java. Descomentei o código, mais o resultado foi os seguinte erro:

java.lang.NoSuchMethodError

   at.net.sf.jasperreports.engine.export.JRPdfExporter.

       exportText(JRPdfExporter.java:1622)

Reinaldo Cerioli

Sempre que ocorre erros de “NoSuchMethod”, “ClassDefNotFoud” e similares, há um problema de configuração no classpath da aplicação, ou então forma utilizadas versões incorretas do JRE/JDK ou APIs de terceiros. Verifique também se todos os jars fornecidos com o JasperReports tenham sido copiados para a pasta WEB-INFO/lib da sua aplicação web. Cheque que ainda se algum deles já estava incluso em sua aplicação, possivelmente em uma versão diferente.

Há ainda a possibilidade de conflitos de versões entre bibliotecas do JasperReports (especialmente componentes do projeto Jakarta Commons, o iText e o Log4J) e as mesmas bibliotecas utilizadas internamente pelo servidor de aplicações ou por outras aplicações instaladas, caso ele não compartimentalize os classloader das aplicações web. O J2EE especifica que deve haver esta compartimentalização, de modo que não haja conflitos de classes de uma aplicação com as de outra aplicação, ou com as classes do próprio servidor. Mas, em nome de melhor desempenho, muitos servidores não o fazem em suas configurações padrão.

O artigo sobre o JasperReports publicado na Edição 13 inclui um exemplo de servlet que gera relatórios em PDF, e que poderá resolver muitas das suas dúvidas.

Acesso a um servidor MySQL remoto

Desenvolvi uma aplicação com banco de dados MYSQL, mas ela só funciona na minha máquina local. Quando usa a URL “jdbc:mysql://localhost/minhaempresa” acesso banco normalmente. Mas não consigo conectar com a URL “jdbc:mysql://delta/minha empresa” onde “delta” é o nome da maquina local, ou mesmo usando o IP da máquina em vez do nome. O que esta faltando para fazer a aplicação funcionar remotamente?

Danilo Fabiano

Para que uma aplicação possa se conectar a um servidor MYSQL rodando em outro computador Linux, devem ser verificadas duas questões:

1.     O firewall interno do servidor Linux está permitindo conexões ao MySQL? Em caso de duvida, experimento desligar o firewall com o comando iptables-F. se com o firewall desligado a conexão funcionar, você deve modificar as regras do iptables para permitir conexões á porta 3306, que é a padrão para o MySQL.

2.     Lembre-se que a autenticação do MySQL é baseada no trio usuário-host-senha e não no par usuário-senha como acontece na maioria dos outros bancos de dados. Então a senha que vale para conexões partindo do IP de loopback (127.0.0.1) não é válida para conexões que partam de outros endereços IP, inclusive o da própria máquina. Deve ser utilizado o comando grant para autorizar as conexões de máquinas remotas; pode ser usada a máscara % (como na cláusula LIKE do SQL) para indicar qualquer host de origem, por exemplo:

      grant all on banco.*to teste@’%’identified by ’senha’;

Funções agregadas do EJB

Existe uma maneira de conseguir o maior valor de campo através de EJB-QL?

Luiz Alberoni

O suporte a funções agregadas (MIN, MAX, COUT, AVG, e SUM) só existe a partir da versão 2.1 do EJB. Versões do JBoss anteriores à 4.0 suportam apenas o EJB 2.0 (embora reconheçam funções agregadas em consultas JBoss-QL). A maioria dos demais servidores de aplicação J2EE também foram apenas recentemente atualizados para o suporte á especificação 2.1, então e bem possível que o seu servidor ainda não reconheça estas funções.

JSP 2 com o Internet Explorer

Tenho tentado rodar os exemplos do artigo “Aplicações Web no Ttomcat 5” da Edição 18. Foram necessários alguns ajustes para fazer funcionar as paginas JSP no internet Explorer 6.0. Por exemplo, em info.jsp tive que modificar a declaração do taglib core:

<%@taglib uri=”http://java.sun.com/jstl/core”prefix=”c”%>

E para mostrar uma expressão EL no navegador tive que usar a tag out:

<c:out value=’${header[“User-Agent”]}’/>

Mas em outros exemplos não tem jeito. Não consigo fazer funcionar.

Sidarta da Silva

O problema não tem relação com a Internet Explorer, pois o navegador nunca recebe as páginas JSP, mas apenas o HTNL resultante. Tudo indica que você esta utilizando versões mais antigas do Tomcat ou do JSTL do que as indicadas pelo artigo. Os exemplos exigem JSP 2.0, Servlets 2.4 e JSTL 1.1, que correspondem ao Tomcat 5.x e Taglibs Standart 1.1.x. O uso do tag <c: out>, assim como da declaração diferente para o taglib core, era necessário no JSP 1.2, usando com o Tomcat 4.x. Esta versão do Tomcat é capaz de rodar apenas o JSTL 1.0, fornecido pelo Taglibs Standard 1.0x. Então basta atualizar sua instalação do Tomcat e do Taglibs-Standart para que os exemplos funcionem sem modificações.

Depuração JSP no Eclipse

Sou desenvolvedor Web e Uso o Eclipse 3, com o JDK 1.3 e Tomcat 4.1, além dos plug-ins Lomboz 3.0 e Sysdeo. Minha dúvida é: como posso depurar páginas JSP? Uso normalmente esse recurso em Classes Java, mas em JSPs não consigo sequer incluir Breakpoints.

Hainison Dornelas

A maioria dos plug-ins para o Eclipse e outros Ides não suporta a depuração direta da paginas JSP. Permite apenas depurar os servelets gerados pela compilação dos JSPs pelo container web. Se você quiser se ater ao Sysdeo, siga as instruções no site do produto sobre como abrir no Workbenck do Eclipse os  os servelets correspondentes ás páginas JSP para realizar a depuração; note que são necessários patches para que isto funcione no Tomcat 4.1.x, devido a um bug na geração do servlets; as versões 4.0.x e 5.x do Tomcat não necessitam de patches.

Mas há caminhos mais fáceis. Alguns plug-ins, como o Lomboz e o JBoss-IDE, implementam a JSR-45 ( Suporte a depuração para outras linguagens), que possibilita depurar diretamente o código-fonte de páginas JSP ( e definir breakpoints). São exigidas versões mais novas do Lomboz (a partir das 3.0) e do Tomcat (5.0 em diante).

Banco de dados com NetBeans

Sou iniciante em Java e em NetBeans e Gostaria de saber como exibir em um formulário os dados cadastrados em um banco de dados (no meu caso o PostgreSQL). Estou usando o NetBeans e já fiz as configurações necessárias para a conexão na aba Runtime.

Marcos Paulo

Primeiro é importante destacar que o Netbeans não fornece componentes visuais para banco de dados, como existem no Visual Basic ou Delphi, por exemplo. Não é esta a filosofia do Java. Os recursos de conexão a BDS do NetBeans existem para que o desenvolvedor possa criar tabelas, preenchê-las com dados de testes ou testar comandos SQL, sem precisar de utilitários específicos do banco adotado.

Para exibir os dados cadastrados, você precisa conhecer as classes da API JDBC (pacote java.sql), que são parte do J2SE. A programação dessa API é bem simples, e com poucos comandos é possível conectar ao banco, ler os dados, copiá-los para caixas de texto (por exemplo) e depois salvar as alterações. Note que usando o JDBC, será necessário escrever comandos SQL.

Programadores Java mais experientes utilizam frameworks de persistência como o Hibernate e o OJB, que eliminam a necessidade de escrever SQL e dispensam chamadas diretas a métodos do JDBC. Isso permite fazer uma programação puramente orientada a objetos. Mas ainda assim, estes frameworks são baseados em APIs, ou seja, em código Java escrito pelo desenvolvedor, e não em propriedades de componentes visuais configurados por um IDE.

Mesmo com os ganhos ao usar frameworks de persistência, porém, recomendamos o aprendizado do básico do JDBC.

As edições 1, 7, 8, 14 e 15 incluem artigos sobre JDBC e bancos de dados que poderão ajudar.

Threads e paralelismo

Lendo o artigo de Osvaldo Doederlein sobre threads (“Concorrência no Java 5”, Edição 20) fiquei com algumas dúvidas. Estamos desenvolvendo uma arquitetura baseada em cluster de alta performance e não sabemos se seria viável usarmos Java para este tipo de aplicação. O processamento de threads seria rápido o suficiente para o processamento paralelo? A máquina virtual nos permite isso?

Marcio Bruno

O recurso de multithreading é suficiente para explorar as capacidades de uma máquina única, inclusive em sistemas multiprocessados de todos os tipos os tipos (SMP, hyperthreading ou as novas arquiteturas multi-core). Para clusters, os threads não é dado nenhum suporte específico. Não é possível criar um processo com threads espalhados por diversos nós (exceto numa JVM da IBM ainda em fase de pesquisa, a Cluster VM for Java – www.haifa.il.ibm.com/projects/systems/cjvm). Aplicações Java em cluster utilizam containers J2EE que distribuem a carga de trabalho pelos nós do cluster, o que resolve o problema de aplicação corporativa, web etc., mas não satisfaz os requisitos de aplicações paralelas de alto desempenho.

Nestas, tipicamente, a comunidade entre os nós é freqüentemente e precisa ser extremamente eficiente – protocolos como RMI, IIOP, HTTP, JMS ou SOAP não dão conta.

Uma solução popular é a Message Passing Interface (MDI) que é uma interface de mensagens de alto desempenho e padronizada. A mpiJava (hpjava.org/mpijava.html) é uma implementação Java da MPI, que permite construir sistemas paralelos de alta performance tanto em Java puro, quanto misturado com outras linguagens. No mesmo site você encontrará o HPJava, uma extensão da linguagem Java (que gera código que roda em JVMs padrão), com suporte à vetorização automática de código e facilidades para uso de MPI.

Osvaldo Doederlein

Patterns e Hibernate

Li o artigo de Júlio Faerman na Edição 21 da Java Magazine (“Patterns aplicados”) e gostaria de parabenizá-lo pela clareza do texto e pelos ótimos exemplos utilizados. Aproveito para perguntar sobre padrões e o Hibernate. Podemos utilizar o padrão DAO para persistir as classes criando uma fabrica para o Hibernate, ou devemos trabalhar com a API do Hibernate diretamente nas classes de negócios do sistema? Acredito que utilizando o DAO teremos uma arquitetura melhor. Estou correto? Além disso, em algumas listas de discussão, venho observando algumas pessoas defenderam que Vos/DTOs deixam de ser úteis quando se utiliza o Hibernate como mecanismo de persistência. Acredito que isso seja verdade em pequenos sistemas onde não há a divisão clara de papéis entre desenvolvedores. Mas em sistemas grandes, acredito que os Vos continuam sendo úteis, por permitirem aos desenvolvedores da camada de apresentação trabalharem com modelos diferentes dos da camada de negócios, e tornando possível utilizar adaptadores para efetuar a tradução de um modelo para o outro. Você poderia me esclarecer estas dúvidas?

André Luiz Rodrigues

Fico feliz que tenha gostado do artigo. Lembre-se que “Arquitetura melhor” depende muito das suas necessidades. Se você pretende cobrir situações em que o Hibernate não é tão apropriado, como a persistência em arquivos, sistemas legados ou otimização especifica do SGBD, certamente o uso de DAOs será útil. Você poderia ter, por exemplo, “HibernateDAO” para persistência com o Hibernate, “XMLDAO” para gravar os dados em arquivos XML e “OracleDAO”. Agora se o Hibernate cobre a maioria de suas necessidades de persistência, uma hierarquia complexa de DAOs pode ser um desperdício de esforços.

Quanto a Vos/DTOs, o principal problema é quando os objetos mudam de amada, por exemplo, quando saem da sua camada de Model (ex.: EJB) para serem usados na camada View (ex.: JPs). Criar adaptadores para a camada “troca de camada” de cada objeto pode ser um exagero. Por outro lado, manter um único tipo em todas as camadas pode gerar um nível de acoplamento indesejado.

Existem abordagens intermediárias, como comunicar-se entre as camadas via interfaces e criar, um princípio, apenas uma implementação que satisfaça a todas estas interfaces. Dessa forma, ainda temos a alternativa de poder trocar de implementação se for necessário, bastando alterar o Factory ou a configuração do container loC (supondo o uso de arquiteturas de inversão de controle).

Júlio Faerman

Licenças livres e comercialização

Se eu publicar o código finte de meu aplicativo usando algumas licenças de Free Software Foundatin posso, ainda assim, reservar para mim o direito de comercialização? A idéia é compartilhar com a comunidade as idéias de como fazer o software, mas reservar para mim os eventuais direitos de sua comercialização. Isto é possível?

Lauro Kozovits

Nada impede a comercialização de um software livre. Mas esta comercialização não pode impor restrições ao uso, ou a posterior cópia de software. Qualquer uma deve poder copiar o software e ate mesmo vender estas copias em CD, ou via download em um site pago, ou através de outra forma qualquer, pelo preço que escolher, sem pedir permissão prévia nem pagar royalties.

Um software livre também não pode estabelecer regras diferentes pra usuários comercias e não-comerciais, entidades sem fins lucrativos, usuários acadêmicos ou para uso pessoal. Não pode impor restrições pela quantidade de usuários, quantidade de conexões de rede, poder processamento nem volume de dados.

Então a comercialização do software livre, no sentido tradicional de venda de licenças de uso, não é possível. O que pode acontecer, como no caso de empresas como a Conectiva/Mandrake, é a venda de cópias, onde se cobra pelo serviço de prensar CDs e imprimir manuais, ou pela manutenção do servidor que oferece as cópias pela internet.

Ainda assim há modelos de negócios interessantes que podem ser construídos em cima de software livre – e empresas que tem sido muito sucesso com esses modelos. Um exemplo é o gerenciador de banco de dados MySQL, que tem uma licença dual: pode ser utilizada a GPL ou então uma licença comercial. A empresa MySQL AB fornece o software sob a GPL, deixando-o para download gratuito no seu site. Entretanto, existe muitas empresas interessados em modificar o MySQL para uma aplicação especifica, ou em embuti-lo com parte de uma aplicação proprietária, coisas que não são permitidas pela GPL. Estes cliente podem comprar o MySQL sob uma licença comercial, isenta das limitações impostas pela GPL.

Sempre que um software for distribuído, tem que estar claro qual licença se aplica para cada copia em particular. A “licença dual” não significa que há duas licenças ao mesmo tempo, mas sim que há a opção de usar uma ou outra, dependendo do cliente. No momento da aquisição (que pode ser gratuita) é estabelecida a licença. Daí em diante ela é irrevogável.

Assim um usuário do MySQL GLP pode instalar o software em quantos computadores desejar, pode revender cópias e modificar o software – mas as mudanças só  podem ser distribuídas sob a licença GLP. Ele/ela não pode derivar um produto proprietário a partir de um copia GLP do MySQL.

Já um usuário do MySQL comercial pode criar suas versões modificadas. Pode também cobrar pelo uso destas versões, ou impor restrições como uma quantidade máxima de usuários simultâneos, tudo dentro dos termos do contrato acordado com uma quantidade máxima de usuários simultâneos, tudo dentro dos termos do contrato acordado com a MySQL AB. A maior utilidade dessa alternativa comercial é que uma empresa podem assim agregar código ao MySQL sem abri-lo os seus concorrentes.

Outro caso semelhante é do JBoss. Ele usa a LGPL (menos restritiva que a GPL), de modo que pode ser embutido,, desde que inalterado, dentro de uma aplicação proprietária baseado no JBoss, pela substituição de componentes. Mas não se pode restringir o uso e a cópia dos componentes originais. Se instalado um servidor “JBoss Turbinado” com limitações  para 50 usuários, posso ter uma quantidade de usuários ilimitada que utilizem apenas os recursos da versão padrão. Se o usuário tiver interesse, pode contratar suporte para o JBoss pela empresa JBoss Group LLC. Que é sua Criadora. Como o software é rico e complexo, dificilmente uma empresa grande ou media irá deixar de contratar o suporte, então a receita esta assegurada. Mas qualquer empresa pode experimentar o software e inicia projetos baseados nele, sem nenhuma despesa inicial, o que reduz bastante os custos de pré-venda, pois o JBoss Group não tem que enviar vendedores para visitar cliente e fazer demonstrações, nem deixar cópias de avaliação. Também é poupado o esforço de configurar copias para expirarem depois de um prazo ou de manter duas verões, uma “completa” e outra “de avaliação” com menos recursos ou outras restrições.

É semelhante ao que acontece com empresas que vendem software de automação comercial, contabilidade, folha de pagamento etc. há necessidade de atualizações periódicas, seja para manter a compatibilidade com novas versões do sistema operacionais, banco de dados, ou servidor web, seja para adequação a um

danças na legislação, ou ainda devido a mudanças nos procedimentos operacionais dos próprios clientes. Dificilmente um usuário deste software faz apenas a compra inicial sem contratar também o suporte. Então seria possível eliminar o custo inicial e ficar apenas com a receita de suporte, ou ainda incluir o custo inicial e ficar apenas com a receita de suporte, ou ainda incluir o custo inicial na anuidade do suporte.

No entanto, qualquer um pode vender serviços de suporte para o JBoss (ou para qualquer outro software livre). Há inclusive empresas no Brasil que o fazem. Você não pode impedir ninguém de vender estes serviços, então certamente o JBoss Group perde clientes para a concorrência e tem que se preocupar em ser melhor que ela (mas tem a vantagem de como criador conhecer melhor o produto de que qualquer outro).

Essa diversidade dá ao cliente mais segurança, pois ele pode optar por um fornecedor de serviços melhor para a sua área. Já licenças proprietárias permitem limitar o suporte a empresas “certificadas”. Mas nem sempre o certificado é um prestador de serviços de qualidade. Algumas vezes é apenas alguém que pagou uma anuidade pelo uso da marca.

A estratégia de deixar o software livre e vender apenas suporte faz com que muitas empresas pequenas e ás vezes geograficamente distantes experimentem o produto. São empresas, que de outra forma, nunca seriam usuárias (por que não comprariam de uma empresa desconhecida e localizada em outro país), e nem contratariam suporte. Mas esta popularização do produto acaba por torná-lo interessante para empresas maiores, que irão contratar o suporte, mesmo de uma empresa remota, ou viabilizam, pelo seu porte, a montagem de uma filial para que sejam atendidas.

O resultado final é que, com o software livre, é possível vender mais contratos de suporte para grandes clientes do que se teria com um software proprietário.

Fernando Lozano