Windshifts - Luca Bastos

25 links recolhidos dentre meus favoritos

2007-09-12T22:15:00.000-03:00

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

2007-06-29T23:20:00.000-03:00

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?

2007-06-19T18:29:00.001-03:00

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...

2007-06-15T16:35:00.000-03:00

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

2007-06-05T23:49:00.000-03:00

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:

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;
Dependências adicionais exigidas pela aplicação;
Classes responsáveis por qualquer exceção Class not found lançada;
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

2007-06-05T11:12:00.000-03:00

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

2007-06-04T21:17:00.000-03:00

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

2007-06-04T17:53:00.000-03:00

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

2007-06-04T17:06:00.000-03:00

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

2007-05-31T01:45:00.000-03:00

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?'

2007-05-29T15:04:00.000-03:00

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

2007-05-11T22:36:00.000-03:00

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:

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.

}

Linguagens funcionais

2007-05-11T17:16:00.000-03:00

Há alguns dias atrás coloquei a seguinte pergunta no GUJ:

Sei que muitas faculdades lá fora ensinam linguagens funcionais de programação e fiquei curioso de fazer uma pequena enquete no GUJ. Perguntei:

Você já ouviu falar ou já usou alguma linguagem funcional?
Você aprendeu alguma linguagem funcional? Qual? Foi na faculdade? Qual faculdade?
Se aprendeu alguma linguagem funcional, você acredita que conhecer uma linguagem funcional pode lhe dar alguma vantagem no futuro?
Se aprendeu alguma linguagem funcional, você admite que no futuro haverá espaço para programadores em linguagens como erlang, links, scala ou outra qualquer do gênero?

Vale a pena ler as respostas uma a uma. Colocarei aqui minha impressão sobre esta pesquisa. No fim revelarei parte dos motivos que me levaram a fazê-la. Em outro post, abordarei um tema que deixará claro porque acho que há motivos imediatos para que a gente procure saber mais sobre linguagens funcionais.

Mas antes de falar sobre as respostas listarei algumas definições encontradas com ajuda do google:

Java, C, Pascal, etc. são o que se chamam de linguagens imperativas no sentido em que consistem em uma seqüência de comandos. Mas o que caracteriza uma linguagem funcional?

Segundo a introdução ao Haskell, um programa funcional é uma expressão e é executado avaliando a expressão. O texto lembra que quem usou uma planilha já tem experiência com programação funcional. Nas planilhas se especifica o valor de uma célula em função dos valores de outras. O foco está no que é calculado e não no como é calculado. Outro exemplo citado é o da linguagem de consultas SQL onde se escreve a expressão sem se preocupar como ela será implementada pelo sistema gerenciador de base de dados.

Segundo http://www.nist.gov/dads/HTML/purelyfnctnl.html, linguagem funcional não permite nenhuma ação destrutiva do tipo sobrescrever dados. As linguagens puramente funcionais são livres de "side effects", isto é, a chamada de uma função não tem nenhum efeito além de avaliar o resultado da função.

Segundo http://cbbrowne.com/info/functional.html, programação funcional é um estilo de programar que enfatiza a avaliação de expressões ao invés da execução de comandos. As espressões nestas linguagens são formadas usando funções para combinar valores básicos. Uma linguagem funcional é uma linguagem que suporta e encoraja a programação no estilo funcional.

Acho que estas definições ainda não deixaram as coisas 100% claras mas o google está aí para resolver esta lacuna. Chega de definições e vamos aos finalmentes.

Não sei se o número de respostas permite tirar muitas conclusões porque apesar do tópico ter sido lido por quase 600 gujeiros, só 17 responderam.

O que consegui entender das respostas foi:

Algumas faculdades ensinam algum tipo de linguagem funcional;
Alguns desenvolvedores mais interessados já estudaram alguma linguagem funcional, mas não ficou claro com qual profundidade;
Foi citado que a exposição a uma linguagem funcional torna mais fácil entender algumas novidades pois elas muitas vezes são oriundas de alguma linguagem funcional;
A maioria não acredita que vá usar alguma linguagem funcional em sua vida profissional

O que eu posso dizer sem antecipar o assunto do meu próximo post?

Muitos esqueceram que já usam linguagens funcionais nas consultas SQL, nas planilhas, nas transformações XSLT e em muitas outras áreas. Ninguém se lembrou de que o conceito de generics do Java veio de uma extensão do Java chamada GJ. Esta é baseada em outra extensão do Java chamada pizza, que por sua vez incorpora princípios de linguagens funcionais e closures é um deles. Ah, acho que quase todo mundo no GUJ já ouviu falar em closures que é, mais um conceito do mundo das linguagens funcionais e que a gente vai usar com o Java 7.

E porque fiz esta pesquisa com nossos homens de Java?

Porque neste modelo de programação, há muita pesquisa acadêmica que repercurte também em grandes empresas como a Microsoft, por exemplo. Devido a isto, há alguns indícios que estamos em meio a uma revolução no modo de escrever programas, com as linguagens pouco a pouco incorporando as facilidades das linguagens funcionais.

Porque no Java serão incluídos alguns conceitos oriundos das linguagens funcionais já no Java 7 e possivelmente alguns outros nas versões subseqüentes. Apesar de que, no Java esta evolução será mais lenta do que nas linguagens dominadas pela Microsoft. O motivo do Java evoluir mais devagar é porque em casa que todo mundo manda ninguém tem razão. A vantagem da padronização feita em grupo do tipo JCP vira transtorno no momento de decidir rápido por mudanças mais radicais que o mercado pode exigir.

Para entender conceitos novos como closures e continuations.

Para estar apto a executar tarefas específicas programando em outras linguagens com mais facilidades de conviver com máquinas multiprocessadas como Scala ou erlang.

Há outros motivos. A motivação mais forte e imediata para aprender pelo menos um mínimo de linguagens funcionais, será assunto do meu próximo post quando falarei um pouco de .NET.

Como uma nação prova que é avançada tecnologicamente

2007-05-08T19:42:00.000-03:00

A America's Cup é a mais antiga competição esportiva que eu tenho notícia. Ela é uma competição entre países e é disputada desde 1852. Tem atraído mais público em Valência na Espanha na marina onde ancoram os barcos do que qualquer clássico de futebol brasileiro decidindo título. É enorme a atenção da mídia e as regatas passam nas TVs de quase todo mundo (mais de 150 países e o Brasil fora disto).

A Louis Vuitton Cup é a competição que define o desafiante do barco da Suiça Alinghi, o atual detentor da America's Cup e que levou a taça de volta para a Europa depois de mais de 150 anos. A LV Cup está quase na semifinal e já tem definidos os participantes: BMW Oracle Racing, Emirates Team New Zeland, Luna Rossa Chalenge e Desafío Español 2007. Falta apenas a rodada de amanhã para acabar o round robin 2 (2o turno). Nesta rodada o barco da China, que está na foto, ficou como bye e não compete mais. Hoje foi o último adeus do Dragão.

Estes barcos são extremamente sofisticados e representam o estado da arte em termos de projeto e construção naval pois a America's Cup é considerada a Fórmula 1 da vela. O orçamento de uma equipe para participar competitivamente beira ou ultrapassa os 200 milhões de Euros. Os recursos computacionais usados no projeto dos barcos são comparáveis aos do projeto de um carro de fórmula 1. Os barcos também passam por diversos ensaios em túneis de vento. Os materiais empregados são sempre de última geração causando inusitadas dificuldades de fabricação tando do casco como da mastreação e das velas.

Como eu disse antes, é uma competição entre países e o regulamento exige que o barco seja construído no país origem da equipe. Pode haver mais de um barco por país e os velejadores podem ser de qualquer nacionalidade. Como não temos um barco brasileiro, o nosso campeoníssmo Torben Grael é quem decide os rumos, ou seja, é o tático do excelente barco italiano Luna Rossa patrocinado pela Prada, Tim, mais um grande banco italiano e outros grandões que nem me lembro.

Provar ao mundo que detém conhecimentos e tecnologias inovadoras como as necessárias para construir um barco destes, é um dos meios usados como ferramenta de marketing para convencer aos importadores do resto do mundo, de que os produtos de um país são bem fabricados. Os japoneses fazem muito isto quando anunciam aqueles robozinhos que não servem para nada mas que nos deixa todos extasiados com a sua tecnologia.

Pois bem, foi isto que fizeram os chineses. Entraram para a America's Cup, perderam quase de todo mundo mas estão lá no seleto grupo de países capazes de fazer isto.

E porque não fazemos igual no Brasil? Não é por falta de torcida. Acho que é por falta de visão do nossos industriais exportadores ou dos órgãos governamentais que fomentam as exportações. E é isto que está emperrando o deslanche do projeto de repetir o feito de 2005/2006 quando aconteceu a nossa maravilhosa participação na regata de volta ao mundo Volvo Ocean Race com uma equipe quase toda de brasileiros e o super barco Brasil 1 construído aqui.

Chinês tem olho fechadinho mas parece que enxerga mais longe do que os brasileiros.

Lançado o Apache CXF 2.0 RC

2007-05-06T15:44:00.000-03:00

O Dan Diephouse anunciou hoje em seu blog que foi lançado o tão aguardado, pelo menos por mim, Apache CXF 2.0 que pretende ser um framework de serviços Open Source intuitivo e fácil de usar.

Suporta:
- WS-Addressing, WS-Policy, WS-RM e WS-Security
- Integração com Spring 2.0
- Construção de web services a partir de POJOs (sem annotations)
- Transporte HTTP, JMS e local (in-JVM)
- Serviços RESTful incluindo serviços JSON.

Download em http://incubator.apache.org/cxf/apache-cxf-20-rc-incubating-release-notes.html

Ele implementa os padrões de web services, inclusive os do JCP. Os serviços são definidos usando contratos WSDL e podem ser acessados por meio de diferentes formatos de mensagens (bindings) e protocolos de rede (transporte) incluindo SOAP por HTTP, SOAP por JMS, XML por HTTP e XML por JMS. Pretende prover uma arquitetura plugável que suporte não somente XML mas também outros tipos de formatos de mensagens com qualquer tipo de transporte.

Suporta também modelos como JAX-WS, JBI, SCA e serviços CORBA. Foi projetado para deployment flexível em vários containers incluindo os baseados em Spring, JBI, SCA, Servlet e J2EE.

Os motivos do lançamento do substituto do XFire e do Celtix ainda como Release Candidate são principalmente dois:
- Ainda estão finalizando os testes de compatibilidade com o JAX-WS TCK, apesar de que a compatibilidade total só virá na versão 2.0.1.
- Liberando logo, mais pessoas usarão e mais chance de descobrir eventuais bugs.

Recomenda-se aos usuários do Celtix e do XFire que avaliem a migração para este que é uma junção melhorada dos dois projetos. Porém databindings JiBX e XMLBeans, só serão suportados na versão 2.1. Como foi desenvolvido para o Java 5, quem usa Java 1.4 precisa se valer do Retrotranslator.

A maior parte dos serviços escritos para o XFire devem ser compatíveis com o CXF. Porém serão necessárias mudanças nos arquivos relativos ao deployment ou na configuração xml para aproveitar as vantagens das APIs melhoradas e das melhorias nos formatos XML. Vejam o XFire migration guide para saber os detalhes.

Vantagens sobre o XFire:
- Melhor suporte a WSDL
- Melhor suporte a JAX-WS
- Melhoria no transporte JMS
- Plugins Maven
- Suporte a sintaxe Spring 2.0
- Melhor suporte a WS-*
- API mais limpa para construir serviços
- Fácil de usar pontos de extensão
- Suporte a RESTful
- Suporte para um binding XML cru, que não inclui um envelope SOAP

PS: Os indianos são minoria esmagadora dentre os 20 commiters.

Não gosto de configuração programática

2007-04-26T10:15:00.000-03:00

Não queria escrever sobre nada fora do meu foco atual mas estou com um assunto engasgado que preciso colocar minha opinião pelo menos para marcar presença. Sei que muitos amigos detestam o monte de XML que precisam escrever para configurar os frameworks que usam e entendo porque não gostam de XML.

Fui um dos primeiros entusiastas na adoção de XML na integração de sistemas ainda quando trabalhava com EDI em 2000. O uso de XML tem um monte de vantagens e algumas poucas, porém quase fatais, desvantagens. Só vou falar de algumas desvantagens: violam TDD, são difíceis de localizar erros, acarretam lentidão quando usadas com parsers inadequados e principalmente ser fácil de abusar do seu uso.

Tendo em vista as desvantagens, alguns programadores resolveram expurgar o XML das suas configurações e passaram a fazer a chamada configuração programática.

Entendo por configuração aqueles parâmetros que servem apenas para permitir a instalação e ajuste fino das aplicações em diversos ambientes. Lá devem ficar as informações que podem ser alteradas pelos profissionais de suporte.

Porém nos últimos tempos há um claro abuso deste conceito. Houve uma febre para tornar os sistemas flexíveis e customizáveis. Os arquivos de configuração cresceram muito. Alguns contêm informações que só dizem respeito ao desenvolvedor do sistema e nunca deveriam estar expostos como configuração. Os arquivos enormes ficaram tão difíceis de alterar que as empresas precisam dispor de programadores especialistas nos frameworks que nada mais fazem do que gerenciar as configurações (Inner-Platform Effect). Ficou mais complexo configurar um sistema do que usar os 237 botões do controle remoto do seu home theater.

1. Solução natural do problema:

Configurar por convenção onde se pode saber por experiência onde estão as coisas.
Permitir mudanças nas convenções por convenção de forma centralizada para fazer uma vez só na vida com alterações em um único lugar.
Limitar as configurações somente àquilo que um profissional de suporte pode fazer em poucos minutos para apagar um "incêndio".
Configurações que só dizem respeito aos programadores preferencialmente devem ser feitas com anotações. É claro que respeitando as limitações e imposições dos frameworks de IoC, AOP, etc..

2. Solução adotada pelos defensores de configuração programática

Configurar via programação Java

Talvez eu esteja ficando um velho ranzinza mas acho absurdo trocar um configuration manager por outro programador e obrigar que todas as modificações sejam feitas em ambientes de desenvolvimento com Java instalado mais toda a parafernália de IDE, dependências, etc. Para mim a solução de configuração programática apenas engessa os sistemas e não toca no real problema de excesso de customização para gente que não precisa disto.

Aplicações corporativas nunca funcionam isoladas. Mensagens síncronas x mensagens assíncronas

2007-04-24T17:06:00.000-03:00

Nas empresas há dezenas de sistemas que precisam trocar informações. Estes sistemas, algumas vezes, foram desenvolvidos de forma independente visando resolver algum problema isolado. Sendo assim ou não, quase todos precisam se integrar aos demais, trocando informações e serviços.

Muitos programadores desenvolvem as trocas de mensagens e as chamadas a comandos em outros sistemas usando mensagens síncronas. Isto geralmente exige algum esforço de programação para ter garantias de que as mensagens chegam ao destino. Talvez a maior parte das aplicações que usam web services para integrar aplicações o façam trocando mensagens síncronas.

Este post serve apenas para lembrar que há vantagens na integração de sistemas usando troca de mensagens assíncronas que usa a abordagem "envie e esqueça": Quem envia as mensagens ou pedidos de execução de comandos não precisa ficar parado esperando a resposta. Esta pode vir posteriormente e ser recebida via callback por alguma thread que a escute. As principais vantagens são:

As mensagens ou chamadas a comando podem ser retransmitidas e assim a confiabilidade global do sistema aumenta muito.
Por não precisar ficar bloqueado esperando resposta, melhora o uso dos recursos dos sistemas e assim também a escalabilidade.

Usar mensagens assíncronas não é mais difícil nem mais caro. Apenas exige que se inclua na arquitetura um provedor de serviços de mensageria. Para a nossa sorte há vários provedores gratuitos com bom desempenho com boas facilidades de gerenciamento.

Em termos de programação Java o esforço não aumenta muito por 2 motivos:

A API JMS é boa, estável e fácil de programar mesmo sem auxílio de Message Driven Beans;
A parte "suja" da programação para garantir o recebimento das mensagens fica por conta do provedor de mensageria.

Então o que você está esperando para mudar seus paradigmas e diminuir o acoplamento entre seus sistemas? Se é por falta de livros seus problemas acabaram pois aí vão 2 dicas boas:

Java Messaging do Eric Bruno
Enterprise Integration Patterns de Gregor Hohpe e Bobby Woolf com várias contribuições de outros.

Pois é, comecei. Alia jacta est

2007-04-24T15:24:00.000-03:00

Será que conseguirei tempo para escrever alguma coisa por aqui? Sei lá, vou tentar.

Meu interesse atual é CEP/ESP/EDA, isto é, sistemas movidos por eventos. Quais são estes sistemas? Quase todos os sistemas corporativos que trocam mensagens dependem de eventos ou usam regras baseadas em fluxos de eventos para tomada de decisões.

Já que falei em trocas de mensagens, é claro que JMS, ESB, SOA e Web Services também fazem parte dos meus interesses e talvez escreva sobre isto. Se possível usando o Apache Camel para modelar as mensagens como tenho feito em brincadeiras caseiras.

Finalmente há 2 assuntos, que se sobrar tempo, pretendo abordar, pois são antigos interesses meus: aplicações servidoras e JMX, sendo este último assunto uma das jóias raras do Java.

Ah, e porque windshifts que significa rondadas de vento? Como antigo velejador, espero que as rondadas de vento me sejam favoráveis e me dêem motivação para escrever.

É isso aí, jogo feito, as cartas estão na mesa.