25 links recolhidos dentre meus favoritos

Para não pensarem que abandonei o blog só porque ando ocupado tratando de um antigo legado em Fortran e envolvido com sistemas não lineares, engenharia, matemática, computação gráfica e outras xaropadas, resolvi colocar aqui uma lista rápida de 25 links. Não inclui todos os melhores que conheço porque evitei colocar blogs que são as minhas melhores fontes. O poucos blogs que aparecem são o do Almaer, que costuma publicar bons links, e o da Caelum, que tem vários ótimos autores.

http://www.almaer.com/blog/

http://www.apl.jhu.edu/~hall/java/

http://www.artima.com/index.jsp

http://blog.caelum.com.br/

http://www.cafeaulait.org/

http://www.ddj.com/

http://dev2dev.bea.com/

http://www.developer.com/

http://www.ibm.com/developerworks/

http://www.infoq.com/

http://www.java-channel.org/

http://www.javalobby.org/

http://java.net/

http://www.java.net/pub/ct/javaonecommunitycorner

http://www.javaperformancetuning.com/

http://javaposse.com/

http://www.javaranch.com/

http://java.sys-con.com/

http://www.javaworld.com/

http://www.jot.fm/issues/issue_2007_09/

http://www.nist.gov/dads/

http://www.onjava.com/

http://www.parleys.com/display/PARLEYS/Home

http://www.softbear.com/people/larry/javalm.htm

http://www.theserverside.com/

Quase tudo em inglês porque quem não consegue ler inglês técnico com fluência é melhor abandonar a área de TI.

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

Ecosistema do Google se expandindo

Só dá o Google. Comecei a usar o Google praticamente quando ele começou e virou logo sinônimo de busca. Agora já uso um monte de coisas "Google" como Search, Blogger, Orkut, Groups, Maps, Reader, Analytics, Images, Video, Labs, Code, Calendar, alguns que baixei, mas não uso, como o GWT, Picasa e o Desktop e os que ainda não experimentei, entre eles o Docs & Spreadsheets. Isto sem falar no monte de APIs para Search, Maps, AdWords, AdSense, GData, etc..

Hoje acontece o Google Developer Day e eles estão lançando mais uma novidade: Gears

O que vem a ser isto? Tirado do Developer Knowledge Base e de Google Gears - Offline Ajax:

O Google Gears é uma extensão open source com licença BSD para o browser, que permite aos desenvolvedores criar aplicações web que podem ser executadas offline. O Gears provê 3 facilidades principais:

• Um servidor local que adiciona um cache especial ao browser e que serve recursos tais como HTML, JavaScript, imagens, etc.. O framework sincroniza com o servidor de tempos em tempos permitindo alternar o trabalho nos modos online/offline;
  
• Um banco de dados (SQLite) para acessar e guardar dados a partir do Browser;
• Um pool de work threads que provê uma API thread-like não bloqueante para o JavaScript possibilitando as aplicações web responder melhor por efetuar operações mais custosas em background.
  

Ainda tem a ferramenta de banco de dados dbquery.html

Brinde: capacidade full text search usando SQLite e o projeto open source "FTS2" do Google. Isto suporta milhões de documentos.

Segundo eles, ainda é um lançamento do tipo early-access para desenvolvedores e não deve ser usado em produção.

O que pensar? O mesmo que eu pensei para o Microsoft Surface também lançado hoje e que é impublicável.

'If Java didn't exist, would .NET?'

Pois é, hoje está todo mundo comentando a frase com que o Colm Smyth encerrou seu blog. Engraçado que o assunto do blog dele nem é a Microsoft. Ele fala da BEA e também não fala do que todo mundo está falando hoje que é o lançamento do servidor de eventos da BEA.

Como eu acho que as arquiteturas baseadas em eventos serão as próximas bolachas do pacote, para mim o lançamento de um servidor de eventos é muito mais importante do que a discussão do Colm que nem recomendo tanto assim. Mas inegavelmente a frase dele criou polêmicas.

'If Ford didn't exist, would Chevrolet?'

'Quem nasceu antes o ovo ou a galinha'

Por aí vai. Onde eu quero chegar? Pois é, muito mais longe do que vocês imaginam.

Estou escrevendo me lembrando como era produtivo meu dia sem blogs para ler. Alguém tem a receita? Preciso produzir mais e ler menos. Se alguém souber de um tratamento eficaz me avise. Pode ser até com injeção na veia. Só não posso é ficar sem Internet como fiquei em Paraty porque me dá crises de abstinência e desando a ler livros feito um desesperado.

Para os viciados como eu, aviso que já tenho mais alguns posts no forno com assuntos com menos abobrinhas.

Linguagens funcionais - parte 2

Vou viajar ao mundo dos betas .NET. Vale a pena porque as novidades parecem interessantes. Vou rumo ao desconhecido porque tenho pouca vivência com este outro mundo. Comentários corrigindo algo que não entendi direito serão muito bem vindos.

Siglas, quando acabo de aprender uma surge mais um monte. Algumas deixo de lado até que um dia fico curioso e procuro meu amigo google como fiz hoje. Queria saber o que é este tal de LINQ que a turma do .NET diz que é o futuro em termos de acesso de dados. Vou colocar aqui algumas coisas que aprendi navegando no google.

LINQ = Language INtegrated Query

É uma nova extensão para as próximas versões das linguagens da plataforma .NET também em sua próxima versão. Por enquanto só pode ser experimentada baixando versões beta do Visual Studio (orca) e da plataforma .NET. Foi concebida para simplificar consultas a dados na memória em coleções como arrays e listas, dados armazenados em bases de dados, dados em documentos XML, dados em arquivos ou em qualquer outra fonte de dados. Atende as questões de mapeamento O/R fazendo com que operações de consultas, tais como instruções SQL, façam parte da linguagem. O trocadilho do nome é para aparecer como o link que integra as consulta aos dados e as linguagens de propósito geral.

Algumas linguagens antigas como Clipper e FoxPro já tinham o acesso às bases de dados de forma embutida na linguagem. Esta facilidade acabou quando se passou a adotar o modelo cliente/servidor com as bases de dados acessadas via SQL. Pelo menos no que tange ao acesso às bases de dados, o futuro deixará a programação .NET de um jeito semelhante aos velhos Clipper e FoxPro. É claro que o LINQ vai muito mais além porque acessa diferentes fontes de dados usando os mesmos conceitos e é isto que é a novidade.

Em termos de inclusão na arquitetura .NET, o LINQ se posiciona como uma camada entre o programa e seus dados. As ferramentas do LINQ se integram na plataforma .NET como um conjunto de extensões onde cada uma tem um sabor para cada tipo de fonte de dados: LINQ para objetos, LINQ para SQL, LINQ para XML, etc.

Trata-se de mais um tentativa da Microsoft de minimizar o problema de descasamento de impedância entre as linguagens de programação e as bases de dados. Não é a sua primeira tentativa e este projeto também não é tão novo assim. Antes parecia que o caminho passaria pelo ObjectSpaces. Agora surge o LINQ oriundo do projeto Cω. Não será na primeira versão do LINQ que todos os problemas serão resolvidos como se pode ler no PDF LINQ 2.0: Democratizing the Cloud. Mas é sobre a versão 1.0 ainda a ser lançada que escrevo.

Vamos comparar um Alo Mundo bem simples atual e como será usando o LINQ. De cara alerto que o exemplo é simples demais mas acho que serve para mostrar o jeitão da coisa:
1. Alo Mundo Velho como é hoje:

using System;
static class AloMundoVelho {
  static void Main() {
    string[] words = { "Alo", "Maravilhoso", 
                       "Mundo", "Velho", 
                       "Microsoft" };
    // Pega palavras ate 5 letras e imprime
    foreach (string word in words) {
      if (word.Length <= 5)
                Console.WriteLine(word);
    }     
  }
}

2. Alo Mundo Linq quando puder usar o LINQ:

using System;
using System.Linq;
static class AloMundo {
  static void Main() {
    string[] words = { "Alo", "Maravilhoso", 
                       "Mundo", "Linq", 
                       "Microsoft" };
    // Pega palavras ate 5 letras
    var shortWords =
                from word in words
                where word.Length <= 5
                select word;
    // Imprime
    foreach (var word in shortWords)
      Console.WriteLine(word);
  }
}

Mostrei o uso do LINQ acessando um array na memória do mesmo jeito que faria se fosse uma base de dados ou um XML.Por ser muito simplório, o uso do LINQ só complicou e isto é o que normalmente acontece quando a gente adota um padrão genérico, como o bridge, por exemplo. Na medida em que as consultas se complicarem, as vantagens do LINQ prevalecerão.

O LINQ define um conjunto de operadores de consultas padronizados que permitirá filtrar, enumerar e criar projeções de vários tipos de collections usando a mesma sintaxe. Tais collections podem incluir arrays, classes enumeráveis, XML, datasets oriundos de bancos de dados e outras fontes de dados. Os operadores fornecem um meio uniforme de obter dados a partir de qualquer objeto que implemente a interface IEnumerable. É assim que arrays, collections, dados relacionais e XML são potenciais fontes de dados.
Abaixo mais um exemplo onde aparece o uso de uma expressão de consulta (query expression). Reparem na inicialização da variável local expr :

using System;
using System.Query;
using System.Collections.Generic;
class Gujeiros {
  static void Main() {
    string[] nomes = { "Paulo", "Philip", 
                       "Fabio", "Carlos", 
                       "Guilherme", "Daniel", 
                        "Meyer", "Luca", 
                       "Mauricio", "Louds", 
                       "Rafael", "thingol"};
    IEnumerable<string> expr = 
                          from s in nomes 
                          where s.Length == 5
                          orderby s
                          select s.ToUpper();
    foreach (string item in expr)
      Console.WriteLine(item);
  }
}

Nenhum dos exemplos mostra, mas é preciso deixar claro que a solução não pretende esconder a base de dados como faz o Hibernate. E é claro também que o Java não tem nada parecido com isto.

Sem o LINQ, o atual programador .NET precisa conhecer e usar linguagens como SQL, XML ou XPath, várias tecnologias e APIs como ADO.NET ou System.Xml. Isto não será mais necessário com os programas escritos em linguagens que incluem o LINQ. Para o programador menos avançado o LINQ pode ser considerado o que se chama de syntatic sugar, isto é, alguma coisa que se acrescenta sem afetar a funcionalidade e apenas torna mais "doce" o seu uso ou entendimento. Realmente seu uso diminuirá bastante a codificação.

O LINQ tem uma outra faceta que pode ser novidade para alguns programadores .NET: o mundo dele é strongly-typed. As vantagens imediatas do uso do LINQ é que as consultas serão verificadas em tempo de compilação e o programador ainda pode se beneficiar das sugestões do VisualStudio IntelliSense.

O LINQ se posiciona um passo acima da programação declarativa comum e é aqui que começo a escrever algo que tem a ver com o título deste blog. Como disse no meu texto anterior sobre linguagens funcionais, SQL é uma linguagem funcional. Só pela a inclusão do LINQ nas linguagens do .NET, já há um toque nelas de linguagem funcional. Porém, o LINQ usado com o C# 3.0, tem mais características de linguagem funcional porque o próprio C# 3.0 inclui novidades oriundas das linguagens funcionais.

Novidades do C# 3.0 (em cinza o que não é exatamente oriundo de linguagens funcionais):

• Local Variable Type Inference - é o var que mostrei no exemplo Alo Mundo. Exemplos de var:
  
  • var i = 5; // equivalente a: int i = 5;
  • var s = "isto eh uma string"; // equivalente a: string s = "isto eh uma string";
• Extension Methods (adiciona novas funções aos métodos existentes sem editar o fonte da classe)
• Anonymous Types
• Objects & Collections Initializers (dispensa múltiplos construtores)
• Lambda Expressions
  É o cálculo lambda oriundo das linguagens funcionais e que existe no Lisp, Ruby e Phyton. Exemplo:
  Func incremento = i => i + 1;
  Incremento(5); // o resultado é 6
• Expression Trees - representa Lambda Expressions como estrutura de dados
  

Mudanças como estas já motivaram algumas manifestações como:

• Is C# becoming a functional language?
• Infoq-Is C# becoming a functional language?
• Linq, Functional Vs Declarative programming
  

Final da história.

A Microsoft está incluindo facilidades das linguagens funcionais na sua plataforma. Aliás, ela pesquisa sua própria linguagem funcional baseada em coisas do Phyton, ML, OCaml, MATLAB, Scheme e do próprio C#. O site de pesquisa da F# descreve o seguinte objetivo: Combining the efficiency, scripting, strong typing and productivity of ML with the stability, libraries, cross-language working and tools of .NET. E mais: F# is a programming language that provides the much sought-after combination of type safety, performance and scripting, with all the advantages of running on a high-quality, well-supported modern runtime system.

E a Sun? Bem, como disse antes as closures vem aí. Volta e meia alguém suspira por continuations. Já li que algumas sonhadas facilidades das linguagens funcionais seriam difíceis de incluir com segurança na JVM e continuations é uma delas.

Mas se o Java está limitado, se pode procurar outros caminhos. A possibilidade de rodar scripts na JVM e ainda usar dentro do código Java, oferece algumas perspectivas de estender o Java. Na linha de pesquisa deste blog, se alguém tiver know how, tempo e coragem, vale a pena experimentar alguns engines do scripting.dev.java.net. Lá tem engine para Haskell e Scheme com Jaskell e SISC respectivamente, Phyton com Jhyton, Ruby com JRuby e o Groovy.

Conclusão e recomendação:
Como disse no outro post, mudanças estão acontecendo e algumas novidades vem justamente das linguagens funcionais. Conhecer um pouco de uma delas não toma tanto tempo assim e pode ter a sua utilidade mesmo que não seja você um Neal Gafter, Doug Lea ou um Gilad Bracha. No mínimo você estará preparado para entender o que vem por aí.

Duas alternativas de linguagens funcionais que me atraem são erlang e Scala. Ambas tem seu valor e são adequadas para processos concorrentes. Escolhi começar pelo erlang que é uma linguagem funcional do tipo do Haskel e é orientada para concorrência. Parece muito adequada para o hardware de hoje em que os processadores estão crescendo mais rapidamente de tamanho do que na capacidade de processamento. O aumento de tamanho é porque as CPUs agora tem mais núcleos sendo já comuns os processadores dual core e quad core. Em breve isto irá longe e haja software para explorar. Estou apostando no erlang com a crença de que com ele será mais fácil encarar o desafio de usar corretamente estas facilidades de hardware. Espero que o erlang me dê também as noções mínimas de programação funcional que acho necessárias para seguir entendendo as mudanças no mundo do desenvolvimento de sistemas.

}