Cotidiano em Wonderland

Tratamento de Erros e Exceções

2010-03-24T13:11:00.002-03:00

Depois de várias discussões sobre o uso de exceções "checked" e "uncheked", tanto em livros quando em blogs e forums, acredito que existe um consenso geral de que:

erros de negócio devem ser tratados em runtime, portanto devem ser utilizadas as checked exceptions;

erros de programação lançam unchecked exceptions, pois bugs ainda não podem ser tratados em tempo de execução; é preciso reparar o software, não há nada a ser feito além de coletar informações sobre o erro, incluindo o estado do aplicativo, e tentar minimizar os efeitos do bug fazendo rollback, por exemplo.

Há os que discordam, os que nunca pensaram no assunto, os que não dão a mínima, mas geralmente essa abordagem é bem aceita.

Um assunto relacionado, mas não tão discutido, é o uso de boolean em contraste às exceções nas APIs de validações. Não encontrei esse assunto nem mesmo no Effective Java 2° Edition, talvez por não considerarem relevante.

Mas acredito que seja, porque nossa equipe já tomou a decisão errada, o que nos custou caro. (E com custar caro eu digo 1) um longo tempo com tratamento de erros deficiente e 2) a necessidade de refactoring.)

Posso não ser um tremendo desenvolvedor, sou um Pleno com uns cinco anos de experiência, um mero mortal enfim, mas havia os feras na equipe, incluindo o arquiteto responsável pelo projeto, logo o principal responsável pelo nosso erro. (Talvez não fosse tão fera assim, ou talvez estivesse com a cabeça em outro lugar na hora do batente.)

A API de validação nesse software não era genérica, não era algo do tipo #notNull, ou #isEmpty das classes Validate e StringUtils da Commons Lang (API de utilidades da Apache). Esse tipo de validação é melhor realizada com as bibliotecas já existentes, como a Commons Lang, Commons Collections (também da Apache), de modo a aproveitarmos o bom trabalho realizado por n profissionais competentes e o auxílio da comunidade. Os desenvolvedores da Commons Lang já fundiram a fuça pensando qual API retorna boolean, qual lança exceção (#notNull lança exceção, #isEmpty retorna true ou false).

Nosso problema era validação de negócios, algo do tipo "temosTudoNosTrinquesPraSeguirAdiante"?

O que acham? Já passaram por problema semelhante? O que decidiram? Têm ideia sobre onde erramos?

Erramos porque decidimos utilizar booleanos, e com isso 1) a API não era capaz de retornar informações adicionais sobre eventuais problemas na validação, 2) os demais métodos da cadeia de chamada também precisavam retornar boolean e 3) comprometida a flexibilidade do tratamento de erros.

No primeiro caso, como a API só retornava true/false, precisavamos inserir diversas linhas de log em meio aos métodos de validação. Isso comprometia bastante a legibilidade do método, gerava duplicação do código de log. Havia código de log espalhado por todo canto. E era isso ou nada (ponto 3).

O segundo ponto infeliz era a necessidade de que todos os métodos a partir da chamada da validação deviam retornar bolean até "o cara" que tratava o erro. Dependendo da complexidade, era uma longa viagem, com umas 5 chamadas de diversas classes retornando boolean, sendo que pelo menos 3 desses métodos eram implementação de um contrato.

A falta de flexibilidade era óbvia, pois não podíamos fazer nada diferente. Se quiséssemos mais informações sobre um erro além de um "false", tínhamos que colocar essa lógica dentro do método onde esse erro ocorreu. Isso não só é limitado ao extremo, como também gera complicações adicionais.

Com a nossa API disparando exceções, 1) somos capazes de encapsular todas as informações que achamos necessária dentro da própria exceção, 2) podemos definir n mecanismos diferentes de tratamento de erro (algumas exceções são "logadas" em arquivos de texto, outras vão para o banco de dados, algumas disparam e-mails, outras não) e 3) o uso da API está mais fácil além de flexível; se um métodos não sabe como tratar o erro de validação, deixe o erro passar adiante para ser tratado mais acima na pilha de invocações.

E tudo passou a ser tão óbvio...!

ModelMat e uma Melhor Arquitetura

2007-07-18T04:44:00.000-03:00

Resolvi estudar e planejar uma boa arquitetura para o ModelMat, que acaba de ir para a versão 0.4. A concentração dos esforços se deu na separação da view e do model.

O objetivo é utilizá-lo como exemplo para uma boa arquitetura GUI Swing, mesmo sendo um exemplo limitado graças à natureza do ModelMat, que difere da maioria dos softwares comerciais. Ainda assim, deverá ajudar a mostrar o "caminho das pedras".

As principais fontes de inspiração foram o padrão Presentation Model, do Martin Fowler, e JGoodies Binding, do Karsten Lentzsch, também em muito baseado no Presentation Model, ainda que eu não tenha utilizado binding automático.

PresentationModel

De acordo com Martin Fowler,

Presentation Model transfere o estado e comportamento da view para uma classe model que faz parte da apresentação (presentation, no original). O Presentation Model interage com a camada de domínio e provê uma interface para a view que minimiza a tomada de decisões nessa view. A view armazena todo o seu estado no Presentation Model ou o sincroniza com o Presentation Model freqüentemente.

No caso do ModelMat, comportamento e estado foram transferidos da view para o model, com possível exceção dos métodos que tem estrita relação com a view. Um exemplo é o método changeColumnName, da classe Spreadsheet, cuja função é alterar o nome das colunas da planilha. (Faria sentido deslocar tal método para o model?)

A comunicação das mudanças no model para a view é feita através do disparo de eventos do model para a view. Assim, por exemplo, SpreadsheetModel dispara um evento para Spreadsheet (a view) atualizar o seu estado. Sem novidades.

O Swing Application Framework (JSR-296), com o seu gerenciamento e ligação de Action's ajudou a mover o comportamento da view para o model.

Como resultado, as views estão completamente "ignorantes". O código fonte da classe ChartView tem apenas 64 linhas, contando com sua documentação; ReportView tem 69 e Spreadsheet, a mais complexa, 228 linhas. As views apenas definem e organizam os componentes visuais e ajustam o seu model. Eis a classe ChartView (documentação omitida):

public final class ChartView extends JPanel {
.....private ChartPanel chartPanel;

.....public ChartView() {
..........super();
..........initComponents();
.....}

.....public ChartView(ChartModel model) {
..........this();
..........add(createChartPanel(model.getJFreeChart()));
.....}

.....private ChartPanel createChartPanel(JFreeChart chart) {
..........chartPanel = new ChartPanel(chart, true);
..........chartPanel.setMouseZoomable(true, false);
..........return chartPanel;
.....}

.....private void initComponents() {
..........setLayout(new java.awt.BorderLayout());
.....}
}

ChartModel define os métodos sobrecarregados reportResult, que contém toda a rotina para processar o resultado da função e mostrá-la ao usuário, e clear, que limpa a área do gráfico.

Explicando a arquitetura da GUI de forma sucinta, há quatro views: ModelMatView, a principal, é composta das demais: Spreadsheet, ReportView e ChartView. Também contém um JMenu, JToolBar e StatusBar. O Presentation Model de ModelMatView é ApplicationModel, que contém os models das demais views: SpreadsheetModel, ReportModel e ChartModel, respectivamente.

O workflow do software é basicamente definido no ApplicationModel, por isso está mais claro. Sua classe interna DoRegression é uma boa mostra de como isso acontece.

private class DoRegression extends Task<AbstractRegressionResult, Void> {

.....DoRegression() {
..........super(ModelMatApplication.getApplication());
.....}

.....protected AbstractRegressionResult doInBackground()
.........................throws CoordinateNumberException, InsufficientDataException {
..........if (selectedRegressionType == RegressionType.LINEAR) {
...............return linearRegression();
..........} else if (selectedRegressionType == RegressionType.NON_LINEAR) {
...............return nonLinearRegression();
..........}
..........return null;
.....}

.....protected void succeeded(AbstractRegressionResult result) {
..........reportModel.reportResult(result);
..........chartModel.reportResult(result);
..........setMessage("Regression succeeded.");
.....}

.....protected void failed(Throwable cause) {
..........setMessage("Regression failed.");
..........ExceptionNotifier.notifyError(cause);
.....}
}

Antes, o uso do padrão Observer para notificar as diversas operações ocorrendo no software tornava difícil o seu entendimento e depuração. Observers foram retirados onde puderam, sendo utilizados apenas para notificar views sobre mudanças nos models.

The Day After...

A única mudança perceptível para o usuário do aplicativo é a melhora na geração de gráficos. Compare o gráfico das duas figuras desse texto com o dessa figura. Esse aperfeiçoamento se deu graças ao melhor uso da API do JFreeChart. O código para gerar os gráficos está menor, mais claro e mais correto.

O resultado de um workflow mais simples e claro e de uma melhor arquitetura é um software mais fácil de entender e mais difícil de estragar.

Na mesma proporção que os componenes ficaram com responsabilidades mais bem definidas, as rotinas desnecessárias e potencialmente problemáticas foram eliminadas.
Há menos imports, classes, métodos, propriedades e código em geral.

Haviam falhas no conceito do software que tornaram-se evidentes e foram corrigidas. A antiga classe Point, por exemplo, não representava um ponto no espaço 2D, como seu nome, seus métodos e propriedades levavam a crer. Inclusive eu pensei. Point na verdade representava índices na planilha - por exemplo, a célula da primeira linha e segunda coluna tem os índices (0, 1).

Portanto, Point foi renomeada para XYTableIndex e seus dois métodos, para getRow e getColumn. De fato se faz necessário uma classe para representar as coordenadas dos pontos no espaço 2D, por isso foi criada uma nova classe Point, com seus métodos getX, getY e outros.

Aperfeiçoamentos no ModelMat com Base no Swing Application Framework

O ModelMat utiliza os benefícios do Swing Application Framework. Como o seu código fonte está no repositório do sítio do projeto, fica fácil consultar como funciona a implementação da JSR-296 na prática. Entre as funcionalidades, estão:

uso de multithreading para melhor resposta do software às ações do usuário (consulte org.modelmat.gui.ApplicationModel)
gerencimento do ciclo de vida do aplicativo (veja org.modelmat.application.ModelMatApplication)
estado da sessão persistente (ModelMatApplication herda essa funcionalidade de application.SingleFrameApplication)
barra de estado (baseada na classe application.example.StatusBar, utilizada em org.modelmat.gui.ModelMatView).

Nota: classes do pacote application e derivados fazem parte do Swing Application Framework.

Nota 2: o ModelMat também pode ser fonte de consulta para implementação de Tray Icon, Tip of the Day e JTable. Novas funcionalidades estão a caminho, como o uso da Java Desktop API e integração com planilhas eletrônicas.

Outros Melhorias

Os nomes das classes foram melhorados. Exemplo: antes, as classes responsáveis pela view chamavam-se VAlgumCoisa, como VReport e VChart; agora chamam-se AlgumaCoisaView, como ReportView e ChartView. A classe Spreadsheet, antiga VTable, é a única exceção a essa regra. Como é claro que uma planilha é uma view, acrescentar essa palavra ao fim da classe (SpreadsheetView) é redundante.

Da mesma forma, nomes de métodos estão mais precisos e concisos: clearReport, da classe ChartView, mudou para clear - suficiente.

Há maior uso de campos (i.e. utilizando o modificador final) e menor utilização de variáveis.

O software está mais documentado. Contudo, sua documentação está incompleta, especialmente a referente ao core do ModelMat.

O algoritmo de regressão foi simplificado. Antes, o uso forçado de Command (GoF), causava indireção e complexidade inúteis. Agora, o uso de Strategy (GoF), padrão mais adequado para um serviço que tem diversas implementações - exatamente o caso das regressões - tornou o processo mais simples, eficiente e elegante.

E a Produtividade Cadê?

Alguém pode indagar "tudo isso, e a única melhora para o usuário final foi uma geração de gráficos mais decente? E a produtividade, cadê ?".

A resposta merece e fica para outro texto.

Muito a Fazer

Esse foi apenas mais um passo na direção certa. Um grande passo considerando que mover o comportamento da view para o model geralmente não está entre as tarefas mais simples em aplicativos Swing.

Referência Utilizada:

Presentation Model, de Martin Fowler

Mais sobre ModelMat em:

Veja Também:

Swing Application Framework (JSR-296) - Parte 3

2007-07-06T13:29:00.000-03:00

A terceira parte do artigo sobre o Swing Application Framework trata sobre a execução de tarefas em background.

A primeira parte discorre sobre a JSR-296, gerenciamento de ciclo de vida e inicialização do aplicativo, o armazenamento do estado da GUI entre sessões e persistência local. A segunda parte apresentou a injeção de recursos e a definição, gerenciamento e binding de Action’s.

Para uma total compreensão dessa terceira parte, é necessária a leitura da segunda parte do artigo e do texto O Básico sobre SwingWorker.

Tarefas em Background

Task estende SwingWorker, o que equivale a dizer que representa uma tarefa que executa em [uma thread em] background. De acordo com sua documentação, Task adiciona [à SwingWorker]:

uma série de propriedades descritivas que podem ser mostradas aos usuários;
um novo conjunto de métodos para customizar o término de uma tarefa;
possibilidade de bloquear entrada (input) à GUI enquanto a tarefa está executando; e
um TaskListener que permite monitorar os três métodos chaves de SwingWorker: doInBackground, process e done.

Done

O método abstrato doInBackground é a principal questão a ser considerada ao implementar tanto uma subclasse de SwingWorker quanto de Task, já que é sua responsabilidade definir exatamente o que irá ser executado em background.

O método done, porém, é final em Task. done é utilizado para executar atividades complementares na event dispatch thread (EDT) após o termino do método doInBackground. Em Task, done invoca os métodos succeeded, cancelled, interrupted ou failed quando a worker thread termina, respectivamente, com sucesso, porque foi cancelado, interrompido ou por alguma falha de execução.

Independentemente do resultado, done sempre invoca finished ao terminar sua execução, mesmo que uma exceção seja lançada. Por padrão, failed grava o erro em questão num arquivo de log; os demais métodos nada fazem. Como done executa na EDT, todos esses métodos também correrão nessa mesma thread.

Task in Action

Como mostrado em O Básico sobre SwingWorker, obter as entidades cadastradas num banco de dados dificilmente deve ocorrer na EDT, sob pena de congelamento da GUI. Aquele artigo mostra o uso de SwingWorker para resolver essa situação, enquanto esse texto irá mostrar o mesmo com Task, por suas facilidades adicionais.

private class LoadEntitiesWithTask extends Task<List<EntityClass>, Void> {

.....LoadEntitiesWithTask() {
..........super();
..........setLoadEnabled(false);
..........setStopEnabled(true);
.....}

.....protected List<EntityClass> doInBackground() {
..........setMessage("Obtendo " + entityName + "s cadastrados...");
..........return domainManager.findAll();
.....}

.....protected void succeeded(final List<EntityClass> newEntities) {
..........synchronized(this) {
...............if (!entities.isEmpty()) {
....................clear();
...............}
...............entities.add(0, EMPTY_ENTITY);
...............entities.addAll(newEntities);
..........}
..........fireContentsChanged(this, 0, entities.size() - 1);
..........setMessage(
...................."Feito: lista de " + entityName + "s obtida com êxito em "
....................+ getExecutionDuration(TimeUnit.MILLISECONDS) + "ms.");
.....}

.....protected void cancelled() {
..........setMessage("Operação cancelada.");
.....}

.....protected void interrupted(final InterruptedException ex) {
..........setMessage("Operação cancelada.");
.....}

.....protected void failed(final Throwable ex) {
..........setMessage("Erro: não foi possível obter " + entityName + "s cadastrados.");
.....}

.....protected void finished() {
..........setLoadEnabled(true);
..........setStopEnabled(false);
.....}
}

As mudanças mais significativas em relação à sua equivalente com SwingWorker são referentes aos métodos succeeded (no lugar de done), cancelled, interrupted, e failed que enviam mensagens a componentes específicos, como statusbar (mais sobre isso depois), e ao método finished.

Task pode ser utilizada em conjunto com @Action's (sobre Action's, ver parte 2) para definir tarefas que iniciam a partir de eventos gerados pela GUI.

@Action(block=BlockingScope.ACTION, enabledProperty="loadEnabled")
public Task load() {
.....loadEntitiesTask = new DefaultEntityModel.LoadEntitiesWithTask();
.....return loadEntitiesTask;
}

Note que o método load retorna Task. Infelizmente, tanta facilidade tem seu preço. Para alterar o comportamento de LoadEntitiesWithTask de modo que apenas obtenha as entidades se as mesmas não foram previamente carregadas, é preciso estender a classe. (Com SwingWorker, bastaria criar uma variação do método load).

private class LoadEntitiesIfEmpty extends LoadEntitiesWithTask {

.....LoadEntitiesIfEmpty() {
..........super();
.....}

.....protected List<EntityClass> doInBackground() {
..........if (entities.isEmpty()) {
...............return super.doInBackground();
..........}
..........return null;
.....}

.....protected void succeeded(final List<EntityClass> entities) {
..........if (entities == null) {
...............return;
..........}
..........super.succeeded(entities);
.....}
}

O método loadIfEmpty é responsável, sob o ponto de vista de quem o invocar, de carregar as entidades no formulário caso isso ainda não tenha acontecido.

public void loadIfEmpty() {
.....loadEntitiesTask = new DefaultEntityModel.LoadEntitiesIfEmpty();
.....ApplicationContext.
...............getInstance().
...............getTaskService().
...............execute(loadEntitiesTask);
}

Bloqueando a GUI

Ao utilizar a worker thread para executar longas tarefas, pode ser necessário bloquear certos componentes ou o aplicativo inteiro até que a tarefa termine.

Como exemplo, a tarefa de recarregar as entidades cadastradas num banco de dados certamente deve correr em background, e a possibilidade de concorrência dessa mesma tarefa dificilmente teria alguma utilidade. Portanto, bloquear o componente que inicia a tarefa em questão até que termine é interessante.

A opção de bloquear a GUI durante a execução de uma tarefa é feita definindo um valor para a propriedade block da anotação Action. Os possíveis valores para block são obtidos através da enumeração BlockingScope de Task: NONE (o padrão), ACTION, COMPONENT, WINDOW e APPLICATION. O método load, acima, utiliza BlockingScope.ACTION:

@Action(block=BlockingScope.ACTION, . . .)
public Task load() {
...... . .
}

Repare que o botão para carregar as entidades está desabilitado enquanto LoadEntitiesWithTask executa (observe a barra de progresso na statusbar).

BlockingScope.WINDOW e BlockingScope.APPLICATION bloqueiam a janela de nível mais alto e o aplicativo inteiro, respectivamente, por padrão mostrando um dialog indicando que o software está ocupado. O modo como esse bloqueio é feito pode ser customizado implementando a classe abstrata application.Task.InputBlocker e estabelecendo-a como o bloqueador de Task por meio de seu método setInputBlocker.

You've Got a Message

Com o auxílio de application.TaskMonitor, desenhada para ser o model de widgets como barra de estado, e dos métodos de Task setMessage e message, enviar notificações para a GUI sobre o estado da execução das tarefas na worker thread beira o trivial.

setMessage foi utilizado por simplicidade. O modo aconselhável para isso é definir as mensagens num arquivo de propriedade e utilizar o método message (consulte documentação da classe e exemplos que acompanham o framework).

Repare na mensagem avisando sob o término da operação. Além disso, como a operação para carregar as entidades chegou ao fim. o botão para carregar as entidades está habiltado, enquanto o que cancela essa operação está desativado...

Outros Métodos Úteis

A classe Task ainda possui uma série de métodos úteis que incluem, mas não se limitam a:

getExecutionDuration retorna o tempo de execução da tarefa;
setProgress tem o objetivo de notificar barras de progresso em statubars que a tarefa teve algum progresso;
isStarted e isPending complementam os métodos, presentes na classe SwingWorker, isDone e isCancelled.

Mantenha em mente que...

Esse artigo é apenas uma introdução ao assunto. Não deixe de consultar a documentação e até mesmo o código-fonte do projeto, fazer experiências, discutir sobre as funcionalidades do framework.

Veja também:

Fontes e Referências utilizadas:

Swing Application Framework Home Page
JSR 296: Swing Application Framework
Javadoc e código fonte do Swing Application Framework
An Introduction to Swing Application Framework API (JSR-296)

O Básico sobre SwingWorker

2007-06-26T07:21:00.000-03:00

Uma GUI razoável tem certos pré-requisitos. Entre esses pré-requisitos está uma interface gráfica que não trava. Ou seja, é sempre responsiva. Isso implica mover tarefas demoradas para uma thread que executa em background.

Esse artigo é uma pequena introdução sobre execução de tarefas potencialmente longas em background com SwingWorker, para desenvolver GUI's que sempre respondem aos eventos gerados pelo usuário.

Nota: esse texto refere-se à classe SwingWorker presente no Java SE 6 (i.e. javax.swing.SwingWorker).

Processos e Threads

Há fartura de material sobre processos e threads disponíveis em livros, revistas e na Internet (veja, por exemplo, The Java Tutorials - Concurrency). Discorrer sobre threads foge do escopo desse texto, porém uma contextualização é válida.

Processos podem ser vistos como sinônimo de programas, embora um programa possa constituir-se de mais de um processo. O sistema operacional aloca para cada processo recursos, como espaço de memória, aos quais só esse processo tem acesso.

Cada processo tem ao menos uma, mas pode ter várias, threads, que compartilham recursos do processo ao qual pertencem e, por isso mesmo, são mais eficientes e sujeitas a uma série de problemas graves, de difícil depuração, como deadlocks, starvation e race condition.

Threads e Swing

Ao programar interfaces gráficas com Swing, ao menos três diferentes threads devem ser consideradas: initial thread, event dispatch thread (EDT) e worker thread, também chamada de background thread.

Num aplicativo Swing para desktop, a thread inicial apenas agenda a criação da GUI através dos métodos estáticos invokeLater ou invokeAndWait, da classe SwingUtilities.

public static void main(final String args[]) {
.....SwingUtilities.invokeLater(new Runnable() {
..........public void run() {
...............// Cria e mosta a GUI.
...............new Applicatio().setVisible(true);
..........}
.....});
}

Em applets, a thread incial invoca os métodos init e start do objeto applet. O agendamento da construção da GUI em applets deve necessariamente ser feito através de invokeAndWait, em init.

A partir daí, o aplicativo passa a correr "baseado em eventos", executados na event dispatch thread, gerados pelo usuário do software através da GUI. Tarefas executadas nessa thread devem terminar rapidamente, caso contrário a interface irá congelar.

Por exemplo, ao clicar no hyperlink Pedir Suporte, o método actionPerformed abre o cliente de e-mail padrão do usuário, com o endereço do suporte e um título para o e-mail (detalhes aqui).

// actionPerformed executa na EDT...
public void actionPerformed(final ActionEvent e) {
.....if (desktop != null) {
..........if (desktop.isSupported(Desktop.Action.MAIL)) {
...............// try...catch omitido para simplificar exemplo.
...............desktop.mail(uri);
..........}
.....}
}

Longas tarefas podem e devem ser executadas na worker thread. A intercomunicação necessária entre a worker thread e a EDT não é uma tarefa trivial. Considere implementar uma subclasse de SwingWorker, que é abstrata, para rodar tarefas em background.

Boa parte dos componentes Swing não é thread safe (veja o porquê em MultiThreaded toolkits: A failed dream?). Isto é, quando executados em concorrência podem causar erros imprevisíveis. Portanto, comumente, invocações aos métodos dos componentes Swing devem ser feitos na event dispatch thread.

Se realmente for necessário invocar tais métodos na worker thread, consulte a documentação das classes Swing para ter certeza que o método em questão é thread safe.

Congelando GUI's - Como Irritar os Usuários do Seu Software... e Perder Clientes

Um exemplo de atividade que certamente irá travar a interface gráfica é a obtenção de objetos cadastrados através do EntityManager da JPA, no Java SE. (Mais sobre JPA aqui mesmo, nesse blog.)

A classe DefaultEntityModel é utilizada como model da GUI. Seu método load é utilizado para carregar a lista de entidades cadastradas.

public void load() {
.....// Primeiro verifica se a lista já foi carregada com as entidades cadastradas no banco de dados;
.....// isto é, se o usuário já havia acessado esse formulário.
.....if (isEmpty()) {
..........// Código auxiliar omitido para melhor clareza.

..........// Bem aqui, congela a GUI ao carregar a lista com as entidades cadastradas.
..........List<EntityClass> loadedEntities = domainManager.findAll();

..........// Finalmente atualiza a GUI. Só então a interface "descongela".
..........entities.addAll(loadedEntities);
..........fireContentsChanged(this, 0, entities.size() - 1);
.....}
}

As entidades cadastradas são carregadas na interface gráfica sob demanda. Para tanto, load é invocado no momento em que o formulário de cadastro aparece para o usuário.

private void formComponentShown(java.awt.event.ComponentEvent evt) {
.....entityListPanel.load();
}

Operações que envolvem manipulação de entidades com JPA, como é caso do método findAll da classe DomainManager (Service que disponibiliza API de alto nível para gerenciamento de entidades) costumam ser lentas no ambiente Java SE, porque implicam:

conexão ao banco de dados;
tentativa de geração das tabelas do banco de dados, de acordo com a configuração;
execução de operações CRUD; e
desconectar-se do banco de dados.

SwingWorker in Action

A classe javax.swing.SwingWorker fornece a infraestrutura necessária para executar tarefas demoradas na worker thread. Cada instância de SwingWorker implementa uma tarefa em background. De acordo com sua documentação:

é desenhada para situações onde é preciso ter tarefas demoradas executando em background que forneçam atualizações para a GUI, seja quando a tarefa terminar, seja enquanto processando (não mostrado nesse artigo).

SwingWorker é parametrizada. O primeiro parâmetro de tipo é utilizado para definir o resultado final dos métodos doInBackground() e get(). O segundo, para definir o tipo dos resultados intermediários em publish(V... chunks) e process(List<V> chunks).

/**
* Background thread utilizada pelo método load para preencher lista de entidades.
*
* LoadEntities espera carregar todas as entidades
* na instância de List, entities, para só então atualizar a GUI.
*/
private class LoadEntities extends SwingWorker<List<EntityClass>, Void> {

.....@Override
.....protected List<EntityClass> doInBackground() {
..........return domainManager.findAll();
.....}

.....@Override
.....public void done() {
..........// Código auxiliar e bloco try...catch omitidos para melhor clareza.
......... entities.addAll(get());
..........fireContentsChanged(this, 0, entities.size() - 1);
.....}
}

Subclasses de SwingWorker devem implementar o método doInBackground. done executa na EDT assim que o método doInBackground termina. get também corre na EDT e espera doInBackground terminar para só então retornar o resultado da computação desse método. Em LoadEntities, get é chamado em done, portanto retorna imediatamente.

O método load de DefaultEntityModel, atualizado, instancia a classe interna LoadEntities e invoca seu método execute na event dispatch thread, que retorna imediatamente. Repare que a assinatura de load não foi alterada, portanto a interface gráfica não precisa ser atualizada.

public void load() {
.....// Primeiro verifica se a lista já foi carregada com as entidades cadastradas no banco de dados;
.....// isto é, se o usuário já havia acessado esse formulário.
.....if (isEmpty()) {
..........// Agora, executa tarefa em background. Conclusão, a GUI não congela.
..........new DefaultEntityModel.LoadEntities().execute();
.....}
}

Repare em
..........new DefaultEntityModel.LoadEntities().execute();

SwingWorker é desenhada para executar apenas uma vez; não há como reaproveitar o uso de suas instâncias.

E não é só isso!

SwingWorker também possibilita:

Cancelar a worker thread em execução com cancel(boolean mayInterruptIfRunning), verificar se essa thread terminou através de isDone(), ou se foi cancelada com isCancelled().
Como mencionado anteriormente, SwingWorker pode fornecer resultados intermediários enquando a worker thread está em execução. Para isso, use o método publish((V... chunks). publish faz com que process(List<V> chunks) seja invocado de modo assíncrono na EDT.
SwingWorker pode amarrar propriedades. Mudanças nessas propriedades disparam eventos que deverão ser tratados na EDT. Na prática, isso possibilita conhecer o estador da background thread (PENDING, STARTED e DONE), assim como o seu progresso.

Consulte as fontes utilizadas nesse artigo para conhecer os detalhes técnicos necessários para implementar essas funcionalidades de SwingWorker.

Veja Também:

Consulte as Fontes Utilizadas, logo abaixo
Swing Development
Componentes SwingX

Fontes Utilizadas:

The Java Tutorials - Concurrency in Swing
The Java Tutorials - Concurrency
SwingWorker (Javadoc do Java SE 6)

Swing Application Framework (JSR-296) - Parte 2

2007-06-15T04:45:00.000-03:00

A segunda parte desse artigo foi publicado no blog batteries not included, do Daniel (Tritone) Fernandes Martins. Você pode acessá-lo clicando aqui.

Valeu, Daniel!

Veja Também:

Swing Application Framework (JSR-296) - Parte 1

Fontes e Referências Utilizadas:

Swing Application Framework Home Page
JSR 296: Swing Application Framework
Javadoc e código fonte do Swing Application Framework
An Introduction to Swing Application Framework API (JSR-296)

Swing Application Framework (JSR-296) - Parte 1

2007-05-29T10:01:00.000-03:00

A missão do Swing Application Framework (JSR-296), segundo os seus criadores, é definir uma infraestrutura que é comum à maioria dos aplicativos Desktop:

gerenciamento do ciclo de vida dos aplicativos, especialmente GUI startup e shutdown
gerenciamento e carregamento de recursos, como strings, mensagens formatadas, cores, fontes e outros, em componentes Swing
apoio para a definição, gerenciamento e ligação de Actions
Actions assíncronos (executam em "background")
Estado da sessão persistente.

O Swing Application Framework visa fornecer uma base padrão e um ponto de partida para aplicativos Swing, tornando mais fácil o seu desenvolvimento, e ser simples o suficiente para que até mesmo programadores novatos entendam como utilizá-lo dentro de horas, ao invés de meses.

Inicialização e Gerenciamento do Ciclo de Vida de Aplicativos

Através da classe Application, a base desse framework, é possível executar tarefas específicas de acordo com o ciclo de vida do aplicativo.

O aplicativo deve estender essa classe e implementar ao menos o método startup, responsável por preparar a GUI inicial e torná-la visível. A implementação dos outros métodos que lidam com o ciclo de vida dos aplicativos - initialize, ready e shutdown - é opcional.

Use initialize se precisar configurar propriedades do sistema antes da construção da GUI. Utilize ready se precisar executar trabalho extra depois que a GUI estiver pronta e visível. O objetivo é fazer com que startup execute menos tarefas, tornando a GUI visível o mais rápido possível. O método shutdown fecha a GUI e executa outras tarefas de limpeza antes de encerrar o aplicativo.

A subclasse concreta de Application inicia o aplicativo por meio de seu método launch.

public final class OhMyApplication extends Application {
.....private SingleFrame mainFrame;

.....@Override
.....protected void initialize(final String [] args) {.....}

.....protected void startup() {
..........mainFrame = new SingleFrame();
..........mainFrame.addWindowListener(new MainFrameListener());
..........mainFrame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
..........mainFrame.pack();
..........mainFrame.setVisible(true);
.....}

.....@Override
.....protected void ready() {
..........TipOfTheDay.show(mainFrame);
.....}

.....@Override
.....protected void shutdown() {
..........mainFrame.setVisible(false);
.....}

.....public static void main(final String[] args) {
..........PlasticLookAndFeel.setPlasticTheme(new ExperienceBlue());
..........Application.launch(OhMyApplication.class, args);
.....}

.....private class MainFrameListener extends WindowAdapter {
..........public void windowClosing(final WindowEvent e) {
...............exit(e);
..........}
.....}
}

Se o aplicativo em questão contar com apenas um JFrame principal, há a opção de criar uma subclasse concreta de SingleFrameApplication, ao invés de estender Application.

Os aplicativos devem ter um arquivo de propriedades com o mesmo nome da classe que estende Application ou SingleFrameApplication num subpacote denominado resources. Esse ResourceBundle irá compartilhar seus recursos por todo o aplicativo e deverá contar com as seguintes propriedades padrões:

Application.name        = Nome do aplicativo
Application.id          = Apropriado para identificadores específicos do aplicativo
Application.title       = Título para dialogs e frames.
Application.version     = Versão pode ser incorporada em mensagens
Application.vendor      = Nome da organização/pessoa responsável pelo software
Application.vendorId    = Apropriado para identificadores específicos do aplicativo
Application.homepage    = Uma URL como http://rafaelfiume.wordpress.com
Application.description = Breve descrição sobre o software.
Application.lookAndFeel = system, default, ou uma classe LookAndFeel

Estado da Sessão Persistente

É interessante manter o estado da interface gráfica entre sessões do aplicativo. Para isso existe a classe SessionStorage. O estado da sessão é armazenado baseado em componentes, desde que estes tenham definidos a propriedade name e uma classe SessionState.Property equivalente.

Por padrão, SessionStorage possui implementações de SessionState.Property para os componentes Window, JTabbedPane, JSplitPane, e JTable, armazenado as propriedades bounds (posição e tamanho da janela) da classe Rectangle para Window's, dividerLocation para JSliderPane's, selectedIndex para JTabbedPane's e width (tamanho das colunas) para JTable's.

SessionStorage é obtido através do método getSessionStorage de ApplicationContext, um Singleton utilizado para encontrar variáveis e serviços globais, o que corresponde a maior parte dos componentes do Swing Application Framework.

Durante a inicialização do software (startup), restore é chamado para restaurar o estado da sessão anterior da GUI. Ao encerrar a execução do programa (shutdown), store é invocado para persisitir a sessão atual da GUI.

@Override
protected void startup() {
...... . .
.....ApplicationContext.getInstance().getSessionStorage().restore(mainFrame, "session.xml");
...... . .
}

@Override
protected void shutdown() {
...... . .
.....ApplicationContext.getInstance().getSessionStorage().save(mainFrame, "session.xml");
...... . .
}

O estado da sessão é armazenado a partir do diretório do usuário. As propriedades vendorId e applicationId (veja a seção Inicialização e Gerenciamento do Ciclo de Vida de Aplicativos) devem estar definidas para garantir que o diretório correto seja acessado em diferentes plataformas (de acordo com a seção Persistência Local, logo abaixo).

A classe SingleFrameApplication implementa rotinas para persistir / restaurar o estado da sessão da GUI, inclusive de janelas secundárias, como dialogs, livrando o programador dessa tarefa.

Persistência Local

SessionStorage utiliza a classe LocalStorage para persistir / restaurar um java.util.Map com dados sobre o estado da GUI numa sessão, por meio de seus métodos save e load.

public void save(Component root, String fileName) throws IOException {
...... . .
.....LocalStorage lst = ApplicationContext.getInstance().getLocalStorage();
.....lst.save(stateMap, fileName);
}

public void restore(Component root, String fileName) throws IOException {
...... . .
.....LocalStorage lst = ApplicationContext.getInstance().getLocalStorage();
.....Map stateMap = (Map) (lst.load(fileName));
...... . .
}

LocalStorage deve ser obtido através do método getLocalStorage de ApplicationContext, e pode ser utilizado para persistir / restaurar outros dados, desde que estejam de acordo com os mecanismos da API Java Beans Persistence, o que inclui Java Beans, bem como a maioria dos tipos primitivos. O método save é implementado com a ajuda de java.beans.XMLEncoder, enquanto load utiliza java.beans.XMLDecoder.

Como visto na seção acima Estado da Sessão Persistente, as propriedades vendorId e applicationId devem estar definidas para garantir que o diretório correto seja acessado em diferentes plataformas. O diretório onde os dados serão persistidos dependem do sistema operacional. No Windows esse diretório poderá ser:

${userHome}\Application Data\${vendorId}\${applicationId}

no Mac OS X:

${userHome}/Library/Application Support/${applicationId}

por fim, em sistemas UNIX e derivados será:

${userHome}/.${applicationId}/

Cenas dos Próximos Capítulos...

Nas partes seguintes serão explicadas as funcionalidades de Injeção de Recursos, definição de Actions e Tasks (tarefas que executam em background).

Fontes e Referências utilizadas:

Swing Application Framework Home Page
JSR 296: Swing Application Framework
Javadoc e código fonte do Swing Application Framework
An Introduction to Swing Application Framework API (JSR-296)

Por que Utilizar a Commons Lang?

2007-05-21T04:40:00.000-03:00

A definição dos objetivos da Commons Lang, que você encontra no sítio do projeto, é algo como:

[...] prover um conjunto de utilitários para a java.lang API, particularmente métodos para manipulação de Strings, métodos numéricos básicos, operações para criação e serialização e obtenção de propriedades do sistema. Além disso, disponibiliza enum com suporte a herança, uma estrutura de exceções com suporte à múltiplas exceções aninhadas, alguns aperfeiçoamentos para java.util.Date e utilitários para a contrução apropriada dos métodos hashCode, toString, equals e compareTo.

O ponto de partida para a Commons Lang é que a Java API deveria fornecer métodos básicos para a manipulação de suas classes principais, tarefa essa que foi "jogada" à mão dos desenvolvedores. Trata-se então de um toolkit com propósito específico e muito bem definido, que é prover essas funcionalidades básicas faltantes.

Builder

A API org.apache.commons.lang.builder está entre as mais úteis por auxiliar na construção de métodos hashCode, toString, equals e compareTo consistentes. As principais classes desse pacote são, respectivamente, HashCodeBuilder, ToStringBuilder, EqualsBuilder e CompareToBuilder, que seguem as regras propostas pelo livro Effective Java de Joshua Bloch.

Veja a API org.apache.commons.lang.builder em ação e seus benefícios em Geração de Métodos hashCode, equals, toString e compareTo no NetBeans.

Enums

Utilize a API org.apache.commons.lang.enums caso precise de enums e não tenha acesso ao JDK 5.0 ou superior, ou ainda, se precisar criar uma hierarquia de enums (superclasse/subclasses).

A classe Enum é abstrata e segue o padrão Typesafe Enum descrito no item 21 do livro Effective Java. Eis um exemplo de seu uso, retirado do Javadoc:

public final class ColorEnum extends Enum {
.....public static final ColorEnum RED = new ColorEnum("Red");
.....public static final ColorEnum GREEN = new ColorEnum("Green");
.....public static final ColorEnum BLUE = new ColorEnum("Blue");

.....private ColorEnum(String color) {
..........super(color);
.....}

.....public static ColorEnum getEnum(String color) {
..........return (ColorEnum) getEnum(ColorEnum.class, color);
.....}

.....public static Map getEnumMap() {
..........return getEnumMap(ColorEnum.class);
.....}

.....public static List getEnumList() {
..........return getEnumList(ColorEnum.class);
.....}

.....public static Iterator iterator() {
..........return iterator(ColorEnum.class);
.....}
}

ValuedEnum, abstrata, é utilizada para criação de Typesafe Enums com valores inteiros, propícios para uso dentro de declarações switch. A terceira classe desse pacote é a EnumUtils, que fornece operações para acessar e manipular Enums.

Enums podem ser extendidos e ter funcionalidades. Consulte o Javadoc para maiores informações.

Exception

O pacote org.apache.commons.lang.exception oferece exceções aninhadas (nested exception) para quem utilizar versões anteriores à JDK 1.4. Nested exceptions permitem que informações sobre as origens de uma exceção não se perca quando for preciso jogar (throw) uma nova exceção, empacotando a original na nova excessão.

A classe ExceptionUtils contém operações para manipular e examinar objetos Throwable.

Dentro do pacote org.apache.commons.lang estão presentes exceções interessantes: IllegalClassException, IncompleteArgumentException, NotImplementedException, NullArgumentException, SerializationException e UnhandledException.

Math

A API org.apache.commons.lang.math extende a API java.math e tem propósitos financeiros, e não científicos. Conta com as classes:

Range. Classe abstrata, representa um conjunto inclusivo de números do mesmo tipo.
IntRange, LongRange, FloatRange, DoubleRange e NumberRange. Representam um conjunto inclusivo de ints, longs, floats, doubles e java.lang.Numbers, respectivamente, imutáveis e serializáveis.
Fraction. Subclasse de java.langNumber, representa corretamente uma fração. É imutável.
JVMRandom. Um wrapper, opera a partir de random() de java.lang.Math.
NumberUtils. Provê funcionalidades adicionais para subclasses de java.lang.Number.

Mutable

O pacote org.apache.commons.lang.Mutable fornece wrappers mutáveis para os tipos de dados primitivos e para java.lang.Object.

Mutable. Wrappers para tipos de dados primitivos ou objetos mutáveis devem implementar essa interface.
MutableBoolean, MutableByte, MutableShort, MutableInt, MutableLong, MutableFloat, MutableLong e MutableObject. Subclasses de java.lang.Number, implementam Mutable, são wrappers mutáveis e comparáveis para booleans, bytes, shorts, ints, longs, floats, doubles e java.lang.Object, respectivamente.

Text

Praticamente uma pequena extensão de java.text, as classes do pacote org.apache.commons.lang.text são desenhadas para manipular texto:

CompositeFormat. Formata utilizando um java.text.Format e processa (parse) utizando outro.
StrBuilder. Um implementação alternativa para StringBuffer/StringBuilder. StrBuilder no entanto: 1) não é final; 2) não é sincronizada; 3) permite às suas subclasses acesso ao seu array interno de caracteres; 4) fornece interessantes métodos adicionais, como size/clear/isEmpty, replace e appendWithSeparators.
StrLookup. Classe base (abstrata) para implementar lookup de um valor String a partir de uma chave String. Contém uma implementação, MapStrLookup, que utiliza java.util.Map e pode ser obtida através de um de seus métodos factory.
StrMatcher. Classe abstrata utilizada para obter a quantidade de caracteres que "batem" (match) com um array de caracteres. Contém várias implementações, como StringMatcher, e seus correspondentes métodos factory.
StrSubstitutor. Utilizada para substituir variáveis dentro de uma String por seus respectivos valores, definidos previamente.
StrTokenizer. Alternativa ao java.util.StringTokenizer, implementa java.util.ListIterator e tem outros funcionalidades úteis.

Time

org.apache.commons.lang.Time tem classes auxiliares para tratamento de datas e períodos de tempo.

DateFormatUtils. Possui constantes e métodos utilitários (i.e. estáticos) para formatação de datas. No geral, essa classe não é muito interessante para softwares ambientados fora dos Estados Unidos.
DateUtils. Conta com constantes e métodos utilitários para lidar com objetos java.util.Calendar e java.util.Date, como addDays, isSameDay e iterators.
DurationFormatUtils. Possui constantes e métodos utilitários para formatação de períodos de tempo.
FastDateFormat. Uma alternativa mais rápida e thread-safe à java.text.SimpleDateFormat.
StopWatch. Abstrai um cronômetro. Se precisar de um, utilize essa classe.

Diversos

O pacote org.apache.commons.lang, além das API's citadas acima, possui diverssas classes utilitárias.

Se precisar lidar constantemente com propriedades do sistema, como diretório do usuário, versão da JDK, do sistema operacional, entre outras tantas, utilize SystemUtils.

SerializationUtils, que junto com as classes do pacote builder é uma das mais interessantes e úteis, auxilia no processo de serialização/desserialização, com métodos simples e diretos como serialize e deserialize.

Validate proporciona um código fonte mais limpo ajudando a validar argumentos, como Collections, com métodos do gênero notNull e notEmpty.

Como sempre, consulte o Javadoc para outras e mais completas informações.

Propósito Geral vs. Propósito Específico

Diferente do que ocorre com frameworks ou bibliotecas de propósito geral, a Commons Lang tem tamanho reduzido (o .jar tem apenas 239,5 KB), é fácil de entender e simples de usar, por ser pequena, ter escopo bem definido, ser auto-documentada e não precisar de toneladas de configuração.

Nesse aspecto, caso semelhante ao da Commons Lang é a JSR-296, cujo tamanho e propósito - ao contrário da plataforma NetBeans por exemplo, que busca abraçar o mundo - também é limitado (i.e. definido, específico).

Particularmente, prefiro toolkits/frameworks especialistas, pois a curva de aprendizado fica reduzida a horas ao invés de meses, há pouco bugs, sempre mais simples de corrigir, e há maior produtividade.

Fontes utilizadas:

Commons Lang Home Page
Javadoc e código fonte da Commons Lang
Nested Exception

Geração de Métodos hashCode, equals, compareTo e toString no NetBeans

2007-05-02T14:00:00.000-03:00

Algumas coisas pedem por soluções automáticas. Entre os candidatos para a automação estão tarefas repetitivas, com regras e condições bem definidas e sujeitas a erros. Exatamente o caso dos métodos hashCode, equals, compateTo e toString.

Enquanto trabalhava com dúzias de entidades (JPA entity beans), a necessidade de geração automática para os método citados ficou ainda mais evidente, por isso comecei a procurar na Net por plugins para esse fim. E achei (thank god!) o NISECommons4E4N. Para utilizá-lo, baixe o arquivo .nbm e instale o plugin no NetBeans. Se precisar de ajuda, veja Nota - nbextras.org.

A classe Contato será utilizada como exemplo para a geração automática dos métodos equals, hashCode, toString e compareTo.

@Entity
public class Contato implements Serializable {

.....@Id private Long id;
.....private String email;
.....private String nomePrimeiro;
.....private String nomeUltimo;
.....private String celular;

.....public Contato() {.....}

...... . . // Acessores e modificadores omitidos por brevidade.
}

equals(Object other) e hashCode()

No código fonte, selecione NISECommons4E4N Lang -> Generate Equals and HashCode... Selecione os campos que devem fazer parte dos métodos equals() e hashCode(), o ponto de inserção para esses métodos - primeiro método na classe, último método, etc. - e demais opções.

Os métodos equals() e hashCode() resultantes para a entidade Contato serão como abaixo:

@Entity
public class Contato implements Serializable {
...... . .

.....@Override
.....public boolean equals(final Object other) {
..........if (this == other)
...............return true;
..........if (!(other instanceof Contato))
...............return false;
..........Contato castOther = (Contato) other;
..........return new EqualsBuilder()
.....................append(id, castOther.id)
.....................append(email, castOther.email)
.....................append(nomePrimeiro, castOther.nomePrimeiro)
.....................append(nomeUltimo, castOther.nomeUltimo)
.....................append(celular, castOther.celular)
.....................isEquals();
.....}

.....@Override
.....public int hashCode() {
..........return new HashCodeBuilder()
.....................append(id)
.....................append(email)
.....................append(nomePrimeiro)
.....................append(nomeUltimo)
.....................append(celular)
.....................toHashCode();
.....}

...... . .
}

toString()

No código fonte, selecione NISECommons4E4N Lang -> Generate ToString Method... Selecione os campos que devem fazer parte do método toString(), seu ponto de inserção e outras opções.

Segue a implementação de toString() para Contato:

@Entity
public class Contato implements Serializable {
...... . .

.....@Override
.....public String toString() {
..........return new ToStringBuilder(this, ToStringStyle.DEFAULT_STYLE)
.....................append("id", id)
.....................append("email", email)
.....................append("nomePrimeiro", nomePrimeiro)
.....................append("nomeUltimo", nomeUltimo)
.....................append("celular", celular)
.....................toString();
.....}

...... . .
}

compareTo(Object other)

Selecione NISECommons4E4N Lang -> Generate CompareTo Method... Selecione os campos que devem fazer parte do método compareTo(), o ponto de inserção e demais opções.

O resultado será:

public class Contato implements Serializable, Comparable<Contato> {
...... . .

.....public int compareTo(final Contato other) {
..........return new CompareToBuilder()
.....................append(id, other.id)
.....................append(email, other.email)
.....................append(nomePrimeiro, other.nomePrimeiro)
.....................append(nomeUltimo, other.nomeUltimo)
.....................append(celular, other.celular)
.....................toComparison();
..........}

...... . .
}

Mas Afinal do que se Trata EqualsBuilder, HashCodeBuilder, ToStringBuilder e CompareToBuilder ?

São classes da biblioteca Commons Lang do Projeto Jakarta.

A premissa do Commons Lang é que a Java API (biblioteca de classes presentes em todos os ambientes de produção Java) tem uma lacuna de métodos para manipulação de suas principais classes. De acordo com o sítio do projeto:

The Lang Component provides a host of helper utilities for the java.lang API, notably String manipulation methods, basic numerical methods, object reflection, creation and serialization, and System properties. Additionally it contains an inheritable enum type, an exception structure that supports multiple types of nested-Exceptions, basic enhancements to java.util.Date and a series of utlities dedicated to help with building methods, such as hashCode, toString and equals.

O fato do plugin NISECommons4E4N se apoiar na Commons Lang pode ser uma desvantagem quando existir o objetivo de evitar ao máximo bibliotecas de terceiros.

Mas a Commons Lang é uma ótima pedida e uma excelente biblioteca. No geral, sobrescrever métodos da classe Object pode ocasionar muitos bugs, a maioria de difícil detecção (vejam o artigo How to avoid traps and correctly override methods from java.lang.Object). A classe EqualsBuilder, por exemplo, segue as regras do Effective Java , de Joshua Bloch.

Veja Também:

Fontes Utilizadas:

Service Locator Não Morreu

2007-04-10T03:13:00.000-03:00

Dependency injection figura entre as principais novidades do EJB 3.0. Com a DI é possível aos clientes obter acesso à componentes apenas declarando suas dependências. (Para saber mais sobre injeção de dependência, veja Pequena Introdução à Dependency Injection e O Papel da Dependency Injection no EJB 3.0.)

Por exemplo, para acessar os serviços de um componente EJB utlizando a DI, teremos algo como:

@EJB
private ProdutoDAO produtoDAO;

O container EJB se encarrega de injetar a referência à ProdutoDAO, liberando o cliente de ProdutoDAO da responsabilidade de procurar, inicializar e instanciar componentes.

Porém, no EJB 3.0, o uso de DI está limitado aos managed components, como enterprise beans e data sources. Para localizar e acessar outros componentes, por exemplo classes auxiliares, ainda é necessário o uso de service locators ou, se realmente for preciso injeção de dependências, utilizar frameworks como PicoContainer e Spring.

Service Locator é outra solução para localizar e acessar componentes de maneira transparente e retirar dos clientes o peso dessa responsabilidade. Um service locator centraliza o mecanismo de procura e acesso, evitando a duplicação de código, degradação de desempenho, dificuldade de manutenção e dependência de fornecedor.

No contexto do J2EE e do Java EE, o service locator é implementado utilizando a API JNDI. Felizmente, seu uso foi simplificado no Java EE 5, em comparação com o J2EE 1.4.

Application Client

O uso de DI em application clients executando sobre o application container está limitado à variáveis estáticas no método main.

public class AppClient {

.....@EJB
.....private static ProdutoDAO produtoDAO;

.....public static void main(String[] args) {
..........System.out.println("Criando produto... ");
..........Produto abacaxi = new Produto();
..........abacaxi.setNome("Abacaxi");
..........abacaxi.setDescricao("Fruta tropical, Gíria pra problemas.");
..........abacaxi.setPreco(new BigDecimal("4.56"));
..........System.out.println("Armazenando produto...");

..........produtoDAO.create(abacaxi);
........... . .
.....}
...... . .
}

Em todos os outros casos, incluindo clientes stand alone (i.e., não executam sobre o application container), é preciso utilizar a API JNDI para localizar e acessar componentes. Conclusão: application clients não se beneficam em nada da injeção de dependência advinda com o EJB 3.0.

Uma Nota Sobre Inversion of Control

Dependency Injection é uma forma de Inversion of Control, já que o cliente apenas declara suas dependências e deixa ao container a tarefa de injetar esses componentes no cliente. Service Locator não é uma forma de IoC, pois o cliente ainda deve obter componentes e serviços, mesmo que com a ajuda de um Service Locator.

Leitura Recomendada:

Fontes Utilizadas:

Waldemar Fiume - Campeão Mundial de Interclubes

2007-04-02T04:49:00.000-03:00

Autor: Felipe Fiume

Dia 29/03/2007 o Palmeiras foi oficialmente confirmado pela FIFA, entidade máxima de futebol, como Campeão Mundial de Clubes. O time bateu campeões internacionais como o Olympique Nice (Campeão Francês 1950/51), o Estrela Vermelha (Campeão Iuguslavo 1950/51), o Vasco (Campeão Carioca de 1951) na semifinal, e na final derrotou o poderoso Juventus (campeão italiano de 1950/51).

O reconhecimento oficial da conquista vem glorificar ainda mais a carreira de um dos maiores ídolos da história do Palmeiras, Waldemar Fiume.

O Pai da Bola (apelido recebido por sua habilidade) fez 601 jogos com a camisa do Palmeiras em 18 anos de clube. Começou a carreira como meia direita e depois passou a atuar mais recuado, primeiro na média central e depois na quarta zaga. Foi tetracampeão paulista (1942,1944,1947,1950), campeão do torneio Rio São Paulo (1951) e Campeão Mundial de Clubes.

Fiume era um jogador versátil, habilidoso e disciplinado taticamente. Foi convocado várias vezes para a seleção paulista, porém não teve oportunidade de jogar uma Copa do Mundo. A CBD (Confederação Brasileira de Desportos, hoje CBF) era sediada no Rio e dava preferência para jogadores dos clubes cariocas. Na Copa de 1950, por exemplo, havia oito jogadores vascaínos e apenas três do Palmeiras. Por ironia, praticamente o mesmo Vasco foi derrotado em 1951 na semifinal do Mundial de Clubes pelo Palmeiras.

Na final contra o Juventus de Turim, todos os brasileiros torciam a favor do Palmeiras, já que a vitória tiraria um pouco do gosto amargo deixado pelo vice no Mundial de 1950. Apesar de Waldemar Fiume não ter jogado os jogos contra o Vasco por estar contudido, por tudo que ele fez no Futebol Paulista e pela hegemonia do Palmeiras em 1950-1951, fica a impressão de que poderia ter sido muito útil à Seleção caso tivesse tido chance de representá-la.

Apesar de não ter servido a Seleção Brasileira, a carreira desse jogador foi brilhante. Tanto que hoje possui um busto na Sociedade Esportiva Palmeiras. Em 1995, ao ir ao Parque Antártica assistir a uma partida do Palmeiras, Fiume ainda era reconhecido e cercado por vários torcedores que se aglomeravam para cumprimentá-lo. Prova de seu brilhantismo e digno de um Campeão Mundial de Clubes.

Pequena Introdução à Dependency Injection

2007-03-29T08:36:00.000-03:00

Um software é composto por uma série de componentes que interagem e colaboram entre si. Tais componentes podem ser classificados como clientes, que dependem de outros componentes para cumprir seus objetivos, e os provedores de serviços (services, ou ainda, server components), que executam tarefas conforme requisitados pelos clientes.

Para que clientes utilizem serviços é preciso, antes, encontrar (look up), e instanciar os provedores de serviços. Deixar essa tarefa sob incumbência do cliente pode não ser a melhor opção.

Dependency Injection (DI) é uma forma moderna e eficaz de "plugar" serviços nos clientes, deixando o trabalho de procura, instanciação e inicialização para o responsável pela DI. Dessa forma, os clientes apenas precisam declarar suas dependências para que os serviços sejam injetados nos mesmos, em tempo de execução, thread safety e sem utilizar API's.

A implementação da injeção de dependência pode ser feita através de código próprio ou por containers, como Spring Framework, PicoContainer, HiveMind, XWork e EJB 3.0.

O container sabe qual componente deve ser injetado através de arquivos de configuração XML, assinatura de métodos (propriedades JavaBeans ou construtores) ou metadados. Há outros meios mais incomuns para isso, como através de interfaces (type 1 IoC).

Benefícios da Dependency Injection

Componentes mais fáceis de manter, justamente por dispensar lógica para ter acesso aos services
Dependências são explicitas e evidentes, tornando o código-fonte mais claro e o desenvolvimento mais simples
Maior facilidade para fazer testes de unidade
Preserva strong typing, eliminando os riscos de ClassCastException.

E Sobre IoC ?

Inversion of Control (IoC) é um termo genérico para um padrão onde o controle e responsabilidade de uma atividade é invertido entre os participantes. Esse conceito é, por vezes, chamado divertidamente de Princípio de Hollywood: "Don't call us, We'll call you", ou, em português, "Não nos telefone; Nós ligaremos para você".

Dependency Injection é uma forma mais específica de IoC, cujo objetivo é eliminar dependências explicitas entre componentes e "externalizar" dos clientes a rotina para acesso aos provedores de serviços.

Ao invés do cliente executar a lógica necessária para obter uma referência ao service do qual é dependente para executar suas tarefas, o container se encarrega de obter e injetar esse componente no cliente. Daí a inversão de controle.

Leitura Recomendada:

Fontes Utilizadas:

Synthetica Look and Feel

2007-03-28T11:12:00.000-03:00

Synthetica é um look and feel baseado no Synth, o que permite que seja modificado até mesmo por não programadores, através de arquivos XML. É possível conhecer as possiblidades do Synthetica por meio do demo disponibilizado pela JavaSoft.

O demo do Synthetica é interessante porque, além de mostrar diversos temas disponíveis, possui exemplos de uma série de extensões de componentes Swing, como SwingX e Flexdoc, juntamente com o código-fonte desses exemplos.

Para ser distribuído com aplicativos comerciais, uma licensa comercial deve ser adquirida. No caso de aplicativos não-comerciais, pode ser distribuído livremente. Requer no mínimo JRE 1.5.

Synthetica é, sem dúvida, um dos mais sofisticados look and feel disponível no mercado.

Synthetica in Action

Para fazer o download do Synthetica, é preciso antes registrar-se no sítio da JavaSoft. Adicione a biblioteca ao classpath do projeto e utilize o método setLookAndFeel(LookAndFeel laf), de UIManager, durante a execução de main para alterar o look and feel.

try {
.....UIManager.setLookAndFeel(new SyntheticaStandardLookAndFeel());
} catch (UnsupportedLookAndFeelException ex) {
.....ex.printStackTrace();
} catch (ParseException ex) {
.....ex.printStackTrace();
}

Existem diversos temas disponíveis para o Synthetica, adquiridos separadamente, como o Synthetica BlueMoon Look and Feel...

... Synthetica GreenDream Look and Feel...

... e o Synthetica BlueIce Look and Feel.

Customização

Uma das grandes vantagens do Synthetica é a possiblidade de customização, ou até criação de um novo tema, sem alterar o código-fonte, mas por meio de arquivos XML. Veja mais detalhes em Customize Synthetica Look and Feel e How Can I Customize an Existing Synthetica Look and Feel.

Também é possível alterar o look and feel programaticamente através de propriedades UI padrões, utilizando o método estático put(Object key, Object value) de UIManager.

// Habilita o anti-aliasing
UIManager.put("Synthetica.text.antialias", Boolean.TRUE);
try {
.....UIManager.setLookAndFeel(new SyntheticaStandardLookAndFeel());
catch (Exception ex) {
.....ex.printStackTrace();
}

Veja a lista completa de propriedades UI que podem ser ajustadas ao utilizar o Synthetica aqui.

O FAQ do Synthetica provê uma série de How To's interessantes, com dicas para contornar possíveis problemas, customização e outras.

Leitura Recomendada:

Veja mais sobre look and feel em:

Fontes Utilizadas:

Synthetica - The Extended Synth Look and Feel

Gigante Vermelha - O Início do Fim

2007-03-27T10:07:00.000-03:00

Durante os estágios finais de sua vida, uma estrela terá transformado quase todo o seu hidrogênio em hélio, que irá cada vez mais se acumular no seu centro. Com o fim do estoque de hidrogênio, a queima nuclear e, consequentemente, a força de expansão, proveniente do calor gerado pela fusão, cessa. Sem a força de expansão, ocorre o colapso gravitacional.

A temperatura no núcleo pode atingir a impressionante marca dos 100 milhões °C e iniciar o processo de fusão de núcleos de hélio em núcleos maiores que, por sua vez, podem ser fundidos em outros ainda maiores, até o momento em que o processo de fusão resulte em núcleos de ferro (26 prótons e 32 nêutrons).

O centro da estrela, mais quente e mais denso, se expande, obrigando suas porções mais externas a expandirem-se também. O calor das regiões externas, nesse estágio, apesar de maior, fica diluído por toda a região ocupada pela estrela. Por isso, sua superfície é mais fria (cerca de 2500 °C), e a estrela emite apenas um brilho avermelhado. Daí o nome Gigante Vermelha.

Dependendo do tamanho da massa estelar, a Gigante Vermelha irá transformar-se numa Anã Branca, Estrela de Nêutron ou Buraco Negro. Anãs Brancas com massa 1,4 superior a do Sol (limite de Chandrasekhar) não resistem a pressão gravitacional e entram em colapso, tornando-se Estrela de Nêutron ou Buraco Negro.

Veja também:

Sol - Um Reator de Fusão Nuclear

Esse artigo bebe das fontes:

Imagem:

Na primeira figura, acima e à direita, Aldebarã, uma Gigante Vermelha, é comparada com o Sol.

Sobre Annotations e Deployment Descriptors no EJB 3.0

2007-03-26T07:23:00.000-03:00

Deployment é o conjunto de atividades que fazem com que um software, ou componentes de software, estejam prontos para uso. Durante o deployment, o container EJB lê as configurações contidas no deployment descriptor ou nas annotations no código-fonte e prepara um ambiente padronizado para a execução dos beans.

Ou seja, o deployment descriptor especifica quais serviços de infra-estrutura o container EJB proverá aos enterprise beans, desde que o deployment seja feito num container EJB certificado.

Annotation (metadado)

Deployment descriptor é um arquivo XML, portanto propenso a erros, e acrescenta grande complexidade ao ciclo de vida de desenvolvimento. As annottions para EJB foram introduzidas para ser uma alternativa aos deployment descriptors e, conseqüentemente, aliviar o desenvolvedor da sua complexidade inerente.

Annotation, ou metadado, é um elemento que pode ser adicionado a um pedaço de código para fornecer informações adicionais sobre esse código. A JSR-175 (A Metadata Facility for the Java Programming Language), íncluída no J2SE 5.0, fornece o meio para criação e processamento de annotations. A JSR-220 definiu uma série de annotations específicas para o desenvolvimento de enterprise beans.

Entretanto, deployment descriptors não foram eliminados, nem estão ultrapassados. Foram mantidos como forma redundante de informação sobre o deployment de um enterprise bean; isto é, podem ser utilizados em conjunto com os metadados. Nesse caso, o deployment descriptor tem precedência sobre a sua annotation equivalente.

Deployment Descriptors Proprietários

Há certos serviços providos pelos containeres que são específicos de cada container EJB, indo além do que define a especificação JSR-220, como clustering e load balancing - uma forma de diferenciação entre servidores Java EE.

A configuração necessária para esses serviços é feita em deployment descriptors proprietários. Esses serviços geralmente podem ser ajustados através de suas respectivas annotations, nesse caso, tornando o código-fonte não portável entre os diferentes servidores.

Annotations in Action

As duas figuras abaixo, retiradas do Apêndice 2 do livro Mastering Enterprise JavaBeans 3.0, demonstram como os metadados ajudam a reduzir a complexidade do desenvolvimento de enterprise beans.

Perceba que as annotations @Stateful, @Remote e @Interceptors equivalem a 16 linhas de código XML de um deployment descriptor equivalente. Além disso, os metadados são inerentemente ligados ao código-fonte, enquanto o deployment descriptor é externo ao código.

Nem Tudo São Flores

O uso de annotation simplifica e agiliza o desenvolvimento de enterprise beans, contudo não substitui completamente os deployment descriptors.

Quando os papéis de Bean Provider e EJB Deployer são executados por pessoas diferentes, pode haver confusão e retrabalho ao definir a configuração do deployment. Nesse caso, como os metadados estão presentes no código-fonte, se o EJB Deployer precisar verificar ou alterar essa configuração, será necesário todo o trabalho para chegar ao código-fonte, inspecioná-lo e alterá-lo.

Principalmente quando a mudança na configuração do deployment é freqüente, é indicado uma separação de responsabilidades bem definida. A configuração deve ficar sob incubência exclusiva do Bean Provider ou do EJB Deployer.

Leitura Recomendada:

Fontes Utilizadas:

SRIGANESH, Rima Patel; BROSE, Gerald; SILVERMAN, Micah. Mastering Enterprise JavaBeans 3.0. Indianapolis - Indiana: Wiley Publishing, Inc, 2006.
Software Deployment

Pequena Introdução ao EJB 3.0

2007-03-23T02:52:00.000-03:00

Enterprise beans podem ser descritos como componentes reutilizáveis que executam rotinas relacionadas à lógica de negócios de um aplicativo, sozinhos ou em conjunto, num ou mais Application Servers. Implementam a tecnologia EJB, que faz parte de um quadro maior chamado Java EE e, na versão 3.0, consiste em duas partes:

A especificação JSR-220, que define as regras para a implementação do suporte a enterprise beans pelos fornecedores de servidores Java EE, de forma a tornar viável o "write once, run anywhere"
Conjunto de interfaces e suas respectivas implementações. Ambos devem seguir os contratos entre componentes e o servidor do aplicativo, definidos pela JSR-220.

Na JSR-220 existem dois tipos de EJB's: session beans e message-driven beans. Session beans executam tarefas para um cliente; podem implementar um web service. Message-drive beans fornecem suporte para processamento assíncrono de requisições de serviços, além das funcionalidades dos sessions beans.

CMP beans foram substituídos pelos JPA entity beans. A JSR-220, no entanto, é compatível com as especificações anteriores, portanto CMP's podem ser utilizados em containeres EJB 3.0, assim como é possível todas as diversas combinações de interações entre cliente, EJB 2.1 e EJB 3.0.

A excitação em torno do EJB 3.0 é motivada graças à simplificação de sua API, se comparado às especificações anteriores:

Interface de objetos e interface home não são mais necessárias
Interfaces para componentes (javax.ejb.SessionBean e javax.ejb.MessageDrivenBean) não são mais necessárias
Utilização de annotations como metadados
Simplificação de API's para acessar o ambiente do bean
Coding-by-exception.

Coding-by-exception é a capacidade dos enterprise e entity beans de assumir um valor padrão para cada metadado. Dessa forma, só é preciso codificar annotations quando seu valor padrão não for apropriado.

Os enterprise beans, na especificação EJB 3.0, são POJO's que, no caso dos session beans, implementam métodos definidos numa business interface local ou remota. A business interface é uma POJI que define os métodos expostos pelo session bean.

Esse conjunto de simplificações, mais a adição dos JPA entity beans, visam facilitar e aumentar a produtividade do desenvolvimento de sistemas distribuídos que utilizam componentes EJB no seu middleware.

Vantagens na utilização de EJB's

Sistemas de informação computacionais distribuídos precisam de uma série de serviços de infra-estrutura (system-level services) para serem viáveis. Entre os também chamados middleware services, porque são comumente requisitados e presentes na camanda do meio, estão:

Invocação Remota de Métodos (RMI). Serviço responsável por conectar uma camada a outra remota, via rede. A requisição de serviço numa camada (e.g. apresentação) é processadas em outra (e.g. negócio)
Balanceamento de Carga. Requisições de clientes por serviços são redirecionadas para servidores com menor carga [de trabalho]
Transparent failover. Se um servidor cair ou ficar indisponível na rede, os clientes são redirecionados de forma transparente para outro servidor em operação
Integração com o back-end. Suporte para persistência de dados em banco de dados e integração com sistemas legados
Gerenciamento de Transações. Proteção à integridade de dados com controle de acesso concorrente e mecanismos para tratamento de excessões (e.g. interrupção brusca em meio a uma transação)
Clustering. O estado de um servidor é replicado para que o cliente possa utilizar outro servidor em caso de queda
Redeployment dinâmico. Capacidade de atualizar um aplicativo, ou seja, realizar um deployment de um ou mais de seus componente, sem precisar reiniciar o servidor
Logging e auditoria. Registro das atividades no servidor de aplicativos, possibilitando a auditoria de eventuais problemas para descobrir a sua causa
Gerenciamento do sistema. Monitoramento do sistema para o caso de falhas graves (fatal errors)
Suporte para múltiplas requisições. Disponibilidade e gerenciamento de múltiplos threads para possibilitar acesso simultâneo dos clientes aos enterprise beans
Processamento assíncrono de requisições (messaging). Maior desacoplamento entre clientes e servidor através de requisições baseadas em mensagens
Gerenciamento do ciclo de vida dos enterprise beans. Componentes são criados e destruídos conforme necessário
Resource pooling. Criação de pool de recursos, como conexões JDBC, e de enterprise beans para fins de reutilização por diversos clientes
Segurança. O acesso aos serviços disponibilizados pelos beans é controlado por metadados específicos
Caching. Armazenamento temporário de dados comumente requisitados por clientes de modo a otimizar a performance do aplicativo
Outros...

O container EJB provê a infra-estrutura necessária para aplicativos distribuídos, liberando o desenvolvedor dessa árdua tarefa para que se concentre na implementação da lógica de negócios, encapsulada em componentes reutilizáveis.

Quando utilizar EJB 3.0 ?

Se entre os requisitos não-funcionais de um aplicativo estiverem escalabilidade, integridade de dados e numerosos clientes, considere utilizar EJB 3.0.

Geralmente, um aplicativo precisa acomodar número crescente de usuários. Nesses casos, os enterpise beans poderão ser distribuídos em diversos servidores, aumentando o desempenho do sistema.

O container EJB tem mecanismos de gerenciamento de transações para preservar a integridade dos dados durante o acesso simultâneo à objetos compartilhados.

Clientes de aplicativos Java EE podem concentrar-se nas rotinas de apresentação, deixando a implementação da lógica de negócio encapsulada nos EJB's. Cliente pode ser JSP, Servlet, rich client (desktop), applet, outro enterprise bean.

Leitura Recomendada:

Fontes Utilizadas:

The Java EE 5 Tutorial
SRIGANESH, Rima Patel; BROSE, Gerald; SILVERMAN, Micah. Mastering Enterprise JavaBeans 3.0. Indianapolis - Indiana: Wiley Publishing, Inc, 2006.
The Java Persistence API - A Simpler Programming Model for Entity Persistence.

Testes de Aceitação em Aplicações Swing

2007-03-22T01:57:00.000-03:00

E aí, galera! Tudo bem com vocês? Meu nome é Daniel Martins, administrador do blog batteries not included. Fui gentilmente convidado pelo Rafael, administrador deste blog, para publicar sobre um assunto de minha escolha. Foi difícil escolher, mas espero que o texto seja de interesse de todos!

Introdução

Levando em consideração que este blog disponibiliza muito material interessante sobre desenvolvimento com Swing, eu acabei optando por não sair muito desse assunto. Decidi escrever sobre um tema que é, ao mesmo tempo, muito importante e pouco comentado pelos desenvolvedores: testes de aceitação em aplicações Swing. É através dos testes de aceitação que podemos simular a utilização do sistema por um usuário e verificar se as reações do sistema correspondem ao esperado.

Acredito que a falta de informação sobre o assunto se deve a uma questão meramente cultural, pois costumamos associar esse tipo de tarefa com trabalho manual, o que era verdade há alguns anos atrás. Entretanto, com o advento das metodologias ágeis, a cada dia surgem novas ferramentas capazes de nos ajudar a automatizar esse processo.

Tipos de Ferramentas

Antes de partir para a apresentação das ferramentas, precisamos aprender um pouco sobre como elas são agrupadas. Basicamente, existem dois tipos de ferramentas para criação e execução de testes de aceitação: as do tipo rec-and-play e as programáveis:

As ferramentas rec-and-play são ferramentas que gravam as ações do usuário com o sistema, permitindo que as mesmas ações sejam reproduzidas de uma forma automatizada;
Já o segundo grupo compreende as ferramentas que fornecem uma API para que o desenvolvedor possa simular as interações do usuário com o sistema.

Optar pela utilização de uma ferramenta de um grupo ou de outro pode impactar positiva ou negativamente no seu projeto. Embora cada ferramenta tenha suas próprias características, podemos indicar algumas vantagens e desvantagens que costumam se aplicar às ferramentas de cada um desses grupos.

Em relação às ferramentas do tipo rec-and-play, a principal vantagem é que não é necessário saber programar para ser capaz de criar e reproduzir os testes. Isso torna qualquer pessoa apta a fazer este trabalho. Além disso, o fato de não se precisar programar os testes torna todo esse processo mais ágil.

Entretanto, a grande desvantagem de ferramentas desse grupo é que os testes se tornam extremamente sensíveis a qualquer modificação na view. Por exemplo, se um determinado teste clica com o mouse em um botão que ficava na posição x da view, e que agora está na posição y, o teste falhará e deverá ser modificado para se adaptar à "nova" view.

Já as ferramentas que estão no segundo grupo são mais confiáveis neste aspecto, sendo necessário modificar os testes apenas em casos mais extremos, como na troca de um componente por outro. A desvantagem é que as ferramentas deste grupo demandam mais esforço na criação dos testes.

Eu particularmente não simpatizo com as ferramentas rec-and-play, pois os testes costumam "quebrar" com muito mais facilidade. Mas devo lembrar que "cada caso é um caso" e a melhor atitude é ponderar os prós e contras de cada tipo de ferramenta antes de fazer sua escolha.

Ferramentas Disponíveis

Agora que já sabemos diferenciar os tipos de ferramentas, nos resta agora conhecer algumas das opções disponíveis:

Jemmy - O Jemmy é uma biblioteca para testes de interfaces gráficas Swing e AWT desenvolvido pelo time do NetBeans. Trata-se de uma ferramenta onde os testes são criados e executados programaticamente, através de uma API bem definida. A documentação ainda é fraca, mas o site está repleto de exemplos de testes, o que já é de grande ajuda.
UISpec4J - Feito em cima do JUnit e pode ser usado para testar interfaces gráficas baseadas em Swing de forma programática. A API fornecida por esta ferramenta é mais simples e intuitiva que a fornecida pelo Jemmy. A má notícia é que, apesar de já estar disponível a algum tempo (desde meados de 2004), existem componentes Swing que não são 100% suportados. Além disso, a ferramenta não é multi-plataforma "de verdade" (alguns testes que fiz não funcionaram no Linux). Em relação a documentação, ela é fraca, mas é possível se virar bem só com os JavaDocs.
Marathon - Esta ferramenta é do tipo rec-and-play e os testes gravados são "convertidos" em scripts Jython, facilitando a modificação dos testes sem que seja necessário recriá-los. Uma coisa legal é que podemos testar qualquer tipo de componente sem que seja necessário trabalho extra (diferentemente do que acontece com o Jemmy e o UISpec4J, por exemplo). A documentação é razoável e dá para se virar sem nenhum problema.
JFCUnit - É uma ferramenta para criação programática de testes de interfaces gráficas Swing, feita como uma extensão ao JUnit. Tudo indica que este é um projeto abandonado, já que o último release foi feito no dia 21 de Dezembro de 2004.
Abbot - O Abbot é uma extensão do JUnit para testes de interfaces gráficas semelhante ao JFCUnit. A diferença é que o projeto não parece estar abandonado.
TestNG-Abbot - O TestNG-Abbot é um projeto cujo objetivo é adaptar o Abbot para rodar sobre o TestNG. A documentação é praticamente inexistente, sendo que as únicas referências que encontrei foram posts em blogs e um artigo no developerworks.com.

É óbvio que existem outras ferramentas além das citadas, inclusive ferramentas pagas. Para mais detalhes, visite esta página.

Mas qual ferramenta escolher?

A função deste artigo não é oferecer um review detalhado sobre cada uma das alternativas, mas sim mostrar quais são essas alternativas. Portanto, a tarefa de descobrir qual ferramenta melhor se adapta às suas necessidades é sua. Minha dica é: crie uma aplicação bem simples nos moldes das que você costuma desenvolver e verifique quais ferramentas fornecem os recursos necessários para testá-la adequadamente.

Em alguns dias, eu publicarei no meu blog um pouco mais sobre o Jemmy. Será mostrado, na prática, como utilizá-lo para testar uma aplicação Swing para conversão de temperaturas.

Bom... eu vou ficando por aqui. Gostaria de agradecer novamente ao Rafael por me oferecer a oportunidade de escrever aqui. Valeu mesmo!

Um abração a todos e bons testes!

Look and Feel - Você Conhece o Nimbus?

2007-03-16T02:23:00.000-03:00

Nimbus é o look and feel do Java Desktop System, implementado como tema GTK nos últimos pre-releases do Solaris 11. Recentemente, um projeto open-source foi criado para tornar o Nimbus o futuro cross-plataform-look-and-feel para o Swing.

É implementado através do Synth e está disponível apenas para Java SE 6. Uma versão compatível com J2SE 5 é esperada apenas depois do lançamento de uma versão mais concreta para Java SE 6, prevista para o final de 2007.

Prazer, Eu Sou Nimbus!

O Nimbus ainda está em estágio preliminar (early alpha), mas já é possível conhecê-lo um pouco melhor através do demo desenvolvido por Richard Bair.

Abaixo estão imagens de JButton's, JCheckBox'es e JRadioButton's com imagens. Os botões da esquerda estão sob o ponteiro do mouse, os do centro estão "intocados" e os da direita, selecionados.

Buttons

Check Boxes

Radio Buttons

So What ?

O objetivo do projeto Nimbus - ambicioso - é ser o melhor look and feel para Swing, competir com o Aero e o Aqua e ser a principal referência como Synth skin (i.e. implementação de look and feel baseado no Synth).

Entre suas inovações estarão facilidades para escolher entre três tamanhos diferentes de widgets e uso do Timing Framework para criação de efeitos visuais.

Matenha-se informado sobre Nimbus em:

Veja mais sobre look and feel em:

Esse artigo bebe das fontes:

SwingX - Aviso Importante

2007-03-15T05:06:00.000-03:00

Os novos componentes SwingX são interessantes, estáveis em sua maioria e podem acrescentar valor ao software e produtividade no seu desenvolvimento. Porém, é importante ressaltar esse aviso disponível no FAQ do SwingLabs:

Todos os componentes do projeto SwingLabs [do qual o SwingX faz parte] são focados para uso em ambiente de produção. Entretanto, a Sun não oferece qualquer garantia de suporte e desenvolvimento presente ou futuro para qualquer um desses componentes.

Esse aviso tem implicações importantes. Por exemplo, a API do JXStatusBar foi atualizada no repositório do projeto em relação ao SwingX 0.8.0. Outro exemplo é a aparição do componente JXErroPane no lugar de JXErrorDialog, que foi "extinto" sumária e silenciosamente.

Portanto, tenha planejamento e cuidado ao utilizar os componentes SwingX.

Veja outros componentes SwingX em:

SwingX

Veja também:

Sol - Um Reator de Fusão Nuclear

2007-03-13T16:19:00.000-03:00

As estrelas são um reator de fusão nuclear natural. Estão sempre em constante instabilidade, sob os domínios da força gravitacional e do empuxo resultante da energia liberada pela fusão nuclear.

A força gravitacional atrai toda a matéria da estrela para o seu centro, onde a temperatura e a pressão (15 milhões °C e 1 milhão atm, respectivamente) chegam ao ponto de fundir os átomos de hidrogênio em hélio. Nesse processo, 4 núcleos de hidrogênio fundem-se formando 1 núcleo de hélio, com 2 prótons e 2 nêutrons.

Por outro lado, a energia gerada pela fusão nuclear empurra a matéria para fora da estrela. Uma força contrabalança a outra: a gravitacional evita que a matéria se dissipe no espaço, e o empuxo gerado pela fusão impede que a estrela se contraia até entrar em colapso.

O Sol

Com a fusão nuclear, para cada 45 prótons, são gerados 55 nêutrons. Assim que um próton é transformado em nêutron, sua carga elétrica é despejada do núcleo em fusão junto com uma quantia de massa equivalente a de um elétron. Essa partícula é chamada de pósitron, ou anti-elétron, já que se trata de um elétron com carga positiva.

Esses pósitrons colidem com os elétrons presentes no Sol, resultando num aniquilamento mútuo, onde ambos são convertidos em raio gama - fótons energéticos que não possuem nem carga elétrica, nem massa.

O Sol converte 600 bilhões de quilos de hidrogênio em 595,8 bilhões de quilos de hélio por segundo. Os 4,2 bilhões de quilos restantes são transformados na radiação gerada durante o aniquilamento mútuo.

Sopa Eletrônica

No centro do Sol, a pressão supera a força eletromagnética na elétrosfera dos átomos, o que faz com que os átomos implodam, gerando uma sopa de elétrons.

Os elétrons, nesse fluído eletrônico, ocupam muito menos espaço do que ocupariam normalmente como parte da elétrosfera num átomo intacto.

Com os elétrons e prótons mais próximos, a resistência eletromagnética à pressão exercida pela força gravitacional aumenta. No entanto, os prótons, desprotegidos pela ausência de um "envoltório" e a 15 milhões °C, movem-se a uma velocidade altíssima, colidindo uns nos outros. É durante essas colisões que ocasionalmente os prótons se fundem, formando um núcleo maior e liberando radiação.

Referência:

Isaac Asimov

Turbinando o Anti-Aliasing

2007-03-12T09:26:00.000-03:00

O Java SE 6 trouxe várias melhorias para a construção de clientes ricos (desktop) e, entre essas mudanças está o uso de anti-aliasing. O Java 5 tem o anti-aliasing desabilitado por padrão, o que contribui para um visual desagradável. Mas, mesmo ao utilizar o Java SE 6, é possível turbinar o anti-aliasing do aplicativo.

Para isso, sobrescreva o método paintChildren(Graphics g) como abaixo:

@Override
public void paintChildren(final Graphics g) {
.....final Graphics2D g2 = (Graphics2D)g;
.....g2.setRenderingHint(
....................RenderingHints.KEY_ANTIALIASING,
....................RenderingHints.VALUE_ANTIALIAS_ON);
.....super.paintChildren(g2);
}

O Antes e o Depois

Aqui está um JLabel sem anti-aliasing (clique na figura para ampliar).

A seguir, o anti-aliasing está habilitado (clique na figura para ampliar).

Nota Pessoal (What Am I Doing?)

Na Internet, outras pessoas - inclusive o pessoal do Swing Hacks - sugerem inserir o argumento
-Dswing.aatext="true" no comando de inicialização do aplicativo para habilitar o anti-aliasing sem tocar no código-fonte.

Ou então, habilitá-lo através de System.setProperty("swing.aatext", "true") .

Não sei que espécie de mágica eu faço, pois não tive sucesso em habilitar o anti-aliasing dessa forma.

Fonte: Swing Hacks

SwingX - JXErrorPane

2007-03-08T13:14:00.000-03:00

O objetivo do JXErrorPane é mostrar mensagens de erro, advertências e a ocorrência de fatal errors aos usuários. JXErrorPane tem o foco em erros irrecuperáveis.

Pode ser configurado para permitir ao usuário relatar o ocorrido ao desenvolvedor do software em questão através de um botão Report.

O usuário pode ver os detalhes relacionados ao erro através do botão Details.

JXErrorPane in Action (1)

É simples e direto utilizar o JXErrorPane. Veja o código abaixo.

try {
.....// Alguma coisa deu errado aqui.
} catch (Exception Ex) {
.....// ErrorInfo encapsula dados sobre o erro.
.....ErrorInfo info = new ErrorInfo(
....................// Título da janela.
...................."Erro ao Tentar Navegar para o Item.",
....................// Breve descrição do erro.
...................."Esse item não existe.",
....................// Descrição detalhada do erro.
....................null,
....................// Categoria, serve para identificar onde o erro ocorreu.
....................// É recomendável utilizar o mesmo nome que teria utilizando logging.
...................."org.testswingx.jxerrorpane",
....................// Throwable, utilizado para obter informações sobre o erro úteis para os desenvolvedores.
....................ex,
....................// Nível do erro.
....................org.jdesktop.swingx.error.ErrorLevel.SEVERE,
....................// O estado do aplicativo no momento em que o erro ocorreu.
....................null);
.....JXErrorPane.showDialog(null, info);
}

Basta encapsular os detalhes do erro em org.jdesktop.swingx.error.ErrorInfo e utilizar o método showDialog(Component owner, ErrorInfo info) de JXErrorPane.

Pode ser melhor mostrar ao usuário uma mensagem mais amigável que o stack trace do erro.

try {
.....// Alguma coisa deu errado aqui.
} catch (Exception Ex) {
.....ErrorInfo info = new ErrorInfo(
..................."Erro ao Tentar Navegar para o Item.",
..................."Esse item não existe.",
....................// Mensagem mais amigável ao usuário, pode inclusive contar com tags html.
..................."Por favor, contate o administrador do sistema.",
..................."org.testswingx.jxerrorpane",
....................null,
....................org.jdesktop.swingx.error.ErrorLevel.SEVERE,
....................null);
.....JXErrorPane.showDialog(null, info);
}

Em situações críticas, é possível encerrar a execução do aplicativo. Basta ajustar o nível de erro em ErrorInfo para ErrorLevel.FATAL.

JXErrorPane in Action (2)

A funcionalidade de maior destaque do JXErrorPane é a possibilidade do usuário do aplicativo relatar o erro ao desenvolvedor do software por e-mail, RSS, ou o que for mais adequado, através de um botão Report.

Basta implementar o método reportError(ErrorInfo info) da interface org.jdesktop.swingx.error.ErrorReporter, e chamar o método setErrorReporter(ErrorReporter reporter) numa instância de JXErrorPane.

private final JXErrorPane errorPane = new JXErrorPane();
. . .
errorPane.setErrorReporter(new EmailErrorReporter());
errorPane.setErrorInfo(info);
JXErrorPane.showDialog(null, errorPane);

Veja outros componentes SwingX em:

SwingX

Referências:

Mais Widgets para Você, Parte 2 - Flamingo

2007-03-07T02:39:00.000-03:00

Além das extensões Swing já comentadas nesse blog, SwingX e L2FProd, há outra digna de menção. Trata-se do Flamingo, disponível sob a licença BSD. O responsável por esse projeto é Kirill Grouchnikov, o criador e mantenedor do Substance Look and Feel.

Alguns componentes Flamingo são inspirados nas inovações da interface gráfica Aero, do Windows Vista, como o widget JRibbon. A última versão lançada, Flamingo 1.1, conta com os componentes:

Abaixo, JRibbon in action em flamingo.dev.java.net/docs/jribbon.html.

Veja outras extensões Swing em:

Referência:

Flamingo (Java.net)

Nota: Os demos dos componentes JRibbon e Bread Crumb Bar são de autoria de Kirill Grouchnikov e estão disponíveis em flamingo.dev.java.net.

Desktop API: Integração entre Aplicativos Java e o Sistema Operacional Nativo

2007-03-05T01:12:00.000-03:00

A Desktop API, do Java SE 6, permite que softwares baseados na tecnologia Java interajam com aplicativos padrões do sistema operacional nativo; ou seja, aplicativos que estão associados com certas extensões de arquivos numa determina plataforma.

Isso equivale a dizer que o software que utiliza a Desktop Api pode:

executar o navegador de Internet padrão com determinado URI (Uniform Resource Identifier)
executar o cliente de e-mail padrão, opcionalmente com determinado mailto URI
executar um aplicativo registrado no sistema operacional hospedeiro, abrir, editar ou imprimir um arquivo associado a esse aplicativo.

Desktop API in Action

Ao clicar no hyperlink Pedir Suporte desse aplicativo, o cliente de e-mail padrão abre uma janela de composição de e-mail com o endereço do suporte técnico e o título "Pedido de Suporte".

O hyperlink é criado automaticamente após adicionar o Action AskForSuporte num JXTaskPane.

public class AskForSuporte extends AbstractAction{
.....// O ator pincipal desse artigo. Se atuar bem, ganha o Oscar!
.....private Desktop desktop;
.....private URI uri;
.....// A URI maito.
.....private static final String MAILTO =
...............mailto:rafaelfiume_fatec@yahoo.com.br?subject=Pedido%20de%20Suporte%20Técnico";
.....// O rótulo do hyperlink.
.....private static final String NAME = "Pedir Suporte";
.....private static final String ACTION = "pedir_suporte";
.....// O tooltip text do hyperlink.
.....private static final String SHORT_DESCRIPTION = "Requisita suporte para o sistema";

.....public AskForSuporte() {
..........super();
..........putValue(Action.NAME, NAME);
..........putValue(Action.SHORT_DESCRIPTION, SHORT_DESCRIPTION);
..........putValue(Action.ACTION_COMMAND_KEY, ACTION);
..........// Verifica se a a plataforma em questão provê suporte para a classe Desktop.
..........if (Desktop.isDesktopSupported()) {
...............desktop = Desktop.getDesktop();
..........}
..........try {
...............uri = new URI(MAILTO);
..........} catch (URISyntaxException ex) {
...............ex.printStackTrace();
..........}
.....}

.....public void actionPerformed(final ActionEvent e) {
..........if (desktop != null) {
...............// Verifica se a plataforma em questão provê suporte para essa ação.
...............if (desktop.isSupported(Desktop.Action.MAIL)) {
....................try {
........................./* Finalmente, o ator principal entra em cena.
.........................* Abre a janela de composição do cliente de e-mail padrão
.........................* com os campos da mensagem especificados pela mailto URI. */
.........................desktop.mail(uri);
....................} catch (IOException ex) {
.........................ex.printStackTrace();
....................}
...............}
..........} else {
.............../* Oh, my!! O sistema operacional não provê suporte,
...............* ou para a classe Desktop, ou para a Desktop.Action.MAIL. */
...............JOptionPane.showMessageDialog(
..............................null,
.............................."Impossível executar o cliente de e-mail padrão do sistema.",
..............................Atenção",
..............................JOptionPane.WARNING_MESSAGE);
..........}
.....}
}

Veja também:

Outras funcionalidades do Java SE 6 em:

Referências:

SwingX - JXList

2007-03-02T03:03:00.000-03:00

Extensão de JList, JXList fornece suporte para highlighting e rollover, além de filtering e sorting. Pode conter elementos atuando como hyperlink.

JXList in Action (1)

O Highligter muda a cor de fundo das linhas da JXList, ditando regras sobre como essas linhas devem ser renderizadas. A figura abaixo mostra um JXList sem highlighting.

Para habilitar o mecanismo de highlighting, use algo parecido com o seguinte código:

JXList list = new JXList();
/* loadModel() é um factory cuja função é retornar uma instância de uma subclasse de DefaultListModel. */
list.setModel(loadModel());
list.setHighlighters(
.....new HighlighterPipeline(new Highlighter[]{ AlternateRowHighlighter.quickSilver })
);

AlternateRowHighlighter é subclasse de Highlighter e possui algumas constantes Highlighter's pré-definidas. HighlighterPipeline é instanciado com uma matriz unidimensional de Highlighter's. A próxima figura mostra o resultado.

O efeito de sobressair-se que uma linha, num certo componente, apresenta quando o cursor do mouse está sobre essa mesma linha é chamado rollover.

// Obtém o gerenciador de Highlighter's para adicionar mais um RolloverHighlighter.
list.getHighlighters().addHighlighter(new RolloverHighlighter(Color.BLUE, Color.ORANGE));
list.setRolloverEnabled(true);

Na figura abaixo, o cursor do mouse está sobre o Item 5.

JXList in Action (2)

Implementar filtro numa JXList é simples e direto. Os filtros estão desativados por padrão no SwingX 0.8.0 porque podem causar instabilidade.

// Habilita filtro, que está desabilitado por padrão.
list.setFilterEnabled(true);
// Configura o filtro.
PatternFilter patternFilter = new PatternFilter(null, 0, 0);
FilterPipeline filterPipeline = new FilterPipeline(new Filter[] { patternFilter });
list.setFilters(filterPipeline);
// Filtro será aplicado sempre que o método setPatern for chamado.
patternFilter.setPattern(pattern);

Na figura abaixo, aparecem apenas os elementos da JXList que contenham o número 1.

Veja outros componentes SwingX em:

SwingX

Referências:

Mais Widgets para Você - L2FProd

2007-03-01T05:02:00.000-03:00

Swing tem componentes gráficos úteis, mas há outros faltando. Além dos widgets SwingX, há várias extensões Swing, algumas comerciais e proprietárias, outras livres. L2FProd.com Common Components ajuda a preencher a lacuna dos componentes faltantes no Swing. O responsável por esse projeto é Frédérick Lavigne, que, entre outros trabalhos, está envolvido com o SwingX e é criador dos look and feel's Synth e SkinLF.

Requer ao menos JDK 1.4.2 e está disponível sob a Apache Software Lincense.

Teste alguns componentes L2FProd através do demo disponibilizado no site do projeto.

Componentes L2FProd

Componentes em comum com SwingX:

JCollapsiblePane (equivale ao JXCollapsiblePane)
JLinkButton (equivale ao JXHyperlink)
JTaskPane (equivale ao JXTaskPaneContainer)
JTaskPaneGroup (equivale ao JXTaskPane)

Componentes de destaque:

JButtonBar
JDirectoryChooser
JFontChooser
JOutlookBar
PropertySheetPanel
PropertySheetTable

Qualquer semelhança não é mera coincidência

Frédérick Lavigne é committer do projeto SwingLabs e responsável pelos widgets do L2FProd, portanto não é estranho que os dois projetos tenham alguns componentes em comum.

L2FProd em IDE's

Assim como SwingX, componentes L2FProd podem ser adicionados à paleta de componentes de uma IDE e usados para a construção de GUI's.

O processo para ter o L2FProd Common Componentes na paleta do NetBeans é idêntico ao explicado no artigo SwingX & NetBeans IDE, mudando apenas a biblioteca: substitua o SwingX pelo L2FProd.

Contribua Você Também!

L2FProd Common Components requer contribuições, tanto com a participação no desenvolvimento da biblioteca, quanto na forma de donações.

Inscreva-se no Java.net e junte-se ao projeto através de https://l2fprod-common.dev.java.net. Para acessar o código-fonte no repositório do projeto, veja Acesso ao Repositório do Java.net com o NetBeans. No campo Module, digite l2fprod-common.

Veja componentes SwingX em:

SwingX

Referências:

Kit de Detecção de Mentiras

2007-02-28T22:47:00.000-03:00

Retirado do livro O Mundo Assombrado pelos Demônios, de Carl Sagan, esse Kit de Detecção de Mentiras é uma ferramenta valiosa para ajudar a separar o joio do trigo quando estamos debatendo e tentando entender diferentes proposições, o que nos levará a melhores decisões, com bases mais sólidas.

O que fazer ao avaliar uma afirmação

Obter confirmação independente dos fatos. Partidários de diversas posições devem tentar chegar a uma conclusão, da forma mais imparcial possível.
Considerar mais de uma hipótese (manter a mente aberta). Não se apegar logo à primeira idéia que pareça estar certa.
Tentar se desprender das próprias idéias. O importante é chegar ao melhor resultado possível. Idéias, próprias ou de outrem, são apenas um estágio intermediário, um meio para um fim.
Se algo que está sendo afirmado pode ser medido, esse algo deve ser quantificado. O que é vago e qualitativo é passível de muitas explicações.
Caso haja uma cadeia de argumentos, todos os elos da cadeia devem ser fortes, e não apenas a maioria deles.
Utilizar a Navalha de Occam: se duas ou mais hipóteses explicarem um fato com igual eficácia, deve-se ficar com a hipótese mais simples.
A pergunta "essa hipótese pode ser falseada ?" deve sempre ser feita. Proposições que não podem ser testadas valem menos do que as que podem.

O que não fazer

Aceitar argumentos de autoridades. Autoridades cometeram erros no passado e cometerão no futuro. Exemplo: Trabalho a trinta anos nessa área, e você ainda quer discutir comigo?
Atacar o argumentador e não o argumento. Ex: O que importa o que diz Bill Gates sobre Linux, já que seu interesse é promover o Windows.
Argumento das causas adversas. Ex: Devemos expor ao ridículo aqueles que não sabem se comportar, caso contrário os novos visitantes apresentarão o mesmo tipo de mal comportamento.
Apelo a ignorância, afirmando que qualquer coisa que não foi provada verdadeira deve ser falsa, e vice-versa. Como Carl Sagan gostava de dizer, a ausência de evidência não é evidência da ausência. Ex: Não há sinal de vida extraterrestre, portanto não existem extraterrestres.
Alegação especial, geralmente utilizada para salvar uma proposição com dificuldades teóricas. Ex: Pergunta: Como posso acreditar que alguém possa prever meu futuro baseado na posição das estrelas, ou em "vozes do além"? Alegação especial: Entre o céu e a Terra há mais coisas do imaginamos.
Petição de princípio (ou supor a resposta). Ex: Precisamos reduzir a idade penal para dezesseis anos se quisermos reduzir a criminalidade em nossso país. Reduzir a idade penal realmente diminui a criminalidade? Existem estudos demonstrando essa relação de causa e efeito?
Seleção das observações (de acordo com Francis Bacon, contar os acertos e esquecer os fracassos). Ex: Ao consultar um vidente, horóscopo, cabala, ou algo do gênero, lembrar-se de todos os acertos, mas desconsiderar todas as previsões furadas.
Praticar a estatística dos números pequenos. Ex: Dizem que uma entre cinco pessoas no mundo são chinesas. Mas é claro que isso não é verdade, pois conheço centenas de pessoas e nenhuma delas é chinesa.
Compreensão errônea da natureza estatística. Ex: O presidente norte-americano Dwight Eisenhower espantando-se ao saber que metade dos norte-americanos tem inteligência abaixo da média.
Incoerência. Ex: Prudentemente armar-se até os dentes para se defender de potenciais nações inimigas, mas ignorar os danos ambientais e suas consequências, porque "não são comprovadas" (vide Iraque vs. New Orleans).
Non sequitor (em português, não se segue). Ex: Nossa empresa (ou tecnologia, nação, ou o que for) prevalecerá, pois estamos trabalhando muito duro para isso. Acontece que as outras empresas (tecnólogos, nações) estão fazendo o mesmo.
Post hoc, ergo propter hoc (em português, aconteceu após uma fato, logo foi por ele causado). Ex: Não existiam armas nucleares antes das mulheres terem direito ao voto.
Pergunta sem sentido. Ex: Você será tão bom presidente quanto eu no futuro?
Dicotomia falsa (exclusão do meio termo). Exemplos: Brasil, ame-o ou deixe-o. Ou você está do meu lado, ou contra mim.
Curto prazo vs. longo prazo (subconjunto da dicotomia falsa). Ex: Para que investir em ciência e tecnologia se há pessoas que nem têm o que comer?
Declive escorregadio (relacionado à exclusão do meio-termo). Exemplos: Se dermos a mão, logo irão querer nossos braços. Se cedermos um passo agora, seremos aniquilados depois.
Confusão de correlação e causa. Ex: Estudos mostram que a proporção de homossexuais que possuem curso superior é maior do que os que não o possuem. Ou seja, estudar torna a pessoa homossexual.
Espantalho - caricaturar uma posição para tornar mais fácil o ataque. Ex: Você é um executivo de uma grande empresa do setor financeiro. Pessoas como você só se preocupam em lucrar. Não temos que ouvir suas opiniões sobre movimentos sociais.
Meia-verdade (evidência suprimida). Ex: O mundo será um lugar melhor sem um tirano como governador de uma nação geopoliticamente explosiva. Mesmo que após a queda desse tirano sobrevenha uma guerra civil?
Palavras equívocas (eufemismo). Substituir palavras ou expressões desgostosas para um público por outras mais suaves. Políticos e empresas freqüentemente rebatizam seus produtos com novos nomes para que voltem a ser aceitável para esse público.

Quando bem aplicado, o Kit de Detecção de Mentiras pode fazer grande diferença, inclusive para avaliarmos nossos próprios argumentos.

Quem é Carl Sagan ?

Professor de astronomia e ciências espaciais na Cornell University e autor de dezenas de livros e artigos, o norte-americano Carl Sagan dedicou a vida ao desenvolvimento e divulgação da ciência, recebendo diversos prêmios e medalhas por essa contribuição. Preocupado com o vírus do analfabetismo científico, que faz com que hoje muitos acreditem em explicações místicas e ficções, Sagan reafirma o poder positivo e benéfico da ciência e da tecnologia, revidando com informações surpreendentes, transmitidas de forma clara e irreverente.

Tradução de Rosaura Eichemberg.

Tray Icon para o Seu Aplicativo

2007-02-26T03:50:00.000-03:00

System tray, ou ainda, Bandeja do Sistema em bom português, é a área do desktop onde usuários podem acessar programas continuamente em execução. É denominado Taskbar Status Area no Windows, Notification Area, no GNOME, e System Tray, no KDE.

O system tray contém um ou mais tray icons, no Java SE 6, representados pela classe TrayIcon. TrayIcon pode ter imagem, tooltip text, menu popup e vários listeners associados a ele.

TrayIcon in Action

O ModelMat usa a classe TrayIconManager para gerenciar a interação desse software com o system tray do desktop em que está rodando.

public class TrayIconManager {
.....// Única instância dessa classe.
.....private static TrayIconManager trayIconManager;
.....// A estrela desse artigo: o Tray Icon!
.....private static TrayIcon trayIcon;
.....// O ícone que aparecerá no System Tray.
.....private static Image icon;
.....// A "bandeja do sistema".
.....private static SystemTray systemTray;
...../* Action Listener para o Tray Icon.
......* Um action event é disparado quando há um duplo clique no Tray Icon. */
.....private static TrayIconActionListener trayIconActionListener;
.....// O popup menu do tray icon.
.....private static PopupMenu popup;
.....// Itens do popup menu.
.....private static final MenuItem menuTip = new MenuItem();
.....private static final MenuItem menuSobre = new MenuItem();
.....private static final MenuItem menuSair = new MenuItem();

.....private TrayIconManager() {
..........super();
.....}

.....public static void setTrayIcon() {
..........synchronized (TrayIconManager.class) {
...............if (trayIconManager == null) {
....................trayIconManager = new TrayIconManager();
...............}
..........}
..........// Verifica se o sistema suporta system tray.
..........if (SystemTray.isSupported()) {
...............// Obtém system tray.
...............systemTray = SystemTray.getSystemTray();
...............icon = Toolkit.getDefaultToolkit().getImage(
..............................TrayIconManager.class.getResource("md1.gif"));
...............popup = new PopupMenu();
...............// Inicializa tray icon.
...............trayIcon = new TrayIcon(icon, "Double-click to maximize/minimize the software", popup);
...............// O ícone deve se enquadrar na bandeja do sistema.
...............trayIcon.setImageAutoSize(true);
...............// Adiciona um ActionListener ao tray icon.
...............trayIconActionListener = new TrayIconActionListener();
...............trayIcon.addActionListener(trayIconActionListener);
...............// Configura menu popup.
...............menuTip.setLabel("Tip of the Day");
...............menuTip.addActionListener(new ShowTipOfTheDay());
...............popup.add(menuTip);
...............menuSobre.setLabel("About ");
...............menuSobre.addActionListener(new ShowAboutDialog());
...............popup.add(menuSobre);
...............popup.addSeparator();
...............menuSair.setLabel("Exit");
...............menuSair.addActionListener(new ExitApplication());
...............popup.add(menuSair);
...............// Adiciona o tray icon no system tray.
...............try {
....................systemTray.add(trayIcon);
...............} catch (AWTException ex) {
....................ex.printStackTrace();
...............}
..........} else {
...............// Ops! A plataforma não provê suporte para system trays.
...............// Fazer algo aqui, como registrar num arquivo de log.
..........}
.....}

.....private class TrayIconActionListener implements ActionListener {
..........public void actionPerformed(final ActionEvent e) {
...............trayIcon.displayMessage(
..............................Oh my!","You double-clicked the tray icon!", TrayIcon.MessageType.INFO);
..........}
.....}

.....private static class ShowTipOfTheDay implements ActionListener {
..........public void actionPerformed(final ActionEvent e) {
...............TipOfTheDay.show(null, true);
..........}
.....}

.....private static class ShowAboutDialog implements ActionListener {
..........public void actionPerformed(final ActionEvent e) {
...............AboutDialog.showDialog();
..........}
.....}

.....private static class ExitApplication implements ActionListener {
..........public void actionPerformed(final ActionEvent e) {
...............System.exit(0);
..........}
.....}
}

A classe principal do sistema, org.modelmat.main.ModelMat, só precisa chamar TrayIconManager.setTrayIcon() para ter o seu tray icon devidamente configurado no system tray do desktop.

Leitura Recomendada:

Fontes Utilizadas:

SwingX - JXGlassBox

2007-02-23T15:45:00.000-02:00

JXGlassBox é, de acordo com sua documentação,

um componente usado para mostrar conteúdo translúcido na interface gráfica para o usuário. Esse componente e todo o seu conteúdo será mostrado com o valor especificado na propriedade de translucência alpha.

JXGlassBox In Action

O componente de boas-vindas desse aplicativo esconde o calendário do usuário. Ao clicar no ícone, um hyperlink com a figura de calendário, o JXGlassBox contendo o JXMonthView aparece na GUI.

O JXGlassBox apenas "se esconde" novamente quando o usuário clica nele. Perceba como é translúcido.

Segue o código relevante para utilizar o JXGlassBox dessa forma:

JXGlassBox glassBox = new JXGlassBox();
JXMonthView monthView = new JXMonthView();
glassBox.setLayout(new BorderLayout());
glassBox.add(monthView, BorderLayout.CENTER);
// Adiciona borda DropShadow no glassBox.
glassBox.setBorder(new DropShadowBorder());
// Cria hyperlink.
JXHyperlink hCalendario = new JXHyperlink();
// Adiciona listener ao hyperlink.
hCalendario.addActionListener(new ActionListener() {
.....public void actionPerformed(ActionEvent evt) {
..........calendarioActionPerformed(evt);
.....}
});
// Adiciona listener ao monthView.
monthView.addMouseListener(new MouseAdapter() {
.....public void mouseClicked(MouseEvent evt) {
..........monthViewMouseClicked(evt);
.....}
});

. . .

// Faz com que o glassBox apareça quando o usuário clicar no hyperlink.
private void calendarioActionPerformed(ActionEvent evt) {
.....Container glassPane = (Container) getRootPane().getGlassPane();
.....// Faz com que apenas um JXGlassBox seja visto por vez.
.....Component glassPaneChildren[] = glassPane.getComponents();
.....for(int i = 0; i < glassPaneChildren.length; ++) {
..........glassPaneChildren[i].setVisible(false);
..........glassPane.remove(glassPaneChildren[i]);
.....}
.....Point p = SwingUtilities.convertPoint(this, hCalendario.getX(), hCalendario.getY(), null);
.....glassBox.showOnGlassPane(glassPane, p.x, p.y);
.....glassBox.setVisible(true);
}

// Faz com que o glassBox desapareça quando o usuário clicar no monthView.
private void monthViewMouseClicked(MouseEvent evt) {
.....glassBox.setVisible(false);
}

JXGlassBox nas mãos de desenvolvedores criativos pode adicionar muito valor à interface gráfica de um aplicativo Swing.

Veja também:

Veja outros componentes SwingX em:

SwingX

Referências:

org.jdesktop.swingx.JXGlassBox
Código-fonte do Demo do SwingX

Splash Screen

2007-02-21T01:50:00.000-02:00

Quando fui mostrar um dos primeiros softwares que fiz em Java para um colega da faculdade, logo veio a pergunta: "e aquela telinha que aparece enquanto o aplicativo está carregando" ?

Era a splash screen.

Sinceramente, eu nem havia pensado nisso, então perguntei se ele achava a splash screen deveras importante. A resposta: "Claro"! Eu estava preocupadíssimo com a integridade dos dados, principalmente quando houvesse acesso simultâneo ao software através de vários clientes e ele me cobra uma splash screen?!

Ok! Como ele estava fazendo o papel de um potencial cliente, resolvi colocar a splash screen no aplicativo. Newbie total, quase perdi um churrasco no Sábado para conseguir implementar essa splash screen e ainda tive que contar com [muita] ajuda do Google e de outros programadores que disponibilizaram código na Web.

Além de quase perder o churrasco, tive que aturar outro colega, desenvolvedor .NET, tirar onda pela dificuldade que tive. "Ahahaha! Com .Net é só selecionar o arquivo de imagem e pronto!" Confesso que fiquei com inveja...

Seus problemas acabaram!

Isso tudo foi antes do Java SE 6.

Se o aplicativo é iniciado a partir da linha de comando ou atalho, basta utilizar a opção -splash:

java -splash:app_splash_screen.gif Application

Se o aplicativo estiver empacotado num arquivo .JAR, inclua a opção SplashScreen-Image: no MANIFEST.mf. Especifique o caminho para a imagem que servirá como splash screen, que por sua vez deverá estar nesse arquivo .JAR.

SplashScreen-Image: org/modelmat/resources/images/modelmat.gif

E não é só isso...

Utilizando AWT ou Swing para implementar a splash screen, a JVM, AWT, provavelmente Swing e talvez até bibliotecas de terceiros precisavam ser inicializadas para que a splash aparecesse.

Além da facilidade, a splash screen no Java SE 6 irá aparecer muito antes porque não precisa esperar todo esse startup.

Leitura Recomendada:

Fonte Utilizada:

New and Updated Desktop Features in Java SE 6, Part 1: Splash Screens

SwingX - JXCollapsiblePane

2007-02-19T10:36:00.000-02:00

JXCollapsiblePane extende as funcionalidades de JPanel, acrescentando a capacidade de retração / expansão de sua área de conteúdo, com animação e efeitos do tipo fade-in / fade-out.

A documentação do JXCollapsiblePane tem um exemplo para entender como utilizar JXCollapsiblePane. Os métodos importantes para seu manuseio são:

setAnimated() / isAnimated(), que controlam a animação fade-in / fade-out.
setCollapsed() / isCollapsed(), que controlam a retração / expansão do painel.

JXCollapsiblePane conta com um Action pronto para uso, que retrai / expande esse componente. Para obtê-lo use:

JXCollapsiblePane collapsiblePane = new JXCollapsiblePane();
Action action = collapsiblePane.getActionMap().get("toggle");

JXCollapsiblePane in Action

Na figura abaixo, o painel de listagem dos produtos está retraído.

Após clicar no botão de listagem, o painel começa se expandir.

Finalmente, os "itens cadastrados" tornam-se visíveis.

Veja outros componentes SwingX em:

Referência:

org.jdesktop.swingx.JXCollapsiblePane

Do JGoodies para Você: Um Painel com Barra de Título Gradiente

2007-02-16T04:46:00.000-02:00

Uma alternativa ao JXTitledPanel, componente SwingX, é o SimpleInternalFrame do JGoodies. Na figura abaixo, o aplicativo demo do JGoodies, Skeleton Pro, faz uso de SimpleInternalFrame.

SimpleInternalFrame consiste numa área de conteúdo e uma área de título em cores degradê, com ícone e barra de ferramenta opcionais e borda do tipo drop shadow.

A classe SimpleInternalFrame está no pacote com.jgoodies.uif-lite.panel, encontrada na pasta src/examples/demo/ da distribuição Looks 2.0. Copie a classe no seu projeto, ou crie um arquivo JAR contendo a classe e adicione-a ao classpath do aplicativo.

Vantagens

As vantagens do SimpleInternalFrame sobre o JXTitlePanel são:

SimpleInternalFrame é licenciado sob BSD, enquanto os componentes SwingX o são sob LGPL
SimpleInternalFrame funciona perfeitamente com o Substance Look and Feel, enquanto o JXTitledPanel não funciona
SimpleInternalFrame configura as cores de sua barra de título gradiente automaticamente, de acordo com o look and feel utilizado pelo aplicativo; é preciso configurar manualmente as cores da barra de título do JXTitlePanel.

A desvantagem é:

Difícil integração com a Matisse - o construtor de interfaces gráficas do NetBeans.

Veja também:

SwingX

Referência:

Eclipse-like Panel: JGoodies SimpleInternalFrame

SwingX - JXTaskPaneContainer

2007-02-15T04:31:00.000-02:00

JXTaskPaneContainer é feito sob medida para JXTaskPane's que, embora possam ser adicionados em qualquer container, possuem um look and feel mais parecido com o sistema operacional nativo quando estão sobre o JXTaskPaneContainer.

É aconselhável que o JXTaskPaneContainer esteja contido num JScrollPane para que a barra de rolagem vertical apareça nos casos onde o JXTaskPaneContainer não possa ser completamente visível.

Configuração

JXTaskPaneContainer possui seis look and feel's diferentes:

Metal
Windows Classic
Windows Luna
Windows Homestead
Windows Silver
Glossy

Veja o demo do SwingLabs para melhor conhecer os seis tipos de L&F's.

Em alguns casos, é possível configurar o JXTaskPaneContainer programaticamente para alterar o look and feel padrão.

Metal

Adicione esse código na classe que contém o objeto JXTaskPaneContainer.

LookAndFeelAddons.setAddon(MetalLookAndFeelAddons.class);
// Se a versão da JVM for 5.0 ou superior...
UIManager.getLookAndFeelDefaults().put(JXTaskPane.uiClassID,
..............."org.jdesktop.swingx.plaf.misc.GlossyTaskPaneUI");

Windows Classic

Adicione esse código na classe que contém o objeto JXTaskPaneContainer.

UIManager.put("win.xpstyle.name", null);
LookAndFeelAddons.setAddon(WindowsClassicLookAndFeelAddons.class);

Windows Luna

Adicione esse código na clas... Bem, você já deve saber.

UIManager.put("win.xpstyle.name", "luna");
LookAndFeelAddons.setAddon(WindowsLookAndFeelAddons.class);

Windows Homestead

UIManager.put("win.xpstyle.name", "homestead");
LookAndFeelAddons.setAddon(WindowsLookAndFeelAddons.class);

Windows Silver

UIManager.put("win.xpstyle.name", "metallic");
LookAndFeelAddons.setAddon(WindowsLookAndFeelAddons.class);

Glossy

LookAndFeelAddons.setAddon(MacOSXLookAndFeelAddons.class);

O Glossy não está disponível no SwingX 0.8.0. Se quiser fazer uso do look and feel do Mac OS X, é preciso acessar o repositório do Java.net, módulo swingx, compilar, gerar o arquivo jar e adicioná-lo ao classpath do aplicativo.

Veja outros componentes SwingX em:

Referências:

Skin Look And Feel

2007-02-14T00:20:00.000-02:00

Baseado na descrição no sítio do projeto,

Skin Look And Feel permite à desenvolvedores Java escrever aplicativos skinnable [i.e. que trocam de skins] utilizando o toolkit Swing. É capaz de carregar pacotes de temas (um conjunto de skins GTK ou KDE) para incrementar widgets de uma GUI. Skin Look And Feel (aka SkinLF) também inclui NativeSkin para criar irregular windows.

Requer ao menos JDK 1.3 e é distribuído sob a licença Skin Look and Feel License, baseada na licença Apache License.

Themepack

SkinLF permite aos desenvolvedores empacotar temas GTK e KDE num arquivo Zip chamado themepack.
Esse arquivo contém o tema GTK ou KDE e um descriptor em XML. Há vários themepacks disponíveis para download no Javootoo. Teste alguns através desse demo.

Para mais informações, veja Understanding Theme Pack Format.

SkinLF in Action

Há duas formas de utilizar o SkinLF diferentes: alterar o look and feel programaticamente e o modo Skinit.

Faça o download do SkinLF, adicione a biblioteca ao classpath do projeto e utilize o método setLookAndFeel(LookAndFeel laf), de UIManager, durante a execução de main para alterar o look and feel programaticamente.
// Define o skin (i.e, o theme pack).
Skin theSkinToUse = SkinLookAndFeel.loadThemePack(
...............ModelMat.class.getResourceAsStream("aquathemepack.zip"));
SkinLookAndFeel.setSkin(theSkinToUse);
// Define o look and feel.
UIManager.setLookAndFeel(new SkinLookAndFeel());

Conversores de Temas

SkinLF tem como um de seus objetivos adicionar suporte a novos theme engines além do GTK e KDE nas próximas versões. Mas, nesse meio tempo, é possível converter um Microsoft Visual Style para um SkinLF themepack usando converters.

Um conversor irá converter (sic) um skin de formato específico para um theme pack usando GTK e KDE engines. Veja Converting a Microsoft Visual Style to a SkinLF themepack para entender como isso pode ser feito.

Native Skin

SkinLF provê aos desenvolvedores acesso à funcionalidades nativas do sistema operacional, como always on top, transparência e irregular windows.

Para informações adicionais, veja o tutorial A Clock using NativeSkin.

Contribua Você Também!

SkinLF requer desenvolvedores e escritores técnicos para corrigir bugs, criar documentação, entre outras tarefas. Para contribuir, registre-se no Java.net e junte-se ao projeto, ou participe da lista de discussões.

Veja mais sobre look and feel em:

Referências:

SwingX - JXTaskPane

2007-02-13T06:12:00.000-02:00

Use JXTaskPane para agrupar um conjunto de componentes visuais relacionados com uma mesma tarefa. JXTaskPane fornece controle para expandir e retrair o painel de conteúdo.

Geralmente são agrupados num JXTaskPaneContainer. Consulte SwingX - JXTaskPaneContainer (A Container for Task Panels) para entender quais os benefícios de agrupar JXTaskPane's num JXTaskPaneContainer.

JXTaskPane criará automaticamente hyperlinks através do método add(javax.swing.Action action).

JXTaskPane in Action

Segue a porção de código relevante para criar os três JTaskPane's agrupados num JXTaskPaneContainer, como na figura ao lado.

JXTaskPaneContainer taskPaneContainer = new JXTaskPaneContainer();
JXTaskPane tpPrincipal = new JXTaskPane();
JXTaskPane tpCalendario = new JXTaskPane();
JXMonthView monthView = new JXMonthView();
JXTaskPane tpSearchUrl = new JXTaskPane();
JLabel labelURL = new JLabel();
JTextField tfURL = new JTextField();
JButton bGo = new JButton();

// DropShadowBorder faz parte da biblioteca SwingX.
taskPaneContainer.setBorder(new DropShadowBorder());

// Define o título.
tpPrincipal.setTitle("Principal");
// Define o ícone.
tpPrincipal.setIcon(newImageIcon(
...............getClass().getResource("/folder_home.png")));
// Adiciona JXHyperlink's através de subclasses de javax.swing.Action.
tpPrincipal.add(new IrParaHome());
tpPrincipal.add(new IrParaCadastroPedido());
tpPrincipal.add(new IrParaCadastroCompra());
// Coloca tpPrincipal em taskPaneContainer.
taskPaneContainer.add(tpPrincipal);

tpCalendario.setTitle("Calendário");
// Faz com que o JXTaskPane esteja retraído.
tpCalendario.setExpanded(false);
// Adiona JXMonthView, também parte do conjunto de componentes SwingX.
tpCalendario.add(monthView);
taskPaneContainer.add(tpCalendario);

// Apenas um indicador para o UI plugável pintar diferente a área de título do JXTaskPane.
tpSearchUrl.setTitle("Pesquisar na Web");
tpSearchUrl.setSpecial(true);
/*
* Componentes labelURL, tfURL e bGo adicionados através da Matisse do NetBeans.
*
* Isso mostra que ainda é possível trabalhar bem com a Matisse
* mesmo com componentes de terceiros.
*/
taskPaneContainer.add(tpSearchUrl);

Action

Action's são interessantes quando mais de um componentes gráfico executa a mesma função, como pode acontecer com um item de menu e um botão da barra de ferramentas.

Encapsulam num mesmo lugar informações como o texto do menu, ícone pequeno para o menu, ícone grande para a barra de ferramenta, tool tip text e o estado do componente (ativado/desativado).

A classe IrParaHome extende AbstracAction - a implementação padrão da interface Action. Dessa forma, é preciso apenas definir o método actionPerformed() em IrParaHome.

Segue a classe IrParaHome, utilizada no código acima.

public class IrParaHome extends AbstractAction {
.....// Texto que aparece no menu e no hyperlink.
.....private static final String NAME = "Home";
.....private static final String ACTION = "go_home";
.....// Tool tip text.
.....private static final String SHORT_DESCRIPTION = "Mostra a tela principal";
.....private static final Icon SMALL_ICON;

.....static {
..........SMALL_ICON = new ImageIcon(IrParaCadastroPedido.class.getResource(
........................."/simpletest/taskpane/home.png"));
.....}

.....public IrParaHome() {
..........super();
..........putValue(Action.NAME, NAME);
..........putValue(Action.SHORT_DESCRIPTION, SHORT_DESCRIPTION);
..........putValue(Action.ACTION_COMMAND_KEY, ACTION);
..........putValue(Action.SMALL_ICON, SMALL_ICON);
.....}

.....public void actionPerformed(ActionEvent e) {
..........// Lógica de navegação aqui.
.....}
}

Veja também:

Veja outros componentes SwingX em:

SwingX

Referências:

org.jdesktop.swingx.JXTaskPane

Gastando Bem o Dinheiro

2007-02-10T02:20:00.000-02:00

Não é fácil angariar verbas para pesquisas científicas mesmo em países ricos, como os Estados Unidos, países membros da União Européia e Japão. Pesquisadores travam verdadeiras batalhas para arrecadar recursos; lançam livros, participam de palestras, conferências, reuniões com políticos e empresários.

Os principais motivos para tanta dificuldade são a imprevisiblidade dos resultados e a enorme soma de dinheiro necessária para pesquisas de ponta. Algumas pesquisas precisam de uma quantia que ultrapassa a casa dos milhões de dólares, chegando aos bilhões. Um exemplo é o CERN - enorme acelerador de partículas situado num túnel de vinte e sete quilômetros em Genebra. Os Estados Unidos planejavam há algum tempo construir um acelerador de partículas com uma circunferência de oitenta e três quilômetros, com um orçamento de, no mínimo, 6 bilhões de dólares.

E isso é gastar bem?

Se em algum ponto no passado algum país muito rico e poderoso resolvesse financiar a invenção de um aparelho que pudesse transmitir imagens e sons a longas distâncias e outro que captasse essas imagens e sons (televisão) para entreter e informar seus espectadores, é mais provável que não houvesse resultado algum.

No fim do século XIX foram apresentadas teorias eletromagnéticas - Maxwell foi o grande responsável - que pouco mais tarde foram comprovadas. As aplicações tecnológicas dessas descobertas foram imensas. Apenas citando alguns exemplos, rádio, televisão, telefonia celular, Internet.

Ao pesquisar ondas eletromagnéticas, Maxwell não planejava assistir televisão. Ele desejava entender mais sobre a natureza, seus fenômenos e mistérios. Aparelhos de raio X, rádio transmissão, radares, motores elétricos, todos esses aparelhos e muitos outros apareceram repentinamente; só puderam ser imaginados e criados após a teoria eletromagnética.

Fato semelhante aconteceu com o computador (com transístores ao invés de válvulas), satélites, cristal líquido, aparelhos que transformam luz solar em energia, e muitos outros. Essas invenções apareceram graças a um novo ramo da física chamado Mecânica Quântica, responsável pelo estudo dos átomos e outras partículas muito estranhas e muitíssimo pequenas (algumas dessas partículas receberam mesmo o nome de partículas estranhas).

E nós (brasileiros) com isso?

Alguém pode argumentar que nós não temos ao menos educação fundamental adequada, não há segurança, falta infra-estrutura e contamos com (coloque o seu problema "preferido" aqui). Por que o Brasil, com tantos problemas pedindo atenção, lutando por verbas, deveria investir em ciência básica?

Ciência básica não é luxo. Tecnologia de ponta provém da aplicação de conhecimentos recém-descobertos e geram mais divisas. Então, a questão é:

O Brasil vai continuar exportando basicamente soja, café e outras commodities, ou irá comercializar também produtos que envolvam nanotecnologia, softwares e outros que precisem de alto nível de conhecimento?

O Brasil é capaz de investir em pesquisa fundamental e ganhar com isso?

Petrobras, Embrapa e (coloque seu exemplo preferido aqui) já provaram que sim faz algum tempo.

Drop-Shadow Menu - Incremente os Menus de Seu Aplicativo

2007-02-09T00:37:00.000-02:00

Um recurso interessante do JGoodies Looks é o Drop-Shadow Menu. As imagens abaixo são do artigo Swing: Enabling Menu Drop-Shadows with JGoodies. A primeira mostra o item Project da barra de menu com a drop-shadow border.

A segunda imagem mostra outro item da barra de menu, sem a drop-shadow border do JGoodies.

Para fazer uso do Drop-Shadow Menu é preciso apenas utilizar um dos look and feels do JGoodies e ativar esse recurso por meio do código:
com.jgoodies.looks.Options.setPopupDropShadowEnabled(true);

Isso afetará tanto os itens na barra de menu, quanto os menus pop-up.

Para ter esse recurso ativado ao utilizar o Substance Look and Feel, utilize o código:
contrib.com.jgoodies.looks.Options.setPopupDropShadowEnabled(true);

Referência:

Swing: Enabling Menu Drop-Shadows with JGoodies