O Eclipse do jeito que a gente precisa

Antigamente eu achava que o bom do Eclipse era ser do jeito que a gente precisava. Com uma arquitetura de plug-ins muito bem bolada, a gente baixava o núcleo central e ia adicionando os plug-ins. Mas infelizmente a vida mansa durou pouco.

Por ser relativamente fácil escrever um plug-in, surgiram um monte deles que a gente baixava e ia instalando por cima dos outros. Só que, às vezes, isto dava conflito. E acontecia mesmo depois que o Eclipse passou a se basear em OSGI, que parece ser uma das melhores promessas de coisas deste gênero disponíveis por aí.

Então surgiu algum "gênio" e pensou: vamos empacotar tudo de uma vez só. Foi então criado o monstro Calisto, enorme engolidor de recursos do meu pobre PC. Diga-se de passagem, que o tal gênio deve ter mudado de emprego porque a mesma idéia "genial" de IDE gulosa, foi copiada pela turma do Netbeans, que na minha máquina exige paciência de Jó durante a carga.

Hoje foi lançado o Europa. Percebi que retrocederam alguns passos e agora criaram 3 sabores diferentes de pacotes. A opção customizada é semelhante a primeira com a recomendação de usar o update. No fim escreverei sobre ela.

Para verificar se ficou bom mesmo, parti para instalar as versões de desenvolvedor que na verdade se divide em duas outras:
Eclipse IDE for Java Developers e Eclipse IDE for Java EE Developers

A primeira delas é mais enxuta e o download é de somente (?) 80 Mb. Vem tudo que eu preciso quando quero examinar um código de um projeto Open Source que é coisa que faço de vez em quando.

Para verificar a possibilidade de adições, resolvi instalar o Test and Performance Tools (TPTP). Podia seguir o caminho mais fácil que é baixar TPTP all-in-one package. Só que este bicho tem quase 200 Mb e vem com um monte de coisas com mais sentido para o Eclipse para JEE.

Assim baixei o tal Eclipse Modeling Framework (EMF and XSD) 2.3.0, que é pré-requisito para o TPTP, e depois baixei o All TPTP plugins Runtime.

Aí foi só instalar primeiro o EMF, depois o TPTP e tudo ficou como eu queria. Melhor dizendo, quase do jeito que eu queria porque o tal zip que eu baixei, veio com GEF e integração do TPTP com o BIRT e com o WTP. Depois de instalado este Eclipse 3.3 ocupa 217 Mb no meu HD.

Não gostei da granulometria dos pacotes do Eclipse. Ainda é como se a gente fosse comprar um carro para trabalhar e nos empurrassem um tração 4x4, mais dispendioso e com "vantagens" que não vamos usar no asfalto.

Partindo do pressuposto que nós somos desenvolvedores, isto é, gente que entende um mínimo de informática, então deveria ser possível montar nosso Eclipse de forma fácil.

Então fui ver como funciona a tal versão customizada. Ela acaba sendo customizada mesmo. Fiz assim: download do eclipse básico que nem vou entrar em detalhes. Aí entrei no update manager para instalar o TPTP e apareceu toda a plataforma do Europa para que escolher o que quero. Selecionei o TPTP e PUFT!

Pipocaram várias dependências. Como me acho do ramo, fui catando os nomes compridões e buscando um a um onde se localizavam na árvore de update. Ufa, deu trabalho mas selecionei todas as dependências e alguns muitos minutos depois, fiquei com um eclipse só com o que eu queria.

Não consegui ainda entender porque a versão que a gente baixa para depois customizar é tão maior do que qualquer uma das versões para desenvolvedores. Depois da instalação via update este eclipse ocupa 276 Mb do meu HD (contra 217 Mb do modo anterior).

Depois disto tudo, fiquei pensando e ainda me pergunto. Não fosse eu tão novidadeiro, seria melhor ao invés de gastar tanto tempo com as idiossincrasias do update do eclipse, usar o

Você sabia que o tiger era o gato da filha do Bruce Scott?

Pois, é. Precisou a Oracle completar 30 anos no último 16 de junho para eu aprender isto. O Bruce Scott escreveu os códigos das primeiras versões do Oracle junto com o Bob Miner, que morreu de câncer em 1994.

Meu primeiro contato com o banco de dados Oracle foi com a versão 5.3 preparando uma cotação para um projeto que infelizmente não ganhei. Mas como muitos de nós que trabalhamos com TI, já ganhei um bom dinheiro com projetos usando o Oracle. Por isto fui procurar saber um pouco da história dele e do Larry Ellison.

Disse o Larry Ellison em uma entrevista a Nicole Ricci em 1998:

“Realmente, quando fundei a Oracle, o objetivo nunca foi chegar a ser uma grande empresa. No máximo esperava ter umas 50 pessoas na empresa e viver bem. Depois de 5 anos, ficou claro que os horizontes eram ilimitados. Os únicos limites erámos nós.”

O próprio Bruce Scott contou em entrevista ao Rich Niemiec em 2001:

“Precisávamos ligar nossos terminais ao computador na sala ao lado e ainda não tínhamos idéia de como passar os fios. Larry pegou uma marreta, abriu um buraco na parede e disse: agora já podem passar os fios. Era o modo de pensar dele: fazer a coisa acontecer de qualquer jeito”.

Vamos ver um pouco da história dos bancos de dados relacionais antes da Oracle

1970 –Dr. Edgar Codd publica A Relational Model of Data for Large Shared Data Banks, sua teoria de modelagem relacional de dados.

1972 – Michael Stonebraker começa a desenvolver o que viria a ser o INGRES. Junto com Eugene “Gene” Wong e outros, incluindo estudantes, usam QUEL ao invés de SQL no Ingres. (Em 1985 o Stonebraker ainda em Berkeley, criou o Post-Ingres, isto é, o Postgres que virou PostgreSQL a partir de 1996).

1976 – Stonebraker, Wong, Kreps e Held publicam na ACM: The Design and Implemenation of INGRES. Percebe-se alguma hostilidade entre Berkeley e o grupo IBM.

1974 – Os estudantes de Berkeley, Jerry Held e Karel Youseffi criam o NonStopSQL (Tandem) baseado no Ingres. Robert Epstein, programador chefe em Berkeley, junto com os estudantes Paula Hawthorne, Mike Ubelland e Eric Allman, formam a Sybase.

Alguns fatos dos primeiros 10 anos da Oracle

1977 – Com 2000 dólares, Larry Ellison, Bob Miner, Ed Oates e Bruce Scott criam a Software Development Laboratories (SDL). O Bob era o chefe do Larry na Ampex onde trabalharam para a CIA em um projeto chamado "Oracle". Bob e Bruce começam a desenvolver o database.

1978 – A CIA é o primeiro cliente, mesmo antes do produto ser lançado comercialmente. Depois a SDL muda o nome para Relational Software Inc. (RSI).

1979 – RSI faz o primeiro lançamento comercial da versão 2. A V1 nunca saiu por medo de que as pessoas não comprassem software na primeira versão. A base de dados foi escrita em Assembler. A primeira venda foi para Wright-Patterson Air Force Base. Foi o primeiro RDBMS do mercado.

1981 – Lançada a primeira ferramenta, Interactive Application Facility (IAF), predecessora do futuro Oracle SQL*Forms.

1982 – RSI muda de nome para Oracle Systems Corporation (OSC) e depois simplificado para Oracle Corporation.

1983 – Lançada a Versão 3, escrita em C para ser portável. O genial Bob Miner, enquanto ainda suportava a versão V2 escrita em Assembler, escreve metade do código e o Bruce Scott a outra metade. Trata-se do primeiro RDBMS 32-bit.

1984 – Lançada a Versão 4 já com várias ferramentas e primeiro database com consistência de leitura. O Oracle foi portado também para o PC.

1985 – Lançadas as Versões 5 e 5.1 e o primeiro database Parallel Server para o VMS/VAX.

1986 – Oracle faz uma oferta pública de ações em 12 de março, um dia antes da Microsoft e 8 dias depois da Sun. As ações abriram a US $15 e fecharam a US $20.75. É lançado o primeiro database client/server.

1987 – Oracle é a maior empresa de DBMS. Aparece o primeiro database SMP (symmetrical multi-processing).

1987 – Rich Niemiec junto com Brad Brown e Joe Trezzo, trabalhando para a Oracle (TUSC), implementam a primeira aplicação client/server rodando Oracle em um 286 com 16 usuários concorrentes client/server para a NEC Corporation.

O resto da história vocês podem conferir em:

http://www.nyoug.org/Presentations/2007/200703_Niemiec_Keynote.pdf

http://www.oracle.com/oramag/profit/07-may/p27anniv_timeline.pdf

Parabéns Oracle.

Como velejador só posso dizer: Bons Ventos Larry Ellison.

Todo programador Java ruim que eu conheço...

Meu amigo Carlos Villela, o famoso fera CV que já ajudou muita gente no GUJ incluindo a mim, criou um tópico no GUJ com o título acima que incendiou a galera. É um dos tópicos mais lidos nos últimos tempos e muita gente respondeu, sendo que alguns mais de uma vez. Fora o esperado flame war, que acho que era o que o CV esperava que fosse mais divertido, muitas respostas boas apareceram. Até acredito que algumas poderiam ser coletadas em um manual de bons conselhos e outras em pit stop para o riso. Eu também respondi lá mais de uma vez. E vou responder de novo, só que desta vez por aqui.

Todo programador Java ruim que eu conheço...

Deve estar preocupado sabendo que os fabricantes de chips quase não fabricam mais CPUs mono cores e que no futuro precisarão aprender outras linguagens muito mais complexas com facilidades de computação paralela para aproveitar os multi cores.

Como muitos já perceberam, a industria de processadores se deparou com o chamado "muro de potência" e não consegue mais crescer a velocidade de processamento seguindo o mesmo ritmo de antes. Antes a lei de Moore previa a duplicação de desempenho a cada 18 ou 24 meses de um processador mono core. As projeções atuais, baseadas no que vem acontecendo nos últimos anos, indicam que o ciclo de duplicação deste tipo de processador é de no mínimo 5 anos.

Assim não é estranho que aumentar a freqüência do clock não seja mais o principal meio de melhorar a capacidade do processador. Já que não se pode crescer para cima o jeito é ir para os lados. O investimento atual é no paralelismo com o crescimento da capacidade de processamento utilizando vários núcleos. Um processador de 2 núcleos consome muito menos energia do que um de 1 só núcleo com o dobro de velocidade.

O hardware está mudando e o mundo do software, que se baseou durante anos no processamento seqüencial, terá que mudar. Já tem gente mudando porque a turma acadêmica de processamento científico e de Data Minning, já está relativamente adiantada na pesquisa de uso de métodos paralelos. O primeiro grandão que percebeu a necessidade de mudanças foi o Google. Eles foram buscar no Lisp o algoritmo MapReduce que se transformou em uma das chaves do sucesso do seu sistema.

Fiquem atentos, já vi o mundo mudar antes e acredito que ainda vou assistir isto acontecer outras vezes nos próximos anos. As mudanças sempre chegam oferecendo oportunidades de sucesso para gente inovadora. Tenho a certeza que não será diferente desta vez. Não duvidem que em futuro não muito longínquo, os Tomcats, JBoss, WebLogics e mais todos os ESBs da vida, não sejam mais escritos em Java e sim em Scala, Erlang ou outra linguagem qualquer com suporte mais fácil ao aproveitamento de mais processadores. Quem sabe o programador seqüencial Java que estamos malhando hoje não seja um novo “Marc Fleury” ou “Ray Ozzie” no mundo da computação paralela?

Consumer JRE

Na reunião do SouJava desta terça feira foi abordado o último JavaOne. Falaram Bruno Souza, Fábio Veloso, Fabiane Nardon e o Maurício Leal. Eles mostraram filmes, contaram histórias, inclusive do quanto os brasileiros são festivamente recebidos por lá e é claro, falaram do JavaFX e do Consumer JRE.

Na verdade a reunião foi um grande bate papo e foi bastante discutida a questão do tamanho do tal Consumer JRE. O Bruno disse que ele ficará em torno de 40% do tamanho atual e que será modularizado. Isto é, se o cara precisa de pouca coisa, só isto será baixado.

Quando cheguei em casa fui conferir algumas coisas.

1. A partir de uma interessante informação do Fábio, descobri que há um JRE somente para o Windows, de mais ou menos 7.1MB para instalação on line, que talvez já use um pouco deste conceito de não baixar tudo. Quem souber mais se é assim que funciona, por favor me confirme.

Download do JRE a partir de http://java.sun.com/javase/downloads/index.jsp

jre-6u1-windows-i586-p.exe = 13.16 MB
jre-6u1-linux-i586-rpm.bin = 17.67 MB

Download automático a partir de http://java.com/ para instalação on line

JRE para o Windows = 7.1MB

2. Microsoft Silverlight

Muito se fala no Silverlight e no tamanho do seu download que é de apenas 1.38MB na versão 1.0 beta mas chega a 4.24 MB na versão 1.1 alpha.

O pessoal que compara com o tamanho do JRE esquece que o Silverlight necessita também do Microsoft.NET Framework Version 2.0 Redistributable Package (x86) cuja versão 2.0 tem 22.4 MB de tamanho para download.

3. Consumer JRE

O Consumer JRE ainda está em desenvolvimento mas o objetivo é diminuir em 60% o tamanho do download do JRE para aplicações Swing de porte médio.

A idéia é modularizar o download do JRE de modo que se possa colocar para funcionar uma aplicação com o mínimo possível do que ela precisa.

Download em passos:

1. Funcionalidades básicas que todas as aplicações precisam: VM, gc, security, classloader e o mínimo de facilidades de rede para possibilitar o download do resto;
2. Dependências adicionais exigidas pela aplicação;
3. Classes responsáveis por qualquer exceção Class not found lançada;
4. Resto do JRE em paralelo até que complete o release completo no sistema do usuário.

A figura lá em cima deste blog, mostra números preliminares em MB, de pacotes da JRE necessários a algumas aplicações para mostrar como se comparam com o JRE completo.

Mas não é só isto. Haverão melhorias também no processo de instalação, os canais gráficos do Swing diretos com o Windows estão sendo reescritos para se prevalecerem das vantagens de rapidez e confiabilidade do DirectX usando a Direct3D library on Windows e um novo look and feel chamado Nimbus de aparência mais moderna.

A previsão de lançamento do Consumer JRE é para o início de 2008. Mas o próximo update 2 do Java 6, previsto para o fim deste mês de junho, já incluirá a melhoria no processo de instalação.

A partir do conhecimento do projeto do Consumer JRE, a idéia do JavaFX fica bem mais viável. Já há plug-ins para o Netbeans 6.0M9 e para o Eclipse 3.2 facilitando a escrita do JavaFX script. Resta agora a comunidade desenvolver ferramentas com capacidades gráficas para construir e renderizar os componentes de modo mais fácil do que o JavaFX Script JavaFXPad Demo

Galera, vamos botar a mão na massa!

Tratamento de exceções parte 3 - Discussão sobre a remoção das checked exceptions da linguagem Java

Continuação de tratamento de exceções:
Parte 1 – Um pouco de história
Parte 2 – Mudanças no conceito de uso das exceções

Há muita gente que sonha com um fork do Java redundando em um Java mais enxuto, com as APIs limpas de deprecateds e também mais poderoso com a inclusão de algumas facilidades que são difíceis de adicionar ao Java com a atual arquitetura da JVM. Entre as inclusões sonhadas, algumas estão na Java 7 Wish List do Peter Ahé. Juntando os desejos dele com mais alguns outros, sem pretensão de esgotar o assunto, podemos fazer uma lista de facilidades tais como real closures, improved type inference, continuations, tail recursion optimization e até mesmo o assunto desta trilogia que são modificações no tratamento das exceções.

Antes que alguém reclame de me ver escrevendo sobre fork do Java, lembro que a quebra de compatibilidade já aconteceu antes. O Swing no Java 2 quebrou as pernas do Java 1.1.6 baseado em AWT e o novo tratamento do foco no Java 1.4 impediu a migração de alguns sistemas feitos com Java 1.3, inclusive um em que eu trabalhava. Então o tal famoso argumento de que o Java sempre é compatível com si mesmo não é muito verdadeiro. Mas vou deixar este assunto para outra rodada de choppe e vou me ater às questões que me propus levantar sobre o tratamento de exceções.

No ultimo dia 26 de maio, o Neal Gafter em seu blog, em resposta ao colega seu no Google Matt Shulman, abordou a questão de remover as checked exceptions da linguagem Java.

Ele termina com uma pergunta:

“This isn't a question I had thought much about. I believe the language could be simplified by treating all exception types as unchecked without breaking existing programs. This could also result in a simplification of future language extensions and APIs. But would the language and platform be better off without checked exceptions?”

Isto é claro que ele suscitou muita polêmica. Li os 55 comentários e sem revelar ainda minha posição, vou resumir aqui alguns favoráveis às mudanças:

Stefan Schulz said...

I think that removing checked exceptions would be a feature and a benefit.

Matthias Ernst said...

Number one on my list!

Bob said...

Count me in.

Christian Plesner Hansen said...

I ran my own little crusade against checked exceptions a while back. I opened an RFE (#6376696)

Peter von der Ahé

I don't think it would work to make it a compiler option (which is why I was in favor of closing RFE 6376696). However, turning checked exception compile-time errors into compile-time warnings makes a lot of sense to me.

Tim O'Brien said... (autor de Jakarta commons Cookbook e Maven, a Developer Notebook)

I think we need an annotation that would allow us to automate the wrapping of checked exceptions with Runtime.

Não vou listar muitos comentários a favor da manutenção das checked exceptions. Somente listo 2, sendo que o segundo me chamou muita atenção:

Cedric said...

Count me firmly on the side of people who find checked exceptions very important to build API's on big code bases. Sure, they can be misused, but unchecked exceptions are being overused in a lot of places as well.

When I use a method from a library, I want to rely on the compiler to tell me what can go wrong, not on the documentation.

Edson said...

We develop systems using Java and .NET.
We deal with checked exceptions encapsulating them in a framework exception (ugly but documented); but exceptions in .NET are totally undocumented (the Microsoft API does not document all possible exceptions, neither our programmers) and we have very big headaches with unexpected exceptions found in production phase.
We desperately need checked exceptions in .NET; don't remove checked exceptions from Java.

Vale a pena acompanhar a discussão toda, inclusive baixar o PDF da apresentação do Marko Van Dooren Combining the robustness of checked exceptions with the flexibility of unchecked exceptions using anchored exception declarations, onde ele aborda o uso de facilidade da linguagem Eiffel para corrigir problemas das checked exceptions.

Não posso deixar de citar a resposta do do Elliotte Rusty Harold em seu próprio blog com veemente defesa das checked exceptions (80 comentários até agora e o Luca que respondeu lá não sou eu).

O que posso concluir depois de ler tanto sobre o tratamento de exceções no Java?

Confesso que são tantas opiniões bem fundamentadas que fiquei confuso. Certamente sou favorável a um fork do Java, mas não para tirar as checked exceptions. Antes disto, acho que precisariam limpar os "deprecateds" para tornar mais enxuto o tal de JRE consumer. E incluir algumas facilidades que andam falando por aí.

Sobre o que fazer com as checked exceptions, gostaria de ver aplicada, em alguns casos, a sugestão do Ahé de fazer com que elas redundem em warnings ao invés de erros de compilação, principalmente nas APIs do tipo JDBC e java.io em que há uso abusivo. Com a ressalva de que se for adotada em todas APIs, dá medo pensar o que um programador relaxado será capaz de fazer em termos de Exception Hidding.

Pelo medo que descrevi na última frase, acho boa a sugestão do Tim O’Brien de criar uma anotação para facilitar o empacotamento automático das exceções checkeds em uncheckeds. Uma anotação do tipo da @ApplicationException do EJB 3.0 para todo o Java SE também parece interessante.

Espero pelo menos ter chamado a atenção para a importância de discutir o assunto dentro do seu projeto para não ser vítima futura da ira do help desk.

Tratamento de exceções - Parte 2 – Mudanças no conceito de uso das exceções

Continuação de Tratamento de exceções - Parte 1 – Um pouco de história

Tendência mais moderna de tratar as exceções no Java.

Vamos começar dando a palavra a um dos criadores do Java, James Gosling em uma entrevista publicada em setembro de 2003 ao Bill Venners da artima:

“Lots of newbie's coming in from the C world complain about exceptions and the fact that they have to put exception handling all over the place—they want to just write their code. But that's stupid: most C code never checks return codes and so it tends to be very fragile. If you want to build something really robust, you need to pay attention to things that can go wrong, and most folks don't in the C world because it's just too damn hard.

One of the design principles behind Java is that I don't care much about how long it takes to slap together something that kind of works. The real measure is how long it takes to write something solid. ”

Como disse no blog anterior, quando aprendi Java, não questionei muito o modelo de tratamento de exceções e era um newbie vindo do mundo C. Mas, como quase todo mundo, achei um pouco complicado a obrigação tratar de exceções das classes da API do Java. Como exemplo de exceções difíceis de entender porque eram checked, lembro de algumas das exceções das versões antigas do JDBC, que ao meu ver deveriam ser consideradas como erros irrecuperáveis.

Naquela época não havia uma boa fonte para entender de forma clara como fazer tratamento de exceções como é o capítulo 8 do livro Effective Java do Joshua Bloch ou o artigo Lidando com Exceptions do nosso amigo Fábio Kung.

O Fábio abordou com muita propriedade o uso das unchecked exceptions e das checked exceptions de acordo com as recomendações do Java pois afinal a Caelum onde dá aulas, entre outras coisas, prepara alunos para certificação Java.

Vamos ver a recomendação oficial da Sun para usar as unchecked exceptions:

No fim está escrito:

“Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.”

Na visão dos tutoriais oficiais do Java, unchecked exceptions devem ser usadas só para os erros.

Este assunto das exceções do Java já causou muita briga e com certeza é um dos mais controversos da linguagem. Como já disse antes, nenhuma outra linguagem adota as checked exceptions.

São muitas as críticas em cima das checked exceptions do Java. Alguns autores as abominam e recomendam procedimentos alternativos para transformar ou embalar algumas delas em unchecked exceptions. Uma busca no google mostra que a discussão do assunto é interminável.

No meu caso, ao contrário de ter a visão newbie e estúpida citada pelo Gosling, talvez apenas não tenha enxergado com muita profundidade que as coisas poderiam ser de outro jeito e as aceitei sem discutir. Assim, minha primeira reação foi de surpresa quando li as primeiras críticas sobre as recomendações de uso das checked e unchecked exceptions. Algumas das reclamações partiram de gente muito influente na comunidade Java e causaram bastante polêmica.

O primeiro autor que vi se insurgindo contra as checked exceptions foi o Bruce Eckel, autor do livro Thinking in Java disponível para download. Na 3ª edição lançada em dezembro de 2002, no capítulo 9 Error Handling with Exceptions, vejam o título Perspectives. Nele o Bruce escreve bastante contra as checked exceptions, apesar de que na minha opinião, não resume claramente porque elas não foram uma boa idéia. Ele cita que o Martin Fowler pensava o mesmo e atribui ao Fowler a seguinte frase: “...on the whole I think that exceptions are good, but Java checked exceptions are more trouble than they are worth”. No mesmo capítulo sob o título Converting checked to unchecked exceptions há um exemplo de um wrapper para “desligar” as checked exceptions. Ver também:
http://mindview.net/WebLog/log-0025
http://www.mindview.net/Etc/Discussions/CheckedExceptions

O segundo a me alertar foi para ter cuidado com o uso delas foi Rod Johnson no livro de 2003, J2EE Design and Development. É um ótimo livro e para mim, o capítulo 4 é leitura recomendada para qualquer desenvolvedor. O capítulo 4 pode ser baixado em http://www.theserverside.com/tt/articles/article.tss?l=RodJohnsonInterview

Neste capítulo 4, sob o título Exception handling – Checked or Unchecked Exceptions, ele tece importantes considerações e diz que o uso de checked exceptions acarreta alguns problemas tais como:

• Aumentar o tamanho do código,
• Torna o código mais difícil de ler
• Incentivar o empacotamento e relançamento de exceções que deveriam interromper o processamento
• Fragilizar a assinatura dos métodos
• Não funcionar bem com interfaces

O Rod é menos radical que o Bruce e acredita que há lugar para as checked exceptions. Porém não recomenda seu uso, a menos que se possa lidar com o problema dentro da lógica do sistema, como por exemplo um limite de gastos excedido em uma dada compra. Na dúvida sobre o que usar, sugere optar por unchecked exceptions. O seu framework Spring provê uma infra-estrutura baseada em unchecked exceptions para encapsular as inadequadas checked exceptions do JDBC e de versões antigas do Hibernate. Mas em uma das famosas brigas sobre este assunto nas discussões do TheServerSide, comentando a entrevista do James Gosling, ele escreveu:

“I actually like the fact that Java has checked exceptions. I use them to enforce callers to react to recoverable conditions. I think I would miss that in C#. It's just that I see an important role for unchecked exceptions as well.”

Acho que devo citar também a entrevista do Anders Hejlsberg na artima com o título The Trouble with Checked Exceptions onde ele defende porque o C# não adotou as checked exceptions.

Repito que durante muitos anos usei as checked exceptions sem maiores questionamentos. Talvez alguns de vocês ainda tenham a mesma posição. Mas é sintomático o que vem acontecendo:

• No EJB até a versão 2.1, era necessário capturar ou lançar um monte de exceções sendo algumas delas de pouco significado. Definir o local para fazer o tratamento correto das exceções era uma das dificuldades de usar os já complicadíssimos EJBs. Havia também uma diferença de conceito entre as exceções unchecked e checked em que nestas últimas, o container não fazia roll back e era feito o commit da transação com erro.
• Com o modelo de POJOs do EJB 3.0 estas questões ficaram mais simples. E das 16 exceções do EJB 3.0, 11 são do tipo unchecked
• No EJB 3.0 apareceu a anotação @ApplicationException para indicar a política de roll back para exceção a ser lançada por erro de lógica do negócio em contraposição aos erros do sistema. Antigamente isto era papel das checked exceptions.
• No Hibernate anterior a versão 3.0, todas as exceções lançadas eram checked. Isto foi feito influenciado pelo JDBC que somente lança este tipo. Mas exceções em operações de bases de dados em geral são erros fatais e assim muita gente fazia como o Spring e as empacotava como subtipo de RuntimeException que é unchecked. O Hibernate da versão 3.0 em diante só lança unchecked exceptions.
• No JPA as exceções são todas unchecked possivelmente por influência da turma do Hibernate, do Toplink e do JDO que também são unchecked
• A API do JSF se baseia em unchecked exceptions enquanto outras mais antigas como Servlets e JMS, só tem checked exceptions
• A API java.io, seguindo o mau modelo do JDBC, usa checked exceptions enquanto o java.nio usa unchecked
• O JDBC 4.0 que saiu com o Java 6 não mudou o conceito de checked para unchecked como muitos gostariam. Mas deu uma bela repaginada nas suas exceções permitindo mostrar erros um pouco mais significativos.
  

Acho que poderia encontrar mais exemplos. A lista acima mostra que o entendimento das exceções mudou, mesmo dentro da Sun. No mínimo se pode dizer que antigamente se abusava do uso das checked exceptions e que agora as novas APIs as usam menos ou usam melhor como no JDBC 4.0 e no EJB 3.0.

Se até a Sun está rediscutindo o uso das exceptions, então é claro que definir uma política coerente para tratamento das exceções deve ser motivo de discussão dentro das equipes de projeto para que esta importante facilidade do Java seja bem usada.

Sem regras claras, programadores simples mortais como nós, às vezes perdem a paciência com tanta exceção para tratar e acabam esquecendo de gravar em log. Isto é tão ruim que o Rodrigo Kumpera, cansado de tanto encontrar esta falha por aí, a denominou de Exception hidding e a incluiu no excelente texto Métrica definitiva da qualidade de um projeto J2EE.

As recomendações do Fabio Kung são um ótimo ponto de partida para as equipes que ainda não criaram suas próprias regras. E quem usa regras antigas, deve fazer como a Sun e o Gavin King do Hibernate e reavaliar como elas são aplicadas atualmente na prática.

No próximo blog vamos ver o que escrevem por aí sobre a remoção das checked exceptions do Java.

Tratamento de exceções - Parte 1 – Um pouco de história

Um pouco da história do porque das exceções do Java serem como são.

Conta o Bjarne Stroutrup, que lá pelos idos de 1984 a 1986, durante o projeto do C++, foi considerada a possibilidade de incluir o tratamento de exceções logo na primeira versão. Isto foi adiado por medo da complexidade adicional que acarretaria à linguagem e também para dar mais tempo ao estudo das suas conseqüências no projeto e na implementação. A avaliação do mecanismo de exceções se estendeu de 1984 até 1989. Foi a primeira facilidade do C++ aberta para discussão pública. O Andrew Koenig, o tal do famoso livro “C Traps and Pitfalls”, e o próprio Bjarne Stroutrup, se dedicaram muito a esta causa. Mas muitos outros tiveram papel importante nas complexas discussões.

Para sentirem o tom das argumentações, o professor Doug McIlroy, um dos gênios do Bell Labs, se colocou contra a inclusão dizendo que os programadores escreveriam código menos confiável lançando exceções ao invés de entender a causa do problema [1]. O Bjarne contra argumentava, que nenhuma facilidade de linguagem consegueria impedir a escrita de código ruim. A primeira implementação de C++ com exceções em um compilador de uso geral só apareceu em 1992. Uma das premissas básicas era a de que elas deveriam ser usadas somente para tratamento de erros [2]. Outra premissa era que não deveria haver a intenção de fazer com que cada função fosse tolerante a falha.

O desenvolvimento do Java começou no início de 1991 a partir de idéias do Bill Joy para uma nova linguagem. Em uma reunião em Aspen, no Colorado, Bill Joy, James Gosling, Mike Sheradin, Patrick Naughton e outros, deram início ao projeto Stealth, que mais tarde se chamou projeto Green. A insatisfação com o uso de C++ no projeto, levou a criação da linguagem que mais tarde se chamou de Java [3].

Como disse, o C++ já tinha tratamento de exceções desde 1992. Só que ainda não era muito usado por ser opcional. Era importante para o Java ser lançado com tratamento de exceções pois precisava mostrar vantagens sobre as linguagens existentes, ao menos em termos de marketing.

Em março de 1995 apareceu o Java 1.02a, que foi a primeira versão alfa tornada pública. Durante os muitos anos dos projetos que redundaram no Java, muitas facilidades de outras linguagens foram estudadas. Fora o C++ e poucas outras linguagens, o tratamento de erros na época, era feito com as funções retornando -1 ou pelo famigerado on error goto do Basic.

O Java foi lançado contemplando o tratamento de exceções tal como é hoje, o que na ocasião foi divulgado como uma das suas grandes vantagens.

No Java o tratamento das exceções de jeito semelhante às outras linguagens é feito por classes que estendem RuntimeException ou Error. São as chamadas unchecked exceptions.

Mas o Java apareceu também com um conceito novo chamado de checked exceptions. É um conjunto especial de exceções estendendo a classe Exception. São checadas em tempo de compilação para conferir se o programador tratou a condição excepcional dentro de uma seqüência try-catch-finally ou a lançou para cima para ser tratada por quem chamou o método.

Como disse o James Gosling no livro The Java Programming Language de 1996: "As checked exceptions forçam o programador considerar o que fazer com os erros onde eles ocorrem no código". Segundo ele, isto seria muito bom porque as exceções seriam notificadas em tempo de compilação ao invés de ocorrerem em tempo de execução como ocorre com as unchecked exceptions.

Forçar o programador a tratar as checked exceptions foi resposta do Java ao fato de que o conceito de exceções existia opcionalmente no C++ e era pouco usado, talvez porque, na maior parte dos casos só eram capturadas em tempo de execução.

Na verdade, o modo de tratar exceções do Java não fez tanto sucesso como o James Gosling esperava porque poucas linguagens adotaram coisas semelhantes e as que o fizeram, usaram condições mais relaxadas. Exatamente como no Java, eu particularmente não tenho notícia de nenhuma outra linguagem. Só para lembrar, o C# não tem as checked exceptions.

Finalizo a história do tratamento de exceções dizendo que quando aprendi Java em 1996, achei muito boa esta novidade do tratamento de exceções e apesar de ter achado um pouco complicado, gostei muito das checked exceptions.

[1] O Doug foi um dos 6 pioneiros do Multics, um projeto extremamente ousado da Bell Labs e anterior ao Unix. Aliás, o nome Unix veio justamente de uma piada do Brian Kernighan em relação ao Multics:
Unix = "One of whatever Multics was many of" ou "Multics without balls". Ver: http://www.multicians.org/unix.html

[2] O livro do Bjarne Stroutrup, C++ Programming Language 2nd Ed de 1991, descreve as exceções mais diz que não há nenhuma implementação disponível. Lá ele enfatiza que sempre que possível se deve manter fidelidade ao princípio: “exception handling is error handling”.

[3] History of the World Wide Web - 1.4. History of Java

Tratamento das exceções no Java

Trilogia sobre o tratamento das exceções no Java

Trilogia, s.m. = Poema dramático composto de 3 tragédias apresentadas nos jogos solenes da Grécia antiga. Também conjunto de três obras ligadas entre si por um tema comum.

• Parte 1 – Um pouco de história
  Um pouco da história do porque das exceções do Java serem como são.
  
  
• Parte 2 – Mudanças no conceito de uso das exceções
  Tendência mais moderna de tratar as exceções no Java.
  
  
• Parte 3 – Discussão sobre a remoção das checked exceptions do Java
  Comentários sobre o blog do Gafter