Zona J

Na sessão de JUG Leaders em que estive no JavaOne, o Matt Thompson (que agora anda pelo Twitter) que é um dos directores do java.net, entre outras coisas, pode ter feito um anúncio.

Ao falar sobre linguagens que correm na JVM no meio sem querer falou de PHP seguido de um “Oops, I just made an announcement”. Se estaria a brincar ou não, a ideia de a Sun suportar oficialmente PHP na JVM não me parece totalmente descabida. Tal como foram buscar pessoal do python para trabalharem no Jython, não me admirava de o mesmo se suceder com o PHP.

O foco na máquina virtual como plataforma quase agnóstica à linguagem de programação está a ser e será de extrema importância. Tanto pelas opções que oferece aos actuais programadores java, bem como a capacidade que tem de atrair programadores e projectos que não correm actualmente na plataforma java.
Este último caso é especialmente importante no caso do PHP, que tem um número gigantesco de developers e projectos de grande dimensão que podiam ganhar com os serviços enterprise que J2EE pode oferecer.

Não se resolve no entanto, aquela que é uma grande vantagem do php e outras linguagens que é a facilidade de deploy. Eu pessoalmente já tive na escolha de tecnologia como factor de ponderação a impossibilidade de conseguir web hosting decente para java, enquanto qualquer hosting tem php e outras linguagens. Este é um factor que faz com que muita gente se inicie e especialize em php.

Mas seria certamente interessante ter o PHP suportado pela Sun. O desafio técnico não é grande, o pessoal da Caucho já provou isso com o Quercus.

Eu bem sei, passou um pouco mais de 2 meses desde o último evento mas já temos o próximo marcado.
Ocorrerá no Instituto Superior Técnico (anfiteatro do complexo) no dia 29 de Maio, das 18h30 às 21h30. Como da última vez, teremos 3 apresentações que pensamos serem interessantes e acabamos com pizza e coca-cola para todos podemos ficar a falar mais à vontade e de forma descontraída.

O plano de festas é o seguinte:

18:30 – Recepção e conversa fiada.
18:45 – Fenix, Uma aplicação web com uma arquitectura não-standard (João Cachopo)
19:30 – Interoperabilidade de Web Services com Metro e WCF (Paulo Traça)
20:15 – Scripting na JVM, Maior produtividade para a plataforma Java (Miguel Duarte)
21:00 – Jantar Pizza e Coca-Cola para todos.

Penso que vai ser uma sessão interessante por isso espero que gostem e apareçam. As inscrições são disponíveis no site do JUGEvents. As inscrições são obrigatórias para prevermos o espaço e comida.

E não se esqueçam de espalhar a palavra com amigos, pessoal da empresa, colegas da faculdade, familia e animais de estimação.

Queria agradecer o apoio sem o mínimo obstáculo por parte dos professores João Cachopo e João Rito Silva do IST que nos deram o espaço, e ao pessoal da Atlassian que nos paga as pizzas e bebidas a todos.

Passaram alguns dias desde o fim do JavaOne e ainda não tinha relatado o último dia nem feito um resumo geral do que foi o evento este ano.

O último dia do JavaOne é já um dia de descompressão. Há menos gente, as pessoas estão cansadas e, para dizer a verdade, as sessões não eram tão apelativas.
Na noite anterior veio o aviso urgente de um surto de virus - o Norovirus - no complexo do JavaOne com grande alarme. Resume-se a um vírus que se espalhou rapidamente por mais de 70 pessoas que trabalhavam no recinto e que atacava o estômago de forma violenta. No entanto, penso que não foi isso que fez com que pouca gente tivesse ido ao último dia e disseram-me que era normal.

No dia fui apenas a duas sessões:

• Using Java Technology at the World’s Largest Web Site

Esta apresentação foi feita por duas pessoas da Yahoo! e pretendeu dar uma ideia sobre como e para quê eles usam java no que eles chamam o maior site da web.
Tendo em conta que a Yahoo! não é propriamente uma empresa Java, percebeu-se que usam Java mais para a camada de middleware sendo que os serviços que residem por baixo são coisas em JNI feitas noutras linguagens ou outros serviços desenvolvidos noutras linguagens.
Um dos grandes desafios que sentiram foi a nível de performance, escalabilidade e disponibilidade. Para ultrapassarem este problema, eles usam uma versão deles alterada do Tomcat que lhes permite colocar vários processos à escuta do mesmo porto paralelamente, garantindo o que eles denominam de load balancing aplicacional. Não entraram em grandes detalhes além de dizerem que tentam sempre utilizar tecnologias opensource e que sejam comummente aceite (Maven e Hibernate, por exemplo).

No entanto, penso que transpareceu a ideia que Java é pequeno, bastante pequeno, no mundo Y!, em relação ao C/C++ e PHP.

• GlassFish Project Web Services Stack “Metro”: Easy to Use, Robust, and High-Performance

Tinhas algumas espectativas para esta sessão mas saíram goradas. Foi apresentada pelo Jitendra Kotamraju (o homem JAX-WS) e o Marek Potociar, ambos funcionários da Sun.
Como alguns funcionários da Sun fazem actualmente, tentaram evangelizar tentando vender o Netbeans: as demos eram feitas todas com wizards do netbeans e com comentários de é tão fácil e gera tudo - já todos passámos pelas demos em que é tudo fácil
A apresentação em si foi bastante superficial no que toca ao Metro e focou-se em coisas bastante específicas do JAX-WS, nomeadamente no envio de attachments grandes. Gostei da forma como é possível abrir streams para enviar e ir gravando bytes sem ter de guardar tudo em memória. Quer isto dizer que não preciso de meter um attachment todo numa mensagem e enviá-lo, ou de o dividir: o cliente faz stream para o servidor que o vai guardando no destino, sem ocupar mais memória do que a de uns quantos chuncks que tem temporariamente.
De resto, não sobrou muita coisa de interesse na apresentação, pois perderam tempo a mostrar como se criavam webservices jax-ws que além de não ser novo, não é propriamente complicado de perceber para os casos simples demonstrados.

De seguida baldei-me às sessões finais. Estava cansado e algumas cobriam coisas que já tinha visto noutros dias (processamento multicore e segurança em web 2.0) portanto foi o resto para descansar.

O que fica do JavaOne

Olhando para trás com alguns dias de distância, o JavaOne é um evento certamente a participar. Aprende-se, trocam-se ideias e conhecem-se pessoas. Uma viagem destas vale muito mais dinheiro do que uma qualquer formação e sai a um preço semelhante (<2500€ TUDO) por isso é algo em que as empresas devem pensar um pouco mais.

Mas afinal, o que fica do JavaOne 2008?

• JavaFX ainda longe

Como disse num post anterior, a Sun tentou vender novamente o JavaFX dedicando-lhe muito tempo na keynote inicial. Ficou demonstrado que ainda há muito trabalho a fazer e nos corredores a conversa era mesmo de descrença em relação ao futuro contra Flash/Flex/Air e Silverlight. O JavaFX terá de ser bastante bom para me desviar do Flex/Air para RIAs.

• O mundo multi-core está cá

Imensas sessões acabaram falando da necessidade de tirar partido das máquinas multicore que por aí polulam. Enquanto antes uma máquina 32 cores era muita fruta, agora facilmente conseguem-se máquinas com 4 ou 8 vezes mais cores mudando apenas os tipos de processadores. Falou disto na palestra de Fortress, que tem primitivas tipo fork-join na base, falou-se em Scala que usa o modelo de Actors também para isto, falou-se - obrigatoriamente - na palestra do Brian Goetz e na de memória transaccional. E isto apenas nas que eu fui.
É realmente importantíssimo pois agora o problema deixa de ser tentar dividir os ciclos de processador entre as nossas threads para antes dividir as nossas threads por vários cores e dar-lhes trabalho. Escreverei mais sobre o fork-join noutra altura pois é muito interessante.

• Linguagens dinâmicas

JRuby, Groovy, Scala e Javascript tiveram espaço em diversas sessões. Falou-se muito especialmente de JRuby e Groovy, sendo que Groovy e Grails parecem ter deixado as pessoas mais maravilhados. Eu que sou um gajo statically typed e chato, gosto muito do Scala.

• Networking

Quando falo de networking estou a falar de conhecer e trocar ideias com outros developers, pois lá não há a conversa de recrutamento nem nada disso. É fácil falar tanto com o zé ninguém como o mais conceituado membro da comunidade java. As diversas festas no fim de cada proporcionam esse tipo de contacto e os cartões de visita são absolutamente obrigatórios de levar.
Algumas das conversas mais interessantes que tive foram mesmo nesses fins de noite.

• JUG

A nível do JUG o JavaOne foi excelente tanto a nível de contactos como de ideias para melhorar a nossa comunidade. Tive relatos de JUGs muito diferentes e que funcionam muito bem - imaginem-se as diferenças entre um JUG Norueguês e um Brasileiro.
Esta experiência servirá para introduzir ideias no nosso JUG e com sorte fazer “coisas bonitas” e ficam os contactos com especialmente com o pessoal dos JUGs do Brasil e Paris, tudo boa gente.

Resumindo, vale a pena. É cansativo e longe mas altamente recompensador tanto para quem vai como para a empresa que patrocina. Por isso tentem convencer a vossa empresa, bem explicado podem ver a importância de um evento deste.

Terceiro dia de JavaOne e o cansaço começa a fazer-se notar - este post está a custar muito mesmo, e ainda estou na primeira linha - mas a motivação para as sessões continua a ser a mesma. Continuo a aguentar nas filas gigantescas necessárias para ter acesso a qualquer sessão técnica. Como sempre, baldei-me à primeira general session e fui directo ao que interessa.

Top 10 Patterns for Scaling Out Java™ Technology-Based Applications

A minha primeira sessão do dia foi provavelmente a sessão mais cheia em que estive até ao momento. Foi apresentada pelo Cameron Purdy, fundador da Tangosol e actualmente Vice Presidente da Oracle que adquiriu a empresa dele. Para quem não sabe, Tangosol oferece produtos - o agora rebranded Oracle Coherence - para garantir escalabilidade de aplicações enterprise.
A palestra do Cameron não foi específica do produto dele - e ainda bem - mas antes sobre best practices de como escalar aplicações. Embora muitas das coisas que tenha falado sejam lógicas e simples, e inclusivamente falámos delas no primeiro encontro do PT.JUG na apresentação sobre Terracotta, realmente fazem sentido quando são explicadas. Ele definiu 3 requisitos que são necessários em qualquer aplicação enterprise, qualquer que seja a dimensão:

• Disponibilidade
• Escalabilidade
• Reliability (não sei bem traduzir)

Embora outras dimensões tenham sido faladas, estas 3 são comuns a qualquer aplicação. De seguida falou-se de como garantir que as mesmas são conseguidas e falou-se de três pontos críticos:

• Latência preditiva

Deve ser possível ter uma garantia de latência, um tipo QoS. A JVM não fornece nada deste tipo e a coisa mais próxima que podemos ter é a Java RTS.

• Num sistema distribuído, podemos ter múltiplas cópias dos mesmo dados. Garantir que estamos a ler a versão mais recente e consistente dos dados existente é desafiante.

• Durabilidade

Ficámos também com uma ideia do tipo de problemas com os quais nos podemos deparar no mundo real: o apresentador falou de sistemas com requisitos de latência na ordem dos 2 milisegundos. Verdadeiramente impressionantes.
A ideia geral que ficou foi a identificação destes problemas, que os sistemas stateful são os que são realmente atingidos, pois em sistemas ou partes de sistema sem estado, a escalabilidade resume-se a clusterizar e aumentar o número de servidor.
Foi uma excelente apresentação e que me suscitou bastante interesse.

Advanced Web Application Security

Esta sessão foi apresentada pelo Joe Walker do DWR e por um especialista de uma empresa de segurança em aplicações web. O que reparei, muito porque sou uma pessoa que repara em coisas inúteis, é que o Joe Walker é na realidade o Ralph Fiennes do mundo geek, mas mais mexido.
Em relação à apresentação, foi bastante interessante. Além de conhecer de forma genérica a maioria dos ataques referidos, já sabia que o DWR era considerada a framework que mais cuidado tem com segurança. No entanto, a apresentação não falou do DWR mas antes das tipologias de ataques com bastantes ataques diferentes:

• Cross-Site Request Forgety (CSRF)

CSRF consiste em fazer com que a página que o utilizador consulta faça um request a uma outra página, por exemplo numa iframe, e dessa forma retirar dados sensível. Suponhamos que o utilizador está logado num determinado site A, se visitar o site B e neste tiver uma iframe que faz um request ao site A para obter dados confidenciais, o ladrão - site B - consegue obter os dados da pessoa no site A. Apresentaram soluções para este problema, nomeadamente o uso da OWASP Servlet Filter ou, como é usado no DWR, o padrão double-submit cookie.

• Cross-Site Scripting (XSS)

XSS é o ataque mais comum. Consiste em fazer com que um input do utilizador chege ao output da página sem ser tratado e, dessa forma, comprometer a segurança do site. Um exemplo é um utilizador inserir uma tag de script numa textbox e depois esse conteudo ser mostrado na página, que poderá executar então o código malicoso. E não apenas tags de script mas muitos casos estranhos em que se consegue correr código javascript - aprendi aliás que se consegue correr javascript num atributo style com style=”background:expression(executaCodigoMauzinho())”.
Os autores propuseram a AntiSammy como método para impedir ataques de XSS.

• Javascript Hijacking

Este ataque baseia-se na ideia de alterar o comportamento do javascript que a página execute, tirando partido das funcionalidades dinâmicas da linguagem javascript. Tipicamente acontece quando se usa JSON mal formado sendo que a solução é ter a certeza que o que é JSON está entre { }

Programming with Functional Objects in Scala

A apresentação de Scala era das apresentações que mais esperava. Não tinha propriamente expectativas de aprender muita coisa - mesmo assim deu para aprender - pois já conhecia os princípios básicos da linguagem; mas queria ter o feeling de se isto é realmente o próximo Java. O apresentador, Martin Odersky, é provavelmente o maior especialista sobre o assunto: criador da linguagem Scala, é também o criador do actual compilador java (javac) e a implementação de generics introduzida no Java 5 foi inspirada no trabalho dele (se bem que a versão dele é bem melhor).
Ele explicou a maioria das features do Scala mostrando as diferenças que tem em relação ao Java e houve algumas coisas que se destacaram como o modelo de actors para concorrência (que por trás usa a framework fork-join, tema recorrente no JavaOne deste ano), traits e mixins que foram explicados de forma simples mas que para quem não sabe os problemas da herança múltipla pode não perceber a utilidade logo de seguida.
Esta sessão foi também interessante pelas perguntas feitas no fim. Falou-se de OCaml e Haskell, nomeadamente do facto de Haskell ser bastante mais avançado na forma como trata tipos.

Fiquei no entanto com a ideia que me acompanhou o resto do dia na cabeça, que foi o Scala como o próximo Java. Sendo esta uma corrente, detecto a corrente do pessoal que quer mudar o java para ficar algo tipo Scala, introduzindo closures e coisas semelhantes; e detecto o pessoal que prefere deixar a linguagem como está, simples e cheia de verbosidade. Tenho uma preocupação real de daqui a 5 anos estar a falar sobre o próximo Scala e penso que esta evolução do modelo de programação mainstream na JVM deve ser pensado de forma estratégica e não apenas por níveis. Algo para pensar e discutir no futuro.

Pimp My Build: 10 Ways to Make Your Build Rock

De seguide devia ter ido a uma sessão sobre java performance mas acabei por ficar no pavilhão de exposições a falar na banca da Jetbrains com o David Booth e outros JUG Leaders.
Acabei por fugir para ir para a sessão sobre como abonitar os builds com Maven e Ant. Na realidade esperava uma apresentação diferente, que me desse alguns padrões e regras de como fazer boa gestão de configurações e builds. Ao invés disso, tive uma sessão bastante divertida e bem apresentada mas com um conteúdo que realmente não adicionou grande conhecimento ao que eu já sabia. Foi, quanto mais, agradável.

De seguida fui para o Thirsty Bear, que é o bar onde se encontra imensa gente do JavaOne, para a festa da JetBrains. Eles tentaram não fazer uma festa normal mas criar alguma conversa com o pessoal sobre o que não gostam no IntelliJ ou o que gostariam de ver implementado. Acabei por ter oportunidade de ficar a falar com parte da core team do IntelliJ sobre o futuro de uma vista bastante futurista: falou-se do tema do Scala, de novas formas de programar (i.e. processamento de linguagem natural, reconhecimento de voz, etc.), linguagens de modelação executáveis, etc. Foi excelente a sensação que a equipa é bastante aberta a ideias, mesmo de pessoas que não usam assim tanto o IntelliJ, como é o meu caso.
Além de tudo, patrocinaram a cerveja e buffet e ofereceram uma das t-shirts mais fixes que vi nos últimos tempos. Tentarei colocar um foto aqui no blog.

Meet the Java™ Posse

Toda a conversa e cerveja com o pessoal da Jetbrains fez com que não conseguisse ir ao BOF sobre Guice, o que me arrependo um pouco. Acabei por ir ao BOF do Java Posse, acompanhado do David Booth da JetBrains e onde encontrei um grupo enorme de JUG leaders. A sessão foi o que se esperava: divertida, com cervejas frescas à descrição no fundo da sala - isto sim é uma sessão técnica, com o barulho de caricas a saltar =)

O fim da noite foi feito com a ida à festa da QCon, da qual alguém, provavelmente brasileiro, tem fotos. Foi uma festa muito barulhenta e confusa e de seguida voltei para o Thirsty Bear com o pessoal brasileiro, o António Gonçalves (expert nos JSRs do JPA 2.0, J2EE 6 e EJB 3.1 e que fala um português excelente) e o Emmanuel Bernard (expert no JSR de Beans validation) que ontem tinha apresentado a sessão sobre beans validation. A conversa foi bastante boa e falou-se sobre o JCP, os nossos países e outras questões técnicas e não técnicas.
Foi uma noite mesmo muito boa.

Não queria deixar de deixar uns apontadores para os colegas brasileiros com quem tanto tenho privado nestes dias:

• Serge Rehem
• Givanildo Nascimento

Tal como no ano passado, também este ano a Sun tem tentado fazer um push muito grande da tecnologia JavaFX.
Começou com a sessão de abertura do evento e com a uma afirmação um pouco surreal que nada daquilo era possível fazer com outras tecnologias.
A realidade que eu vejo é que Flash, Flex, Air e Silverlight estão bem à frente do JavaFX em termos de aceitação, complexidade de aplicações e efeito wow. O único uso em que vejo lógico o JavaFX é para os actuais programadores Swing, que não são assim tantos. E mesmo aqui penso que preferia uma solução com Flex e java a funcionar por baixo com BlazeDS ou GraniteDS.

Outra questão é a integração do JavaFX e do JavaFX Script com as linguagens dinâmicas existentes na JVM actualmente (JRuby, Grooby, Jython, etc.). A questão de como usar estas linguagens no JavaFX da forma como são usadas hoje em dia para facilitar o desenvolvimento de applets foi levantada ontem na sessão do Script Bowl mas ficou sem resposta e causou alguns risos nos oradores.

A ideia geral com que fico e depois de falar com muita gente, tendo todos a mesma ideia, é que JavaFX é ainda pouco maduro em relação à concorrência e não tem lógica fingir que é a melhor coisa à face da terra. Tem a vantagem de ser open-source - penso eu, não verifiquei -, que das outras apenas o Flex é. Mas não chega.

O dia dois do JavaOne foi na sua generalidade melhor que o primeiro dia. Ultrapassada a desorientação inicial própria de quem está na primeira vez num evento com mais de 15.000 pessoas todas em filas de um lado para o outro, relaxei mais neste dia e aproveitei as apresentações a que fui.

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

Cá estou no JavaOne em São Francisco e de volta à escrita.
Depois de uma viagem extenuante de cerca de 16 horas e um fuso horário com menos 8 horas, cheguei ontem à noite para o JUG Leaders dinner. Tive a oportunidade conhecer muitos líderes de outros países, especialmente muitos irmãos brasileiros que deram uma ajuda aqui ao caloiro destas coisas de networking.

General Session

Hoje de manhã começou a conferência com a General Session, bem cedo e com muitas filas para entrar. A frase de marca deste ano é “Java + You” e que serve para defenderem a idea da tecnologia Java estar integrada em tudo o que usamos. Esta é aliás a linha de marketing que tem sido usada pela Sun e foi isso que esta primeira sessão foi, previsivelmente: Marketing.
O ponto mais focado foi JavaFX e as suas capacidades. Embora o lei de Murphy tenha feito com as demos não funcionassem muito bem, foi uma mensagem que a Sun quer e precisa de concorrer tanto com a Adobe como com a Microsoft no Flash e Silverlight respectivamente. Tentaram demonstrar que o que fazem com JavaFX não é possível com qualquer outra tecnologia o que não é obviamente verdade. O mais interessante de toda a apresentação foi a capacidade de arrastarem uma applet de uma página web para o desktop, fechar o browser e continuar a usar a aplicação. Quando se tentar fechar a aplicação, somos interrogados se queremos deixá-la instalada na nossa máquina. Útil, definitivamente.
A sessão terminou com a presença de Neil Young no palco a vender a ideia do uso de JavaFX com Blueray para criar conteúdos ricos. Além de uma personagem com o seu quê de ébrio às 8 da manhã, foi mais um pouco de marketing.

Fortress

A minha primeira sessão técnica foi sobre Fortress, apresentada pela Christine Flood. A apresentadora parece-me que despachou rápido a apresentação mas o conteúdo valeu a pena para alguém como eu que pouco ou nada sabia sobre a linguagem.
A palestra foi feita em contagem decrescente com as 10 melhores features da linguagem. Gostava de colocar aqui os 10 pontos que referi mas não tenho os slides. Mal tenha edito o post, mas posso dizer que tem coisas como contratos, memória transacional, paralelismo implicito, notação matemática e outras coisas interessantes.

A linguagem Fortress é muito interessante para desenvolvimento de aplicações científicas, por exemplo para HPC, mas também para ambientes em que contratos, conformidade e performance são importantes - indústria aeroespacial, biotech, etc.

De seguida devia ter ido a uma sessão intitulada “SOA and 35 Million Transactions per Day: Mission Impossible?” mas acabei por ficar a falar um pouco sobre o JEDI com o Daniel de Oliveira do DFJUG e fui à conferência para bloggers do Jonathan Schwarz e o Rick Green. Um ambiente bastante próximo mas com respostas rígidas e um pouco evasivas por parte do pessoal da Sun - por exemplo, não quiseram responder a perguntas sobre despedimentos anunciados pela Sun na semana passada.

Spring 2.5, pelo mestre

Depois do almoço e da balda a outra General Session - que vou continuar a não ir, é mais marketing e o descanço / carregamento de baterias é mais importante - foi a vez da apresentação do Rod Johnson sobre o Spring 2.5. Foi uma apresentação adequada tanto a utilizadores que já utilizaram versões anteriores do Spring como utilizadores totalmente novos ao ecossistema Spring.
Foi possível saber algo sobre o caminho a seguir em diversos aspectos - suporte para java 1.3 já não está disponível na versão 2.5 e na versão 3.0 só será suportado java 5+.
Esta nova versão tira também partido da possibilidade de fazer deploy de ficheiros RAR, que evita que se tenha de criar um EAR ou um WAR específicamente para fazer deploy de Spring quando não é realmente necessário. Foi igualmente anunciado que esta versão de Spring é oficialmente compatível com as versões 6.X do Websphere.
Falou-se igualmente sobre OSGi - aliás, fala-se muito sobre OSGi em todo o lado este ano no JavaOne - e sobre como Spring suporta o standard. Todos os JARs Spring são OSGi packets e podemos escolher se queremos Spring a funcionar sobre J2EE ou sobre OSGi.
Bastante interessante a apresentação, pedagógica com alguma regras que podem ser úteis para o futuro, nomeadamente sobre quando usar annotations ou XML para configuração Spring.

Defective Java™ Code: Turning WTF Code into a Learning Experience

Esta sessão foi bastante interessante e um pouco ao estilo dos Java Puzzlers. Foi apresentada pelo Bill Pugh, criador do FindBugs, e focou-se em diversos tipos de bugs, nomeadamente problemas de sincronismo (locks, race conditions) e, curiosamente, falou-se bastante sobre implementações de métodos equals. Na realidade, é bastante simples criar métodos equals que não são facilmente extensíveis e que podem não garantir a simetria necessária.
Acima de tudo esta sessão deixou-me o mindset de tentar encontrar padrões de erros a partir dos bugs que vou encontrando ou cometendo. E foi a sessão com o melhor título de todos, sem dúvida.

Let’s Resync: What’s New for Concurrency on the Java™ Platform, Standard

Um dos meus focos de interesse actuais, como se pode ver pelas sessões que tenho escolhido, é o paralelismo, performance e escalabilidade. Esta apresentação falou principalmente da framework fork-join que estará disponível no JDK7.
O que esta framework, ao invés de aproximações anteriores como usar threads directamente e join(), ou usar Executors e Futures como no java.util.concurrent, permite dividir trabalho de forma simples e ter uma framework que sabe distribuir esse trabalho por um conjunto de threads e, por sua vez, distribuir esse trabalho por um conjunto de cores.
A forma como as threads “agarram” o trabalho é por um processo chamado work stealing e que também é usado na linguagem Fortress. Permite que as threads que estão livres vão à lista de tarefas de outras threads retirar-lhes tarefas e executá-las. Na realidade, é criado um efeito divide-and-conquer e o custo associado com esta solução é bastante baixo.

São fornecidos objectos extremamente uteis em cima da framework, nomeadamente o ParallelArray. O que este array faz é encapsular a lógica toda do fork-join e permite que o utilizador use 3 tipos de operações: filtro, mapeamento e agregação, que podem ser built-in (i.e. sum(), max(),…) ou definidas pelo utilizador. Ao fazermos uma sequencia de operações sobre um array deste tipo, temos automaticamente código paralelizado - é um pouco como o MapReduce do Google.

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

Decidi ir a um Birds-of-Feather sobre GWT e foi um pouco desanimador. Pouco ou nada de novo para alguém que não sabe muito da coisa, o que não é bom sinal. Foi tempo perdido.

JUG Community BOF: JUG Leaders from Around the World Interact with Sun

No fim do dia foi a sessão em que os JUG Leaders e amigos se encontraram e falaram um pouco sobre o futuro da plataforma Java. O objectivo era seleccionar 3 temas e discuti-los mais aprofundadamente mas a conversa dispersou-se e precisava-se de pelo menos mais 1 hora para se ter discutido algo realmente interessante.
A notícia que acabou por sair, sem querer ou talvez intencionalmente por parte do responsável da Sun, é que a JVM irá suportar PHP brevemente, tal como suporta hoje Ruby, Python, etc. É uma excelente notícia e um óptimo move, se se provar verdade, dada a quantidade de aplicações e programadores PHP existentes.

No fim, havia cerveja de graça e festas mas o Jet Lag falou mais alto e o hotel foi o destino certo. A sensação que fica é que o JavaOne é realmente um mundo e quer-se aproveitar todos os momentos para absorver o que se passa. Talvez seja sensação de rookie mas isto é mesmo um sítio divertido para estar!

Quando brinquei com C#, uma das coisas pelas quais fiquei apaixonado foi a implementação deles de properties. Enquanto em java temos a especificação dos JavaBeans e os nossos getters e setters de atributos são métodos que têm de corresponder a uma determinada nomenclatura, em C# essa definição é ao nível da sintaxe da linguagem.

O uso de getters e setters em java não deixam de me parecer como uma solução de recurso que passou a standard. Se se implementarem properties agora, teríamos sempre de manter o suporte para aquela horrível nomenclatura a que todos nos habituámos a não odiar.

Além disso é já hoje em dia uma questão cultural mudar uma prática tão enraízada. Penso mesmo que mais são os opositores à ideia - lembro-me de uns whiteboards no JavaPolis neste ano com propostas e votações sobre as futuras alterações à linguagem java e que deixo a imagem em baixo. Também há uma descrição mais promenorizada na página do Javapolis.

Eu pessoalmente, gostava bastante de poder usar propriedades em Java.

Nestas últimas 2 semanas, em que não tenho escrito nada aqui no Zona J, tenho estado a preparar a minha ida ao JavaOne pela primeira vez.

O JavaOne ocorre em São Francisco de 6 a 9 de Maio e é a maior conferência de developers do mundo. Serão mais de 320 sessões técnicas em 4 dias (para quem é demasiado preguiçoso para fazer as contas, isto dá 80 sessões por dia!) e se algo pode ser dito para demonstrar a força da indústria e comunidade à volta da tecnologia Java, esta é a maior prova.

Eu sempre quis ir ao JavaOne pois todas as pessoas que lá estiveram (entre eles o Ricardo Antunes aqui do Zona J) o descreveram como uma experiência obrigatória. A oportunidade surgiu com um programa da Sun EUA de Top Bloggers em que acabei por ser escolhido e foi-me enviado um convite de entrada na conferência como blogger/press - quer isto dizer que vou poder fazer de jornalista e cobrir o evento mas, acima de tudo, devo ter comida de graça. Feito o convite, tinha mesmo de ir e a empresa onde eu trabalho, a Karma Consulting, deu-me a ajuda que eu precisava para a viagem - obrigado chefe!.

Quando custa ir ao JavaOne

A ida a uma conferência deste género tem custos elevados. Mesmo com o dólar a valer quase o mesmo que o Yen, a ida à conferência com origem em Lisboa, tem os seguintes gastos:

• Entrada na conferência - $1495/€950

A entrada ao preço early bid é de $1595 mas o PTJUG (e todos os outros JUGs) tem um desconto de $100 se usarem um código específico. Esse código pode ser encontrado na mailing list do PTJUG, para quem estiver interessado.

• Viagem avião - aprox. €1000

O preço da viagem de avião pode variar muito consoante a disponibilidade e os voos mais baratos são por vezes difíceis, mas com alguma antecedência conseguem-se voos a €800. Além disso a viagem é muito longa, especialmente nas rates mais baixas em que se fazem 2 escalas e a duração de voo ultrapassa as 23 horas!

• Estadia - aprox. 500€

A conferência tem um conjunto de hotéis com os quais combina as rates e um hotel médio custa cerca de $150/95€ por noite. Se contarmos 5 noites, arredondamos para 500€

• Gastos extra - ??

Com tanta sessão técnica para ver, não deverá haver muito tempo para gastar dinheiro. Será seguro pensar em algo tipo €500.

Resumindo, €3000 é uma conta redonda e próxima do que pode custar ir ao JavaOne. Na minha opinião, para os benefícios que traz é bem mais interessante para uma empresa promover a ida dos seus funcionários a uma conferência destas do que pagar cursos de certificação para figurarem no CV por preços semelhantes.

Que sessões vou ver no JavaOne

O site oficial do evento oferece um sistema de escolha das sessões técnicas. Dentro destas há as sessões técnicas propriamente ditas, mais conceituadas e formais; e os BOFs, ou Birds of Feather, que são sessões mais pequenas e informais.
Com tanta sessão interessante demora-se mesmo muito tempo a escolher as sessões que queremos ver, mas posso destacar as seguintes sessões que planeio ver:

• Fortress: A Next-Generation Programming Language Brought to You by Sun Labs

Fortress é uma linguagem saída dos Sun Research Labs que tem coisas como paralelismo implícito (o código escrito é paralelizado por omissão, sempre que possível), notação matemática na linguagem, transaccionalidade e outras coisas interessantes.

• Defective Java™ Code: Turning WTF Code into a Learning Experience

Esta sessão via ser dada pelo William Pugh, criador do FindBugs e será uma aproximação prática com projectos reais, como seja o OpenJDK.

• JUG Community BOF: JUG Leaders from Around the World Interact with Sun

JUG Leaders e representantes da Sun reunem-se para falar sobre o funcionamento das comunidades de JUG e a sua relação com a Sun.

• Comet: The Rise of Highly Interactive Web Sites

Apresentada pelo Joe Walker, do DWR.

• Top 10 Patterns for Scaling Out Java™ Technology-Based Applications

Sessões dada pelo Cameron Purdy, ex-CEO da Tangosol, agora na Oracle e à frente da área de desenvolvimento. É certamente a pessoa indicada para falar de temas como escalabilidade e computação em grelha. Deverá falar bastante de Oracle Coherence.

• Programming with Functional Objects in Scala

Uma das sessões que tenho mais expectativa. Sou um fã da linguagem Scala, embora ainda não possa ter usado a linguagem para umas brincadeiras práticas. O senhor Martin Odersky em pessoa vai apresentar a sessão.

• Meet the Java™ Posse

Sou ouvinte regular do podcast The Java Posse e este BOF será certamente divertido. Vai ser uma oportunidade de ligar as caras aos nomes e vozes.

Tenho muitas mais sessões no meu horário e tenho a certeza que mesmo que não consiga ir a todas, vou perder algum peso a correr entre elas.

Para quem ainda quiser ir ao JavaOne este ano, não se esqueça que o preço do Early Bid acaba a 7 de Abril e que podem obter o tal desconto de $100.
Se alguém estiver a ler e for ao JavaOne diga alguma coisa nos comentários, terei todo o gosto em combinar alguma coisa visto que vou sozinho e sou uma pessoa muito anti-social.

Quem já utilizou bibliotecas de javascript certamente verificou que é sempre disponibilizada uma versão comprimida e um versão normal. Isto acontece porque queremos poupar largura de banda, dado que as páginas têm cada vez mais javascript. Além disso, o javascript é carregado antes do render da página, como tal o download é “bloqueante” para o processamento da página.

No entanto, para o código javascript que nós próprios desenvolvemos ou que as frameworks que usamos usam ou geram raramente minimizamos os ficheiros javascript. Isto apenas seria feito para cenários de produção, mas rapidamente se tornaria demasiado trabalhoso.
Se queremos minimizar apenas para determinados cenários e de forma totalmente automática, tem lógica incluir este processo nos nossos processos de build.

E é aqui que entra o plugin do YUICompressor para o Maven.
Este plugin permite processar os ficheiros javascript, minimizando-os. Também corre o JSLint, para verificar a correcção do código. Este último é uma forma de análise estática de código que ajudo muito a reduzir a probabilidade de erros não detectados.

Falo do YUICompressor como podia falar de outras ferramentas de compressão e obfuscação de javascript, como seja o JSMin, ShrinkSafe, Packer ou outro. Não sei é sobre a existência de plugins para todos, embora não deve ser muito complexo de os desenvolver.

Desta forma conseguimos comprimir o nosso código para melhorar a performance e verificar estaticamente por erros no javascript (um erro javascript pode quebrar o build: bom!). Podemos ainda usar o plugin para gerar documentação javascript (JsTools) ou mesmo para efectuar testes unitários em javascript (JsUnit).

Poderíamos ainda melhor mais a performance, gzipando os nossos ficheiros a nível do servidor. Para esta e outras optimizações, é muito útil o YSlow, também da Yahoo que é um plugin para o Firebug que verifica determinados parâmetros de performance na página.