A Sun vem há muito tempo fazendo esforços para facilitar a manipulação de XML e de webservices na plataforma. São tantos projetos, subprojetos e especificações que podemos facilmente nos encontrar perdidos no meio de tantas siglas. Elas são:

JAXP (pacote java.xml no geral) – Processamento geral de XML, com os já antigos SAX e DOM, além de transformadores (XLST) e XPath.

JAXB (pacote javax.xml.bind) – Assocaição/mapeamento de classes java para XML.

JAX-WS (pacote javax.xml.ws) – Criação e consumo de webservices. Aliada a especificação de metadados para webservices (pacote javax.jws), previamente já vista aqui no blog, a JAX-WS tornasse poderosa e fácil de usar.

JAXR (pacote javax.xml.registry) – para acesso aos registros de serviços XMLs, como UDDI.

JAX-RPC (pacote javax.xml.rpc) – era o nome antigo do atual JAX-WS. O JAX-WS mudou de nome e já apareceu como 2.0, essa mundaça foi justificada pelo fato dessa API passar a trabalhar bem mais próxima da API do JAXB, além do óbvio marketing.

E a Sun não para por aí, temos mais especificações: a duvidosa JSR 267 que possibilita um JSP acessar diretamente um webservice (!) através de taglibs e a esperada JSR 311 para trabalhar com serviços de maneira RESTful, oferecendo simples anotações para expor métodos Java através de URI + métodos HTTP.

Não são todos subprojetos de manipulação de xml com java que viraram especificações, e as que viraram nem todas estão no Java SE. A Fast Infoset é uma especificação ISO para representação binária do padrão XML (economizando assim espaço e banda, além de melhorar performance do parsing) possui uma implementação Java, utilizada dentro do Metro, projeto que fornece os recursos de webservices do Glassfish.

Muitas dessas APIs, juntamente com implementações de referência (RIs), agora estão presentes no java SE 6.0, que antes eram opcionais. Qual é o problema disso? Até então diversos servidores de aplicação e frameworks traziam embutido implementações do JAXB, JAX-WS, etc. Ao rodar essas aplicações com o Java 6 o sistema de classloading da plataforma vai primeiro carregar as classes da api padrão, mesmo que você tenha implementações dessas APIS de XML no classpath. O ruim aqui é que muitos servidores de aplicação acabam se amarrando a detalhes de sua própria implementação e versão, como é esse caso do JBoss com o JAX-WS. Quando rodado com o Java 6, temos a seguinte exception quando você tenta acessar um webservice que está implantando no servidor:

java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage
at javax.xml.soap.SOAPMessage.setProperty(SOAPMessage.java:424)


Enfrentamos esse problema recentemente, e para resolve-lo usamos o sistema de endosso de jars (endorsed jars) do Java: determinados diretórios podem ser configurados para que alguns pacotes específicos possam ser carregados destes antes do Classloader tentar chegar ao rt.jar.

Um outro problema comum é com o JAXB: o Java 6 vem com a versão 2.0, se você precisar usar a 1.1 ou a 2.1, vai ter problemas. O interessante é que a JAXB do Java SE já foi projetada para ela mesma detectar se o classloading foi correto, ou se partiu de uma versão posterior/anterior a ela, mostrando uma mensagem de erro amigável. Para outras bibliotecas esse problema pode ser muito sutil: o classloader pode acabar carregando parte da biblioteca de uma versão recente, já que algumas classes novas só existem nesse jar, e o restante de uma outra antiga, resultando exceptions como NoSuchMethodError, que não mostram claramente que o problema é a existência de dois jars de versões diferentes no classpath daquela aplicação.

Podemos ver que mesmo seguindos boas práticas, isolando bibliotecas e não usando a terrível variável de ambiente CLASSPATH, acabamos sempre enfrentando o classloader hell.

Aconteceu no último final de semana o Conexão Java 2007, evento organizado pelo GUJ, PortalJava e Tempo Real Eventos. A Caelum esteve lá com stand, palestras e tutoriais.

Muito bom rever os amigos do GUJ, do PortalJava e ex-alunos da Caelum. As palestras foram ótimas e ainda tivemos os tutoriais. Paralelamente, o Philip comandava a muvuca com discussões acaloradas sobre arquitetura.

Lá no GUJ há um tópico onde o pessoal está colocando impressões sobre o evento e palestras (as nossas estão logo após as fotos).

Algumas fotos dos mini-cursos, do auditório e da muvuca lá fora:

Este ano, a Caelum ministrou 3 tutoriais e uma palestra no evento. Você pode baixar o material de cada um logo abaixo:

• Tutorial Hibernate 3.2 com Nico Steppat
• Tutorial de JSF e AJAX com Sérgio Lopes (sexta) e Fabio Kung (sábado)
• Tutorial Java ME com Sérgio Lopes
• Palestra Java ME com Thadeu Russo

Faz tempo que postei a primeira parte dessa introdução ao JavaFX, baseada na minha palestra no Falando em Java 2007. Se você não leu, leia primeiro aquele artigo antes de seguir com este. O Java FX é a proposta do mundo Java para combater o domínio do Adobe Flex (abordado no curso FJ-29) no mercado de RIAs.

Relembrando, falamos que o JavaFX Script é uma nova linguagem de programação orientada a objetos, com sintaxe declarativa, recursos de programação funcional, tipagem estática (mas com inferência de tipos). Através do JFX podemos acessar as APIs do Swing e do AWT de forma fácil para construir interfaces ricas.

Observe o uso de componentes Swing de forma declarativa:

import javafx.ui.*;
Frame {
    width: 300
    height: 100
    centerOnScreen: true

    title: "Minha aplicacao JavaFX"
    visible: true

    content: Box {
        orientation: VERTICAL
        content: [
            Label {
                text: "Nome"
            },
            TextField {

            },
            Button {
                text: "OK"
            }
        ]
    }
}

Nesse exemplo, usamos um Frame com um Label, um TextField e um Button dentro. O Box é um componente de layout, análogo ao uso que se faz do BoxLayout do Swing.

Como uma linguagem orientada a objetos, o Java FX tem o suporte a classes. A sintaxe é um pouco diferente do Java, não se assuste:

public class Pessoa {
    public attribute nome: String;
    public operation limpa();

}
attribute Pessoa.nome = "Nome padrão";
operation Pessoa.limpa() {
    this.nome = "";
}

Dentro de uma classe, podemos declarar attributes, operations e functions (uma operation é o análogo ao método do Java; uma function está mais para uma função como na matemática, sem efeitos colaterais). Repare que dentro da classe declaramos apenas a interface; a implementação deve ficar fora da classe. Repare também que os valores default dos atributos também são declarados fora da classe.

Agora instanciamos a classe para usá-la:

var p1 = Pessoa{};
p1.nome = "Sérgio";
println(p1.nome);

Repare que não há chamada a construtor; usa-se as chaves para instanciar objetos, como nos exemplos anteriores. E também não declaramos o tipo da variável, ele é descoberto (inferida) automaticamente.

Se você leu atentamente o código da classe Pessoa, deve ter ficado horrorizado com uma coisa: os atributos são públicos! Em JavaFX é possível escrever atributos private e getters/setters como operations, mas o jeito mais comum de se fazer os getters e setters nessa plataforma é através de triggers.

O JavaFX possui suporte a uma série de triggers que podem ser disparadas em certos eventos da linguagem. Uma delas é na modificação de uma variável, veja:

// setNome
trigger on Pessoa.nome = outroValor {
    println("Mudei o nome para: {outroValor}");
}

Isso é praticamente um setter! (Nota: obviamente que triggers não garantem encapsulamento, por isso existe o private e a parafernalha de sempre.)

E note também a sintaxe do uso do println: em JavaFX, “concatenamos” strings acessando-as com chaves dentro da string.

Um dos recursos mais interessantes do JavaFX Script é o data binding automático entre Model e View: quando os dados do model mudam, a view é automaticamente atualizada e vice-versa. Por exemplo, se fizéssemos um TextField para a digitarem o nome de uma Pessoa, podemos atrelar um objeto Pessoa ao campo de texto com o operador bind:

// instancia Pessoa em algum ponto do código
var pessoa = Pessoa{};

// ...
     // na hora de fazer o formulario, atrelamos pessoa.nome ao TextField
     TextField {
           value: bind pessoa.nome
     }
// ...

Nesse exemplo, toda vez que alteraremo valor do campo de texto, nossa instância do model estará atualizada (e se alterássemos o model, a view também veria). Esse tipo de recurso não existe no Java padrão e no Swing. (Nota: a JSR 295 tenta implementar algo assim para o Swing.)

Até agora usamos bastante coisa do Swing/AWT, mas além disso, podemos usar recursos de desenho em duas dimensões com Java 2D e, em breve, também suporte ao Java 3D e APIs de Multimedia. Veja como é simples desenhar com Java 2D (e observe como a sintaxe é muito semelhante a um SVG):

import javafx.ui.*;
import javafx.ui.canvas.*;
import java.lang.*;

Frame {
    title: "Loja virtual com JavaFX"
    width: 700
    height: 560
    visible: true
    centerOnScreen: true

    content: Canvas {
        content: [
            Rect {
                x: 0
                y: 0
                width: 700
                height: 560
                fill: Color {red: 0.086, green: 0.086, blue: 0.086}
            },
            Text {
                x: 20
                y: 15
                content: "Loja Virtual de MP3 "
                font: Font {faceName: "Gill Sans", size: 32, style: PLAIN}
                fill: Color {red: 0.176, green: 1, blue: 0.435}
            }
        ]
    }
}

Este exemplo é o princípio da Loja Virtual que fiz para a palestra e que mostrei no artigo anterior. Ele apenas desenha um retângulo e coloca um texto. Repare no uso das classes do java 2D, no uso das cores e fontes e na forma estruturada em que estão declarados os elementos do desenho. No próximo artigo irei mostrar os bastidores da Loja Virtual para apresentar recursos avançados do JavaFX.

Para testar os códigos deste e dos outros artigos, recomendo o uso do plugin para o Eclipse ou para o Netbeans. Você pode encontrar mais detalhes sobre como usá-los na página oficial do projeto.

Algumas pessoas têm me perguntado sobre o presente e o futuro do JavaFX. A verdade é que, hoje, ele ainda é muito instável e muito beta. Não é para ser usado em produção ainda, não é para sairmos migrando nossos projetos para o JFX. Mas a Sun tem falado muito do JavaFX e investido pesado nisso, o que faz com a tecnologia tem um futuro potencialmente promissor.

Como disse no outro artigo, o sucesso do JFX vai depender das ferramentas que surgirem em torno da tecnologia (e a Sun sabe disso). Por isso o Flash é tão mais popular hoje em dia. Hoje já temos algumas ferramentas para o JFX desenvolvidas mais como provas de conceito, mas que dão idéia de como esse mercado será o futuro.

• A ReportMill lançou o JFXBuilder, uma ferramenta poderosa para gerar relatórios em JFX;
• O projeto oficial openjfx tem o JavaFXPad que é um editor dinâmico para JavaFX que mostra um preview da tela enquanto você escreve;
• E há o JavaFX SVG Translator, que transforma arquivos SVG em JavaFX; e com isso conseguimos usar qualquer editor vetorial com suporte a SVG para criar coisas para JavaFX, começando já a integrar os designers na plataforma.

Tudo isso em pouco tempo em que apenas versões de teste do JavaFX existem! Minha dica hoje é: brinque com o JavaFX, leia sobre ele e fique de olho na tecnologia! Espere grandes avanços em 2008!

Recentemente, o psicólogo e servidor público de uma instituição federal Alberto Kime, postou um depoimento chocante no fórum “Perguntas e Respostas” do RubyOnBr.org. Pedindo licença ao Alberto, vou replicar o depoimento aqui:

Bom dia aos participantes do RubyOnBr. Assiti ontem a palestra do Shairon em um evento. Na verdade não fui lá para aprender Ruby, sou psicólogo e servidor público em uma instituição federal. Fui para prestigiar um amigo meu em outra palestra. Cheguei mais cedo, então e vi um rapaz falando de linguagem humana e de programação, o ato de pensar, lingüística, gramática, “semiótica”, sistema cognitivo, e outras ciência que eu nem imaginava que a computação estudava. Ele disse “você aprende ruby sem querer”, fiquei sem entender e complementou com uma analogia meio paródia de Descartes “você pensa no programa ele logo existe”.

Então pedi meu filho que instala-se o programa que entende ruby o “irb”, peguei um manual na internet e comecei a ler, pensar e “programar”. Eu fiquei muito feliz por não saber programar e “brincar” de ser programador, eu com 53 anos me sentindo capaz, e como o palestrante disse “expressar o pensamento em um programa”.

Eu só estou falando isso aqui porque fiquei muito empolgado e lendo o forum vi que programadores podem “ser humanos e legais”.

Um abraço a todos e obrigado por essa experiência.

Alberto.

É impressionante ver que uma pessoa sem experiência alguma com programação pode achá-la tão intuitiva. Mais chocante ainda é ver um psicólogo elogiando a arte da programação e como os programas podem ser humanos e legais.

E aí, não acha que está na hora de se sentir assim?

Em todas as aulas do RR-11 (nosso curso de Ruby on Rails), comento com os alunos a necessidade de agitar um pouco mais a comunidade no Brasil. Recentemente, o meu xará Fabio Akita manifestou a vontade de organizar um evento diferente, nos moldes das RejectConfs que acontecem pelo mundo.

É com muito prazer que anunciamos um evento diferente, com participação aberta para todos: RejectConf SP’07, que vai acontecer no dia 17 de novembro de 2007 no auditório Jacy Monteiro do Instituto de Matemática e Estatística da USP.

O evento sai de graça para todos, mas são apenas 80 vagas. Corra e se inscreva no anúncio original do Akita, onde você também pode manifestar o interesse em palestrar sobre alguma coisa e descobrir como chegar no local.

A Caelum está patrocinando o evento e vai fornecer o coffe-break. Incrível a força da comunidade, não?

Nos vemos por lá!