java.lang.UnsupportedClassVersionError: Bad version number in .class file

Após decompilar uma classe (aproveitando, usei o JD-GUI que funcionou bem no MacOS) que estava rodando no servidor (e *MEH* eu não tinha o fonte), alterar, recompilar na minha máquina e jogar de volta pro servidor, comecei a receber a mensagem de erro. Após revisar todas as configurações do Eclipse (Java Compiler específico no projeto, JRE System Library correto) continuei recebendo o mesmo erro.

Depois de procurar muito, descobri que mesmo alterando todas as configurações no Eclipse, na pasta do projeto ainda ficou um arquivo configurado pra java 6.0. Então se enfrentar o mesmo problema, procure pelo arquivo:

$PROJECT_ROOT/.settings/org.eclipse.jst.common.project.facet.core.prefs

E edite alterando a JRE para a correta para o seu projeto.

Mas sendo mais prático preguiçoso, sempre existe uma forma mais fácil e menos dolorosa de fazer as coisas. E foi então que achei o rmagick-osx-installer. Basta fazer download, descompactar e executar

ruby rm_install.rb

E depois de todo processo completo (com um pouco de sorte), você verá um lindo resumo como esse:

Summary: There were 0 failures
libpng 1.2.26 was already installed.
libjpeg was installed successfully
ghostscript was installed successfully
ghostscript-fonts-std was installed successfully
FreeType 9.17.3 was already installed.
libwmf was installed successfully
ImageMagick was installed successfully
RMagick was installed successfully
Removing rm_install_tmp directory...Done

Hoje resolvi fazer uma atualização do Rails e cia aqui e dei de cara com um problema chato de resolver. Além de instalar as versões novas dos gems, queria me livrar as antigas. Mas sempre que tentava fazer o gem cleanup, recebia o seguinte erro:

~ plentz$ sudo gem cleanup
Cleaning up installed gems...
Attempting to uninstall mongrel-1.0.1
ERROR: While executing gem ... (Gem::InstallError)
Unknown gem mongrel = 1.0.1

Depois de fazer um find (find . -iname mongrel* mesmo) no / inteiro, descobri um diretório com vários gems antigos. Ele fica em:

/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/gems/1.8

Entrei nele e fiz literalmente um limpa. Apaguei todos arquivos dentro das pastas specifications, doc, cache e gems. Então se quizer deixar sua instalação 100% fresh, rode os comandos abaixo, e caso encontre algum problema, siga a dica acima:

sudo gem update --system
sudo gem update
sudo gem cleanup

Depois confira que você ficou só com as últimas versões rodando: gem list.

É exatamente esse a impressão que eu tenho depois de migrar os nossos servidores para o Jetty. Depois de ver muita gente reclamando de OutOfMemory no Tomcat, inclusive aqui da empresa, resolvemos tentar o Jetty.

A tempo que escutava o pessoal da Caelum (e principalmente o Kung) falando bem do Jetty, mas só quando se começa a usar que se percebe as vantagens. Como temos várias aplicações rodando (diferente do GUJ, que era só o JForum, acredito), imaginei que a troca não seria tão smooth assim.

Claro que antes de sair trocando tudo, fizemos alguns testes pra ter certeza que tudo ia ocorrer bem. Por sinal, a troca foi bem tranquila do ponto de vista da aplicação, só tivemos que fazer alguns ajustes:

• o Jetty lança java.util.Collections$UnmodifiableMap ao tentar modificar diretamente o (Hash)Map devolvido com request.getParameterMap() ao invés de usar o método setAttribute() do request - coisa que o Tomcat deixa;
• Diferenças ao tentar recuperar um resource do sistema utilizando como pasta base “.”, ou usar “..” pra navegar na estrutura de pastas. Para resolver, basta usar como pasta base “/” (ex: “/com/foo/resources/xpto.xml”) e colocar dentro do WEB-INF/classes;
• E a última, mas simples de resolver, é que o Jetty deixa habilitado listagem de diretórios. Você pode alterar isso no etc/webdefault.xml, trocando o atributo dirAllowed para false;

Feitos esses ajustes, chegou a vez de configurar o Jetty para atender aos diferentes domínios. E é aqui que vi uma das grandes vantagens do Jetty. A parte de configuração dele fica muito organizada. Fizemos da seguinte forma:

• Para cada aplicação (pra cada .war na pasta /webapps do Jetty), criamos um arquivo de contexto no /contexts (não é necessário, mas como temos urls diferentes e contextos diferentes, tivemos que customizar - e acabamos ganhando um brinde que conto depois)
• Cada arquivo de context tem uma estrutura estupidamente simples:

  
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd">
<Configure class="org.mortbay.jetty.webapp.WebAppContext">
  <Set name="contextPath">/</Set>
  <Set name="war"><SystemProperty name="jetty.home" default="."/>/webapps/demo_foo.war</Set>
  <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

  <Set name=”virtualHosts”>
    <Array type=”String”>
      <Item>demo.foo.com</Item>
    </Array>
  </Set>

</Configure>


Explicando por partes:

• WebAppContext é o tipo de contexto que você vai usar, estamos usando esse pois permite o hotdeploy
• contextPath serve para dizer (óbvio) o contexto que quer que a aplicação fique disponível. Aqui prefirimos colocar todas no contexto / e configurar diferentes Virtual Hosts pra cada aplicação.
• a propriedade war só diz qual .war (que pode ser um exploded war também) que vai ser deployado naquele contexto
• na seção que diz virtualHosts, você pode configurar todos os endereços que quer que sua aplicacão responda. Para ela aceitar mais de um endereço, basta ir adicionando Item’s com as outras URLs. Aproveitando, no Jetty 7 será possível usar wildcards!

Com isso feito, ficou muito fácil configurar o deploy automático de todas nossas aplicações, pois basta substituir o arquivo .war e dar um touch no arquivo de contexts que o Jetty faz reload do contexto (e esse é o brinde! )! Agora, com o Jetty combinado ao Hudson, com um clique podemos fazer deploy de qualquer uma das nossas aplicações em um ambiente específico ou mesmo em todos, automaticamente. Mas isso já é assunto para um outro post.

Links Relacionados

• Melhorando o GUJ: Jetty, NIO e load balancing
• Jetty Documentation

Mas perai. Qualquer um consegue acessar o meu chamado na Anatel? E se eu trocar o número do chamado? Vamos ver. http://sistemas.anatel.gov.br/focus/FaleConosco/MostrarDetalheSolicitacao.asp?idtSolicitacao=7094111. Excelente. Chamados públicos e com id sequencial. Parabéns equipe Anatel. Muito bom.

Ou seja, qualquer pessoa pode acessar qualquer chamado, pois os mesmos são abertos a público. E pior, com dados que não poderiam ser publicados, como CPF, email, telefone…ótimo não? Mas fica ainda pior. Sempre pode ficar pior. Me dei conta que o login do site da Anatel é a combinação CPF+email. E esses dados são exibidos publicamente. Já entenderam o tamanho do problema, né?

Então já que após 3 dias até agora não escutei um “ah” da Anatel, resolvi fazer uma certa publicidade, pra ver se as coisas andam mais rápido. Por sinal, meu chamado do BrTurbo parece estar andando mais rápido que o chamado deles.

Só fica a dúvida: e a privacidade, Anatel?

update: pra quem não viu, tirei uma screenshot reproduzindo o problema, Anatel tentando corrigir o problema e do site da Anatel “em Manutenção”.
update 2: recebi agora pela manhã uma ligação da responsável pelo sistema da Anatel, agradecendo sobre o alerta e se comprometendo a só colocar o sistema no ar novamente quando tudo estiver resolvido - e me deixou o número para ligar diretamente, caso encontre outro problema. A publicidade funcionou.

Links:

• Baguete - Furo: Anatel retira dados do ar
• Baguete - Furo: Anatel expõe dados pessoais
• iMasters - Anatel exibe dados de usuários na web

Além disso, hoje também foi oficialmente lançado o Github, que é basicamente um host especializado em Git. E quem acompanha blogs gringos porai, deve ter percebido que não param de pipocar posts em tudo quanto é lado, explicando como usar Git e porque git é melhor que Subversion (acho que ninguém tem coragem de tentar comparar Git com CVS né?) então nem vou perder meu tempo escrevendo mais um. E como provavelmente daqui a algum tempo (pouco, inclusive), você vai estar abandonando seu querido Subversion, siga os links do post e comece a usar. Não dói. Give It a Try.

Reclamações na central deles não adiantam em nada, e quando entrei em contato na última vez (depois de esperar 40 minutos[sério!] no telefone), comentei com o atendente depois de explicar o problema todo:

Bom, eu to ligando na verdade nem é pra reclamar, porque sei que não adianta. É mais pra pegar um número de protocolo e poder reclamar com a Anatel e entrar na justiça para cancelar o serviço. Inclusive, tu já deve estar enjoado de gente reclamando, então nem vou ocupar mais a linha, porque devem ter mais zilhões de clientes querendo reclamar.

Ele só riu. Então fica a dica, se não comprou, não compre. Se comprou, ligue pra central de atendimento do consumidor da Claro (número 1052 - dica, ligue do celular e coloque no viva voz, pra não cansar o braço enquanto espera), reclame, anote o número do protocolo, ligue pra Anatel (número 0800 332001), reclame passando o número do protocolo da Claro e entre com seu devido processo contra a Claro.

Ótimo einh? Recebi um CD de instação pra Mac e tudo vai funcionar corretamente. Bom, nem tudo é tão fácil. O CD instala os drivers do modem e também um discador para que você possa conectar. O problema é que se você tenta usar o discador, a mensagem que é exibida é “Fail to connect”. Talvez o problema seja que eu já esteja utilizando o Leopard, mas enfim, o que importa é que não funciona.

Depois de duas horas com o vendedor da loja da Claro tentando instalar (e o cara era realmente competente, só que não haviam dado treinamento para instalação em Mac`s - dei a sorte de ser atendido justamente pelo cara que foi para São Paulo ter treinamento disso e repassar pro pessoal aqui no RS), tivemos a idéia de tentar usar o discador do próprio Mac OS. E funcionou. Então caso você tenha problemas, a dica é usar o cd de instalação que acompanha para instalar os drivers, mas para conectar, crie uma conexão e não use o discador (MobileConnect) - ele até serve pra alguma coisa, já que é possível ver como está o sinal da operadora na tela principal.

Para criar uma conexão nova (depois de ter instalado os drivers), entre em System Preferences, Network, clique no sinal de +, selecione HUAWEI Mobile em interface e coloque o mesmo em Service name. Coloque os seguintes dados para conexão:

Telephone number: *99***1#
Account name: claro
Password: claro

Entre agora em Advanced…, na aba Modem, selecione Vendor como Other, e em model selecione HUAWEI Mobile Connect - 3G Modem. Clique em OK, em seguida Apply. Para testar, clique em Connect. Se você deixar selecionada a opção “Show modem status in menu bar”, o que eu recomendo, você pode mandar conectar clicando no ícone do telefone do menu bar e em seguida Connect HUAWEI…That’s it.

update: pra quem estiver se sentindo lesado ou estiver com problemas na conexão, registre um chamado na Anatel, fone 0800 33 2001.

Volta e meia vemos pela internet alguém falando que open source não dá dinheiro. Quem tem um pouco mais de conhecimento (e vivência) em ambientes desse tipo, sabe que muitas vezes o dinheiro pode não vir diretamente da empresa “guarda-chuva” do projeto, mas através de reconhecimento por se ter participado do desenvolvimento de algum software que é usado por dezenas, centenas ou mesmo milhares de desenvolvedores. E com um pouco mais de dedicação(e expertise), é possível ser contrato pela empresa (e ainda ganhar um bom dinheiro). No Brasil mesmo, temos excelentes exemplos de gente trabalhando para projetos open source full time, como o Fernando Meyer, que trabalha no projeto Jboss Drools contratado pela RedHat e também o Rodrigo Kumpera (ou louds), trabalhando pela Novell no projeto Mono, ambos amigos pessoais. Além deles, com certeza devem existir outros que não conheço.

Pensando nesse pessoal, Jason Allen e Scott Collison criaram um site de relacionamentos para desenvolvedores: o Ohloh. O nome é tão estranho quanto o “primo” famoso, orkut, mas o foco é bem diferente. O Ohloh oferece uma série de recursos para quem participa de projetos open source, como possibilidade de criar “profiles” dos seus projetos e indexar o código fonte, permitindo que os desenvolvedores linkem seu profile aos seus commits no repositório. Também é possível dar um kudo(segundo a definição que está no site: (ku·do) a statement of praise or approval; accolade; compliment.) como forma de demonstrar sua confiança/admiração em algum desenvolvedor. Excenlente oportunidade pra quem colabora em algum projeto mostrar seu trabalho. Quem se cadastrar e tiver curiosidade pode dar uma passada no meu profile lá.

Na mesma linha, nas últimas semanas (ok, fazia meses que não postava), acabei ganhando alguns “pontos de confiança” em alguns projetos. Me tornei commiter (é, versão aportuguezada de quem pode dar commit no repositório), dos projetos Hibernate (e seus subprojetos) e do Vraptor (junto com o pessoal da Caelum) - tanto o Hibernate quanto o VRaptor já estão indexados no Ohloh. Motivo à mais pra gatar um tempo extra codando na frente do micro

Já estava com esse post em draft à séculos, mas como o tempo andava curto, acabava sempre procastinando de terminar. Algum tempo atrás (ok, bastante tempo, foi dia 30 de abril, 2007), ocorreu mais um encontro do Spin RS, fórum regional voltado para a melhoria das práticas de Engenharia de Software. Nessa edição em especial, diversas “celebridades” da IEEE estavam presentes, então vale a pena dar uma olhada, mesmo que seja somente nos slides das palestras.

Rebecca Wirfs-Brock: sensacional. Candidata forte à melhor palestra. A palestra dela foi basicamente uma aula de como contar histórias (uma habilidade importantíssima pra quem desenvolve orientado à objetos, já que precisamos saber fazer um “roteiro” de como os objetos interagem, etc). O nome da palestra era “Trends on Object-Oriented Software Design”, mas acabou virando “The Art of Telling your Design Story”.
PS: recomendo mesmo o livro da Rebecca, Object Design: Roles, Responsibilities, and Collaborations.

Outra palestra bacana foi a do Philippe Kruchten, sobre Arquitetura de software, onde ele levantou algumas questões sobre quem, como e quando deve fazer a arquitetura de um sistema. Mas a parte que mais me chamou atenção foi durante as perguntas da platéia, onde alguém perguntou alguma dica de como se tornar um bom arquiteto de software, e ele respondeu bem tranquilamente “troque muitas vezes de emprego”. Reações curiosas puderam ser observadas.

Dessa vez só o Phillip Calçado e o Marcello Azambuja que vieram, mas próxima vez espero ver mais gente por aqui, até para valorizar mais o evento (e também pra participar do churrasco pós-evento).

Quem programa em Java e nunca passou por esse problema? Você está desenvolvendo, tudo funciona perfeitamente, quando a aplicação vai para produção e os usuários começam a usar você percebe que o contador de conexões disponíveis no seu pool só diminui.

As razões para isso podem ser as mais variadas (sendo a maioria deles problemas da aplicação e não algo ligado ao data source, servidor de aplicação ou mesmo driver jdbc), mas as mais comuns são:

• ausência de chamada ao connection.close();
• falta de um tratamento de excessões, e conseqüentemente, o método close() não é chamado;

É importante saber, que sempre que você estiver lidando diretamente com Connection (o que não é algo muito aconselhável, sabendo que já existem diversos frameworks que abstraem/simplificam a utilização de jdbc), você deve fechar ela através do método close() e o mesmo deve estar dentro de um bloco finally{}, para que ele seja executado mesmo se ocorrer um problema durante a execução do seu código.

Mas e quando você já revisou “todo” seu código e mesmo assim as conexões continuam vazando? Você olha as conexões do seu pool e elas simplesmente parecem ir para o limbo. Aqui alguns já podem começar a se perguntar, “mas tem como eu monitorar as conexões do meu pool?”. E é aqui que entra um recurso não muito conhecido (e menos ainda, usado): Java Management Extensions ou simplesmente JMX.

Copiando o site da Sun:

JMX technology provides the tools for building distributed, Web-based, modular and dynamic solutions for managing and monitoring devices, applications, and service-driven networks. By design, this standard is suitable for adapting legacy systems, implementing new management and monitoring solutions, and plugging into those of the future.

A maioria (se não todos) dos application servers já vem com recursos JMX prontos pra monitoramento e diagnóstico de connection leaks. Ativar o monitoramento do data source pode muitas vezes sacrificar um pouco da performance da aplicação (principalmente em um arquitetura Database-Centered), mas normalmente é um custo aceitável para descobrir os pontos de perda das conexões.

No JBoss, servidor de aplicação que eu utilizo no meu atual projeto, ligar o monitoramento é bem simples. Quando ativo, ele basicamente armazena o stack trace de todos os pontos onde temos chamadas à getConnection(), até que essa conexão sehja devolvida ao pool. Para ligar o monitoramento, altere o arquivo de configuração do seu data source(provavelmente um *-ds.xml) adicionando a linha abaixo
<local-tx-datasource>
.....
<track-statements>true</track-statements>
</local-tx-datasource>

Agora basta acessar o mbean CachedConnectionManager através da interface JMX do Jboss e invocar listInUseConnections() para ver o stack trace das conexões que não foram fechadas. Provavelmente vai ser algo semelhante à essa. Se você quizer apenas ver como anda seu pool, acesse o mbean ManagedConnectionPool, procurando principalmente pelos seguinte valores:

• AvailableConnectionCount - total de conexões disponíveis no pool
• InUseConnectionCount - total de conexões sendo usadas atualmente
• ConnectionCount - indica o total de conexões abertas atualmente no pool

Utilizando esses recursos e tendo um pouco de paciência, fica bem mais fácil achar os pontos de vazamento da aplicação.

Mais informações:

• Jboss DataSources
• Connection Leak Tracing - Sun Application Server
• Bea WebLogic - Profile Connection Leak
• IBM Web Sphere Aplication Server - Connection Leak Diagnostics
• The Joy of Finding Connection Leaks

Quem lê meu blog já à algum tempo, sabe que eu uso o Eclipse como principal ferramenta de trabalho. O que poucos sabem é que todos podem colaborar nas decisões do projeto, e de quebra, priorizar as correções de bugs e melhorias. Pra dar um empurrãozinho nos preguiçosos, segue minha lista atual de votos.

Community

• 71735 - Eclipse source repository should convert to subversion.
• 177497 - Bug status explanation page does not mention RESOLVED REMIND
• 178923 - Remove LATER and REMIND resolutions when Bugzilla 3.0 is released

JDT

• 182064 - Should be possible to “Migrate JAR File” in User Libraries
• 182071 - [1.5][compiler] Unnecessary cast detection fails on ternary operation

Platform

• 2009 - [EditorMgmt] Need to sort out handling of out-of-synch resources (1GDFD96)
• 8009 - [Editor Mgmt] Split File Editor
• 14916 - [Navigator] How can I recover from a “resource is out of sync” problem ?
• 19419 - [resources] Cancellation during file transfer leaves files out-of-sync
• 35973 - [resources] Better project organization
• 46207 - [Workbench] [Services] Combine, compose, nest workbenchparts and editorparts
• 52338 - [find/replace] regex replace with newline doesn’t insert anything
• 92250 - [Workbench] Excessive amount of Permanent Generation memory reported by the VM
• 102527 - [Wizards] Add support for projects refactoring (ie add/remove nature)
• 118294 - Renaming an External Tool Builder (set to run during Auto Builds) causes error
• 134416 - “Run As..” - “Ant Build” results in “Unable to find ant file to run”
• 142364 - Replacing a large number of files hangs Eclipse
• 163714 - Update manager interactively asks for mirror selection
• 167660 - Out of sync not refreshed after file is closed
• 169121 - cpu get >50 when I did refactor to a method
• 169386 - [Edit] Local side of java compare should be more like java editor

Web Tools

• 95450 - add extract include file for JSP source refactoring
• 100511 - JavaScript refactoring and better code complete
• 107052 - jsp editor error if jsp is under a subdirectory
• 119334 - [jsp20] jsp:directive.tag import= list not recognized in .tagx XML tag files
• 124288 - [Plan] Improve JSP 2.0 support
• 124796 - [refactoring] moving a servlet is not reflected in web.xml
• 136850 - JSTL Code Assist from imported projects.
• 157465 - jsp fragment does not see any variables/tags from its parent
• 168538 - “Convert to a Dynamic Web Project” should work for Java projects

Uns meses atrás tive um problema com o uso do Hibernate, em um caso um tanto quanto incomum: o projeto usava Ingres, um banco de dados muito pouco usado, e com algumas particularidades idiotas (sendo gentíl com eles). O tipo responsável por armazenar as datas no Ingres, diferentemente de todos os outros bancos que já vi, aceita três “estados” nas colunas de data: uma data (óbvio), null, ” - sim, uma empty string.

Com isto, eu não poderia usar as classes padrão para datas no Java, acabei criando uma classe Data para tratar desses estados. Como o tipo foi criado por mim, o Hibernate não oferece nada pronto (por razões óbvias), tive que achar uma alternativa.

Lendo um pouco a referência, mais especificamente o capítulo Custom value types, descobri que para esses casos especiais, onde muitos já apelariam para alguma forma menos ortodoxa, o Hibernate oferece um mecanismo muito poderoso : os UserTypes.

Um UserType é basicamente uma interface que permite a implementação de como um determinado tipo será recuperado e persistido no seu banco de dados. Este recurso é extremamente útil e me salvou graciosamente.

E porque estou escrevendo isso tudo? Recebi hoje uma dúvida bem interessante por mensagem privada no GUJ. O usuário perguntava se haveria possibilidade de usar Hibernate em conjunto com o banco PostGIS - focado em armazenar dados geométricos.

O principal desafio é como mapear os dados que são armazenados em Geometry, como são chamados os tipos geométricos no PostGIS. Como não existe nenhum tipo nativo do Java que seria correspondente (e nem a especificação do JDBC preve isso - tipos clob, lobs e variantes não contam!), o trabalho pode ser um pouco mais complicado que se imagina.

Dando uma pesquisada, acabei encontrado uma thread da lista de users do PostGIS que trata exatamente disso. Nela é apresentada uma solução elegante para o tratamento dos tipos no Hibernate - e que acabou virando parte do projeto. SpatialEJB3 nada mais é que um UserType (GeometryType no caso) com a implementação responsável por tratar o tipo Geometry. Ele pode ser usadao tanto com Hibernate puro, quanto para EJB3. Só achei estranho que as classes ainda não estão no postgis.jar.

Para usar o recurso, fica extremamente simples:

@Type(type = "org.postgis.hibernate.GeometryType")
public Geometry getLocation(){
return location;
}

No site é possível encontrar a documentação do projeto.

And we did it.

ps: e eles tão com um timinho bem produtivo de marketing, einh?

Desde que o porca morreu, estou hospedando meu blog no Dreamhost. Host bem bacana, uma série de features úteis (Subversion, Rails, etc etc), mas sempre há espaço pra melhoras. E eles tem uma forma bem legal de fazer isso, através de um espaço para os usuários votarem quais features acham legais de serem adicionadas. Dando uma passada rápida por cima achei algumas legais:

• Allow one-click installation of Trac (http://projects.edgewall.com/trac/)
• Install and support Apache Tomcat for JSP (JavaServer Pages) support.
• Add Java Servlet support.
• Allow multiple votes on one suggestion.
• Notify my via email whenever I get a new referral signed up.
• Compile pdflib support into PHP for creating pdf documents.
• Add DreamHost Staff submissions to the suggestions area, not just customers’ suggestions.

Sugestões também são bem-vindas.