Todos os dias a primeira sessão do dia no JavaOne é uma General Session e começa às 8h30 da manhã. Tendo em conta que normalmente são vendor talks (Oracle, AMD, etc.) ficou oficialmente decidido que essa hora será sempre gasta na noite anterior no consumo de cerveja.

The Script Bowl: A Rapid-Fire Comparison of Scripting Languages

O dia começou com um painel muito muito interessante sobre linguagens de scripting ou, como prefiro chamá-las genericamente, dinâmicas. O painel consistiu de 4 linguagens (Groovy, JRuby, Jython e Scala) cada uma com um seu defensor a quem cabia o papel de defender a sua linguagem preferida em 3 rounds. Os defensores eram os seguintes:

• Guillaume Laforge pelo Groovy
• Charles Nutter pelo JRuby
• Frank Wierzbicki pelo Jython
• Jorge Ortiz pelo Scala

A sessão consistiu em 3 rounds, em que o público podia votar por sms em tempo real. Os rounds eram os seguintes:

1. Criar uma aplicação cliente de twitter (applet)

Aqui tanto a aplicação em groovy como em jruby destacaram-se pelo aspecto gráfico polido. A solução em jython foi bastante básica e em cima do joelho e a de Scala mostrou muito bem como usar closures para tratar de eventos e deixou uma impressão muito boa.

2. Criar uma aplicação web que gerisse países e cidades, com integração com mapa

Aqui o groovy dominou totalmente com o Grails. Além de o código ser muito mais perceptível do que o de jruby com o rails, usou uma tag custom para a integração do mapa que deixou a audiência com os olhos a brilhar. A solução do jython foi com django e limitou-se a demonstrar a geração automática da secção de admin sem grandes costumizações, nem mesmo com o mapa. O moço do Scala deitou tudo a perder não tendo implementado a aplicação web porque perdeu muito tempo na applet – e ele é um dos core developers do Lift, uma web framework escrita em Scala!. Aproveitou para demonstrar as funcionalidades de comet / reverse ajax / data push de uma forma simples.

3. O último round foi um vale tudo – basicamente pediram para mostrarem e defenderem o que a linguagem deles

fazia melhor que as outras.
O defensor do Groovy optou por defender a integração com Java; o Charles Nutter mostrou uma aplicação muito interessante em que uma aplicação de visualização respondia ao som e pitch da voz dele; o do jython não me lembro realmente do que disse; o do Scala defendeu a forma como o Scala trata da questão de concorrência com os actors.

Foi uma sessão com um ambiente descontraído, com demonstrações giras. A idea com que fiquei foi muito favorável para o Groovy/Grails e para o Scala, para coisas mais server-side.
Na votaçao do público, o JRuby recebeu os votos dos seus fãs e ficou em primeiro, seguido do Groovy, Scala e Jython em último.

Improving Application Performance with Monitoring and Profiling Tools

De seguida fui para uma apresentação que foca no meu outro tema de preferência além da área web: performance/concorrênca. Falou-se de ferramentas de CPU, de memória e de uso genérico.
Esta apresentação consistiu numa apresentação de uma enormidade de aplicações que se podem usar para monitorizar e fazer profiling de aplicações java. Foram elas:

• DTrace

O DTrace é interessantíssimo e já tinha lido alguma coisas sobre o mesmo, especialmente do pessoal dos Macs. E aí reside a sua principal limitação: apenas está disponível em Solaris e OS X no JDK 6 e eu não conheço nenhum sistema de produção que tenha esta configuração.
Permite obter informações muito importantes como seja a contenção de locks, o tempo de garbage collecting ou os tempos de invocaçao

comprar cialis generico en española

por método. Tudo isto é obtido de forma live, em que se faz attach ao processo java que está a correr e se retiram os dados enquanto ele executa.
No entanto, DTrace é relativamente complexo pois implica a criação de scripts próprios (chamados DScripts). Foram indicadas duas ferramentas auxiliares: Chime para formatar o output e D-Light, que é um UI para criar DScripts facilmente.

• Sun Studio Collector/Analyser

Ao contrário do DTrace, o Collector não faz attach a um processo e funciona por sampling. Ou seja, temos de correr um processo num outro ambiente, que vai recolher dados para analisar e depois para o processor e usar o Sun Studio. Está disponível tanto em Solaris como em Linux.
Serve como substituto do DTrace para quando não se usa Solaris ou OS X.

• JPS, JInfo e JStack

Estas aplicações são bastante simples e disponível nas versões 1.4.2+. O JPS permite listar process IDs de aplicaçoes java a correr; o JInfo permite ver informações como propriedades de sistema, flags da VM e inclusivamente mudar as flags da VM (Permite-nos retirar estas informações a partir de um core dump); JStack permite-nos gerar stack traces de forma simples e é bastante útil para identificar deadlocks.

• BTrace

O BTrace não é bem uma aplicação mas mais uma framework. Permite-nos criar os nossos proprios

viagra cheap

scripts, que tiram partido de anotações, para obtermos as informações desejadas através de bytecode intrumentalization. Está disponível apenas na versão JDK 6 e em Solaris, Linux e OS X.

• GCHisto

Esta pequena aplicação permite-nos detectar o comportamento do garbage collector visualmente. Requer que a aplicação seja executada com as flags -XX:+PrintGCTimeStamps e -XX+PrintGCDetails pois desenha os histogramas baseado nos logs do GC.

• JMap

Esta aplicação permite listar os objectos existentes na heap. Disponível na versão 1.4.2+ mas apenas em Solaris.

• JHat

O JHat permite, a partir de um binary heap file (que pode ser criado com o JMap), pesquisar por objectos na heap. Para tal, usa algo a que chamam OQL (Object Query Language), que não é mais que Javascipt com uns objectos especiais para pesquisar na heap. Está disponível a partir da versão 6 do JDK, sendo que para versões anteriores o projecto chamava-se simplesmente Hat.

• JConsole

A JConsole era a única aplicação que eu conhecia de todas as que foram faladas. Disponível desde a versão 1.4.2, permite consultar dados sobre memória, threads, MBeans e outras informações a partir de uma simples applet.

• Netbeans Profiling Tools

Incluído com o IDE Netbeans, vem este pacote de profiling tools que usa o motor JFluid para retirar dados de CPU, memória e threads. A integração com o IDE pareceu interessante embora não tenha sido demonstrada, mas pode-se marcar pontos de profiling como se se marcassem breakpoints directamente no IDE. Certamente a testar, com este hype todo à volta do Netbeans.

• VisualVM

O produto VisualVM foi o culminar da apresentação, o ponto a que eles queriam chegar. Inclui funcionalidades do JPS, JInfo, JStack, Jconsole e JStat. Além disso é extensível com plugins para o Btrace, GCHisto ou mesmo Glassfish ou Terracotta.

Java Persistense API 2.0

A sessão sobre JPA foi definitivamente a mais fraca dos dois dias até agora. Foi um debitar das alterações existentes na especificação do JSR 317 pela spec leader e muito pouco pedagógica. As pessoas ficaram com sono e não captei realmente nada assim de importante além da ideia que se está a complicar um bocado a coisas. Coisas como o Doctrine para php têm implementações bem fáceis de entender para os mesmos problemas, ou então a sessão conseguiu complica o simples.
O que valeu foi ter podido falar um pouco com o Michael Santos que além de Java Champion, é co-lead do JSR 310 (Date & Time API). Tive a oportunidade de ele referir as relações deste JSR como o de JPA, bem como o do J2EE 6 (JSR 316)que deverá também usar o JSR 310. Foi uma boa companhia para a sessão.

Transactional Memory in Java Technology-Based Systems

Esta foi provavelmente a sessão mais trabalhosa do JavaOne até ao momento. Foi apresentada por dois membros da Intel e um deles tinha um sotaque completamente russo o que tornou quase impossível perceber metade da apresentação. Foi no entanto bastante divertido pois sempre que ele falava saia 5% da sala.
A apresentação em si focou-se nos pontos de atomicidade que já tinha visto ontem nas apresentações de Fortress e do Brian Goetz. Falou-se memória transaccional por software (STM) e também por hardware (HTM), que desconhecia por completo. Dentro da STM, focaram o McRT que é o Multi-core runtime da intel que oferece funcionalidades de memória transaccional por software. Por enquanto apenas está disponível em C++, mas prometeram a versão para Java num dia de são nunca à tarde.

JSR 303: From a World of Constraints to Constrain the World

Sessão bastante interessante apresentado pelo leader do JSR 303, funcionário da JBoss. Falou-se sobre como e onde definir constraints no nosso modelo de domínio de forma a que seja independente de camada – uma validação deve ser homogénea desde a apresentação à base de dados.
O que esta especificação permite é a especificação de constraints de validação sobre beans/pojos de diversos tipos – simples e built-in, custom made, com dependências entre campos, etc. – e que fornece uma forma de cada camada poder executar as validações. Não define como essas camadas tratam o resultado das validações, portanto é bastante genérico, tem apoio de todos os quadrantes da indústria e rapidamente se vai tornar standard.
Além disso o speaker foi bastante acessível e simpático.

Comet: The Rise of Highly Interactive Web Sites

Eu já há bastante tempo que sei o que é Comet, o conceito é bastante simples: permitir que uma acção num cliente (tipicamente página web) seja reflectido em todos os clientes que estão na mesma vista sem que estes tenham que fazer nada. Mas não tinha a noção das diferentes aproximações do problema.
Esta sessão foi apresentada pelo Joe Walker do DWR, que explicou como o DWR usa o comet para fazer push de dados para o cliente; e pelo Alex Russell, o homem do Dojo Toolkit e do Cometd. Falaram de duas aproximações distintas: enquanto o DWR tem o Comet embutido e o push de dados para o cliente faz parte da lógica de apresentação da aplicação; o cometd é como que um servidor proxy, muito útil para aplicações já existentes pois os clientes ligam-se é ao servidor Cometd para receberem os updates.
Foi uma apresentação muito esclarecedora de duas pessoas que demonstraram serem mesmo os speakers ideais para o assunto.

Real World, Not Hello World: GWT Development for Java™ Technology Shops

Tinha planeado ir ver uma apresentação sobre JRuby pelo Ola Bini mas acabei por ficar na mesma sala para a apresentação seguinte. Por um lado, fiquei com menos entusiasmo pela as apresentações jruby depois do script bowl; por outro, conheci o Alexandre Gomes no jantar dos JUG Leaders e fiquei também para o ver a palestrar.
Esta apresentação foi tripartida: o Alexandre falou sobre GWT, um membro da equipa do IceFaces falou sobre o Comet deles e o líder do project Grizzly falou sobre o projecto em si e a integração com GWT.
Eu pessoalmente continuo a não estar totalmente convencido com a solução GWT mas estou a dar a oportunidade de ser surpreendido. O modelo de desenvolvimento à lá Swing com definição de layout e widgets no código java não me cai bem.
De qualquer modo, gostei bastante da apresentação do Alexandre e dos colegas dele.

No fim do dia, decidi ir até à festa de Eclipse onde supostamente havia cerveja gratis mas nada disso. Pelo caminho conhecemos um texano muito simpático que nos acompanhou numas cervejas e que pensava que Portugal era na América do Sul. Simpáticamente explicámos onde ficava no mapa o que mesmo assim não impediu que ele ficasse realmente envergonhado com a bacorada. Mas foi uma conversa excelente mesmo no que toca a empreendorismo.
O interessante da festa da eclipse foram na realidade 2 outros factos: em primeiro lugar, o director de marketing da Jetbrains, criadores do IntelliJ IDEA estava por lá, esse mesmo que oferece as licensas de IntelliJ que podemos distribuir nos eventos do nosso PT.JUG; também por lá estava o Rod Johnson, criador do Spring a assinar autógrafos e com raparigas giras à volta à procura de festa: é mais uma razão para participar em projectos open-source.

E assim foi, mais um dia cansativo mas a tentar aproveitar ao máximo a experiência do JavaOne.

disponibilizá-los também no Slideshare.
Coloco aqui as 3 apresentações.

Developers Java: O que as e

no prescription viagra

mpresas dizem que precisam mesmo

cheap cialis

mesmo

Por Fernando Fernandez

| View

Lightweight Grids with Terracotta

Por Cesario Ramos

| View

Web 2.0 em Java com Google Web Toolkit

Por Hugo Pinto

| View

Enjoy!

Esta conversa já me surgiu em diversas ocasiões e voltou a despontar numa thread na mailing list do PTJUG, e confesso que tenho alguma dificuldade em compreender a enorme resistência que imensos programadores apresentam em apren

der e utilizar javascript. Isto é, baterem código mesmo em javascript sem usar frameworks que gerem o código todo – e.g. GWT, ou helpers de php, ruby, etc. -, mas usando obviamente bibliotecas como o prototype, jquery, etc.

Javascript é uma linguagem dinâmica, weakly typed e prototipada. Logo aqui, há diferenças para as linguagens que a maioria usa: C#, Java (statically generic cialis no prescription e strongly typed) e python (dynamically mas strongly typed). O modelo de prototipagem é um pouco diferente do modelo de classes para definição de objectos, por isso percebo que possa introduzir confusão ou pelo menos dar origem a um novo processo de aprendizagem.

Mas não é assim tão complicado como isso…

Razões para usar javascript directamente, não ter medo e assumi-lo com orgulho

1. Desenvolvimento web = (X)HTML + CSS + Javascript + linguagem_server_side

Quer sejamos programadores java ou de uma outra tecnologia web, a probabilidade de termos de usar ou gerar html, css e javascript é muito elevada. Podemos inclusivamente usar geradores mas como facilitadores e não por sermos incapazes de produzir código de qualidade numa linguagem dinâmica ou, pelo menos, compreender o código que estamos a gerar. Devemos poder mudar de linguagem e continuar a dominar a parte de interface web, apenas tendo de aprender conceitos da outra linguagem/plataforma.

2. jsFUD

Durante muito tempo, javascript foi muito pouco estudado e visto como uma linguagem de scripting básica que permitia escrever umas linhas de código. Não havia propriamente estruturação de código e muita gente entende que programar javascript é isso. É um pouco como aquelas aplicações java de alunos de primeiro ano que metem 2000 linhas de código num só ficheiro ao monte.
Hoje em dia javascript não é isso, é uma linguagem madura, os problemas de interoperabilidade entre browsers são mitigados com as novas bibliotecas, estão a ser preparadas virtual machines (compilação JIT incluída) que melhorarão imenso a performance de código no browser, há uma proposta de uma nova versão da linguagem (resumo da nova especificação) com possibilidades de verificação de tipos estática e outras features que fazem dela uma linguagem muito mais parecida com algo tipo java (ActionScript é a coisa mais parecida actualmente).

3. Javascript não é só web

Nos últimos meses tenho desenvolvido aplicações com a suite de BPM Teamworks da Lombardi que utiliza javascript como linguagem de programação para as actividades dos BPMs. A utilização de javascript nestes moldes ou, melhor ainda, como linguagem para desenvolver plugins ou algo semelhante para aplicações, tirando partido das suas propriedades dinâmicas é altamente refrescante. Basta usar os jars que a Mozilla fornece com a implementação do projecto Rhino.

4. JSON

Poder estar a programar e definir as minhas estruturas de dados em formato JSON é magnífico. É menos verboso, simples e escrevo muito menos new’s.

5. Abrir horizontes

Last but not least, não devemos ter receio de linguagens dinâmicas. Um programador java tem um trabalho confortável e laborioso: estamos protegidos com verificações estáticas em tempo de compilação, checked exceptions e outras demais coisas o que nos dá segurança e permite apanhar erros cedo; por outro lado, tudo isto nos dá mais trabalho sem muitas vezes nos garantir qualidade do software (para isso preferiria ter contratos estritos definidos entre os componentes com verificações em tempo de compilação e runtime, o que seria demais para a maioria nos sistemas).
Trata-se pois, de uma questão de encontrar a chave de fendas que funcione melhor com o parafuso. Sejam linguagens dinâmicas ou não, o que interessa é a que produza melhor resultado final e isso pode nem sequer depender da linguagem mas de outros factores externos como a equipa, o tipo de requisitos, etc.

Em termos de resumo, coisas como o GWT são excelentes paradigmas mas não se deve perder de vista o que se passa debaixo do capô. Experimentem desenvolver uma aplicação em javascript para testar o poder da linguagem. Repito, uma aplicação, não um bloco de script.

Bastante útil para fazer mashups e coisas desse género.