Consumer JRE

Quarta-feira, Junho 6, 2007 por Luca Bastos



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

Terça-feira, Junho 5, 2007 por Luca Bastos


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

Terça-feira, Junho 5, 2007 por Luca Bastos

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

Segunda-feira, Junho 4, 2007 por Luca Bastos


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

Segunda-feira, Junho 4, 2007 por Luca Bastos



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 2Mudanças no conceito de uso das exceções
    Tendência mais moderna de tratar as exceções no Java.

  • Parte 3Discussão sobre a remoção das checked exceptions do Java
    Comentários sobre o blog do Gafter

Ecosistema do Google se expandindo

Quinta-feira, Maio 31, 2007 por Luca Bastos


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

Terça-feira, Maio 29, 2007 por Luca Bastos


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.

Hello world!

Quinta-feira, Maio 17, 2007 por Luca Bastos

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

Linguagens funcionais – parte 2

Sábado, Maio 12, 2007 por Luca Bastos


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

Sexta-Feira, Maio 11, 2007 por Luca Bastos


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:

  1. Você já ouviu falar ou já usou alguma linguagem funcional?
  2. Você aprendeu alguma linguagem funcional? Qual? Foi na faculdade? Qual faculdade?
  3. Se aprendeu alguma linguagem funcional, você acredita que conhecer uma linguagem funcional pode lhe dar alguma vantagem no futuro?
  4. 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.