Blog do Mister M

O site do JustJava 2006 já está no ar e a chamada de trabalhos, vulgo CFP (Call For Papers) já começou. Confira!

Muitas pessoas me perguntam quando o genesis irá suportar Swing. A resposta é que ele já suporta.

A versão atualmente no HEAD do CVS tem suporte Swing há algum tempo – bem como a anotações do Java 5 -, mas simplesmente não tivemos tempo de atualizar a documentação completamente ainda. Contudo, estou trabalhando nisso nestes dias.

O exemplo useradmin já utiliza Thinlet e Swing e serve de referência de uso da API. Para quem não tiver paciência de aguardar a documentação atualizada, pode conferir o snapshot de janeiro aqui.

Bem, após a morte do JavaBlogs, essa é a nova casa dos meus comentários sobre o mundo Java. Espero postar com mais freqüência.

Quem programa em Java e nunca escreveu código que lançou uma NullPointerException, que atire a primeira pedra. A NPE talvez seja a exceção mais comum em Java e causa ódio em algumas pessoas, que acham que a linguagem podia “engoli-la” de algum jeito. Posso dizer pra vocês que isso, definitivamente, é uma péssima idéia.

No meu projeto atual tivemos, por várias razões, que escrever um pedaço do código em PL/SQL. Num é que a tal da linguagem “engole” os erros de operações com null? Funciona mais ou menos assim: qualquer coisa que você faz com null, dá null! Parece bom? Que nada! Imagina que isso:

IF X > 0 THEN
   ...
ELSE
   ...
END IF;

pode cair no else se x for null! Quem conhece PL, pode dizer: mas existe o NVL pra isso! Usar NVL(var, valor) retorna valor se var for null. Agora, imagina usar NVL pra quase todo uso de variável numérica no seu código. Pois é, nojento mesmo! O bonito é quando você não faz isso. O resultado pode acabar sendo um null como retorno da function ou em um campo da tabela. Aí, vai achar por que deu null… :-(

Por isso eu digo: benditas NPEs!!! Pelo menos, tem um stack trace onde eu sei exatamente em que linha os problemas ocorrem e limito meu escopo de “caça” ao null. BTW, um dia eu pego o cara que decidiu que as coisas fossem assim em PL… :-P

Uma das mudanças do Tiger que eu não coloquei nos slides da minha palestra no BrasilOne é o suporte a covariância. O que é isso?

Basicamente, no escopo do Tiger, isso se refere ao fato de um método poder sobrescrever outro retornando uma subclasse do tipo de retorno do método original. Algo assim:

public interface Product {
   //...
}

public abstract class Factory {
   public abstract Product create();

   //...
}

public class ConcreteProduct implements Product {
   //...
}

public class ConcreteFactory extends Factory {
   public ConcreteProduct create() {
      //...
   }

   //...
}

O exemplo de covariância é o método create(). A “graça” de ter covariância é que você elimina os casts quando está acessando o tipo concreto diretamente, o que seria muito bom pra quando você tem uma família de interfaces sendo implementadas todas juntas por um conjunto de classes concretas que são dependentes entre si. O código fica muito mais “limpo” do que é hoje.

Pois é, mais uma importante lição para o arquivo: java.awt.Font é mais uma API medonha do JDK. O problema é como funciona o carregamento de fontes.

A API provê um método chamado getFont(String name) que carrega uma fonte dado seu nome. Caso não encontre uma fonte com este nome, retorna null. A maior parte do código de terceiros, i.e., fora do JDK, que carrega fontes pelo nome, usa este método e geralmente utiliza uma fonte default caso o método retorne null. Como usar outra fonte pode ter impactos altamente negativos para diversos usos, como impressão de formulários específicos, geralmente não é este comportamento que o desenvolvedor deseja na aplicação.

Existe uma maneira padrão de se carregar uma fonte em Java: o método createFont(int fontFormat, java.io.InputStream fontStream), que funciona com fontes TrueType, criadas com fontFormat Font.TRUETYPE_FONT. Ou seja, se você anexar a sua aplicação os arquivos .TTF das fontes que você usou, é possível carregá-los dinamicamente. Mas, nem tudo é bonito assim :-/

Embora a API, ao carregar um arquivo de fonte, seja capaz até mesmo de identificar o nome da fonte, não existe na API uma forma de associar um nome a uma fonte. Em outras palavras, você consegue carregar uma fonte por nome, mas não é possível afetar ou customizar o retorno de getFont(String). Levando em conta que, como eu disse antes, a maior parte do código do mundo “acredita” em getFont(String), a menos que a fonte esteja instalada no S.O. – e exatamente a mesma fonte, o que raramente acontece :-/ -, tudo dá errado.

Qual a solução para o problema? Se você está lidando com open-source, existe a possibilidade de reescrever o código para usar seu próprio esquema de carregamento de fontes por nome, que permita associar o nome a certa instância de Font. Você pode também escrever um aspecto que intercepte a chamada a getFont(String) se você não quiser manter um branch ou se o software for fechado (e a licença permitir modificação binária).

Como prometido, vou falar um pouco sobre projetos em si. Na maioria dos projetos que falham, sempre alguém – ou quase todo mundo – sabe que as coisas vão dar errado logo no começo. Os motivos são vários: prazo impossível, equipe sub-dimensionada, despreparo, gerência caótica, restrições técnicas ridículas e absurdas etc. O problema acaba sendo que ninguém fala e depois fica reclamando, no velho esquema sabia-desde-o-começo-que-não-ia-funcionar. Alguns não falam simplesmente porque isso não funcionou das outras vezes e acham que nada vai ser diferente se fizerem alguma coisa. Então, do que adianta falar que as coisas vão dar errado? Depende da sua atitude.

Se você tiver argumentos para justificar a sua expectativa de falha – projetos passados que deram errado são uma ótima referência nessas horas -, use-os. Procure convencer as pessoas que trabalham com você antes de tentar convencer gerentes e/ou outros responsáveis. Muitas vezes você poderá ouvir coisas do tipo: “fizemos tal mudança depois da última vez, logo dessa vez vai funcionar”. O fato é que, se as coisas não deram certo da vez anterior, só vão dar certo depois da primeira vez que não ocorrer um fracasso. Logo, se a última vez tudo deu errado, dessa vez provavelmente o máximo que pode acontecer é que tudo não seja um desastre completo, a menos que alguém que tenha um histórico em entregar projetos bem-sucedidos esteja liderando a equipe ou tenha poder de decisão dentro dela.

Outra coisa que geralmente as pessoas dizem é que você não está a fim de se matar de trabalhar. Bem, se isso for verdade, parabéns; afinal você é um dos poucos profissionais de TI que acha que existe vida fora do micro :-) Agora, falando sério, projetos funcionam como uma maratona: só adianta dar um gás perto do final e, se você sabe que o prazo final não é nem de longe a linha de chegada, você seria apenas um idiota de se gastasse suas energias agora e morresse bem antes da metade do caminho. É mais fácil – e vai causar muito menos danos ao cliente e a todos os envolvidos – se você disser na primeira semana do projeto que a entrega vai atrasar do que avisar uma semana depois do término do prazo… Infelizmente, a maioria das consultorias acredita que a segunda estratégia seja a mais inteligente, mas acredito que você, que vai passar seis meses sem ver sua família e seus amigos, deixando sua vida as traças e se sentindo um zumbi durante todo esse período – e mais algum tempo depois, geralmente -, não compartilhe desse mesmo pensamento.

Uma armadilha comum é começar a se convencer de que as coisas vão dar certo. Por quê? Os outros acreditam, é isso? Por um acaso deu certo da última vez em que os outros acreditavam? Realmente mudou alguma coisa? Existe alguma evidência concreta de que as coisas vão ser diferentes? Não adianta tentar se enganar, pois quem vai pagar o pato é você mesmo. Se você ganha (bem) por hora e prefere o dinheiro a sua vida, pode se dar por feliz, mas se não for o caso, é melhor manter sua posição inicial se você quiser passar pelo menos algumas horas fora do escritório. Caso contrário, você ainda corre o risco de se matar e ouvir de alguém da gerência coisas do tipo: “mas vocês trabalharam tanto pra entregar só isso no final?”, “são muitas horas, não sei se teremos como pagar” ou ainda “se você sabia que ia dar errado, por que mudou de idéia?”, que, com certeza, vai ser muito pior do que continuar lembrando porque as coisas vão dar errado…

Resumindo, dizer que as coisas não vão dar certo no começo, quando se tem base pra isso, não é ser pessimista nem preguiçoso, mas é, na realidade, uma forma de economizar o dinheiro da empresa – que não vai queimar recursos achando que miraculosamente vai entregar em três meses o projeto que vai levar um ano pra ser desenvolvido e que provavelmente vai ter condições de fazer a coisa certa, mudando radicalmente a situação ou tomando medidas reais para lidar com o atraso -, não decepcionar de verdade o cliente, dizendo depois do prazo que ainda falta mais do que o tempo de projeto inicial para entregar o que ele pediu, e poupar a sua própria vida, ou salvar a sua pele, se assim preferir. Como esse é um post um tanto quanto existencial – quem disse que projetos e desenvolvimento de software são ciências exatas estava delirando e muito -, comentários, mesmo que desmintam totalmente o que eu disse, são bem-vindos :-)

Simplesmente maluco. Dá até vontade de escrever um mini-port do AspectWerkz usando algo assim, mas aí eu lembro dos trinta e oito bilhões e meio de TODOs que estão me aguardando e a sanidade mental fala mais alto. Em breve, novos posts sobre projetos :-)

“Que livro eu uso para aprender Java?” tem se tornado uma pergunta cada vez mais difícil de se responder, dada a velocidade com que a plataforma evolui. Se esta pergunta é feita por alguém que não sabe inglês o suficiente para compreender um livro nesse idioma, as respostas ficam ainda mais escassas.

Há muito tempo atrás, numa galáxia muito distante eu mesmo me fazia esta pergunta, embora soubesse inglês. Queria aprender Java, mas só encontrava livros que “começavam errado” por mostrar como fazer applets ou mexendo com Swing – uma das minhas principais objeções ao Java – Como Programar é justamente essa. O tutorial da Sun parecia um pouco complicado demais e tinha dificuldade de achar algo melhor. Até que encontrei o Thinking in Java, do Bruce Eckel, disponível online em formato PDF. O livro parecia ter a abordagem correta, explorando primeiro os conceitos de orientação a objetos e mostrando como implementá-los em Java, sem fazer “firulas” como usar applets ou JOptionPanes da vida “do nada” como os outros livros. Acabei aprendendo Java com ele e, anos depois, estou contando essa história aqui neste blog.

Depois de alguns anos decidi iniciar um projeto de tradução do livro, com o apoio do Bruce Eckel. Infelizmente, devido a outras tarefas não tenho tido tempo de acompanhar pessoalmente o processo, mas muitas pessoas competentes tomaram a liderança no grupo e a tradução tem progredido significativamente. Portanto, a próxima vez que alguém lhe perguntar sobre um livro, recomende o Pensando em Java.