OR: windowtext; FONT-FAMILY: Verdana">style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana; mso-bidi-font-size: 12.0pt">Osvaldo Pinali Doederlein
Você já teve algum problema difícil que exigia “entrar” com o debugger em métodos das APIs do Java? Ou quem sabe, tentou aprender com os mestres, examinando o funcionamento interno de APIs interessantes? Senão, já detectou algum bug potencial do runtime do Java mas não conseguia capturar informações suficientes para reportar o problema à Sun de forma adequada? Estes problemas foram resolvidos desde que a página de downloads do projeto Mustang (o futuro Java SE 6.0) passou a disponibilizar não só os builds convencionais do Java SE 6.0, mas também os builds “fastdebug”.
Os makefiles do projeto definem três tipos de builds. Os builds de produção são aqueles que todos conhecemos, disponibilizados para download em java.sun.com. Não incluem nenhum código de depuração, pois isto tornaria o JRE maior e mais lento. No outro extremo, os builds de debug incorporam muito código de depuração, permitindo diagnosticar os mínimos detalhes de todo o funcionamento da JVM e das APIs. Mas são extremamente lentos. Poucos desenvolvedores agüentariam utilizá-los, e as informações adicionais que proporcionam só são úteis para os engenheiros que trabalham todos os dias com o código fonte do JRE.
Mas existe uma opção de compilação intermediária. Os builds fastdebug são um meio-termo entre esses dois extremos, com suporte a depuração suficiente para programadores de aplicações. Nestes builds:
· Os jars do JRE (como o lib/rt.jar) são compilados com informações completas de depuração, incluindo dados sobre variáveis locais e parâmetros, cuja falta complica a depuração das APIs em versões de produção do JRE. Veja a diferença: a Figura 1 mostra uma tentativa de depurar (no Eclipse) a implementação do método HashMap.put() no build de produção do Java SE 6.0. Observe que os nomes corretos das variáveis não aparecem no debugger, o que dificulta bastante acompanhar o que está acontecendo. Já na ...
