MacJava - Think different, think Java.

Gerencia de Testes

2006-08-27T12:18:00.000-03:00

Tenho tido algumas discussões com alguns especialistas acerca de testes de aplicações.
O que tenho notado é que a maioria tem a sua própria concepção de testes de um sistema.
As pessoas sabem utilizar o JUnit, por exemplo, mas geralmente não saber o que testar e nem o que testar.
Num dos fóruns de discussões que tenho participado alguém me recomendou dar uma olhada do site da Borland (http://www.borland.com/br/products/silk/test_management.html) e acebei descobrindo algumas coisas interessantes.
As questões que relaciono a baixo foram tiradas do referido site.

What is the requirements test coverage for an application?
Have all high-priority requirements been met?
What are the optimal schedule, priorities and resource allocation for each test?
What progress is being made against the testing strategy?
What are the test results for a specific build?
Where are the defects? What are the necessary steps to resolve them?
What is the status of each defect? Is an open issue holding up the release?
Is the application ready for deployment?
Are certain features likely to compromise the quality of the overall release?
What are the quality trends for an application?

Alguém se habilita a comentar?

Ja tem novidades para o Java 7 - Dolphin

2006-08-27T11:19:00.000-03:00

Ainda tem gente que nem usou todas as novidades do Java 5 e já estamos esperando pelo Mustang - eu sou um deles ;-) .
O Java 5 é o que mais mudanças trouxe para od desenvolvedores Java e a maioria dessas mudanças foram muito bem aceitas.
O Mustang chega com a expectativa de ser extremanente performático, e isso eu já comprovei. O JIT do Mustang chega a ser até 10x mais perfomático do que o Java 5.
Nem saiu o Java 6 e já tem novidade para o Java 7. Uma delas é a evolução do JMX. A especificação virá com algumas novidades e permitirá monitoramento remoto de forma mais eficaz. Mas a novidade mesmo é a proposta de Gilad Bracha, Neal Gafter, James Gosling e Peter von der Ahé para o Java 7. A proposta (vc pode ver o pdf aqui) define métodos locais e o outro o chamado "closures" (não sei bem ainda como traduzir o termo).
Eu curti a parada dos métodos locais, vejam um exemplo:

public static void main(String[] args) {
int soma2(int x) { return x+2; }
int(int) soma2b = soma2;
System.out.println(soma2b(2));
}

Já os "closures" é assim:

int(int) soma2b = (int x) {return x+2; };

Agora é só esperar se isso vai vingar mesmo ou não no Java 7.

Qual o custo de monitorar uma aplicação com jconsole

2006-08-27T10:47:00.001-03:00

Bom, como estou participando das discussões acerca do JMX estou publicando aqui um artigo(de livre tradução) do Eamonn McManus (líder do grupo de discussão do JMX 2.0). Segue o artigo:

Qual o custo de monitorar uma aplicação com jconsole ?

Recentemente, muitas pessoas tem me perguntado qual o custo de monitorar uma aplicação com JMX.
Se eu rodo a aplicação com –Dcom.sun.management.jmxremote e conecto o jconsole, quanto isso afetará a performance da minha aplicação ?
Aqui estão alguns resultados baseados em experimentos não muito rigorosos.
Uma resposta rápida seria: Rodando com –Dcom.sun.management.jmxremote não tem impacto significante. Conectando o jconsole há um impacto de 3 a 4%.
A resposta a esta questão depende muito da natureza da aplicação e o que ela está fazendo na máquina onde está rodando.
Minhas medidas foram feitas brincando com a constante e (neperiano) usando BigInteger. Não tive a intenção de ilustrar o uso apropriado de técnicas matemáticas. Eu quis um caminho simples para criar uma aplicação que fizesse muita computação e alocasse muitos objetos com curto tempo de vida. Então, minhas medidas são interessantes para esta aplicação e, provavelmente, totalmente irrelevantes para outras.
A seguir o método que consome mais tempo na aplicação:

private static void computeE(int digits) {
BigInteger one = BigInteger.TEN.pow(digits);
BigInteger e = BigInteger.ZERO;
BigInteger invfact = one;
BigInteger n = BigInteger.ONE;
while (invfact.compareTo(BigInteger.ZERO) > 0) {
e = e.add(invfact);
invfact = invfact.divide(n);
n = n.add(BigInteger.ONE);
}
System.out.println(e);
}

Note que os dígitos não são precisos devido ao truncamento dos resultados da divisão.
Eu rodei este método com o parâmetro digits igual a 30000 numa máquina SPARC antiga. M eloguei nesta máquina numa sessão X-Windows, logo houve uma atividade de background. Eu rodei cada medida duas ou três vezes para cada configuração e peguei o menor tempo. (Eu avisei que os teste não foram rigorosos. De que condições de teste e padrões de desvio estamos falando ?)
Criei uma thread por CPU para fazer com que a máquina fosse usada no limite. Se não nós poderíamos ter um overhead zero para permitindo monitoramento porque ele poderia estar usando uma CPU não ativa.
O tempo de startup é ligeiramente grande quando se permite o monitoramento porque é necessário algum trabalho extra como criar um conector RMI. Eu supus, a título de interesse, que isto é um custo enquanto a aplicação está rodando. Então eu medi o tempo entre a criação das threads computeE e sua finalização.
Eu usei duas plataformas Java para medidas: JDK 1.5.0_07 da Sun e o Mustang 1.6.0-rc-b92. O tempo de computação foi 37% melhor no Mustang, provavelmente devido ao compilador JIT e/ou gerenciamento de memória. O tempo é melhor ainda se você roda com a opção –server. Mas, o que estamos interessados é a relativa diferença entre monitorar e não monitorar a aplicação.
A primeira medição da aplicação foi feita sem nenhum parâmetro de especial de linha de comando. Então, o monitoramento não foi permitido. Esta é a referência para outras medidas.

Tiger	Mustang
28.3	18.0

Então eu rodei a aplicação com –Dcom.sun.management.jmxremote, o qual teve dois efeitos:

Criou a plataforma MBean Server e a populou com um conjunto de Mbeans contendo instrumentações de JVM.
Criou e iniciou um conector RMI Server e colocou seu endereço onde o jconsole pudesse encontrá-lo.
Com esta opção nós podemos conectar o jconsole a partir de uma máquina local. Mas eu não conectei o jconsole para fazer as medidas. O efeito sobre a performance foi menor que 1% neste caso, de fato toda diferença observada foi menor que a margem de erro. Logo não houve diferença significante no tempo de computação. Em outras palavras, sem conectar o jconsole, permitindo o monitoramento, não teria efeito sobre performance da sua aplicação.
Eu obtive o mesmo resultado quando rodei com:

-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.remote.ssl=false 
permitindo ao jconsole conectar remotamente, mas sem segurança, sem afetar a performance. Note que nós desencorajamos fortemente rodar aplicações desta forma em ambiente de produção.
Rodando com

-Dcom.sun.management.jmxremote.port=9999
-Dcom.sun.management.jmxremote.password.file=jmxremote.password
(criando socket SSL seguro)

o impacto também foi menor do que 1%.
Então eu rodei a opção não-segura novamente, mas desta vez conectando o jconsole do Tiger a partir de uma outra máquina. Eu obtive:

Tiger	Mustang
29.85 (+5.5%)	19.1 (+6.1%)

Aqui temos um grande impacto. Isso pode ter a ver com o polling de vários Mbeans na JVM que o jconsole usa para mostrar os gráficos dos valores de heap size e o número de threads por tempo. Não há como parar o jconsole, mesmo que você não esteja interessado nestas informações, mas você pode mudar o intervalo de polling. Se você muda o intervalo de 4 segundos (default) para 1000 segundos, então você não terá muito impacto do polling. (Isso implica também no intervalo de amostragem dos gráficos, ou seja, se você quiser ver as informações vai ter que pagar o preço a JVM).
Rodando o jconsole do Tiger com –interval=1000 temos:

Tiger	Mustang
29.28 (+3.5%)	18.7 (+3.9%)

O jconsole não está no polling, mas ainda temos algum overhead, provavelmente alguma atividade de background do RMI e/ou acréscimo de memória usado pela conexão aberta.
O jconsole do Mustang, que é visualmente mais agradável, possui uma otimização para obter os vários atributos da JVM de forma mais eficiente, logo o impacto do polling é menor. Se você não puder migrar suas aplicações para o Mustang agora, você poderá fazer o download do JDK do Mustang só para rodar o jconsole!
Aqui estão so resultados rodando a aplicação com a opção não-segura e conectando ao jconsole do Mustang a partir de uma outra máquina:

Tiger	Mustang
29.6 (+4.5%)	18.8 (+4.4%)

Já temos um comportamento melhor do jconsole aqui. Claro, ainda não uasmos o –interval=1000, usando-o:

Tiger	Mustang
29.2 (+3.2%)	18.7 (+3.9%)

Finalmente eu tentei uma opção mais fraca de segurança(-Dcom.sun.management.jmxremote.ssl=true
-Dcom.sun.management.jmxremote.authenticate=true, que é o default) e não observei qualquer diferença significante. Mesmo com o polling do jconsole com 4 segundos, não foi observado nenhum overhead devido ao SSL.

Observação
Estes resultados não são conclusivos! Eles meramente são um indicativo de um conjunto de medidas sobre um tipo de aplicação. O impacto poderia ser muito maior se a adição da conexão JMX empurrasse a aplicação num modo diferente de operação. Por exemplo, o uso adicional de memória poderia ser o bastante para mudar o comportamento do gabage collector significativamente e provavelmente negativamente. Mas,você teria que operar bem no limite desta situação, e isso poderia acontecer sem uma conexão JMX se, por exemplo, a aplicação precisasse manipular um pouco mais de objetos.

De volta as atividades

2006-08-27T10:41:00.000-03:00

Olá a todos que visitam meu blog.
Depois de um bom tempo sem ter tido a oportunidade de atualizar as notícias e idéias postadas aqui, estou de volta para poder trocar idéias com os amigos(as) novamente.
Recentemente fui aceito como um "expert" no grupo que elabora a especificação do JMX 2.0 e admitido no quadro de funcionários da NET TV a Cabo como arquiteto Java EE.
Com base nessas exepriências acumuladas pretendo publicar notícias e informações que possam ajudar a todos que desenvolvem sistemas usando Java como linguagem.
Abraço a todos.
Carlos Santiago

Spring e WebWork, juntos

2005-10-13T09:44:00.000-03:00

O WebWork da Open Synphony padronizou o uso do Spring em sua middle-tier.
Patrick Lightbody, um dos líderes do projeto WebWork, disse: "as the most complete 'lightweight container' available today, Spring is the de facto standard for the management of the internal architecture of a J2EE application. We are excited to ship official Spring integration with WebWork 2.2, which is nearing final release. This integration will make it even easier for WebWork users to use Spring."
Mais detalhes aqui.

Spring e a inicializacao de beans

2005-10-11T21:55:00.000-03:00

É possivel inicializar um bean com com determinados parâmetros usando o Spring.
O Spring é responsável por criar as instâncias dos beans da nossa aplicação, mas em algumas vezes, antes mesmo da aplicação entrar no ar, temos que garantir que determinadas condições sejam satisfeitas, uma delas é a correta incialização de um bean.
O próprio Spring verifica as dependências para criação de um singleton do seu bean, mas podemos passar parâmetros para este nosso bean no tempo em que o Spring estiver verificando as suas dependências.
Isso pode ser importânte se vc tem que setar determinadas variáveis de seu bean, por exemplo, antes dele ser criado e estar disponibilizado na aplicação.
Este recurso se parece bastante com a idéia de blocos estáticos disponível em java.
Vc pode passar parâmetros de incialização de duas maneiras para o seu bean.
Usando o método init() e a outra é implementando a interface InicializingBean.
Os dois tem basicamente a mesma função. No primeiro vc terá que acrescentar na bean o atributo init-method e indicar o nome do método. No segundo caso vc não precisa fazer isso, pois como vc será obrigado a implementar o método afterPropertiesSet(), o Spring sabe que é este o método que possui as inicializações.
Como era de se esperar é dentro destes métodos que vc irá colocar as incializações necessária ao seu bean.
O cap. 5 do livro Pro Spring de Rob Horrop traz mais detalhes sobre este recurso.

Spring: A Developer's Notebook

2005-10-10T09:17:00.000-03:00

O capítulo 1 do livro Spring: A Developer's Notebook está disponível para download.

DisplayTag

2005-10-05T11:46:00.000-03:00

No projeto LinkPeças que estou desenvolvendo para o Grupo Rodobens apareceu a necessidade de fazer paginação de jsp.
Todos nós sabemos o quanto isso é chato, sem contar a montoeira de código que tem que ser inserido na camada de apresentação e todas aquelas idas e vindas ao banco pra buscar os registros.
Conversando com meu amigo Gilmar, da Kaffa, ele me indicou o uso da DisplayTag.
Achei fantástico o fato de poder disponibilizar os dados de uma collection sem precisar iterar por ela.
Outro grande lance dessa API é que ela faz a paginação dos registros de forma muito simples.
Formatar a apresentação dos registros também é possível, por exemplo, inserir máscaras a um dado campo, formatar datas, criar links dinâmicamente.
Tudo isso é feito através do padrão Decorator. Você escreve uma classe, isso mesmo uma classe, que será a responsável por estas formatações. Não rola javascript para ficar formatando os dados. Eu achei isso MARAVILHOSO !
DisplayTag, me permitiu renderizar uma página que apresenta registros paginados de 10 em 10, onde cada linha da tabela tem uma caracterísitca específica, por exemplo, um link apontanto pra um controlador específico, dependendo do status do registro. Além disso o registro recebe um flag (uma imagem) que indica se o prazo de verificação do pedido está vencido ou não.
A colletion passa pelo Decorator antes de ser renderizada. No Decorator, então, faço as verificações e formatações necessárias a cada registro na colletion.
A única dificuldade que encontrei com relação a esta API é a documentação. Apesar de ter fartos exemplos de utilização da API e um tutorial ainda é necessário dedicar algum tempo para entender como funciona os meandros da API, ou seja, é indispensável as consultas ao JavaDoc da API.
Mas vale muito a pena conhecer e utilizar esta API.

Quantos são os frameworks de MVC em Java ?

2005-09-17T14:21:00.000-03:00

Essa é uma questão que me despertou interesse depois que eu li o capítulo 10 do livro Spring in Action (ver minha resenha neste blog).
Lendo como era possível integrar o IoC do Spring às Actions do Struts, o autor, em determinado momento, indica o site manageability onde são listados mais de 50 frameworks de MVC escritos em Java.
Oras, pra mim isso foi uma surpresa, pois, eu já havia ouvido falar em, no máximo, meia dúzia deles - Struts, Webwork, Spring MVC, Tapestry, MentaWai, Cocoon.
Aí me lembrei de uma enquete feita com 1537 (até o momento em que vi a enquete) no PortalJava com o título "Qual o seu framework de MVC ? ". Como se poderá ver nessa enquete a maioria (43,07%) sequer sabe o que é um framework de MVC.
O segundo maior índice é do Struts. Mas, acho que mais por "ouvir falar" do que por uso efetivo em aplicações.
Então fica a questão porque tantos frameworks de MVC ?
Meu amigo Sérgio do MentaWai , argumenta que o uso ostencivo de XML para configuração desses framewoks, como Strus, Spring MVC, Tapestry etc, são um complicometro a mais. Talvez ele esteja certo. O MentaWai na sua versão 1.1 já tem até suporte a IoC, o que, para mim, é fundamental em um framework, com o mínimo de XML.
Será que fale a pena o esforço de desenvolver um framework só pelo fato de desenvolver um framework ?
Reinventar a roda é inútil, mas seria possível aperfeiçoá-la ?

Do PowerPC ao Intel

2005-09-13T09:48:00.000-03:00

No último evento da Apple em São francisco Stve Jobs fez um key note que chocou vários usuários de MAC.
Neste evento foi anunciado que a Apple irá abandonar seus processadores RISC em prol dos processadores CISC da Intel.
Eu mesmo, numa primeira instância fiquei idignado com isso, pois sou um fã obstinado de produtos Apple e sou um feliz usário de um iBook G4 de 1.2Ghz com 768Mb de RAM e desenvolve em Java muito bem com ele, obrigado.
Mas depois de assistir ao key note de Stve Jobs as coisas fizeram mais sentido.
É clara a estratégia da Apple, a de finalmente entrar no mercado de PC CISC com grande poder de fogo.
O que isso tem a ver com Java ? Oras, tudo, pois como Java é uma linguagem multiplataforma os aplicativos desenvolvidos nessa linguagem não sofrerão nenhuma altereção com a nova plataforma da Apple.
Outro grande lance de Jobs é que o usário agora poderá escolher entre Windows, Linux e MAC OS pra instalar em sua máquina !!!
Isso irá trazer fortes dores de cabeça para Microsoft, assim espero.
O Aqua, a intereface gráfica do MAC OS, é muito mais intuitira do que o Windows e muito mais fácil de configurar, sem falar que o sistema por traz disso tudo é um UNIX, para felicidades daqueles que sempre quiseram usar o LINUX, mas não o fazem pelas dificuldades de configuração que este ainda apresneta para os simples mortais usuários de PC.
A previsão é de que os primeiros MAC com processador Intel saim em junho de 2006 e a migração completa seja feita até junho de 2007.
Para os desenvolvedores a Apple já está diponibilizando uma série de soluções que permitiram "converter" suas aplicação para nova plataforma, veja aqui o site. no caso do Java, como já dissemos, isso é totalmente transparente ;-)
De resto eu recomento fortemente a quem se interessar pelo assunto a aassitir o key note do Steve Jobs, você poderá baixá-lo em http://www.apple.com/quicktime/qtv/wwdc05/.
Agora só nos resta aguardar e ver no que via dar esta estória e torcer para que, mais uma vez, a Apple esteja no caminho certo.

Spring in Action

2005-09-12T20:41:00.000-03:00

O uso de frameworks no desenvolvimento de aplicações corporativas é imprescindível. Hoje não se pode falar de aplicações corporativas sérias sem associá-las a algum framework.
O desenvolvedor deve estar sempre atento às novas ondas tecnologicas que surgem a todos os dias, o que às vezes, é impossível!
Existem vários frameworks para diversas finalidades dentro de um projeto. Um desenvolvedor experiente tem que conhecer pelos menos uns 3 frameworks para desenvolver aplicaões corporativas para web.
Aí fica a questão: mais um framework pra que ? Os que existem já não dão conta do recado, já não estão super experimentados e aprovados pela comunidade de desenvolvedores por toda parte ? Então porque ter que aprender mais um framework ?
O Spring não é mais um framework.
O Spring proporciona ao desenvolvedor implementar suas aplicações de forma clara e robusta. Para isso um dos fortes conceitos empregados por este framework é o de IoC – Invertion of Control (ou como prefere Martin Fowler: dependency injection).
Para que um framework tenha uma boa aceitação na comunidade de desenvolvedores não basta que ele seja bom, ele tem que ser bem documentado. Tem que existir várias fontes de referência acerca de seu uso, bons exemplos, cases, etc. Tudo ao fácil e ao alcance daqueles que estão afim de aprender seus recursos.
Pois bem, no caso do Spring isso não é tarefa tão simples assim. Primeiro porque não existe, ainda uma ampla gama de referências sobre o Spring em língua portuguesa. Segundo que é difícil de enontrar cases de sucesso que usaram amplamente este framework, e isso se deve porque o Spring é um framework relativamente novo no mercado.
Procuraremos aqui expor as nossas impressões acerca de uma das referências bibliográficas sobre o Spring: Spring in Action.
O livro é dividido em 3 partes com 11 capítulos ao todo cobrindo a versão 1.0.x do Spring.
A primeira parte, Spring Essencials, que procura cobrir os aspectos básicos do framework. O fundamental para se aprender a usar o Spring é obter um sólido conhecimento acerca de IoC, e isso o primeiro capítulo do livro trata bem.
Um dos capítulos de destaque desta obra é o que trata de AOP. O Spring provê um amplo suporte a AOP e no capítulo 3 o leitor encontrará uma boa introdução a este tema.
Spring in the Business Layer, que enfoca como o Spring pode trabalhar com banco de dados (JDBC, Hibernate, JDO, JTA etc), gerenciando transações, acessando métodos remotamente e acessando servicos. Nesta parte vale muito a pena a leitura do capítulo 5, sobre gerenciamento de transações, pois o desenvolvedor ficará surpreso de como o Spring pode proporcionar um controle de transação sem ser intrusivo no código da aplicação, tornando-a assim mais desacoplada.
A terceira parte do livro é uma das que mais desperta interesse por parte dos desenvolvedores, a saber: Spring in the Web Tier.
Hoje desenvolvero pra web com Java é quase que uma regra, claro que é crescente o desenvolvimento para desktop com Java, mas o desenvolvimento para web é predominante.
Nesta terceira parte os capítulos 8 e 11 são destaques, pena que não são tão elucidativos assim.
Aqui cabem as críticas.
Os exemplos do livro não são assim tão claros, principalmente na terceira parte do livro onde esperaríamos ter uma grande gama de exemplos de códigos etc. Mas não é o que encontramos. Os exemplos de código nesta terceira parte são fracos e não exploram todas as possibilidades do framework. Lendo, acabei tendo a impressão que os autores já estavam meio que de saco cheio de escrever e vão atropelando tudo.
O resultado disso é que o leitor tem que dedicar um bom tempo para poder entender o que está rolando.
Seja como for para um primeira aproximação sobre o Spring o livro tem lá sua serventia, não resolve tudo, não mostra todos os secredos (para isso o leitor/aprendiz terá que participar dos fóruns), mas ajuda a entender qual a proposta do framework e ajuda a decidir se ele serve ou não para o seu projeto de desenvolvimento.
Por falar em fóruns, o fórum do Spring é muito bom. Lá o desenvolvedor porderá trocar idéias e até ter suas dúvidas respondidas pelos próprios desenvolvedores do Spring.
Vamos aguardar para que surja uma tradução desta obra, como aconteceu com o caso do Struts em Ação e o Hibernate em Ação, ampliando assim as chances deste framework ser um pouco mais conhecido por aqui.

foto

2005-09-03T10:14:00.000-03:00

foto
Originally uploaded by java_carlos.

Desenvolvimento com Spring

2005-09-02T12:39:00.000-03:00

Tenho usado o Spring no desenvolvimento de uma aplicação pequena para o Grupo Rodobens, o LinkPeças.

Decidi usar este framework basicamente pelo fato de usar o conteito de IoC (ou dependency injection como prefere Martin Fowler), mas decobri que ele poderia fazer muito mais por mim nesse projeto.

Estou usando Spring de cabo a rabo nesse projeto e tenho gostado muito dos resultados que tenho obtido. Fácil manutenção, escalabilidade, clareza de código, são alguns dos benefícios que o Spring tem me proporcionado.

Ao invés do Struts tenho usando o SpringMVC e o achei bem mais fácil de se usar do que o próprio Struts. Ainda neste projeto tenho utilizado o DisplayTag para fazer a paginação de List e agora estou implementando Struts-menu para criar dinamicamente menus.

O Spring é tudo de bom para o desenvolvimento de aplicações de forma clara , orientada a objetos, e de fácil manutenabilidade.

O que o meu colega Sérgio, um dos criadores do Mentawai, reclama, e com razão, é a quantidade de arquivos XML para configurar o Spring.

Ele tem uma certa razão nesse quesito, mas como sou um fã de XML, não me importo em ter que escrever definiçòes nestes arquivos, eu até acredito que isto me ajude a entender melhor ofuncionamento do framework, e quem sabe, até me dar condições de buscar aspectos melhores de desenvolvimento, como pode ser o caso do próprio Mentawai.

Mas por enquanto tenho me saido bem com o uso do Spring, mas pretendo fazer alguns ensaios com o Mentawai. IoC pra mim hoje é uma das principais características que um framework deve proporcionar, e me parece que o Mentawai vai bem nessa direção.

Vamos aguardar.