Você é um administrador e também pode acessar esta página.

A tag possui três atributos exclusivos: ifAllGranted , ifAnyGranted e ifNotGranted . Todos os atributos suportam um ou mais ma is roles separados por vírgula. O atributo ifAllGranted informa que o usuário tem que possuir todos os roles declarados para retornar true. O atributo ifAnyGranted necessita de apenas um dos roles para retornar true e o atributo ifNotGranted será true apenas se o usuário não possuir nenhum dos roles. A tag permite acessar as propriedades do objeto Authentication do usuário logado no JSP. Por exemplo, o trecho de código a seguir, codificado no index.jsp , irá exibir as informações informações do usuário utilizando a tag :

Informações do usuário logado:
Login:
Senha:
E-mail:
Logout


Conclusões Com os exemplos demonstrados podemos ver alguns dos principais casos de uso de segurança em uma aplicação web. O Spring Security centraliza as configurações em apenas um arquivo que será empacotado  juntament  junta mentee com o war da ap aplicaç licação ão,, dispen dispen-sando configurações externas do container. A aplicação não fica apenas mais enxuta, como também mais extensível, como vimos através da interface UserDetailsService e

Outra forma de se obter o usuário logado, porém sem necessitar do Httpatravé ravé s da cl clas asse se SecuServletRequest , , é at rityContextHolder. Essa classe mantém o objeto Authentication em uma variável thread-local. O método a seguir pode ser implementado em uma classe de utilidade e pode ser chamado em qualquer ponto da aplicação: public static Usuario getUsuarioLogado() { Authentication authentication = (Authentication) SecurityContextHolder.getContext() SecurityContextHolder .getContext().getAuthen .getAuthentication(); tication(); if (authentication instanceof Usuario) { return (Usuario) authentication.getPrincipal(); } return null; }

Utilizando as taglibs O Spring Security fornece duas tags úteis para codificação de JSPs: e . Ambas podem ser importadas com a declaração a seguir: <%@ taglib prefix=”sec” uri=”http://www.springframework. uri=”http://www.springframework. org/security/tags” %>

A tag é utilizada para mostrar/ trar /esconder informações in formações de acordo com as permissões (roles) do usuário. Veja o código a seguir: Edição 69  Java  Java Magazine 

37



dos eventos de autenticação e autorização. Dessa forma é possível implementar casos complexos de gerenciamento de usuários, de forma desacoplada do domínio de negócios da aplicação. Alguns assuntos não foram abordados no artigo por motivo de espaço, porém o leitor pode consultar a documentação no site do framework. Algumas funcionalidades oferecidas pelo Spring Security e não apresentadas são: segurança a nível de métodos (utilizando anotações e AOP), suporte a HTTPS, controle de sessões concorrentes e diferentes formas de autenticação, como certificados certif icados X509, LDAP LDAP,, etc. Para mais informações sobre single sign on consulte o quadro “Single sign on com CAS e OpenID”.

Dê seu feedback sobre esta edição! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

e

d

c  

o      

www.devmedia.com.br/javamagazine/feedback 

www.springsource.org Portal do Spring Framework e sub-projetos

 static.springframework.org/spring-security/   static.springframework.org/spring-security/   site/index.html   Acesso direto à home page do Spring Security 

 springide.org/blog Download do Spring IDE (plugin para o Eclipse)

www.jasig.org/cas Homepage do projeto CAS 

openid.net 

[email protected] michelzanini.wordpress.com

Homepage do OpenID

www.myopenid.com Provider de logins OpenID

md5-hash-online.waraxe.us Gerador online de hash md5 

   e

   t     a     e       o     ã  i   d

Dê seu voto sobre este artigo, através do link:

Michel Zanini É formado em Ciências da Computação pela Universidade Federal de Santa Catarina (UFSC) e possui as certificações SCJP, SCWCD, SCBCD e SCDJWS.

  u

  e    s      ê

Edição 69 • Java Magazine

39

SEÇÃO JAVA: NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA

  

N

a Edição 67 apresentamos a plataforma JavaFX, introduzindo-a de forma conceitual e dando alguns “aperitivos” das suas funcionalidades e programação. Na Edição anterior (68), seguimos com um primeiro tutorial de programação JavaFX, ensinando o básico da linguagem e framework de uma forma prática, mas bastante informal. Agora, encerrando esta cobertura inicial da JavaFX, vamos nos focar apenas na linguagem JavaFX Script, cobrindo-a de uma forma mais formal e abrangente. (Para o leitor ainda pouco motivado a aprender  JavaFX Script, seria boa idéia começar pelo quadro “Por que uma nova linguagem?”.) Não é meu objetivo repetir o documento de Referência da Linguagem de Programação JavaFX Script que está disponível em openjfx.dev.java.net/langref . Ao invés disso, a idéia é explicar a linguagem de uma forma concisa e pragmática, tendo como alvo não alguém que vai escrever um compilador ou outra ferramenta que exige conhecimento formal da linguagem, mas um desenvolvedor que deseja vencer a curva de aprendizado da sua sintaxe ou então ter uma referência de fácil consulta. Ainda mais especificamente, escrevo pensando no programador que já conhece  bem a linguagem Java, o que permitirá resumir ou omitir explicações dos pontos onde ambas as linguagens forem iguais ou muito parecidas (e são muitos pontos). Assim, podemos concentrar nosso tempo e neurônios nas partes que são diferentes. O artigo é organizado como uma referência da linguagem, agrupando suas funcionalidades em seções como Valores, Operadores, Classes etc., de forma similar a uma referência formal. No entanto, fiz este agrupamento de uma forma “relaxada” segundo critérios conceituais e não de gramática formal. Por exemplo, a seção de Ope-

40 Java Magazine



Edição 69

 De que se trata o artigo:  Apresentamos uma referência da linguagem JavaFX Script, que faz parte da plataforma JavaFX.

Para que serve:  JavaFX é a nova plataforma RIA da Sun, compatível com Java SE e Java ME, já apresentadas em artigos anteriores desta série. Alguns leitores podem encarar a exigência de aprender uma nova linguagem de programação como um obstáculo, mas este aprendizado é facilitado pela semelhança entre JavaFX Script e Java – tiramos proveito desta semelhança para explicar a nova linguagem de forma concisa. Mesmo para quem já aprendeu JavaFX Script, o artigo serve como uma referência bem organizada e pragmática (ao contrário da referência oficial, que tem uma estrutura mais formal, certamente mais detalhada, mas não adequada à facilidade de consulta e sem pretensões didáticas).

Em que situação o tema é útil:  A linguagem JavaFX Script é um pré-requisito para desenvolver para a plataforma JavaFX, a qual promete grande produtividade, mas (com qualquer plataforma) somente após vencer uma curva inicial de aprendizado. Mesmo para quem não tiver grande interesse na JavaFX, o artigo apresenta muitas inovações da JavaFX Script que são um aprendizado valioso para qualquer interessado em linguagens de programação.

radores não possui todos os operadores, pois alguns deles são cobertos em outras seções (ex.: os diversos operadores específicos para sequences são mostrados na seção Sequences). Também não me preocupei em documentar minimamente alguns aspectos mais elementares da linguagem que são exatamente idênticos a Java, por exemplo a sintaxe para números literais. A intenção é ter um texto o mais compacto e didático possível, mas ainda assim, suficientemente organizado e formal para servir como referência da linguagem. No decorrer do artigo, uso o termo “JavaFX” no lugar de “JavaFX Script”, por simplicidade.

Tipos e Valores O sistema de tipos da JavaFX é inspirado no Java, mas com melhorias importantes. Na Tabela 1 , classifiquei os tipos da JavaFX em cinco categorias e comparei-os aos

tipos equivalentes em Java. Vamos comentar apenas as novidades desta tabela. Valores A maior novidade é que o typesystem de JavaFX é OO-puro: não existem tipos primitivos. Por outro lado, existem “tipos de valor”, que são aqueles cuja igualdade de referência é equivalente à igualdade de valor (em outras palavras: x == y se e somente se x.equals(y)). Os tipos primitivos do Java, como int , são tipos de valor, por isso não há dois valores 17 distintos, por exemplo. O mesmo vale para o Integer da JavaFX. Além disso, os valores são imutáveis, e não admitem null. A diferença entre esses tipos da JavaFX e os tipos primitivos do Java é que os tipos de valor são objetos. Em JavaFX, todos os tipos, sem exceção, são derivados de Object. Em termos de implementação, os valores de JavaFX são equivalentes aos primitivos de Java, evitando o custo de desempenho

   

 OSVALDO PINALI DOEDERLEIN de usar objetos. Por exemplo, se você olhar o arquivo .class gerado pelo javafxc para uma função que recebe um parâmetro Integer , verá que o bytecode compilado irá conter um método que recebe um int primitivo. Somente quando um valor é utilizado em alguma operação que exige sua faceta OO, a JavaFX faz uma conversão automática para um objeto. Você pode considerar isso uma versão melhorada do autoboxing de Java 5. As melhorias incluem a simplificação (não há tipos paralelos como int/Integer) e desempenho (o compilador, runtime e frameworks usam várias técnicas para representar valores na forma primitiva, e reduzir ao mínimo as conversões de/para a forma OO).

VALORES (value types) Comentários true ou false Inteiro, 8 bits sem sinal Inteiro, 16 bits com sinal Inteiro, 32 bits com sinal IEEE754, 32 bits IEEE754, 64 bits String Duração temporal



Java boolean byte short int float double (Em Java, é tipo de referência) N/A; costuma-se usar long

VOID Comentários Nenhum valor

JavaFX Void

Java void REFERÊNCIA

Comentários

 Strings Menção honrosa vai para o tipo String da  JavaFX Script, que ao contrário de Java, é definido como um value type. Além disso, carrega um lote de funcionalidades extra: O valor default de uma String não inicializada é “” (string vazia). É impossível ter uma string null; se você fizer esta atribuição, fica com “”. Nunca acontecerá uma NullPointerException envolvendo strings (ou qualquer value type);  , não  O operador == equivale a equals() há distinção entre igualdade e identidade (novamente, como todos value types); Pode-se mesclar strings com expressões, por exemplo: “Alô, {nome}!” será expandido conforme o valor dinâmico da variável nome. Ou então, “Temperatura: {%2.2f temp}” , a variável temp será formatada no estilo de System.printf() (ex.: %2.2f 32.257 32,25); Pode ser delimitada por aspas simples ou  duplas, ex.: ‘String com “aspas duplas” dentro’;  Internacionalização é simples: def msg = ##”ERRO” irá atribuir a msg o valor da string associada à chave ERRO no resource bundle da aplicação; se não existir este resource, o valor da string será “ERRO” mesmo.

JavaFX Boolean Byte Short Integer Number, Float Double String Duration

Java class, interface

Função

JavaFX class function ( parâme tros) : retorno

Seqüência/Array

TipoElemento []

TipoElemento []

Classe

N/D

Tabela 1. Classificações de tipos da JavaFX, comparativamente com Java.

Para separar a chave do valor default, use ##[ERRO]”Deu zebra!”; É o único tipo de JavaFX Script para  manipular caracteres. Não existe um tipo específico para um caractere único, como o char do Java. Conversões automáticas são feitas ao invocar classes/APIs de Java que utilizam char; ex.: “Osvaldo”.charAt(0) = “O”. Duration O tipo de valor Duration representa uma quantidade de tempo. Exemplos de literais: 15ms (15 milissegundos), 2.3s (2.3 segundos), 55m (55 minutos), 10h (10 horas), 10h + 5m (10 horas e 5 minutos). Este tipo não passa de

um açúcar sintático para um long contendo o tempo normalizado para milissegundos, mas ao usar o framework de animação da  JavaFX, você verá que é muito conveniente ter uma sintaxe especial para isso. Void  O Void do Java FX significa o mesmo que o do Java, mas é mais útil, ver seção Controle. Referência Os reference types da JavaFX também são familiares. Ver seções sobre funções e sequences.

Edição 69  Java Magazine 

41

 

Funções  JavaFX Script possui funções de primeira ordem. Exemplo:

SEQUENCES Expressão def dias : String[] = [ “Dom”, “Seg”, “Ter” ]  def dias = [ “Dom”, “Seg”, “Ter” ] 

var validador: function (o:Object): Boolean

 sizeo f dias

O tipo da variável validador é uma função que possui um parâmetro do tipo Object e retorna um Boolean. Portanto, funções podem ser atribuídas a variáveis, passadas como parâmetro, etc. como quaisquer outros tipos. A linguagem Java possui uma aproximação desta facilidade, com binando interfaces com inner classes – mas o resultado é uma sintaxe confusa. Com a versão muito melhorada de JavaFX, podemos escrever por exemplo um tratador de eventos assim:

dias[1] 

Stage { onClose: function() { FX.exit() } }

delete dias

Funções suportam os seguintes modificadores (antes do function): Visibilidade (public , protected , package  , e por default script-private); abstract , igual a Java;  override , igual ao @Override do Java 5 (mas é mandatório); bound  , que examinaremos em Binding;  Não há nada equivalente ao final dos métodos Java.

dias[1 .. 2]  dias[1 .. <3]  dias[d | d.startsWith(“T”)]  dias[0] = “DOM”  insert “Qua” into dias insert “Qua” before dias[3]  insert “Qua” after dias[2]  insert [“Qua”, “Qui”] into dias [ dias, [“Qua”, “Qui”] ] 

42 Java Magazine



Edição 69

3 “Seg” [“Ter”, “Qua”] [“Ter”] [“DOM”, “Seg”, “Ter”] [“Dom”, “Seg”, “Ter”, “Qua”] [“Dom”, “Seg”, “Ter”, “Qua”, “Qui” ]

delete dias[1]  delete “Dom” from dias

[“Seg”, “Ter”]

delete dias[1 .. 2] 

[“Seg”] [] [ “D”, “S”, “T” ] (for generator , retorna uma sequence com os elementos

for (d in dias) d.charAt(0)

produzidos por cada iteração) for (d in dias where d.startsWith(“T”)) d.charAt(0)

[ “T” ]

[ 1 .. 100 ] 

[ 1, 2, 3, 4, .., 98, 99, 100 ] (É na verdade uma instância de Range, não consome memória com a lista de elementos)

[ 1 .. 100 step 10]  dias = “Sáb” 

[ 1, 11, 21, 31, 41, 51, 61, 71, 81, 91 ] (Novamente Range) [ “Sáb” ] (Uma sequence de um único elemento pode ser Inicializada/atribuída sem os ‘ [] ’)

reverse dias

 Sequences As sequences da JavaFX Script possuem sintaxe similar, mas signif icado e capacidades diferentes dos arrays do Java. Em comum com os arrays, as sequences são coleções de objetos de um tipo homogêneo e com tamanho fixo, indexadas a partir da base 0. As diferenças começam com algumas sintaxes facilitadas (syntax sugar), mas vão além. A Tabela 2 exemplifica todas as capacidades e sintaxes específicas para sequences. Algumas coisas são simples – por exemplo, o operador sizeof  equivale ao pseudo-atributo length dos arrays do Java; e com o ‘..’ você pode especificar ranges (intervalos), que podem ser usados tanto para determinar quais elementos da sequence serão manipulados (como em delete dias[1 .. 2]), quanto para criar uma sequence contendo todos os números inteiros do range (como em [1 .. 100]).

Resultado [ “Dom”, “Seg”, “Ter” ]

[ 1, null, 2 ] 

[ “Ter”, “Seg”, “Dom” ] [ 1, 2 ] (Nulos não são suportados)

Tabela 2. Sintaxes de uso de sequences.

Uma característica importante das sequences é que elas não admitem aninhamento; qualquer tentativa de colocar uma sequence dentro de outra irá gerar uma sequence única com todos os elementos. Por exemplo, o resultado de [ dias, [“Qua, “Qui”] ] não é [ “Dom”, “Seg”, “Ter”, [“Qua, “Qui”] ] , e sim [ “Dom”, “Seg”, “Ter”, “Qua, “Qui” ]. Esta transformação é conhecida como  flattening  (achatamento), e embora possa parecer uma limitação, é uma característica importante do estilo de programação da linguagem. Este estilo incentiva o uso de expressões “fluentes” – onde o output de cada expressão é usado como input da seguinte, algo similar ao uso de pipes em shell scripts. Para isso funcionar, é preciso que todas as operações utilizem uma estrutura de dados padronizada; no Unix essa

estrutura é texto ASCII, em Java FX Script (e outras linguagens) é a lista ou sequence. O leitor expert em outras linguagens que fazem uso  pesado de listas/sequences, como as da família LISP, sabe que tais linguagens permitem o uso de estruturas aninhadas. Mas JavaFX Script não pretende ser uma linguagem de programação funcional sofisticada, para quem curte técnicas do tipo “map/reduce”; ao invés disso, foi feita a opção por sequences com flattening automático, o que simplifica os cenários de uso mais importantes para JavaFX, por exemplo a inicialização de estruturas complexas como o Scene Graph.

Observe a tentativa da JavaFX Script de usar uma sintaxe SQL-like para a manipulação de dados: sintaxes como insert..into , delete..from , o in e o where do for.

Num detalhe importante, o leitor pode estar confuso com minha afirmação que as sequences são imutáveis, seguida por uma tabela que indica várias sintaxes para sua alteração. Explico: todas essas sintaxes criam uma nova sequence. Por exemplo: var dias = [ “Dom”, “Seg”, “Ter” ]; var diasUteis = dias; delete “Dom” from diasUteis; println(diasUteis);  // [“Seg”, “Ter” ] println(dias);  // [ “Dom”, “Seg”, “ Ter” ]

No exemplo acima, após a atribuição diasUteis = dias , ambas variáveis apontam para a mesma sequence. Mas em seguida, o delete cria uma nova sequence e a atribui à variável diasUteis; a sequence original continua existindo pois ainda é referenciada por dias. Este truque sintático – operadores como delete e insert , que executam uma atribuição ‘escondida’ – mantêm a sintaxe familiar para quem não está acostumado ao estilo funcional (no qual nunca, ou raramente, se altera o valor de variáveis preexistentes). Para mais detalhes, veja o quadro “Imperativo ou Funcional?”.

Declarações Nesta seção veremos como JavaFX Script permite declarar variáveis e funções. Na Tabela 3 , podemos ver que as variáveis de JavaFX podem ser declaradas com var ou def . A diferença é que o def  é usado para constantes (similar às variáveis final do  Java), enquanto var indica variáveis propriamente ditas (i.e., cujo valor pode variar). As declarações estáticas de tipo são opcionais, mas isso não significa que JavaFX Script seja uma linguagem dinamicamente tipada. Ao contrário,  JavaFX é tão estat icamente tipada quanto Java; a diferença é que contamos com inferência de tipos , ou seja, a capacidade do compilador de determinar automaticamente o tipo. No exemplo var x = 5 , o tipo de x é estabelecido como Integer , pois este é o tipo do valor 5 com o qual a variável é inicializada. No caso específico das declarações def  , como o valor inicial é mandatório, a declaração de tipo jamais é necessária. Também salta aos olhos que JavaFX Script utiliza o “estilo Pascal” de declarações de tipos, ou seja nome : Tipo ao invés de Tipo nome como em Java. Apesar de parecer

Expressão var x 

VARIÁVEIS E ATRIBUTOS Significado Ilegal

var x : Integer 

Declara variável mutável, de tipo Integer, inicializada com o valor default para o seu tipo (no caso, 0)

var x = 5

Declara e inicializa variável mutável, de tipo Integer

var x : Integer = 5

Declara e inicializa variável mutável, de tipo Integer

def  x = 5

Declara e inicializa constante, de tipo Integer

def x : 

Declara e inicializa constante, de tipo Integer

def  x 

Ilegal, valor é exigido

def x : Integer 

Ilegal, valor é exigido

for (d in dias) { d = “Domingo” }

Ilegal: é proibido modificar “variáveis induzidas”, como a variável de iteração de um for

Expressão   (a : Integer) : Integer 

{ return a * 2; }  (a : Integer, b : Integer)

{ return a + b; }  (nome : String)

{ println(“Alo, {nome}”); }  (nome)

{ println(“Alo, {nome}”); } … alo(“Osvaldo”);  (Double) : Boolean var f : function function  

FUNÇÕES Significado Declara uma função com um parâmetro retorno também Integer

Integer e tipo de

Declara uma função com dois parâmetros retorno também Integer

Integer e tipo de

Declara uma função com um parâmetro retorno Void

String e tipo de

Declara uma função com um parâmetro retorno Void

String e tipo de

Declara uma variável cujo tipo é uma função com um parâmetro Double e tipo de retorno Boolean Declara uma variável cujo tipo é uma função com um parâmetro Double e tipo de retorno Boolean, e inicializa-a com uma função deste tipo

}

  (a : Double) {  return a >= 0;  } function (a : Double) { a = 5 }

Declara uma variável cujo tipo é uma função com um parâmetro Double e tipo de retorno Boolean, e inicializa-a com uma função deste tipo Ilegal: é proibido modificar parâmetros

Tabela 3. Declarações de variáveis e funções.

uma diferença gratuita e desagradável de  Java, você se acostumará e verá que existem bons motivos para isso (o mesmo vale para Scala, que – não coincidentemente – também usa inferência de tipos). A mesma sintaxe de declarações pode ser utilizada em três escopos distintos: var x = 5; function x1 () { return x; } // Retorna 5 class Y { var x = 6; function x2 () { return x; } // Retorna 6 function z () { var x = 7; def f = function x3 () { return x; } // Retorna 7 } }

 JavaFX suporta variáveis e funções locais, de instância, e globais. Esta última opção parece ser uma novidade, mas de fato não é, pois ocupa o lugar dos static do Java. Se num arquivo Y.fx você tiver um elemento global x , este será acessível externamente com a sintaxe  Y.x , ou seja, igual às static s. Em termos de compilação e desempenho, a equivalência também permanece: variáveis e funções globais são transformadas pelo javafxc em variáveis e métodos static . A inferência de tipos também funciona para funções, especialmente o tipo de retorno: raramente é preciso especificálo explicitamente, pois ao encontrar por exemplo uma operação return a + b no Edição 69  Java Magazine 

43

 

corpo da função, o  javafxc determina que o tipo desta expressão é o tipo estático de retorno a função. Mas alguns programadores podem preferir especificar o tipo de retorno, para ter certeza que este será um tipo específico (neste caso, um return e onde e não possui exatamente o mesmo tipo declarado para retorno, sofrerá uma conversão implícita se possível). O compilador  javafxc irá transformar as funções em métodos idênticos aos do Java, com uma “assinatura”  no bytecode que inclui os tipos dos parâmetros e do retorno, sendo que esta assinatura influi na compilação e na compatibilidade binária de outras classes compiladas com invocações ao método (função) em questão. Assim, as funções de JavaFX Script podem ser  também invocadas a partir de classes Java, de maneira direta e tipicamente sem nenhum overhead.

VISIBILIDADE 

Significado



Igual a Java, permite acesso a partir de qualquer código



Igual a Java, permite acesso para a mesma classe ou derivadas, e também outras classes do mesmo package Igual ao package-private do Java (exceto por exigir uma palavra-chave: não é a visibilidade default!), permite acesso para classes do mesmo  (Somente para propriedades) Permite inicialização em cláusulas de construção do objeto; depois disso, comporta-se como script-private (Somente para propriedades) Permite inicialização e também leitura de qualquer código, mas não permite outras alterações exceto para código do mesmo script Sem palavra-chave, é a default: permite acesso total para código do mesmo script (seja qual for a classe, ou mesmo código “global” do script). Comparando com Java, é um nível intermediário entre e package- private

   script-private

Tabela 4.  PROPRIEDADES 

Significado

 nomeString

Assim como em Java, o modificador de visibilidade (caso exista) vem no início da declaração, antes do   Trigger de alteração. Será invocado inclusive para a atribuição inicial à variável; se for necessário discriminar esta situação, basta usar 

String

Os tipos dos parâmetros, surpreendentemente, também podem ser inferidos. Isso é possível se houver pelo menos uma invocação à função no mesmo script, ou em atribuições ou inicializações para uma propriedade tipada como função: function teste (a, b) { a + b } println(teste(10, 15)); class A { var b : function (a:String); } A { b: function (x) { println(x.charAt(0)) } }

No primeiro exemplo, o compilador determina que os parâmetros a e b de teste() são do tipo Number , devido à presença da invocação teste(10, 15). No segundo exemplo, ao compilar a última linha onde instanciamos um objeto do tipo A , a function (x) {...} não exige declarar que x é uma String pois esta função está sendo atribuída à propriedade A.b , e para esta atribuição ser válida, a função no lado direito deve ter a mesma assinatura da propriedade no lado esquerdo. Visibilidade  JavaFX suporta um conjunto completo de modificadores de visibilidade, de fato, mais completo que Java. Veja a relação completa na Tabela 4. Mais explicações (sobre a necessidade dos novos níveis) na próxima seção. Mas antes de chegar lá, podemos destacar um fato interessante:  JavaFX não possui um nível de visibilidade private. Você logo entenderá o motivo.

44 Java Magazine



Edição 69



if (not   println(“ Novo nome: {nome}”);



} var nome : String

 nomeVelho { 

Trigger de alteração, com cláusula de acesso ao valor anterior da propriedade

println(“Velho: {nomeVelho}, novo: {nome}”); }

Trigger de alteração, com cláusula de acesso ao valor anterior, para se pVelhos[i .. j] = pNovos {  quence. Neste caso temos até quatro variáveis para controle da alteração: println(“Alterando: {pVelhos[i..j]}  é a parte da sequence que foi modificada,  contém os novos elementos que substituíram aquela parte (  para um ). para: {pNovos}”); var projetos : Pr ojeto[] 

} var osvaldo = Pessoa { 

nome: “Osvaldo”, cargos: [  Cargo { titulo: “Editor” }, Cargo { titulo: “Desenvolvedor” } ] 

Instanciação e inicialização de objetos (ou árvores de objetos), através da enumeração de valores iniciais para suas propriedades públicas. É também a notação de objetos literais de JavaFX Script (não por acaso, idêntica à JSON de JavaScript tipado).

 }

Tabela 5. Propriedades.

Propriedades  JavaFX Script utiliza o termo “propriedade” ao invés de atributo. Propriedades são atributos de classes, mas com alguns recursos adicionais em comparação com os atributos do Java. A Tabela 5 resume a sintaxe, que complementamos com as seguintes explicações:

Não se usa getters ou setters. Propriedades são declaradas com visibilidade pública. Para propriedades que você não deseja que possam ser modificadas arbitrariamente, basta usar os níveis public-init (equivalente a um atributo do Java que só pode ser inicializado por um construtor) ou public-read (equivalente a um atributo do  Java que possui getter, mas não setter); 

 Se o leitor observar a  com as estruturas de controle de JavaFX e estiver perguntando “onde está o switch?”, a resposta simples é: não tem. Mas a resposta mais longa é... tem algo parecido , ou poderá ter logo. Muitos designers de linguagens OO apontam que a estrutura de controle switch é anti-OO pois muitas vezes pode ser substituída por polimorfismo ou outras técnicas. Em JavaFX, tiveram a coragem de deixar o switch de fora. Isso significa que você tem que usar ou polirmorfismo, ou cascatas de ifs, onde normalmente usaria um switch. Mas esta parte do design da linguagem me parece incipiente pois, para realmente não sentirmos falta do switch, precisamos de outros mecanismos (o polimorfismo nem sempre é adequado). JavaFX já possui parte da solução (funções de primeira ordem) – é melhor i lustrar com um exemplo prático: [ function() { println(“Case 0”); } function() { println(“Case 1”); } function() { println(“Case 2”); } function() { println(“Case 3”); } ][valor]();

Ao invés de case, usamos uma sequence contendo uma função com o código correspondente para o case do seu índice. Ao invés de switch(valor), usamos o valor para indexar a sequence, obtendo e executando a função que contém o código deste “caso”. Note que os “casos” poderiam ter parâmetros e retornar valores (desde que todos tenham a mesma assinatura:

Não há construtores. Objetos são instanciados com uma sintaxe de objetos literais;  Triggers. As propriedades podem 

possuir triggers, que são funções invocadas automaticamente quando o valor da função for modificado. Isso substitui a necessidade de setters para alterações não-triviais de propriedades;  Binding. O recurso de binding (ver seção Binding) permite manter diversas propriedades associadas entre si de forma automática. Para quem vem de uma linguagem OO tradicional como C++ ou Java, poderão parecer “heréticas” idéias como não en-

isso será verificado pelo compilador!), o que já tornaria esta técnica mais poderosa que o switch/ case do Java. Observe mais uma vez a inferência de tipos de JavaFX: no exemplo, o tipo da sequence é function() [].Digamos que você edite apenas um dos “casos” e coloque um parâmetro Integer na função; então o tipo inferido será o tipo mais elementar compatível com todos os casos – no caso, um tipo Function genérico (herdado por todos os tipos de função). Mas se você utilizar a sequence como no exemplo, indexando-a e executando a invocação com (), o compilador exige que todas as funções possuam assinatura compatível com a da invocação – no caso, nenhum parâmetro – e reclamará de qualquer “caso” que seja diferente disso. O maior problema é que nem todos os switch/ case possuem um domínio de valores como 0, 1, 2..., que se prestem ao mapeamento para índices de sequence. O ideal seria então usar mapas (sequences associativas), o que permitiria criar uma estrutura como [ “Ouros”: function() { println(“Ouros”} ], etc.; isso também permitiria o uso de objetos arbitrários, não só números, como chave. Infelizmente JavaFX ainda não possui nenhum suporte nativo a estruturas de dado deste tipo – pode-se us ar as do Java como  java.util.HashMap, mas isso não teria facilidades como uma sintaxe especializada de inicialização e indexação. Uma versão futura da linguagem possuirá este suporte a mapas, provavelmente a JavaFX 2.0

(ver JFXC-642 no JIRA). Mas também seria bom permitir a declaração de funções triviais ainda mais simples (sem o function()), e mesmo assim, faltaria o default. Há linguagens, como Smalltalk, que sempre se viraram muito bem sem o switch. Na pior hipótese você pode simplesmente usar ifs em cascata, o que em JavaFX talvez não seja ruim, lembrando que if é uma expressão e você pode escrever código como:

capsular atributos com getters e setters, ou não dispor de um nível de visibilidade private. Mas analisando a linguagem como um todo, podemos entender seu design. A soma de recursos como visi bilidade mais refinada (especialmente public-init e public-read), instanciação “estilo JSON”, triggers e binding, substitui 99% das necessidades de getters, setters e construtores. Ou seja, seus atributos (opa, propriedades!) continuarão tão bem encapsulados quanto antes , só que com um código bem mais simples – e, de quebra, algumas novas facilidades. Quanto à visibilidade private , esta não existe de fato nem em Java – um membro

private de uma classe pode ser acessado

def sobrenome = if (nome == “Osvaldo”) “Doederlein” else if (nome == “Eduardo”) “Spínola” else “Silva”;

…o que é mais enxuto que, com um switch, ter que fazer uma atribuição separada para sobrenome em cada case. (Para um exemplo tão trivial o Java permitiria usar o ternário ?:, mas não se os cases tivessem que executar algum statement antes do valor retornado.) Mas esta solução ainda incomoda um pouco: esteticamente, o primeiro ”caso” (if) não tem um cabeçalho idêntico aos demais (else if); e a repetição de “nome ==” também me incomoda um pouco, ainda que seja mais legível e genérica que os cases. Eficiência não é um problema pois o compilador poderia reconhecer uma cascata de ifs com estrutura s imilar a um switch, e gerar código idêntico (com bytecodes tableswitch ou lookupswi tch).

por suas classes aninhadas ou inner classes. Classes aninhadas/inner costumam ser fortemente acopladas à sua enclosing class ,  justificando o acesso privilegiado. Em JavaFX a lógica é igual: todo o código contido por um script .fx é fortemente acoplado (se não for, divida-o em vários scripts).  JavaFX só torna explíc ito e homogêneo um design que, em Java, é acidental e imperfeito. Acidental, pois não era assim no  Java 1.0 – mudou no 1.1 quando as classes aninhadas/inner foram criadas. Imperfeito, pois Java permite definir várias classes no mesmo arquivo .java (desde que só uma seja pública), mas não há privilégios de Edição 69  Java Magazine 

45

 

acesso a membros privados entre estas classes – embora o mesmo argumento de alto acoplamento seja válido. Ilustrando de forma mais aplicada as sintaxes de propriedades e construção de objetos, apresento novamente o “Alô Mundo” da JavaFX: Stage { title: “Aplicação Alô Mundo” width: 250 height: 80 scene: Scene { content: Text { font: Font { size: 24 } x: 10, y: 30 content: “Alô, JavaFX!” } } onClose: function() { FX.exit() } }

O código acima constrói a aplicação completa (ok, faltando só as declarações package e import). Este código instancia (e retorna – ver seção Controle) um objeto Stage. Este objeto é inicializado com o valor 250 para a propriedade width , etc. No caso da propriedade scene , seu valor é um objeto Scene que é inicializado da mesma forma, idem para a propriedade content de Scene. Finalmente, a propriedade onClose tem o tipo function (): Void , sendo inicializada com uma função deste tipo. Teoricamente, você poderia fazer o mesmo em Java, com expressões new aninhadas. Mas há três problemas. Primeiro, os construtores do Java são rígidos – se um objeto com os atributos a , b , c possui apenas um construtor (a,b) , inicializar apenas a exige passar explicitamente o valor default de b , e inicializar c exige invocar setC() após a construção (saindo além da inicialização hierárquica). O segundo problema é que os frameworks Java não costumam trabalhar com “atributos funcionais” como onClose , preferindo design patterns como Template Method (um método onClose() que pode ser redefinido) ou Observer (um método como addCloseListener()); ambos suportam uma expressão única de inicialização, mas ao custo de código bem mais confuso devido à horrível sintaxe das inner classes. Terceiro, a invocação de construtores não indica o nome dos argumentos, de forma que expressões de construção longas e/ou aninhadas tendem a ficar difíceis de ler se você não souber de cor qual argumento

46 Java Magazine



Edição 69

BINDING Declaração

Significado

def  x = bind y 

Sempre que o valor de y mudar, este mesmo valor será copiado para x (x é um alias para y)

def  x = bind y + f(10)

Sempre que o valor de y mudar, a expressão y + f(10) é reavaliada e o novo resultado atribuído a x. Note que f(10) não será invocada novamente – o valor retornado anteriormente será reutilizado

def  x = bind y  + f(z, 10)

Dessa vez, como a invocação a f() tem um parâmetro alimentado por uma variável z; se esta variável mudar, f(z, 10) será reavaliada

bound function f ( x : Double) {  Como f  é declarada como uma bound function, o bind de z reexecutará return x * y  f(a) sempre que qualquer variável utilizada por f() seja alterada. Isso inclui } tanto os parâmetros (como a) quanto outras variáveis externas (atributos def  z = bind f(a) ou globais) como y def iniciaisDias = bind Sempre que ocorrer uma modificação na sequence dias, o for será reexefor (d in dias) d.charAt(0) cutado somente para os elementos modificados, resultando em alterações também incrementais na sequence iniciaisDias def  posAtual  = bind Point {  Se uma das variáveis xAtual ou yAtual mudar, será construído um novo  x: xAtual, y:yAtual  objeto Point, que será atribuído a posAtual  }

def  posAtual = Point {  bind x: xAtual, y:yAtual   }

def  x = bind y with inverse

Se a variável xAtual mudar, a propriedade posAtual.x será modificada (não será criado um novo objeto Point ). Se yAtual for alterada nada acontecerá, pois não tem bind Se y for alterada, seu valor é copiado para x. Mas se x sofrer uma atribuição, seu valor é copiado para y Nota: with inverse não suporta expressões mais complexas

Tabela 6. Binding. OPERADORES ARITMÉTICOS Operador

Significado

+ - * / ++ -+= -= *= /= mod

Igual a Java Igual a Java: operadores com atribuição combinada Resto de divisão, como o % do Java (não há equivalente a %=)

OPERADORES RELACIONAIS Operador

Significado

not or and == != <= >= < >

Negação, como o ! do Java Disjunção, como o || do Java Conjunção, como o && do Java Igual a Java

OUTROS OPERADORES Operador

Significado

instanceof  obj as String sizeof e

Igual a Java Typecast: como (String)obj  do Java Retorna o tamanho de uma expressã o. Para uma sequence, é o seu número de elementos. Para objetos de outros tipos (ex.: Integer), é 0 se o objeto for null, 1 se não-nulo.

Tabela 7. Operadores.

que vai em cada posição (ou se isso não for evidente pelos valores passados). Alguns frameworks Java modernos adotam o pattern de “APIs fluentes” no qual métodos terminam com um return this , o que permite encadear expressões

como: new X(a).setB(b).setC(c) , etc. Um método addXxxListener() também poderia seguir este design. Mas o resultado, mais uma vez, é bem pouco elegante. Na minha opinião, é uma tentativa pobre de imitar a linguagem Smalltak, na qual o estilo “fluente”  é natural devido à sua sintaxe de mensagens (não há

 parâmetros posicionais) e aofato de todos os métodos retornarem this por default (não existe o tipo void  ). E como, na definição do Java SE 7, os conservadores venceram a briga e ficaremos sem closures, o Java continua condenado a gambiarras pavorosas (ainda que sejam melhor-que-nada) como “APIs fluentes”.

Por que tudo isso é importante – não é muito oba-oba em cima de uma economia de algumas linhas de código para inicializar objetos complexos? Acontece que esta facilidade sintática possui outros “efeitos colaterais” positivos. Por exemplo, você pode usar a sintaxe de notação de objetos literais do JavaFX para muitas tarefas onde tipicamente usaria XML, resultando num código que é mais enxuto e legível, fácil de emitir e interpretar (como sabe qualquer programador JavaScript que prefere JSON a XML). Um exemplo concreto disso é o formato gráfico FXD (ver Edição 67), nada mais que código JavaFX com inicializações de classes gráficas. Outro exemplo é a construção da árvore de componentes e eventos da GUI, ilustrada acima: este código, além de enxuto e legível, é ideal para manipulação de ferramentas. Por tudo isso, JavaFX dispensa a necessidade de linguagens de descrição de GUI como XAML (Silverlight), MXML (Flex), XUL (Mozilla), “layouts” do Android, etc. A falta de algo equivalente (uma DSL para GUI & gráficos) não é uma lacuna de JavaFX, pelo contrário, sua presença em plataformas competidoras revela inadequações das linguagens de programação principais destas plataformas. Na JavaFX, o FXD é inclusive  bom o suficiente para substituir o formato SVG de gráficos vetoriais1. Binding Binding é uma das características mais “famosas” de JavaFX Script, pois além de ser um poderoso recurso de programação em geral, é uma peça essencial para os frameworks e o estilo de programação da plataforma JavaFX. Se você (como eu) começou aprendendo sobre binding examinando os fontes de diversos demos que só utilizam as duas 1 Isso obviamente não é devido somente à sintaxe de objetos literais, mas também ao poderoso framework de Scene Graph, que define entidades gráficas suficientemente ricas para ser equivalente ao metamodelo SVG.

DECISÃO Declaração

Significado

if (1 != 0) then  println(“ok!”) else  println(“pane na CPU!”) var msg = if (1 != 0) “ ok ” else “  pane ” 

Igual a Java, exceto que a palavra-chave opcional)

Declaração

Significado

while (x++ < y) println(x) for (d in dias) println(d) var nums = for (n in [ 3, 2, 1]) n*2

Igual a Java. A expressão while tem tipo Void

for (n in nums where n >= 0)...

Filtra a iteração, ignorando elementos que não satisfazem ao . Em Java, exigiria um  contendo um    var  retorna o número ordinal do elemento iterado (0, 1, 2, ...). Tecnicamente,   é um operador de sequences, pois a iteração é sempre feita sobre sequences Como em Java, sendo que  e  têm tipo  Não há "gotos disfarçados"  label ou  label 

for (d in dias) println ( indexof d) for/while (..) { if (a) break else continue }

then é suportada(porém,

Igual ao operador ternário ‘ ?:’ do Java

msg = “ok” ITERAÇÃO / GENERATORS

Igual ao for estendido do Java 5, só muda ‘ :’ para ‘in’ Gera uma sequence com todos os valores “retornados”

nums = [ 6, 4, 2 ]

EXCEÇÕES Declaração

Significado

try, throw, catch, finally, throws

Como em Java. As expressões  e  têm tipo 

BLOCOS Declaração

Significado

{ fazAlgo() } { fazAlgo();  return } { fazAlgo(); return valor } { fazAlgo(); valor }

Igual a Java: bloco Igual a Java: bloco, retornando valor. Note que o  é opcional

INVOCAÇÃO Declaração

new Cliente(“Osvaldo”) m(a, b) obj.m(a, b) Tabela 8. Estruturas de controle.

Significado Igual a Java: instancia objeto e invoca construtor Igual a Java: invocação de método, sendo  o receiver default

variantes mais simples deste recurso (bind x = y e criação de objetos com binding igualmente simples em propriedades), poderá se surpreender com a Tabela 6 , que mostra uma sofisticação extraordinária. Vamos demonstrar esta capacidade com um exemplo que explora uma das sintaxes complexas, combinado com triggers para logar o que acontece: var dias = [ “Dom”, “Seg”, “Ter” ] on replace d[i..j] = nd { println(“{d[i..j]} = {nd}”) } def iniciaisDias = bind for (d in dias) d.charAt(0); dias[1..2] = [ “TER”, “QUA” ];

Executando o código acima, o output será o seguinte: -> DomSegTer -> DST SegTer -> TERQUA DST -> DTT DTT -> DTQ

As duas primeiras linhas são efeito das atribuições dos valores iniciais a dias , e por conseqüência do binding, a iniciaisDias – pois a trigger é disparada inclusive para a atribuição inicial. (Note que ao exibir sequences com o recurso de mesclagem de strings, os elementos são concatenados.) Na terceira linha, que é o Edição 69  Java Magazine 

47

 

 Ao serem apresentados à JavaFX, muitos desenvolvedores têm a seguinte reação: aprovam as funcionalidades, o framework, mas... isso precisava de uma nova linguagem? Não daria para suportar todos os recursos da JavaFX com APIs orientadas à linguagem Java, ou talvez, uma sintaxe “Java estendida” (mantendo compatibilidade retroativa) ao invés de inventar outra linguagem separada? A resposta curta: Sim, seria possível fazer tudo com Java ou com uma extensão de Java... porém, não seria uma boa idéia. Vamos exp licar os porquês – a “resposta longa”.

tipação. As competidoras incluem JavaScript, ActionScript, e linguagens XML como XAML e MXML (para estas últimas, a vantagem é o uso de ferramentas visuais). JavaFX Script possui diversas características de alta produtividade, como: inferência de tipos, binding, sequences, inicialização declarativa de estruturas hierárquicas de objetos, sintaxes de alto nível para diversas necessidades de programação geral (desde o simples relaxamento na pontuação até o for “turbinado”), e sintaxes especiais para algumas APIs.

 Agilidade Produtividade Competitiva Todas as plataformas RIA competidoras utilizam alguma linguagem de programação considerada de “alta produtividade” – pelo menos segundo alguns critérios, como alta densidade de código (mais funcionalidade com menos linhas de código) e facilidade de proto -

que mais nos interessa, “SegTer -> TERQUA” vemos que o binding de iniciaisDias foi acionado pela atribuição a dias; sendo que esta atribuição modificou apenas dois dos seus elementos. Na quarta e quinta linhas, vemos que o for (d in dias) é reexecutado somente para estes elementos (dias[1..2]), e as alterações de iniciaisDias também são feitas de maneira incremental: repare que são geradas duas alterações independentes para os elementos de índice 1 (“S”"T") e 2 ("T""Q"), ao invés de uma alteração única que causaria um log "DST -> DTQ". Podemos concluir várias coisas. Primeiro, como já disse, o binding do Java vai bem além daqueles casos simplórios que você viu em javafx.com/samples; é um recurso que pode ser explorado de inúmeras formas. Segundo, as capacidades das sequences do Java são ainda mais incrementadas pelo tratamento especial de outros recursos da linguagem, como triggers e binding – de uma forma geral, a linguagem tenta otimizar o esforço destas operações tornando-as o mais incrementais possíveis (se você tem uma sequence de 1000 elementos e altera apenas um elemento, isso não irá gerar

48 Java Magazine



Edição 69

Quando se fala em evolução da linguagem Java, não podemos nos esquecer que a Sun não é dona do Java. A especificação da linguagem, bem como de todas APIs formais, é controlada pelo Java Community Process (JCP). Embora a Sun mantenha certas prerrogativas e um alto grau de influência no JCP, isso não in clui carta

execuções de triggers ou bindings considerando todos os 1000 elementos). Como nada é perfeito, um alerta: binding é pesado, especialmente devido às capacidades de avaliação incremental de sequences e expressões complexas. Para cada variável sujeita a binding e cada expressão bind , o runtime é obrigado a manter na memória estruturas de dados relativamente grandes. É por isso que você pode encontrar na internet algumas pessoas comentando que ficaram horrorizadas ao ver que uma variável Boolean ocupava 100 bytes ou mais. Use este recurso apenas quando necessário (especialmente na JavaFX Mobile).

Operadores  Já apresentamos alguns operadores da JavaFX especializados em sequences; veremos agora os operadores mais convencionais para manipulação de valores em geral. A Tabela 7 revela algumas das minhas poucas discordâncias do design de JavaFX Script. Alguns operadores desviam de  Java, a meu ver gratuitamente: por que, por exemplo, and ao invés de &&? O argumento é que operadores nomeados são mais “simples” que símbolos misteriosos

branca para fazer o que quiser com a plataforma. Em especial, a evolução de especificações preexistentes é sempre “torturante” pois precisa levar em conta os interesses de diversos players com voz no JCP, e possivelmente grande investimento na tecnologia em questão. A quebra de compatibilidade retroativa é virtualmente impossível. A Sun chegou atrasada à briga do R IA. Se fosse seguir o caminho de estender a linguagem Java (mesmo que isso fosse tecnicamente uma boa idéia), ou criar a JavaFX sob os auspícios do JCP, o lançamento da JavaFX 1.0 levaria pelo menos o dobro do tem po, e a sua evolução até a JavaFX 2.0 levaria 3-4 anos ao invés de um ano. Isso liquidaria qualquer chance da JavaFX de competir. Órgãos de padrões como o JCP são excelentes para tecnologias já razoavelmente maduras, mas são quase sempre péssimos para criar coisas completamente novas – a inovação raramente acontece em comitês.

como && , mas não engulo isso, lembrando que linguagens RIA competidoras, como JavaScript e ActionScript, utili zam os operadores simbólicos tradicionais da família C. Os operadores simbólicos são mais legíveis pois se destacam de nomes de variáveis e funções; ao ler um código como aa || bb && cc , a distinção entre operadores/operandos é imediatamente clara, o que não ocorre para aa or bb and cc – que exige um “parsing mental” para reconhecer or e and como operadores e as demais palavras como identificadores de variáveis. Pior que isso, vejo algumas inconsistências: a exclamação ! foi substituída por not como operador de negação, mas no operador diferente-de != , continuamos vendo a exclamação indicando negação. Mais: o ‘|’ de [a | a > 5] e o where de for (a in b where a > 5) têm exatamente o mesmo significado... nada é perfeito, e na minha opinião, a sintaxe de operadores não-simbólicos é um lugar onde o design de JavaFX Script derrapou. Outras divergências me parecem OK. O operador de typecast as é mais elegante que o do Java, pois sendo posfixado, é coerente com a ordem de avaliação, ex.: dVar * 2.0 as

Integer , temos primeiro uma multiplicação entre variáveis Double , depois sua conversão para Integer , e observe também que não precisamos usar parênteses – (dVar * 2.0) as Integer – pois a precedência do as é mais fraca (i.e.,

o typecast é avaliado depois da maioria dos outros operadores). E o sizeof  é um conceito  bastante interessante, coerente com o design orientado a expressões de JavaFX Script.  JavaFX não possui operadores de manipulação de bits, como | , & , ^ , ~ , << , >> e >>> do Java. O veterano de C/C++/Java dentro de mim também não gostou disso à primeira vista, mas acabei entendendo, pois estes operadores são de uso muito raro na enorme maioria das aplicações, e  JavaFX Script é uma linguagem dedicada à camada de aplicação – não se supõe que alguém vá usá-la para “escovações de  bits” como algoritmos de compressão ou criptografia. Principalmente lembrando que JavaFX é uma linguagem “parceira” de Java: é trivial invocar métodos de casses Java a partir de JavaFX e viceversa, misturar ambas classes no mesmo projeto/IDE etc. Além disso, JavaFX reserva os tokens << e >> para outro propósito: escape de literais externas. Por exemplo, se você tiver que invocar um método bind() de uma classe  Java,pode fazê-lo comobj.<>(argumentos). Sem o escape isso seria ilegal por que bind  é uma  palavra-chave em JavaFX. Java 7 também terá um mecanismo de escape similar,

Controle  JavaFX Script, como qualquer linguagem de programação, precisa de estruturas de controle como decisões e loops. Você poderia imaginar que pelo menos nesta área, a linguagem seria praticamente igual a Java. Engano, também aqui JavaFX apresenta inovações poderosas, muito embora mantenha uma boa similaridade sintática com Java. Veja a Tabela 8. Começaremos pela novidade conceitual: JavaFX Script é uma linguagem orientada a expressões . Não existe a dualidade entre “statements” (que não geram nenhum valor, como o if  do Java) e “expressões” (que retornam um valor, como x + y). Porém, nos casos onde não há nenhum valor que faça sentido associar

CONTROLE Declaração

Significado

Pessoa { 

Declara uma classe

var nome : String; var sobrenome : String; function nomeCompleto () {  “{nome}{sobrenome}”  }  } craque = Pessoa { 

Instancia (aloca e inicializa) objeto de uma classe

nome: “Mané”  sobrenome: “Garrincha”   } Pessoa();

craque.nome = “Mané”  craque.sobrenome = “Garrincha”  list  java.uti l.

 ArrayLi st(100); IPessoa { 

Instancia (aloca e inicializa) objeto de uma classe (Classes JavaFX não podem ter construtores, mas a sintaxe  é suportada por questão de homogeneidade) Instancia (aloca e inicializa) objeto de uma classe Neste caso é uma classe Java, que tem construtores com parâmetros, que podemos invocar de forma normal Classe abstrata pura (substitui interfaces)

abstract function nomeCompleto ();  }  A extends B , C, D {...}

Herança

C 

O bloco init é invocado após a alocação do objeto e a inicialização de todas as propriedades (inclusive de todas as classes-base). Os  são invocados depois disso, e se for o caso, depois que todos os init da hierarquia Pode-se redefinir tanto funções quanto propriedades. No caso das propriedades, o  serve apenas para modificar o valor default e/ou a cláusula 

init { println(“init ok!”); }

 { println(“postinit ok!”); } }



var y = 0; function f () { y + y }

}    }

Tabela 9. Classes.

a determinada expressão, seu tipo é definido como Void . Isso pode parecer malandragem, qual é a diferença entre um statement e uma expressão Void? A maior diferença é técnica: a gramática da linguagem fica mais simples e unificada, o único efeito do Void é não permitir o uso de determinada expressão no lado direito de lugares que exijam um valor, como uma atribuição. Porém, podemos ver que a linguagem faz um grande esforço para que quase tudo seja uma expressão normal (não-Void). Notavelmente, as estruturas de controle if e for são expressões que retornam valores. Vemos também que num  bloco de código, o return é geralmente desnecessário para retornos com valor – basta terminar o bloco com um valor, como: def function par (n : Number) { n mod 2 == 0 }

O bloco {} em si é uma expressão que possui valor, o qual pode ter tipo Void (se termina por um return sem valor ou outra expressão de tipo Void) ou outro tipo qualquer. E não, a Tabela 8 não está incompleta: Veja o quadro “Cadê o switch?”. Generators Uma vantagem do design orientado a expressões de JavaFX, e seu uso de tipos de dados de alto nível como sequences e estruturas de controle avançadas como  generators (for), é que o  javaf xc tem oportunidade para fazer otimizações importantes. Por exemplo, ao conhecer o for da JavaFX Script, você talvez tenha se horrorizado ao imaginar que este sempre irá gerar uma sequence com os valores produzidos por cada iteração Edição 69  Java Magazine 

49

 

 Na minha mania de aprender novas linguagens mexendo em código dos outros, cheguei ao se guinte trecho de um demo (javafx.com/samples/ SmokeParticles/):

Esta nova versão faz uma substituição única da sequence antiga pela nova, a qual é criada da seguinte forma: primeiro temos um for que retorna todos os elementos da sequence anterior que continuam vivos (juntei a funcionalidade de isdead() a update()), e depois temos a nova Particle. O ‘[...]’ mais externo serve concatena a sequence gerada pelo for com o objeto final, sendo que graças ao flattening automático, o resultado será uma sequence simples com todos estes elementos. A nova versão é característica do estilo funcional, evitando alterações repetitivas como insert e delete. Sobrou uma alteração de variável (parts = ...), mas é uma só, e mesmo esta atribuição só restou por que eu não quis reescrever o programa todo. É um código bem mais “limpo”, menor (10 linhas ao invés de 14) e mais simples (sua complexidade ciclomática – quantidade e aninhamento de estruturas de controle – é menor.) Mais importante, a versão funcional é idêntica a uma descrição formal / matemática do algoritmo, que podemos enunciar como: “o novo conjunto de partículas é formado pelas partículas preexistentes que após o update() continuem vivas, mais uma partícula nova”. É por isso que tanta gente gosta de programação funcional: é o estilo de programação que permite traduzir, de forma direta, algoritmos especificados de forma matematicamente rigorosa (que é quase sempre a descrição mais enxuta e elegante possível).

Bem, agora as más notícias. Testando meu novo código, este funcionou, mas com um desempenho muito pior. O problema é que a sequence parts é amarrada, via binding, ao scene graph da animação do programa; porém, o binding de sequences não é otimizado para o cenário de substituição total de uma sequence (com uma atribuição explícita), apesar de ser otimizado para manipulações pontuais como insert e delete. A otimização em questão evita que o scene graph inteiro seja reconstruído em cada frame da animação, o que resulta em péssimo desempenho. Ou seja, não se trata de um bug/limitação de desempenho das sequences propriamente ditas, mas somente da combinação entre sequences e binding, ou talvez, do runtime do scene graph. Regist rei um novo bug descrevendo o problema (javafx-jira. kenai.com/browse/JFXC-2911). É o tipo de coisa que, infelizmente, podemos esperar de um software complexo como a JavaFX que ainda é praticamente recém-lançado no momento em que escrevo. Mas não tira o mérito do estilo de programação funcional ou do design de sequences (o JIRA da JavaFX registra uma grande quantidade de bugs similares, a maioria corrigidos antes mesmo do release 1.0 – mas o trabalho obviamente ainda não terminou)

do loop. Mas não é exatamente assim; o compilador só faz isso se necessário. Assim, no código

for não está sendo utilizado de qualquer

def x = [1, 2, 3] def y = for (n in x) n * 2

Classes

(tanto classes quanto interfaces). Ou seja,  JavaFX Script unifica nossas class e interface numa única entidade, também não exigindo distinguir entre extends e implements. Como JavaFX faz isso? Se você observar os arquivos gerados pelo javafxc , verá que uma classe C da JavaFX gera um par de .class , que se você descompilar gerando arquivos .java (ou examinar com o  javap), verá que correspondem a uma interface C.Intf  e uma classe C que implementa esta interface. Junto com alguns outros truques de compilação, isso permite integrar o paradigma de herança múltipla generalizada da JavaFX Script ao modelo OO

var parts: Particle[]; … function update() : Void { insert Particle { x : 84 y : 164 timer : 100 acc : bind acc vx : 0.3 * random.nextGaussian() vy : 0.3 * random.nextGaussian() - 1 } into parts; var i = sizeof parts - 1; while( i >= 0 ) { parts[i].update(); if( parts[i].isdead()) delete parts[i.intValue()]; i--; } }

Seu funcionamento é o seguinte: primeiro um novo objeto Particle é criado e inserido ao final da sequence parts; depois, um loop varre todos os elementos que já estavam na sequence, invocando os métodos update() e isdead(), e deletando da sequence aqueles que estão “mortos”. Mas achei esse código feio, confuso, então resolvi reescrevê-lo: function update() : Void { parts = [ for (p in parts where not p.update()) p Particle { x : 84 y : 164 timer : 100 acc : bind acc vx : 0.3 * random.nextGaussian() vy : 0.3 * random.nextGaussian() - 1 } ] }

…a sequence será de fato gerada, no caso [2, 4, 6] , e atribuída a y. Porém, neste outro código: def x = [1, 2, 3] for (n in x) n * 2

…o for só irá avaliar a expressão n * 2 para cada n in x , mas nenhuma sequence será criada, pois o “valor de retorno” do

50 Java Magazine



Edição 69

forma (como termo de outra expressão, lado-direito de atribuição, etc.).  JavaFX é uma linguagem OO baseada em classes, com sintaxe básica parecida com  Java, mas com pelo menos um grande desvio do design de Java. A Tabela 9 resume a sintaxe das classes de  JavaFX. Não existem interfaces, apenas classes, e a herança múltipla é suportada para tudo (funções abstratas e concretas, e até mesmo propriedades). Classes da JavaFX podem inclusive herdar qualquer coisa de Java

do bytecode / JVM, que suporta herança múltipla apenas para interfaces com métodos abstratos.

Conclusões Este artigo encerra uma primeira “trilogia” de JavaFX, na qual cobrimos os aspectos principais desta nova plataforma: tecnologia RIA, mobilidade, linguagem de programação, pontos principais do framework. A partir deste ponto, minha expectativa é que um leitor que sabe programar Java e tem interesse pela plataforma JavaFX possa andar com seus próprios pés, chegando ao ponto de desenvolver aplicações RIA sofisticadas para desktop e dispositivos móveis. Há duas partes da JavaFX que cobrimos de forma superficial: os recursos de mídia (ver Edição 67) e as APIs  javafx.* (ver Edição 68). Estes temas renderiam, seguramente, pelo menos mais dois capítulos da série.

Mesmo na linguagem JavaFX Script, coberta neste artigo, existem tópicos específicos que poderíamos explorar, como a integração com  Java, ou o desempenho. Mas preferi parar por aqui, por três motivos. Primeiro, a plataforma JavaFX ainda é muito recente e ainda é difícil avaliar o interesse dos leitores por uma cobertura tão contínua e abrangente. Segundo, o mundo não parou por causa da JavaFX, e há outros temas que pretendo cobrir nas próximas edições. Terceiro, a JavaFX ainda está em rápida evolução: no caso específico dos frameworks, não vou gastar nosso tempo (meu e dos leitores) com um “artigão” sobre os frameworks da JavaFX 1.1, quando sei que já em junho deste ano (quando nossa próxima Edição já estaria nas bancas) a Sun terá lançado a JavaFX 1.5, com muitas novidades especialmente nas APIs. Resumindo, espero que o leitor

tenha apreciado estes primeiros artigos, tanto quanto eu apreciei escrevê-los... chegou a hora de fazer uma pausa, mas com planos de voltar à JavaFX daqui a algumas edições, com as baterias recarregadas. Osvaldo Pinali Doederlein [email protected]

É Mestre em Engenharia de Software Orientado a Objetos, membro individual do Java Community Process e trabalha na Visionnaire Virtus como arquiteto e desenvolvedor.

Dê seu feedback sobre esta edição! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

 eedb    e      ê

    e    ç   d       o     ã

  s

Dê seu voto sobre este artigo, através do link:

www.devmedia.com.br/javamagazine/feedback 

  

  





  

Edição 69  Java Magazine 

51

SEÇÃO JAVA: NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA

 

N

este artigo conheceremos a nova API de data e hora que está sendo elaborada para a plataforma Java SE 7. O foco da nova API é resolver vários problemas que afetam os desenvolvedores  Java há anos, presentes nas classes java.util. Date e  java.util.Calendar.



Por que uma nova API?

Para que serve: 

A arquitetura elaborada para as classes Date e Calendar , ambas do pacote java.util é bastante questionável. Veremos algumas dessas decisões arquiteturais dúbias, além de “bugs” da API atual, no decorrer do artigo. Outro grande problema é a falta de tipos para representar unidades comuns no dia-a-dia de qualquer desenvolvedor como, por exemplo, períodos, instantes, durações, entre outros. Sem class es que representem essas unidades do “mundo real”, é necessária a criação de soluções paliativas por conta e ri sco dos desenvolvedores. Isso resulta em mais codificação e código legado para manutenção. Esses pontos claramente abrem espaço a uma nova abordagem para o tratamento de datas e horas dentro da plataforma Java.

Apresentar a nova API de datas e horas que será incorporada na plataforma Java, provendo discussões sobre a sua arquitetura e exemplos de uso da API, além de comparações com as classes atuais.

 Alguns dos problemas apresentados  por Date e Calendar  Um dos principais problemas das classes atuais é a inconsistência. A classe java.util. Date não representa uma data, mas sim um instante na linha do tempo. Desta forma, não temos como representar somente uma data ou somente o tempo. Outro exemplo de inconsistência é o fato da classe Date utilizar anos com base em 1900, enquanto a Calendar requerer os anos completos, incluindo o século. O código apresentado a seguir, apesar do uso de um construtor descontinuado (deprecated), ilustra a criação de uma data cujo ano será 3909, ao contrário do que parece ao ler o código.

52 Java Magazine



Edição 69

De que se trata o artigo:  O artigo aborda o resultado da JSR-310, a JSR que está definindo a nova API de data e hora que será incorporada na plataforma Java. A arquitetura e as principais classes e interfaces da API são discutidas e exemplificadas. Além disso, são abordadas as lacunas presentes nas classes atuais (Date e Calendar) e como a javax.time endereça tais problemas.

Em que situação o tema é útil:  O tema é importante para qualquer um que deseje estar atualizado sobre as novas tendências da plataforma Java. A manipulação de datas e horas é peça-chave em qualquer implementação e a criação de uma nova API tende a facilitar muito a vida do desenvolvedor.

Novos tempos: javax.time:  O artigo aborda a nova API para representação de datas e horas da plataforma Java e como ela facilita a vida do desenvolvedor Java, corrigindo bugs e endereçando problemas das classes atuais Date e Calendar. A nova API possui representações distintas para datas que serão utilizadas para cálculos computacionais e datas que serão utilizadas por seres humanos. Além disso, temos representações padrão para tipos de dados que atualmente precisamos criar como durações, períodos e intervalos.

Date date = new Date(2009, 2, 1);

O início dos meses em 0 (Zero) na classe Calendar também é algo que tem atrapalhado a vida dos desenvolvedores  Java de forma considerável. Por exemplo, para criar uma instância de Calendar que represente a data 01/01/2009, temos que escrever o seguinte código: Calendar calendar = new GregorianCalendar(2009, 0, 1);

Além disso, temos uma série de outros problemas arquiteturais ou de implementação:  Os objetos são mutáveis, inseguros em ambiente multi-thread, requerendo sincronização; Não há como formatar uma instância de Calendar usando as classes do pacote java.text;

Não existe opção para representar períodos ou durações de forma padronizada;  As APIs atuais exigem muito código para tarefas rotineiras de man ipulação de datas e horas. Sem mencionar ainda que muitas dessas “tarefas rotineiras” constituem casos de uso comuns e poderiam ser implementados pelas próprias APIs. 

Esses são apenas alguns dos problemas que a JSR 3101 irá resolver. Os já velhos conhecidos problemas devido às 1 A nova especificação para representação de datas e horas dentro da plataforma Java, denominada javax.time neste artigo, está sendo criada pela JSR 310. O link para acesso à JSR pode ser obtido na seção de Links.

      



DANIEL CICERO AMADEI E MICHAEL NASCIMENTO SANTOS alterações no horário de verão também estão sendo endereçados. Além de tudo isso, você verá que a API é muito mais intuitiva e irá lhe poupar muitas e muitas linhas de codif icação.

Repare na atribuição ao objeto date com o resultado da invocação do método. Isso é necessário, pois é criado um novo objeto, mantendo o original inalterado, pois os objetos envolvidos são imutáveis.

Princípios de Design da JSR 310

Interfaces Fluentes As classes e interfaces seguem o padrão de fluência para permitir uma melhor legibilidade do código. Isso transforma as invocações a mais do que um método em sentenças de fácil leitura. O código apresentado a seguir, além do ano, altera o mês e o dia.

A JSR 310 tem sido elaborada com algu ns princípios para facilitar seu uso e entendimento e tornar seu código mais robusto e de fácil leitura. Baseada em padrões A nova API está sendo construída totalmente alinhada com o ISO-8601, um padrão internacional para representação de datas e horas. Imutável  Os principais objetos da nova API serão imutáveis. Não será possível alterá-los após a construção. Também serão threadsafe , podendo até mesmo ser singletons . A seguir, um primeiro exemplo, da criação de uma data (sem a hora!): LocalDate date = LocalDate.date(2009, 1, 1);

Nesse caso, criamos uma data com a classe  javax.time.calendar.LocalDate. Essa classe representa uma data sem fuso horário (time zone2) no padrão ISO-8601, resultando em 2009-01-01. Caso desejemos alterar o ano dessa data, por exemplo, para 2010 não iremos utilizar um método set(). Neste caso, devemos utilizar um método with() , que cria uma nova instância da classe com o ano desejado. O código ficaria conforme apresentado a seguir: date = date.withYear(2010);

2 Utilizaremos os termos em inglês para a zona de fuso horário, time zone e fuso horário como offset, como veremos no decorrer de todo o artigo para que não precisemos usar os termos em português, muito mais incomuns até mesmo aqui no Brasil.

date = date.withYear(2010).withMonthOfYear(3). withDayOfMonth(2);

Clareza Os métodos são bem definidos e indicam claramente seu propósito. Por exemplo, para subtrair dois anos de uma data qualquer, utilizamos o seguinte código: date = date.withYear(2010).withMonthOfYear(3). withDayOfMonth(2); date = date.minusYears(2);

a utiliza para ajustar suas datas de forma padronizada e bem definida. Além disso, a  javax.time traz consigo uma classe utilitária, a  javax.time.calendar.DateAd justers , contendo implementações dos casos de uso mais comuns para o ajuste de datas. Essas implementações devem satisfazer a maioria das necessidades de desenvolvimento. O código apresentado a seguir ilustra o ajuste sendo realizado em uma data: LocalDate date = Clock.systemDefaultZone().today(); date = date.with(DateAdjusters.next(DayOfWeek.MONDAY));

O código que apresentamos, além do ajuste da data, apresenta uma nova classe:  javax.time.calendar.Clock . Essa classe é um façade para o acesso à data e hora correntes. O método today() , que invocamos na classe Clock , retorna a data corrente como uma instância de LocalDate. Voltando a falar sobre o ajuste da data, ele ocorre na invocação ao método with(). Informamos DateAdjusters.next(DayOfWeek.MONDAY) como parâmetro do método. O objeto retornado pelo método next() é responsável

Isso irá resultar na data 2008-03-02. Muito mais claro do que o método roll(intfield, int amount) da classe Calendar. Extensível  Através de pontos de extensão, utilizando conceitos do design pattern Strategy , é possível controlar e customizar como a API se comporta em relação às datas e horas. Mesmo assim, não é necessário ser um especialista para usar a API. São fornecidas implementações padrão para a maioria dos cenários. Um exemplo desses “ganchos” para extensibilidade é a interface javax.time.calendar. DateAdjuster , capaz de realizar ajustes em uma data de forma padronizada. Você simplesmente implementa essa interface e Edição 69  Java Magazine 

53



por ajustar a data para a segunda-feira subsequente à data informada. Avaliando as datas, caso executemos tal código no dia 05/02/2009, após o ajuste, a nova data (lembre-se da imutabilidade!) será dia 09/02/2009. Ainda no âmbito dos  Adjuste rs , outro exemplo muito interessante de sua aplica bilidade seria o ajuste das datas para dias úteis. Você pode, ainda, implementar seu próprio adjuster – digamos, para saltar feriados obtidos de um cadastro de feriados do seu sistema. Duas escalas para lidar com tempo A  javax.time apresenta duas formas distintas para lidar com o tempo. Uma escala voltada para máquinas, denominada Continuous e a outra com foco em datas para seres humanos, denominada Human.

Continuous Essa abordagem da javax.time é voltada para máquinas e representa o tempo na forma de um número incremental, sem muito significado para seres humanos, porém com grande valor para uso em processamentos que requerem cálculos envolvendo timestamps. Instant  A classe  javax.time.Instant representa um ponto instantâneo na linha do tempo, um

instante de tempo, conhecido também como timestamp. Possui precisão de nanossegundos e 96 bits para armazenamento. Através dessa abordagem, é possível armazenar até algumas centenas de vezes uma data equivalente ao tempo de existência do universo. (Para os curiosos, o universo tem em torno de 13,8 bilhões de anos.) A seguir, um exemplo onde validamos se um instante é superior a outro utilizando o método isAfter(). Instant instante1 = Clock.systemDefaultZone().instant(); //qualquer código aqui Instant instante2 = Clock.systemDefaultZone().instant(); boolean avaliacao = instante1.isAfter(instante2);

Duration A classe  javax.time.Duration representa uma duração de tempo. Dentro da  javax. time , ela representa a duração entre dois instantes. O instante inicial que forma uma instância de Duration é inclusivo e o final é exclusivo. Apesar de armazenar dados provenientes de lá, a classe Duration é desconectada e independente da linha do tempo. O código apresentado a seguir ilustra o uso da classe Duration: Instant agora = Clock.systemDefaultZone().instant(); Instant umMinutoMais = agora.plusSeconds(60); Duration duration = Duration.durationBetween(agora, umMinutoMais); System.out.println(duration);

No trecho de código apresentado, vemos primeiramente a criação de dois instantes. O primeiro representa o momento exato da execução, enquanto que o segundo derivamos a partir do primeiro com a soma de 60 segundos. Repare no método plusSeconds(). Ele é conciso, bem definido e indica exatamente seu propósito e a unidade manipulada. Após a criação dos instantes, criamos uma duração entre eles, que deverá conter exatamente 60 segundos. Ao imprimir a duração no console,

temos a impressão da duração utilizando o padrão ISO-8601. InstantInterval  A classe  javax.time.InstantInterval representa um intervalo de instantes na linha do tempo. A classe pode possuir intervalos inclusivos, exclusivos ou algum dos intervalos pode não estar associado, isso quer dizer que podemos criar o intervalo com apenas o instante de início e posteriormente associar o instante final. O código apresentado 3 a seguir ilustra a criação de um intervalo a partir de dois instantes e a posterior verificação se um terceiro intervalo está contido entre eles: Instant agora = Clock.systemDefaultZone().instant(); Instant umMinutoMais = agora.plusSeconds(60); InstantInterval intervalo = InstantInterval. intervalBetween(agora, umMinutoMais); boolean contido = intervalo.contains(Clock. systemDefaultZone().instant());

No exemplo, por utilizarmos o método “padrão”, o intervalo inicial é inclusivo e o final é exclusivo. Existe outro método que recebe valores booleanos indicando se desejamos que cada um dos intervalos seja inclusivo (true) ou exclusivo (false). Além disso, podemos construir a instância de InstantInterval a partir dos métodos “builder ”: intervalFrom() e intervalTo() .

Human Essa abordagem da  javax.time é voltada para seres humanos. Ela representa os valores de datas e horas utilizando campos com classes específicas para representar cada um dos dados do calendário: ano, mês, dia, hora, minuto e segundo. Além desses campos mais comuns, temos algumas outras classes ou enumerações para representar, por exemplo, o dia do ano, a semana do ano, os nanossegundos de cada segundo, entre outras. Através da abordagem para seres humanos, temos formas (classes!) para representar datas e horas, datas sem hora, horas sem data, offsets e time zones. 3 Até a finalização deste artigo, a classe InstantInterval ainda não estava finalizada e funcional na implementação de referência da  javax.time e o código apresentado como exemplo ainda nãoestava funcionando corretamente.

54 Java Magazine



Edição 69

Datas e Horas locais (sem time zone ou offset) Os tipos mais simples presentes dentro da  javax.time são os tipos chamados de “locais”. Esses tipos podem representar data ou hora de forma isolada ou as duas em conjunto. São chamadas de locais por não estarem associados a um offset ou time zone. LocalDate A primeira classe que mereceria nossa atenção seria a  javax.time.calendar.LocalDate. Como já estamos cansados de ver exemplos envolvendo essa classe, pois é a que estamos acompanhando no decorrer do artigo, veremos algo a mais. A representação dos campos de datas e horas dentro das classes é efetuada através de classes com este propósito. Com isso, essas classes contém métodos implementando ações comuns, requeridas de cada um desses campos que compõem nossas datas e horas. A  javax.time utiliza como padrão os métodos get() retornando valores numéricos para tais campos, por exemplo, getYear() retorna o ano como um inteiro e os métodos to() retornam as classes específicas, no caso do ano, seria a classe javax.time. calendar.field.Year. O exemplo apresentado a seguir ilustra o uso do método toYear(). LocalDate hoje = Clock.systemDefaultZone().today(); Year ano = hoje.toYear(); boolean bissexto = ano.isLeap();

No exemplo, obtemos o ano e, a partir do objeto criado, verificamos se ele é bissexto. Repare como isso seria trabalhoso caso o ano fosse representado somente pelo tipo primitivo (int). Teríamos que fazer esse cálculo manualmente, cada um em seu projeto, testar esse código e mantê-lo. No exemplo apresentado a seguir, temos a obtenção do mês, representado pela enumeração  javax.time.calendar.field.MonthOfYear e, a partir dela, obtemos o último dia do mês representado pela classe  javax.time.calendar. field.DayOfMonth. LocalDate hoje = Clock.systemDefaultZone().today(); MonthOfYear mes = hoje.toMonthOfYear(); DayOfMonth ultimoDiaMes = mes.getLastDayOfMonth (hoje.toYear());

Vemos aqui também, com a obtenção do último dia do mês, o grande valor no uso de classes específicas em comparação com tipos primitivos. O cálculo do último

dia do mês é resolvido automaticamente pela API, poupando você, des envolvedor, desse (grande) trabalho. LocalTime A classe  javax.time.calendar.LocalTime representa uma hora sem time zone ou offset. O trecho de código apresentado a seguir imprime a hora corrente e, posteriormente, subtrai uma hora e imprime o valor atualizado. LocalTime agora = Clock.systemDefaultZone().currentTime(); System.out.println(agora); agora = agora.minusHours(1); System.out.println(agora);

LocalDateTime A classe  javax.time.calendar.LocalDateTime representa uma data e hora sem time zone ou offset. O trecho de exemplo apresentado a seguir imprime a hora corrente e posteriormente subtrai 36 horas e imprime o valor atualizado. LocalDateTime agora = Clock.systemDefaultZone(). currentDateTime(); System.out.println(agora); agora = agora.minusHours(36); System.out.println(agora);

No exemplo, caso a primeira data e hora fosse representada por “2009-0207T11:50:08.093”, após a subtração de 36 horas, teríamos “2009-02-05T23:50:08.093”. Repare que o cálculo ocorreu corretamente e alterou até mesmo a data.

Datas e Horas com offset As datas e horas com offset representam um valor relativo ao UTC (Coordinated Universal Time ou Tempo Universal Coordenado). Esses valores relativos, ou offsets, estão geralmente casados com as áreas de fuso horário (time zones), porém a  javax. time separa os dois conceitos: offsets e time zones em classes distintas. O objetivo dessa separação é tratar trocas de offset por uma mesma time zone devido a horários de inverno ou verão. OffsetDate A classe  javax.time.calendar.OffsetDate representa uma data com um offset em relação ao UTC. Por exemplo, ao criar um objeto

Nota do DevMan Thread-safe: Thread-safe ou, melhor dizendo, thread-

safety é o conceito que usamos para nomear a situação em que o acesso de múltiplas threads a um elemento no mesmo momento não apresenta resultados inconsistentes, sem que uma thread tenha interferência sobre os dados manipulados por outra thread.

OffsetDate aqui no Brasil, na região que segue

o horário de Brasília, temos como offset o valor -03h00min, ou seja, se em Brasília são 16h, o horário UTC estará marcando 13h. O trecho de código apresentado a seguir ilustra a obtenção da data atual considerando o offset: OffsetDate hoje = Clock.systemDefaultZone().offsetDateTime(). toOffsetDate();

Caso esteja sob o offset de Brasília, ao imprimir o objeto, a string “2009-02-0703:00” teria sido impressa no console, seguindo o padrão ISO-8601 para datas e horas com offset. OffsetTime A classe  javax.time.calendar.OffsetTime representa um horário com um offset em relação ao UTC, seguindo o mesmo padrão da classe OffsetDate. O trecho de código apresentado a seguir ilustra a obtenção do horário atual considerando o offset. Após isso, a criação de uma nova instância de OffsetTime contendo o mesmo horário, porém com o offset encontrado no Japão, que é +09h00min. Após isso, fazemos uma comparação dos dois horários com o intuito de ilustrar que a comparação levará em conta o offset. OffsetTime hojeBrasil = Clock.systemDefaultZone(). offsetDateTime().toOffsetTime(); OffsetTimehojeJapao = hojeBrasil.withOffset(ZoneOffset. zoneOffset(9)); boolean horarioJapaoPosterior = hojeJapao.isAfter(hojeBrasil);

Após a execução do código apresentado, a variável horarioJapaoPosterior irá armazenar o valor true indicando que a hora no Japão é posterior. OffsetDateTime A classe  javax.time.calendar.Off setDateTime representa uma data e um horário com um Edição 69  Java Magazine 

55



offset em relação ao UTC, seguindo o padrão dos dois exemplos vistos até o momento. O código a seguir ilustra a obtenção de uma OffsetDateTime. OffsetDateTime hojeBrasil = Clock.systemDefaultZone(). offsetDateTime();

Ao imprimir essa variável no console, temos uma string representando a data, horário e o offset seguindo o padrão ISO: “2009-02-09T23:20:54.171-03:00”.

Time Zones Além de objetos capazes de armazenar o offset, temos a classe  javax.time.calendar. ZonedDateTime que armazena também o time zone. O time zone é representado pela classe  javax.time.calendar.TimeZone que tem o propósito de tratar regras e exceções das alterações nos offsets das regiões mundiais. Essas alterações geralmente se devem a mudanças no horário de verão ou inverno. Dentro da javax.time , é possível instanciar a classe TimeZone a partir de um identificador da base de time zones zoneinfo4 ou a partir do offset em relação à UTC. O código apresentado a seguir ilustra a obtenção de duas instâncias de ZonedDateTime , a primeira com o time zone padrão da JVM, configurado como “América/Sao_Paulo” e o segundo forçando o uso do time zone de Paris. ZonedDateTime agora = Clock.systemDefaultZone(). zonedDateTime(); System.out.println(agora); TimeZone timeZone = TimeZone.timeZone(“Europe/Paris”); agora = Clock.system(timeZone).zonedDateTime(); System.out.println(agora);

Ao executar o código apresentado, as datas e horas correspondentes ao time zone informado são impressas no console: 2009-02-09T23:37:18.968-03:00 UTC-03:00 2009-02-10T03:37:18.968+01:00 Europe/Paris

Repare que a primeira string impressa apresenta o time zone como UTC-03:00, isso por que não há um identificador correspondente para este time zone, ao 4 A base de dados denominada zoneinfo ou tz é um conjunto das zonas de fuso horário de todo o mundo. Essa base de dados também é chamada de Olson Database devido ao nome de seu criador,Arthur David Olson.

56 Java Magazine



Edição 69

contrário do que ocorreu com o time zone de Paris, que criamos a partir do identificador, que é apresentado na impressão do objeto. Uma forma equivalente de obter a instância de ZonedDateTime à que utilizamos é a apresentada a seguir, uma vez que o time zone de Paris corresponde ao offset de uma hora em relação ao UTC: ZonedDateTime agora = Clock.systemDefaultZone(). zonedDateTime(); System.out.println(agora); TimeZone timeZone = TimeZone.timeZone(ZoneOffset. zoneOffset(1)); agora = Clock.system(timeZone).zonedDateTime(); System.out.println(agora);

Matchers e Resolvers Como já dissemos, a  javax.time recorre a conceitos do design pattern Strategy para que você possa customizar pontos de seu comportamento. Um exemplo pelo qual já passamos foi o dos Adjusters quepermitem a realização de ajustes em datas e horas de forma bastante flexível. Além dos Adjusters , a  javax.time nos provê o conceito de Matchers e Resolvers , que veremos agora.  Matchers Os Matchers possuem a responsabilidade de realizar consultas em datas e horas de forma muito simples e flexível. Eles reduzem drasticamente a quantidade de código e a lógica empregada neste tipo de operação. O código apresentado a seguir ilustra a consulta à data (e hora) atual. Nesse caso consultamos se o ano é 2009, valorizando uma variável booleana denominada ano2009. Como estamos realmente em 2009, essa variável será valorizada com true. LocalDateTime agora = Clock.systemDefaultZone().dateTime(); boolean ano2009 = agora.matches(Year.isoYear(2009));

A consulta envolvendo o horário é praticamente idêntica, conforme pode ser visto a seguir: LocalDateTime agora = Clock.systemDefaultZone().dateTime(); boolean vinteUmaHoras = agora.matches(HourOfDay. hourOfDay(21));

É possível realizar tais operações, pois cada uma dessas classes ( Year , HourOfDay

e as outras classes representando os elementos do calendário) implementa as interfaces necessárias para executar o método matches(). A interface que representa o  Matc her para a consulta em datas é a  javax.time. calendar.DateMatcher , que possui um único método boolean matchesDate(LocalDate input). Já a interface para a consulta em horários é a  javax.time.calendar.TimeMatcher e ela segue o mesmo padrão da outra que vimos, possuindo um único método boolean matchesTime(LocalTime time). Essas i nterfaces estão disponíveis para você, desenvolvedor, implementar sua própria estratégia de consulta nas datas ou nos horários. Com isso, você garante que terá essa lógica implementada em um objeto coeso e reutili zável. A Listagem 1 apresenta um exemplo de implementação de DateMatcher para verificar se a data possui um dia ímpar ou não. A classe  javax.time.calendar.DateMatcher s possui alguns matchers pré-configurados para você utilizar. Entre os matchers que  já vêm por padrão temos, por exemplo, um para verificar se estamos durante a semana ou em um final de semana, se é o primeiro ou último dia do mês, além de alguns outros. O código apresentado a seguir ilustra o uso da classe DateMatchers para a verificação se a data corrente é um final de semana. LocalDateTime agora = Clock.systemDefaultZone(). dateTime(); boolean finalDeSemana = agora.matches(DateMatchers. weekendDay());

Como visto, a classe DateMatcher pode nos auxiliar com a verificação de datas e nos auxiliar muito em tarefas do mundo real como, por exemplo, verificar se determinada data está dentro do domingo de páscoa ou na sexta-feira santa. Resolvers Assim como os matchers , os Resolvers são pontos de extensibilidade disponíveis na javax.time . Através deles você pode indicar como deseja que uma data inválida seja tratada, por exemplo, ao criar uma data no dia 29 de fevereiro em um

Listagem 1. Exemplo do uso de um DateMatcher customizado para realizar a consulta de dias ímpares package br.com.jm.javax.time.human.matchers; //imports...

E uma classe para representar o período como um todo:  javax.time.period.Period. O código apresentado a seguir representa a criação de um período de duas horas:

public class ExemploMatcherDiaImpar {

}

public static void main(String[] args) throws Exception { LocalDateTime agora = Clock.systemDefaultZone().dateTime(); boolean diaImpar = agora.matches(new DiaImparMatcher()); System.out.println(diaImpar); }

class DiaImparMatcher implements DateMatcher { @Override public boolean matchesDate(LocalDate data) { if (data.getDayOfMonth() % 2 == 0) { return false; } else { return true; } } }

Listagem 2. Uso de static imports para minimizar a verbosidade do código no uso de Resolvers package br.com.jm.javax.time.human.resolvers; import static javax.time.calendar.field.DayOfMonth.dayOfMonth; import static javax.time.calendar.field.MonthOfYear.monthOfYear; import static javax.time.calendar.field.Year.isoYear; import javax.time.calendar.DateResolvers; import javax.time.calendar.LocalDate;

public static void main(String[] args) throws Exception { LocalDate data = DateResolvers.nextValid().resolveDate(isoYear(2009), monthOfYear(2), dayOfMonth(29));

}

System.out.println(data);

ano que não seja bissexto. A classe javax. time.calendar.DateResolvers possui algumas implementações dos casos de uso mais comuns onde possa vir a ser necessário o uso de um Resolver. O exemplo apresentado a seguir ilustra a criação de uma data utilizando um resolver provido pela classe DateResolvers que resolve uma data inválida como a próxima data válida. LocalDate data = DateResolvers.nex tValid(). resolveDate(Year. isoYear(2009), MonthOfYear.monthOfYear(2), DayOfMonth. dayOfMonth(29));

Ao imprimir tal data no console, temos como data apresentada 2009-03-01. Caso você tenha achado o código verboso demais, é possível utilizar o recurso de static imports para reduzir a verbosidade. A Listagem 2 apresenta tal opção.

A partir desse momento, o objeto representa o determinado período para o qual foi criado. Ao imprimir tal período no console, é impressa sua represe ntação de acordo com o padrão ISO-8106. Essa representação para o período de duas horas é “PT2H” Uma das grandes vantagens no uso de objetos especializados para os períodos é permitir que você execute operações nesse objeto. Isso resultará na criação de outro objeto para representar o novo período resultante da operação. O objeto que representa o período também é imutável. A seguir, uma subtração de quarenta minutos de nosso período de duas horas: .

period = period.minusMinutes(40);

public class ExemploResolverSI {

}

Period period = Period. hours(2);

Períodos Os períodos, dentro da  javax.time , são cidadãos de primeira-classe. Isso quer dizer que existem classes capazes de representá-los, ao contrário do que você encontra nas APIs atuais, onde não há forma padrão para representar períodos. Através da representação dos períodos, podemos expressar durações de tempo da maneira tratada pelos seres humanos como, por exemplo, a duração de uma reunião ou de suas férias. Como dito, existe uma class e para cada parte do período:  javax.time.period.field.Days  javax.time.period.field.Hours  javax.time.period.field.Minutes  javax.time.period.f ield.Months  javax.time.period.f ield.Seconds  javax.time.period.f ield.Weeks  javax.time.period.f ield.Years 

Ao executar tal operação, o período ainda permanece com duas horas e menos quarenta minutos e necessita ser normalizado para representar o período real, que seria de uma hora e vinte mi nutos. Normalização O método normalize() retorna uma cópia do período normalizado para os limites padrão dos campos de data e hora, levando em conta as seguintes regras: 12 meses em um ano; 60 minutos em uma hora; 60 segundos em um m inuto; 1.000.000.000 de nanossegundos em um segundo.

Por exemplo, um período de 13 meses é normalizado para um ano e um mês e a criação de um período de 5000 minutos com o código Period.minutes(5000) resulta em um período normalizado de 83 horas e 20 minutos. Caso você necessite ainda realizar a normalização por dias, quebrando cada 24 horas em um dia, você deve utilizar o método normalizedWith24HourDays() , que neste nosso exemplo resultaria em um período de três dias, onze horas e vinte minutos. Edição 69  Java Magazine 

57



Michael Nascimento Santos

desenvolvimento. Acesse o site da JSR (veja seção de Links) e faça parte da definição do futuro da linguagem. O código apresentado neste artigo está disponível para download no site da revista, contando com um JAR da  javax.time compilado durante a escrita do artigo. Como a API ainda está sendo concebida, é possível que quando o artigo chegar a você, leitor, algo possa ter sido alterado. Devido a isso, deixamos aqui a sugestão de baixar os fontes da última versão da API e adequar os exemplos às possíveis alterações. Acesse também a lista de discussões para entender o rumo que está sendo dado à API.

Conclusão Você conheceu um pouco sobre a nova especificação para representar datas e horas dentro da plataforma Java. Essa nova API tenta trazer várias facilidades e corrigir problemas conhecidos das opções atuais, buscando transformar seu código em algo mais legível e simples. Passamos por todos os pontos mais importantes da nova API, fornecendo exemplos pontuais e focados, tentando ambientar você com os novos conceitos. A JSR 310, que está definindo a nova API, é aberta e você pode contribuir para seu

[email protected] 

É um dos spec-leads da JSR-310 e expert em outras cinco JSRs. Ganhou um JavaOne Rock Star Speaker Award pela sua palestra sobre a JSR-310 em 2008 no JavaOne. Atua como Senior Technical Consultant na Summa Technologies do Brasil.

Daniel Cicero Amadei [email protected]

É Bacharel em Sistemas de Informação pelo Mackenzie e pós-graduado pela Fundação Vanzolini. Trabalha com Java desde 1999 e possui as certifi cações SCJP, SCWCD, SCBCD, SCDJWS, SCEA, BEA Certified Developer: Integration Solutions e BEA Certified SOA Architect. Já atuou como Desenvolvedor, Analista e Arquiteto de Sistemas e atualmente é Consultor em Arquitetura BEA.

 jsr-310.dev.java.net  Site de desenvolvimento da JSR 310, onde você pode obter acesso a todos os artefatos relacionados à nova API, além de participar de seu desenvolvimento, cadastrando-se nas listas de discussão.

Dê seu feedback sobre esta edição! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

 jcp.org/en/jsr/detail?id=310 Site oficial da JSR 310, parte do JCP.  joda-time.sourceforge.net  Site da Joda Time, API que está servindo de base para o desenvolvimento da JSR 310.

Edição Especial

               

Entenda os principais conceitos sobre Testes e Inspeção de Software

       

                                                                                                    

               

                                                                                                       

Requisitos

Conheça os principais conceitos envolvidos na Engenharia de Requisitos

Especial

Projeto

Entenda o conceito de Arquitetura de Software e como trabalhar com os Estilos Arquiteturais

Mais de 60 mil downloads na primeira edição!

Processos

Melhore seus processos através da análise de risco e conformidade

Veja como integrar conceitos de Modelos Tradicionais e Ágeis

o      

    a

   e

    ã  i   d       o

Faça um up grade em sua carreira.

Engenharia de Software

Ferramentas Open Source e melhores práticas na gestão de defeitos

c  

www.devmedia.com.br/javamagazine/feedback 

Saibaseusignificadoeparaqueserve

Verificação, Validação & Teste

eed

Dê seu voto sobre este artigo, através do link:

Conhecimento faz diferença!     e     n       i     z     a     g     a     m

  u

  e    s      ê

Veja como integrar o Processo Unificado ao desenvolvimento Web

Faça já sua assinatura digital! | www.devmedia.com.br/es

Em um mercado cada vez mais focado em qualidade ter conhecimentos aprofundados sobre requisitos, metodologia, análises, testes, entre outros, pode ser a diferença entre conquistar ou não uma boa posição profissional. Sabendo disso a DevMedia lança para os desenvolvedores brasileiros sua primeira revista digital totalmente especializada em Engenharia de Software. Todos os meses você irá encontrar artigos sobre Metodologias Ageis; Metodologias tradicionais ( document  driven); ALM ( application lifecycle management ); SOA (aplicações orientadas a servicos); Analise de sistemas; modelagem; Métricas; orientação à objetos; UML; testes e muito mais. Assine já!

          

        

                    

                                                                  

                    

                    



       



 



       

       

       







































































 



 









 



 





      

 



59

69   Java Magazine                Edição       

SEÇÃO JAVA: NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA

      

S

egundo a Biologia, o processo permanente de mudança que vem transformando a vida na Terra, desde o seu princípio mais simples até a sua atual diversidade, é conhecido como Evolução. A evolução ocorre quando um ser vivo se reproduz, e pequenas mudanças aleatórias nos seus genes fazem com que o seu descendente seja diferente dele próprio. Essas mudanças, se benéficas, fazem com que o indivíduo sobreviva o tempo necessário para se reproduzir, dando início a um novo ciclo de transformações, o que resulta no surgimento de novas espécies1. Num paralelo entre o processo de evolução dos seres vivos com o de um software de computador, verificamos como ambos são parecidos. O software, geralmente, inicia o seu clico de vida de forma bem simples, com poucas funcionalidades, somente com o intuito de atender certa demanda do momento. À medida que vai sendo utilizado, o software, se for bom, acaba aguçando a criatividade dos usuários, que solicitam novas versões mais aperfeiçoadas e com mais funcionalidades. Estas solicitações induzem o software a entrar no clico de evoluções, resultando em novos releases. Neste artigo, falaremos sobre como este processo evolutivo dos softwares atingiu o Wireless Toolkit (WTK). Apresentaremos algumas das principais novidades que a Sun Microsystems preparou, justificando a mudança do seu nome para  Java ME Pla tform SDK 3.

De Toolkit para SDK O fato de a Sun ter mudando o nome do WTK não deve causar muito espanto 1 Trecho baseado no artigo ‘Introdução à Evolução’.(fonte Wikipedia)

60 Java Magazine



Edição 69

 De que se trata o artigo:  Apresentação da nova ferramenta da Sun para a plataforma Java ME: o Java ME Platform SDK, o sucessor do Wireless Toolkit. Neste artigo, as principais novidades trazidas por esta ferramenta são apresentadas de uma forma clara e objetiva para o leitor.

Para que serve:  Proporcionar uma apresentação objetiva das principais funcionalidades da nova ferramenta de desenvolvimento da plataforma Java ME. Esta apresentação concede ao leitor uma visão geral, mas completa, do que de novo ele pode vir a utilizar daqui para frente no desenvolvimento de suas aplicações.

Em que situação o tema é útil:  No momento em que uma ferramenta que usamos com frequência surge com uma versão nova, é sempre válido dar uma olhada nas principai s novidades que ela vem trazendo. Estas novid ades, geralmente, vêm para melhorar nossa produtividade, além de nos proporcionar mais subsídios, a fim de desenvolvermos aplicações ainda melhores.

 Java ME Platform SDK 3:  Assim como os seres vivos, os softwares de computador também evoluem a partir do momento em que se inicia um novo ciclo. No caso da principal ferramenta de desenvolvimento da plataforma Java ME, o Wireless Toolkit, este seu novo ciclo trouxe-lhe evoluções bastante expressivas. Mudanças que vão desde o nome, passando pelo novo conceito da ferramenta, até chegar às suas novas funcionalidades. A ferramenta que antes era considerada um simples toolkit (caixa de ferramenta), agora passa a ser um completo SDK, contando com um ambiente integrado de desenvolvimento. Editor de código, emuladores, nova máquina virtual e APIs são somente algumas das muitas novidades trazidas por esta nova ferramenta. Sem falar que até o seu nome é novidade, pois agora a ferramenta é chamada de Java ME Platform SDK 3. Com todas essas novidades é possível constatar o grande passo que a plataforma Java ME dá em direção a uma maior popularização da plataforma. Pois com o ambiente de desenvolvimento integrado baseado no NetBeans, novos desenvolvedores terão mais facilidades de criar as suas primeiras aplicações, o que garante uma maior chance de crescimento da comunidade Java ME.

aos desenvolvedores, tendo em vista que esta não é a primeira vez. Desde o surgimento da plataforma Java ME, por volta de 1999, esta já é a segunda vez que a Sun muda o nome da ferramenta. O nome original,  Java 2 Pla tform Mic ro Edition Wireless Toolkit , foi substituído em 2007, devido à nova versão

1.5 (ou 5) da plataforma Java. Desde então, a Sun retirou o famigerado “2” de todos os nomes de suas plataformas e ferramentas. Com isto, o que era J2ME virou Java ME, o que também acabou refletindo na primeira mudança de nome do WTK para Sun Java Wireless Toolkit.

    

 ERNANDES MOURÃO JÚNIOR A mudança do nome na nova versão, que agora insere o termo SDK (Standard Development Kit), se deve ao fato da ferramenta proporcionar um ambiente de desenvolvimento completo, e não somente os emuladores, ferramentas de monitoração (e.g. monitor de memória), códigos de exemplo, documentação, etc. O pacote agora também vem com editor de código com assistência de codificação (veja a seção “Netbeans “Lite”). Além disso, a plataforma Java ME é suportada de forma muito mais completa (o antigo WTK suportava apenas a configu ração CLDC, exigindo toolkits separados para CDC e outras variantes). Um arsenal completo que eleva a categoria da ferramenta, justificando o acréscimo do termo SDK.

NetBeans “Lite” De longe a mais importante e impactante novidade do Java ME Platform SDK 3 é o ambiente de desenvolvimento integrado (veja Figura 1), baseado na plataforma NetBeans. Nas versões anteriores da ferramenta, todo o desenvolvimento das aplicações (e.g. escrita de código) tinha que ser feito numa ferramenta (IDE) à parte, como por exemplo, Eclipse, NetBeans, VistaMax, etc. O trabalho do WTK era executar os emuladores, alterar configurações de ambiente da plataforma, monitoramento de memória, dentre outras funcionalidades auxiliares. IDEs como Eclipse e NetBeans, por exemplo, permitiam que o WTK pudesse ser integrado, possibilitando ao desenvolvedor uma transparência do seu uso. As principais ferramentas deste am biente de desenvolv imento integrado são o editor de código, gerenciador de projetos e arquivos, integração com o

Figura 1. 

Ant, configurações do projeto (e.g. propriedades do arquivo JAD), ofuscador de código, além de outras de cunho mais geral, encontradas em qualquer distri buição do NetBeans. Quem já trabalha com o Netbeans Mo-

 bility Pack vai se sentir em casa neste novo ambiente, pois ambos são praticamente o mesmo. Além disso, aqueles que, porventura, decidirem migrar para o NetBeans Mobility Pack futuramente,  já que este dispõe de mais fu ncionalida-

Edição 69  Java Magazine 

61

 

Nota do DevMan Ant: Ant é uma ferramenta utilizada para automatizar a

construção de software. Ela é similar ao make, mas é escrita na linguagem Java e foi desenvolvida inicialmente para ser utilizada em projetos desta linguagem. (fonte Wikipedia)

des, não encontrarão barreiras. Pois o arquivo de projeto do Java ME Platform SDK 3 é totalmente compatível com o Mobility Pack, o que facilita muito a migração entre as ferramentas.

A KVM se Despede Após quase dez anos desde sua chegada, a máquina virtual da Java ME, a Kilo Virtual Machine (KVM) , fi nalmente encerra o seu ciclo de vida. Este fim já era esperado, já que há alguns anos, a KVM já não estava mais presente nos dispositivos móveis disponíveis no mercado, sendo esta substituída pela CLDC HotSpot Virtual Machine. Um projeto mais moderno e robusto, que já conseguia atender melhor as atuais demandas por desempenho. O que prolongou um pouco mais a vida da KVM foi o fato da Sun conti nuar utilizando-a em seus emuladores. Até a última versão do WTK, a 2.5.2, todos os emuladores ainda eram baseados na KVM. No entanto, com a chegada do Java ME Platform SDK 3 a Sun finalmente “aposentou” a KVM, trazendo de uma vez por todas, a CLDC HotSpot Virtual Machine também para os seus emuladores, inclusive para a configuração CDC. Com esta mudança, o comportamento das aplicações no emulador ficou mais parecido ao encontrado nos dispositivos reais. Dentre as principais vantagens da CLDC HotSpot Virtual Machine, comparada à KVM, estão a compilação dinâmica das instruções de bytecode em instruções nativas (veja o quadro “Compilação Just-in-time (JIT)”), menor consumo e fragmentação de memória, maior economia da bateria, dentre outras. Em termos de números, a execução de uma instrução compilada dinamicamente, chega a ser cinquenta vezes mai s rápida do que uma instrução interpretada.

62 Java Magazine



Edição 69

Figura 2. 

Para conhecer um pouco mais sobre a CLDC HotSpot Virtual Machine e a sua chegada aos dispositivos móveis, veja a seção Links , além do artigo “Java: Uma perspect iva”, da Edição 65.

Descobrindo as Diferenças Existe na Internet uma iniciativa chamada de Wireless Universal Resource File (WURFL) , aonde desenvolvedores e entusiastas vêm tentando catalogar todos os dispositivos móveis disponíveis no mercado, assim como suas características. O objetivo é fornecer uma base de dados centralizada para os desenvolvedores. Neste caso, um arquivo XML, afim de que eles possam conhecer, antecipadamente, as principais diferenças que existem de um dispositivo para outro, além de ter uma idéia da fatia de mercado que suas aplicações estão abrangendo. Com o objetivo de facilitar o acesso às informações providas pelo WURFL (para saber mais sobre esta iniciativa, veja a seção Links), a Sun desenvolveu uma nova funcionalidade, no Java ME Platform SDK 3, chamada Device Database Search , que acessa essa base de dados de uma forma fácil e rápida. O

usuário pode tanto solicitar para ver a lista completa de todos os dispositivos disponíveis, como ele também pode aplicar alguns filtros (e.g. fabricante, modelo, JSRs suportadas, tamanho de tela, etc.), a fim de facilitar a busca pelo dispositivo desejado. O resultado é apresentado numa lista, onde modelo e fabricante são identificados. Para ver os detalhes de um determinado dispositivo, basta selecioná-lo na lista, que todas as suas informações serão exibidas numa outra lista ao lado (veja Figura 2).

LWUIT Ganha Força A equipe do projeto Lightweight User Interface Toolkit (LWUIT) deve estar orgulhosa com esta conquista. Tendo em vista a grande popularização deste projeto entre os desenvolvedores Java ME, a Sun não perdeu tempo em tentar transformar este projeto numa espécie de padrão dentro da comunidade de desenvolvedores. Os engenheiros da Sun devem ter percebido a quantidade de projetos que existem na Internet, que 2 Ferramenta utilitária do LWUIT que serve para editar arquivos de recurso do framework,como por exemplo,definição de tema,imagens, textos internacionalizados, etc.

visam melhorar a vida dos desenvolvedores, no tocante do desenvolvimento de interfaces gráficas mais sofisticadas. Com isso, a Sun não hesitou e incorporou o LWUIT como uma de suas bibliotecas padrão, disponibilizou uma aplicação exemplo e integrou uma de suas ferramentas utilitárias, o Resource Manager2 , dentro do Java ME Platform SDK 3. Alavancando de vez o nome LWUIT dentro da comunidade Java ME. O LWUIT, para quem ainda não conhece, é um  fram ework de componentes gráficos inspirado no Swing da plataforma Java Standard Edition (Java SE), especificamente modelado e construído para ambientes restritos em poder de processamento e memória, como o dos dispositivos móveis. O LWUIT traz para o mundo móvel, algumas das funcionalidades para o desenvolvimento de interfaces gráficas já conhecidas no desktop e que são bem características do Swing, como por exemplo, layouts (e.g. FlowLayout), renders (componentes que especificam a forma como um objeto é desenhado na tela), manipuladores de evento (e.g. ActionListener), etc. Com toda esta integração, para um desenvolvedor acrescentar o suporte ao LWUIT à sua aplicação dentro do  Java ME Platform SDK 3, basta somente alguns passos: acessar as propriedades do projeto, selecionar  , clicar no botão  e selecionar a biblioteca LWUIT, que já aparece na lista, ju nto com as demais bibliotecas disponíveis na ferramenta. Além disso, a aplicação exemplo é bem completa, o que serve como uma boa referência inicial para os desenvolvedores que estão começando no LWUIT (para saber mais sobre LWUIT, veja a Edição 60 e a seção Links). Ela apresenta diversos exemplos de várias partes do  framework.

Figura 3. Tela do profiler que mostra os tempos de execução dos métodos da aplicação

Encontrando o “Gargalo” Como se os problema de lógica não fossem o bastante, os problemas de desempenho também tem sido uma constante 3 Determinado trecho de um processamento que demora muito para ser executado, afetando o tempo final de resposta de um processo.

Edição 69  Java Magazine 

63

 

 A característica da plataforma Java que permite que suas aplicações sejam possíveis de serem executadas em diferentes plataformas (e.g. Windows e Linux), sem necessidade de recompilação, é o fato do seu código-fonte ser compilado para uma representação intermediária, conhecida como bytecode. Mas sua execução depende de outra aplicação, esta sim dependente de plataforma: a máquina virtual, que interpreta o bytecode . Os ganhos em portabili dade com este código intermediário, por outro lado, gera problemas de desempenho, pois a interpretação é bem menos eficiente que a execução de código nativo. Entretanto, o problema pode ser re-

nas aplicações atuais, principalmente nas móveis, devido às exigentes demandas por mais funcionalidades, sem falar das restrições de processamento, inerentes aos dispositivos móveis. A fim de também facilitar mais esta tarefa dos desenvolvedores, já que por muito tempo esta também foi executada com o auxilio de APIs como System.out. println() e System.currentTimeMillis() , foram criados os monitores de processamento ( profiler). São ferramentas que monitoram toda a execução da aplicação, registrando os tempos de execução e a quantidade de vezes que cada método foi executado. Informações muito valiosas quando se está à procura do “gargalo”3 de um determinado processo. No Java ME Platform SDK 3, esta ferramenta de monitoração é a mesma encontrada em outras distribuições do NetBeans, também usada para testes em aplicações Java SE e Java EE.

Para ativar o  profiler para determinada aplicação no Java ME Platform SDK 3, basta habilitar a opção Enable profiler nas propriedades do emulador utilizado. Durante a execução, o profiler registra num arquivo (e.g. data.prof ), todas as informações sobre o código que está sendo executado. Ao final da execução, é preciso informar ao SDK, através da opção Profile>Import Java  ME SDK Snapshot , o caminho do arquivo gerado pelo  profiler , a fim de que a informação coletada seja apresentada. Nesta

64 Java Magazine



Edição 69

solvido com ajuda da técnica de compilação  Just-in-time (JIT), que consiste na compilação do bytecode para código nativo durante a execução da aplicação. No momento em que um método vai ser executado, este é convertido numa representação de código de máquina. Por isso o termo  Just-in-ti me que, em português, significa “no momento exato”. Este código compilado fica salvo na memória, pronto para execuções futuras. Além da plataforma Java, a .NET também utiliza esta técnica. Neste caso, o código intermediário convertido pela máquina virtual .NET é o Microsoft Intermediate Language (MIL). Para saber mais sobre a JIT, veja a seção .

nova tela que é mostrada (veja Figura 3), o desenvolvedor pode ver o tempo gasto para executar cada método e a quantidade de vezes em que ele foi executado, além de ainda poder agrupar todas estas informações por classe ou por pacote. Dando uma visão mais macro dos tempos de execução de cada componente da aplicação.

E mais JSRs A cada dia novas APIs são finalmente especificadas, tornando-se aptas a serem implementadas por algum fa brica nte, que suporte a plataforma Java ME em seus dispositivos móveis. O que normalmente acontece é a implementação dessas APIs chegarem primeiro às ferramentas de desenvolvimento, tendo em vista uma maior facilidade de implementá-las em plataformas Windows ou Linux, por exemplo, para depois chegarem aos dispositivos. No Java ME Platform SDK 3, três novas APIs estão finalmente disponíveis para os desenvolvedores: Mobile Sensor API (JSR 256) (veja o artigo da Edição 55), XML API for Java ME (JSR 280) e a  Java Bind ing for the Ope nGL ES AP I (JSR 239). A primeira é responsável por

fornecer acesso a alguns sensores (e.g. acelerômetro) disponíveis em certos dispositivos móveis (veja o quadro “Trabalhando com Sensores no Emulador”). A JSR 280, por sua vez, define

uma API exclusiva para manipular arquivos XML com parsers SAX2 e DOM. A idéia é acabar com a fragmentação que existe atualmente, onde cada API que precisa manipular XML define o seu próprio mecanismo para desempenhar este trabalho (e.g. Web Services Specification (JSR 172)). E finalmente, a JSR 239 vem para prover o suporte ao desenvolvimento de gráficos 3D através da biblioteca OpenGL ES, a qual é um subconjunto da OpenGL 1.3. Para fechar o pacote das novas API, o  Java ME Platform SDK 3 também disponibiliza aplicações exemplo para cada nova API suportada, inclusive as que já eram suportadas. Um ótimo “pontapé inicial” para quem está começando a trabalhar com as APIs mais recentes.

Quanto mais Emuladores, Melhor É inquestionável a qualidade dos emuladores disponibilizados pelo Java ME Platform SDK 3, assim como os de suas versões anteriores. Todos eles seguem à risca cada ponto das especificações das APIs, dando maior segurança ao desenvolvedor sobre a corretude do seu código. Se nenhuma exceção for lançada, alertando sobre alguma operação indevida, é porque ele está no caminho certo. No entanto, por mais que as especificações sirvam para definir uma base comum, além de diminuir as chances de incompatibilidade entre as diferentes implementações, no mundo real as coisas não são tão perfeitas assim. É comum encontrar problemas de incompatibilidade entre uma implementação feita para o Windows, que não funciona no Linux, e vice-versa. No mundo móvel então, é ainda pior. Aplicações feitas para rodar num dispositivo da Nokia podem precisar de ajustes para rodar perfeitamente num Motorola ou Sony Ericsson, por exemplo. Por mais que sigam a risca o que está na especificação, sempre é possível ter algo na implementação (inclusive bugs) que gera um comportamento diferente. A complexidade e as restrições dessas plataformas móveis potencializam ainda mais este problema. Tendo em vista essas possíveis diferenças, os testes em outras plataformas

 Existem algumas APIs Java ME que i nteragem com alguns tipos de hardware ou serviço, que vem integrado a algumas linhas de dispositivos móveis. Por exemplo, a Mobile Sensor API (JSR 256), que interage com sensores (e.g. acelerômetro); a Location API (JSR 179), que captura os dados de um GPS; e a Payment API (JSR 229), que fornece serviço de pagamentos em geral. Imaginar como se testa uma aplicação desenvolvida com estas APIs, no dispositivo real, não é difícil. Pois neste caso, o hardware ou serviço está presente no dispositivo e a API vai acessá-lo para poder retornar suas informações. Mas o que

Nota do DevMan OpenGL: OpenGL é uma API aberta utilizada na computação

gráfica para desenvolvimento de aplicativos gráficos, ambientes 3D, jogos,entre outros.(fonte Wikipedia)

acontece quando não se tem o dispositivo real em mãos, para testar a aplicação? A resposta é simples: para cada API que interage com um hardware ou serviço, os emuladores do Java ME Platform SDK executam tais papéis, simulando-os. No caso da JSR 256, para a qual a emulação de sensores é mais uma novidade do Java ME Platform SDK, o desenvolvedor pode alterar as informações que o acelerômetro retorna. Desta forma, o desenvolvedor pode informar novos valores para as coordenadas x, y e z, que representam a leitura tridimensional deste tipo de hardware.

vista a rapidez que é por em execução a aplicação no emulador. Entretanto, eles nunca vão substituir o teste no dispositivo real, pois, se de um emulador para outro já existem diferenças, imagine do emulador para o hardware.

Suporte Oficial se tornam muito importantes para uma aplicação Java ME, que deseja rodar em dispositivos de mais de um fabricante. Nesta versão do Java ME Platform SDK 3 é possível importar outros emuladores desenvolvidos, por exemplo, pela Nokia, Samsung, Motorola, Sony Ericsson, dentre outros, para dentro da ferramenta e usá-los para testar suas aplicações. Uma funcionalidade já encontrada no NetBeans Mobility Pack. Para importar novos emuladores, é preciso informar o caminho do SDK do fabricante, o qual os emuladores pertencem. Para isto, deve-se acessar Tools>Java Platforms , selecionar o tipo de plataforma J2ME , clicar em Add Plaform , selecionar Custom Java ME MIDP Platform Emulador e informar os caminhos solicitados pelo restante do wizard. Após ter configurado a nova plataforma, basta acessar as propriedades do projeto e selecionar a nova plataforma e o emulador a ser utilizado. Testes em emuladores é realmente uma “mão na roda”, pois facilitam muito o desenvolvimento, tendo em

Com exceção do sistema operacional Symbian, outros sistemas como Palm OS e Windows Mobile, também bem populares no mercado, nunca foram referência pelo seu suporte à plataforma  Java ME, pelo contrário. Esta questão, acredito, deve-se ao fato que ambos possuem, desde muito cedo, suas próprias

Para acessar as ferramentas de simulação dos emuladores, o desenvolvedor precisa acessar a opção View>External Events Generator, disponível no próprio emulador. Depois disto, uma nova tela será apresentada, com uma série abas nela. Cada aba, por sua vez, representa um tipo de hardware ou serviço que pode ser simulado. No caso do acelerômetro, a aba Sensors é a que fornece os meios para simulá-lo. Nesta mesma aba, o Java ME Platform SDK ainda fornece a simulação de um sensor de temperatura.

plataformas nativas (baseadas em C) de desenvolvimento de aplicações. Ambas muito bem difundidas e poderosas, e que acabou gerando uma comunidade de desenvolvedores duradoura. Com relação ao Palm OS, a Sun até que se esforçou na época do lançamento da primeira versão do Wireless Toolkit (ainda MIDP 1.0), disponibilizando uma máquina virtual que podia ser instalada nos dispositivos da empresa Palm. No entanto, a investida não vingou, talvez pelo desinteresse da própria Palm, e o projeto ficou pelo caminho. A IBM também tentou, lançando uma máquina virtual chamada Websphere Everyplace Micro Environment (WME) ,

Edição 69  Java Magazine 

65

 

Figura 4. Ícone que mostra a máquina virtual Java ME no Windows Mobile 6.

com suporte ao MIDP 2.0. A Palm dessa vez até esboçou um incentivo, publicando a VM da IBM no seu site como um produto homologado. Porém, em 2008, o incentivo acabou e a Palm retirou o apoio. Hoje este projeto está parado no tempo, assim como o próprio Palm OS, que vem sumindo do mercado aos poucos. A história da plataforma Java ME no sistema operacional da Microsoft não é muito diferente da vivida pela Palm. Esta também é marcada pela dificuldade de encontrar uma máquina virtual robusta e sólida, o que ajudaria a difundir melhor a Java ME nos populares PDAs da empresa de Bill Gates. No entanto, por mais que o suporte seja fraco, o Windows Mobile chega ainda a ser melhor que o Palm OS, com relação a  Java ME. Nas versões para smartphones do Windows Mobile, por exemplo, até existe uma máquina virtual que já acompanha o dispositivo. Por mais que seja restrito em recursos, ainda serve para rodar aplicações mais simples. A IBM também investiu na  Java ME para o Windows Mobile, disponi bilizando uma versão paga da sua máquina virtual, WME, voltada para versões anteriores deste sistema. Mas agora, as coisas parecem que vão melhorar para os desenvolvedores Java ME que querem rodar suas aplicações no Windows Mobile. A Sun está disponibilizando, no Java ME Platform SDK 3, uma

66 Java Magazine



Edição 69

máquina virtual para o Windows Mobile 6, que pode tanto ser instalado em um emulador do próprio sistema operacional no PC, quanto num dispositivo real. Tudo o que o desenvolvedor precisa fazer é instalar a maquina virtual (veja Figura 4), através do arquivo  , que se encontra disponível no SDK na pasta  ,  no emulador ou no dispositivo. Além de executar as aplicações, o desenvolvedor ainda tem a possibilidade de depurar suas aplicações tanto no emulador quanto no dispositivo real. Com mais esta plataforma dando suporte à Java ME, agora com a assinatura da Sun, a plataforma Java dá mais um passo muito importante na consolidação do seu nome nas principais plataformas móveis do mercado.

Conclusão A Sun, com certeza, acertou com o Java ME Platform SDK, pois a falta do ambiente de codificação do Wireless Toolkit atrapalhava, de certa forma, os novos desenvolvedores. O problema era que estes não conseguiam, rapidamente, codificar um . Haja vista que precisavam usar um editor de código externo, importar o projeto para o toolkit, etc. Com o Java ME Platform SDK tudo ficou mais integrado. A facilidade de criar um projeto, codificar, escolher o emulador e colocar para executar são características muito importantes, que todo iniciante, em qualquer plataforma, gosta de ter. Entretanto, o Java ME Platform SDK é indicado somente para aplicações de teste ou pequenas, pois algumas funcionalidades importantes no desenvolvimento de aplicações mais

complexas, como depuração e controle de versão, não estão disponíveis. Nesses casos, o recomendado mesmo é o NetBeans Mobility Pack, que oferece o ambiente completo do NetBeans mais uma série de ferramentas específicas para Java ME.

Ernandes Mourão Júnior [email protected]

É Bacharel em Informática pela Universidade de Fortaleza e desenvolvedor certificado Java (SCWCD, SCBCD e SCMAD). Atualmente exerce os cargos de Analista de Desenvolvimento de Sistemas e Líder Técnico Java ME no Instituto Atlântico, em Fortaleza/CE. Recentemente foi premiado como um dos vencedores do Sony Ericsson Content Awards 2008, com a aplicação EcoMate.

http://java.sun.com/javame/downloads/   sdk30ea.jsp Página de download do Java ME Platform SDK 3 http://java.sun.com/j2me/docs/pdf/CLDCHI_whitepaper-February_2005.pdf  CLDC HotSpot™ Implementation Virtual Machine http://wurfl.sourceforge.net/  WURFL: Wireless Universal Resource File https://lwuit.dev.java.net/  LWUIT: Lightweight User Interface Toolkit http://pt.wikipedia.org/wiki/JIT  JIT: Just-in-time Dê seu feedback sobre esta edição! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

 ee   e    s

c  

o          e

   t     a

      o     ã  i   d

Dê seu voto sobre este artigo, através do link:

www.devmedia.com.br/javamagazine/feedback 

Edição 69  

SEÇÃO JAVA: NESTA SEÇÃO VOCÊ ENCONTRA ARTIGOS INTERMEDIÁRIOS E AVANÇADOS SOBRE JAVA

 

I

ntegrar aplicações não é uma tarefa trivial. Protocolos diversos, APIs exóticas, tecnologias e ambientes complexos e cronogramas agressivos são alguns aspectos que desafiam diariamente analistas desenvolvedores Java EE. Conto aqui uma história que resume estes desafios. Uma equipe necessitava enviar emails de sua aplicação Java. Uma tarefa aparentemente trivial, que muitos desenvolvedores vivem todos os dias. A equipe não possuía experiência com a API JavaMail, mas com a ajuda de um recurso externo a equipe se capacitou e desenvolveu o código necessário para suportar a integração, que neste caso ocorreria com o servidor Microsoft Exchange. Código implementado, testes internos realizados com sucesso e aprovação gerencial. Aparentemente o problema foi resolvido. A vida real, entretanto, guarda surpresas. Na véspera da semana de implementação, o código foi implantado na empresa do cliente (vamos chamá-la de empresa ACME), mas os casos de uso que requeriam a integração com o Microsoft Exchange não funcionavam. Todos os olhos e atenções (e culpas) foram lançados para o servidor de email da Microsoft. Após a descoberta que o servidor de email do cliente (v2007) estava em uma diferente versão do ambiente interno da desenvolvedora (v2003), modificações no ambiente de desenvolvimento foram realizadas para adequar o servidor. Nenhum resultado positivo foi alcançado. O pânico se instalou! Mais investigações foram realizadas e a equipe descobriu que o servidor de email de produção não residia na mesma rede do servidor de aplicação do cliente, mas em um distante local remoto (em outra cidade) em um provedor com um acesso controlado por um firewall. O analista de

68 Java Magazine



Edição 69

 De que se trata o artigo:  O artigo apresenta técnicas e práticas provadas de integração de aplicações Java com outras aplicações, sistemas e bancos de dados. Projetos de integração apresentam muitas complexidades técnicas e muitas possibilidades técnicas em Java tais como JMS, JCA, JDBC, RMI, HTTP e SOAP. O artigo mostra como escolher estas tecnologias e como utilizá-las adequadamente através de padrões de integração de aplicações (EIP).

Para que serve:  O artigo é útil para que desenvolvedores possam conhecer os riscos associados à integração de sistemas Java com outros sistemas e aplicar as melhores práticas de mercado e padrões de integração para mitigar e eliminar estes riscos. Projetos com riscos técnicos reduzidos possuem maior garantia de sucesso, maior qualidade, estabilidade e manutenções mais simples e facilitadas.

Em que situação o tema é útil:  Em projetos de TI que requerem integrações de todo tipo, como bancos de dados relacionais, bases de dados em outros formatos, sistemas de filas de mensagens, aplicações legadas em plataformas baixas e altas ou aplicativos como CRM (Customer Relationship Management) e ERP (Enteprise Resource Planning).

Estratégias de Integração de Aplicações Java EE:  Integrar aplicações Java com outros sistemas não é uma tarefa trivial. Para reduzir riscos e manter projetos sob controle, devemos usar práticas provadas de integração de sistemas. As melhores práticas de integração são denominadas padrões EAI (EAI Patterns) e foram popularizadas por Gregor Hohpe através do seu livro Enterprise Integration Patterns. Estas práticas permitem que um arquiteto ou desenvolvedor escolha as estratégias mais eficientes de integração de sistemas Java com outros sistemas e produza soluções mais perenes e econômicas. Estas práticas de integração também são fundamentais para empresas que estejam buscando iniciativas SOA e BPM, pois permitem gerir adequadamente a criação e evolução de serviços (ativos) em repositórios de serviços (ESB). Um processo simples para que você possa aprender a integrar sistemas em projetos envolve os seguintes passos: (1) Coletar os requisitos arquiteturais de interoperabilidade; (2) Desenvolver soluções independentes de tecnologi a para cada requisito arquitetural coletado; (3) Estudar os exemplos disponibiliz ados na referência [1]; (4) Estudar as tecnologias Java mais adequadas para cada requis ito (ex: WebServices ou RMI); (5) Implementar os cenários com as tecnologias Java escolhidas; (6) Testar as soluções em ambiente de homologação.

infra-estrutura do cliente não foi questionado o bastante para informar este fato. Para encurtar a história, a equipe desco briu que o envio de emails neste ambiente requeria o uso de certificados e protocolos com garantia de transporte seg uro (SMTP sobre SSL). Noites mal-dormidas, um atra-

so de algumas semanas no cronograma, um cliente relativamente estressado e o desafio foi finalmente vencido. Que lições podemos aprender com esta história? Enumero algumas abaixo: 

serem integrados sejam exatamente iguais;

  

     

MARCO AURÉLIO DE SOUZA MENDES Nota do DevMan Requisitos Funcionais e Requisitos Não-Funcionais:

Requisitos funcionais expressam os desejos dos interessados do projeto na perspectiva da funcionalidade. Exemplos incluem cadastros, relatórios e fluxos de trabalho. Requisitos não-funcionais expressam atributos de qualidade de um sistema tais como desempenho, usabilidade, disponibilidade ou portabilidade. Requisitos funcionais e não-funcionais importantes para o negócio (prioritários) e complexos formam o conjunto de requisitos arquiteturais que devem ser foco inicial de qualquer projeto de TI. Requisitos funcionais e não-funcionais coletados podem responder a perguntas sobre escolhas de estratégias e tecnologias sobre interoperabil idade. Por exemplo, restrições sobre desempenho podem eventualmente influenciar na escolha de uma integração com soquetes ao invés de XML e Web Services.



isto é, a organização física do ambiente de produção do cliente. Diagramas UML de implantação são uma ferramenta útil neste aspecto; requisitos nãofuncionais que possam interferir na interoperabilidade; 

real do cliente. O leitor mais experiente pode questionar as lições aprendidas neste exemplo.  . Mas devemos lembrar que senso comum não é prática comum. Seja um “Indiana Jones” de aplicações Java na sua empresa. Faça uma arqueologia de software nas aplicações Java da sua empresa e colete os erros e lições aprendidas. Os erros do passado são uma excelente fonte de aprendizado para projetos futuros.

O objetivo deste artigo é mostrar a você como tornar senso comum em prática comum, isto é, evitar erros comuns de in-

tegrações de sistemas em projetos e evitar estresses desnecessários. Vamos abordar estratégias e técnicas para organizar o seu trabalho, organizados da seguinte forma nas seções seguintes deste artigo: 

Iremos conhecer aqui fundamentos da integração de sistemas;  

 Java. Aqui iremos citar as principais tecnologias e padrões Java para a integração de aplicações; 

conhecer aqui as melhores práticas de mercado para integrar aplicações; 

Vamos abordar aqui as principais tarefas necessárias durante um projeto para garantir uma boa interoperabilidade de suas aplicações Java.

Estilos, Níveis e Topologias de Integração inimigo, para  , Sun Tzu, A

Arte da Guerra. Como conhecer o inimigo? Primeiramente devemos compreender que interoperabilidade é um mecanismo arquitetural , ou seja, uma preocupação importante de um projeto e que, portanto, requer a atenção técnica ainda no começo do projeto. Devemos investigar as interoperabilidades requeridas no nosso projeto através do estilo, nível e topologia associados, pois para cada um haverá uma abordagem técnica diferenciada e tecnologias distintas em Java.

A interoperabilidade de aplicações pode se apresentar em quatro estilos, conforme Gregor Hohpe [1]. 1. O primeiro estilo é a transferência de arquivos , onde duas aplicações compartilham as informações através de um arquivo texto ou binário. O protocolo FTP é um exemplo popular de tecnologia que suporta este estilo; 2. O segundo estilo, talvez o mais popular, é através de dados compartilhados em bancos de dados; 3. O próximo estilo é através de procedimentos remotos (RPC) , onde um programa cliente invoca uma funcionalidade em outra máquina. As tecnologias de WebServices são exemplos normalmente associados a RPC; 4. O último estilo é através de passagem de mensagens. Programas com suporte a filas de mensagens, como a especificação  Java JMS, são exemplo deste estilo. Pare um minuto e responda: Qual o estilo requerido no exemplo citado de interoperabilidade com o Microsoft  Exchange? (Resposta no final deste artigo).

Além dos estilos, podemos classificar a interoperabilidade em níveis, listados a seguir: 1. Nível de dados. Como integrar fontes de dados relacionais ou em outros formatos e como reduzir a sua redundância?

Colete os requisitos arquiteturais diretamente com representantes do seu cliente em reuniões conjuntas com o analista de requisitos. Normalmente analistas de requisitos têm dificuldade de capturar e expressar  informações técnicas, o que implica em informações truncadas e novas descobertas indesejadas no final  do projeto.

Edição 69  Java Magazine 

69



Figura 2. A topologia de comunicação ponto a ponto liga duas aplicações diretamente. A topologia Hub and Spoke usa um barramento central (Hub) para ligar múltiplos clientes.

Figura 1. Mash-up do Internet Google. Diferentes aplicações foram integradas aqui em nível de camada de apresentação. Podemos ver no exemplo acima blogs de diferentes autores, o Google Talk e mesmo uma aplicação de previsão de tempo.

Estilo de Interoperabilidade

APIs/Tecnologias Java

Transferência de Arquivos

Streams I/O; Soquetes

Bancos de Dados Compartilhados

JDBC

Procedimentos Remotos (RPC)

Servlets, JCA, Web Services/SOAP

Passagem de Mensagens

JMS, Web Services/SOAP

Tabela 1. Tecnologias Java para suportar estilos de interoperabilidade. Níveis de Interoperabilidade

APIs/Tecnologias Java

Nível de Dados

JDBC

Nível de Interface de Aplicação

Servlets, EJB/RMI, JCA, Web Services/SOAP, JavaMail

Nível de Processos de Negócio

JBI (Java Business Integration), OpenSOA SCA

Nível de Apresentação

Portlets

Tabela 2. Tecnologias Java para suportar níveis de interoperabilidade. Topologias de Interoperabilidade

APIs/Tecnologias Java

Ponto a ponto

Servlets, WebServices/SOAP, EJB/RMI

Hub and Spoke

JBI, OpenSOA SCA

Tabela 3. Tecnologias Java para suportar topologias de interoperabilidade.

A integração em nível de dados foca na movimentação de dados entre aplicações com o objetivo de compartilhar o mesmo dado entre aplicações diferentes; 2. Nível de Interfaces de Aplicação (API). Como integrar APIs de aplicação

em outras tecnologias que não sejam  Java? A integração via APIs passa pela chamada de funções através de protocolos síncronos (RPC) ou assíncronos (mensagens); 3. Nível de Processos de Negócio. Domínio do mundo BPM/SOA, a integração em nível de processos de negócio foca no desenvol-

70 Java Magazine



Edição 69

vimento de componentes de alto nível que irão fornecer interfaces de alto nível que podem ser considerados serviços; 4. Nível de Apresentação. Popularmente conhecidos como mash-ups, integram aplicações através de um conjunto de vários  portlets (janelas visuais independentes) que residem em um determinado portal. A Figura 1 mostra um exemplo de integração neste nível. Um novo teste: Qual o nível associado ao exemplo citado de interoperabilidade com o Microsoft Exchange? (Resposta no final deste artigo).

Finalmente, devemos considerar tam bém a questão da topologia da aplicação. Dois modelos clássicos existem: 1. Comunicação Ponto a Ponto. A integração ponto a ponto é também chamada de integração oportunista e ocorre diretamente entre dois sistemas que queiram conversar. Quando conectamos uma TV diretamente a um DVD, usamos intuitivamente esta topologia de integração; 2. Comunicação Hub an d Spok e. Topologia popularizada pelos ESB (um tipo particular de  Hub and Spoke), esta topologia usa um mediador central para comunicar cada aplicação (Spoke) que deseje conversar. Nenhuma aplicação conversa diretamente com outra aplicação. Isto pode parecer confuso e complexo, mas considere (na sua sala de TV dos sonhos) como você poderia integrar adequadamente uma televisão digital, um computador, um sistema de som 7.1, um DVD, um vídeocassete (para as fitas de formatura da sua família), um projetor e um vídeo-game de última geração. É claro neste exemplo que usar um aparelho central para gerir todas as conexões é mais vantajoso. O Home-Theater é um hub na sua sala de TV dos sonhos e pode ligar todos os fios dos aparelhos (Figura 2). Mais um desafio: Qual a topologia associada ao exemplo citado de interoperabilidade com o Microsoft Exchange? (Resposta no final deste artigo). Colete os requisitos arquiteturais de interoperabilidade na sua aplicação. Para cada requisito arquitetural, defina o estilo, nível e topologia associada.

Padrão EAI

Pergunta endereçada Como eu posso integrar múltiplas aplicações de forma que elas possam trocar informações?

Nota do DevMan Diagramas de Casos de Uso:



Como uma aplicação se comunica com outra através de mensagens?



Diagramas de casos de uso são visualizações de negócio usadas por analistas de requisitos para o auxílio na coleta e entendimento de requisitos. Estes diagramas possuem atualmente grande popularidade na comunidade de analistas e podem ser ferramentas poderosas para a coleta de interoperabilidades. No nosso exemplo, poderíamos representar a interoperabilidade do envio do e-mail com o seguinte diagrama.

Como uma aplicação se conecta a um canal de mensagens para enviar e receber mensagens?



Como mensagens podem ser usadas para transferir dados entre aplicações?



Como mensagens podem ser enviadas para outro sistema se o originador não tem todas as informações necessárias? 

Como um consumidor de mensagens (ex: Microsoft Exchange) pode selecionar que tipos de mensagens ele deseja receber. 

Tabela 4. Padrões EAI usados para resolver a interoperabilidade com o Microsoft Exchange.

Tecnologias de Interoperabilidade Java   , Sun Tzu.

A plataforma Java foi desenhada e evoluída nos últimos anos com um grande suporte para interoperabilidade. Considere como exemplo simples a especificação  JDBC. Projetada de forma elegante para suportar a portabilidade de sistemas operacionais e bancos de dados, ela é um exemplo que suporta a integração do estilo (ver Tabela 1) banco de dados compartilhados, em nível (ver Tabela 2) de dados. Diversas outras tecnologias foram projetadas para suportar outros estilos e níveis. Apresentamos alguns exemplos nas Tabelas 1 , 2 e 3 , sem nos ater aos detalhes da API, que podem ser encontrados em artigos anteriores da revista Java Magazine. As Tabelas 1 , 2 e 3 mostram que é fundamental escolher adequadamente a tática (tecnologia) conforme o tipo de terreno (estilo, nível ou topologia).

Não use as tecnologias Java no primeiro combate a um problema de interoperabilidade. A tecnologia é secundária e deve ser considerada apenas após a correta coleta e desenvolvimento dos requisitos arquiteturais e definição dos estilos, níveis e topologia.

Padrões de Integração de Aplicações (EIP) damente a situação e um bom general lida cuidadosamente com ela. Se não é vantajoso, nunca envie suas tropas; se não lhe rende  ganhos, nunca utilize seus homens; se não é uma situação perigosa, nunca lute uma batalha   , Sun Tzu.

Conhecemos o inimigo. Conhecemos as ferramentas. Entretanto, a grande chave na interoperabilidade de aplicações é saber como aplicar as tecnologias Java a nosso favor. Neste aspecto, introduzimos o conceito de um padrão de integração de aplicações. Um padrão EIP é uma solução provada aplicável ao contexto de integração de aplicações corporativas.

Note que neste diagrama o Microsoft Exchange suporta a operação de envio de email e por isso é chamado de Ator Secundário.

O livro Enterprise Integration Patterns [1] apresenta 65 padrões de integração de sistemas. Cada padrão resolve um problema particular no contexto de integração de aplicações corporativas e pode ser usado  junto com outros padrões EIP para solucionar um problema do mundo real. Consideremos, para ilustrar o conceito, um problema similar ao citado no começo deste artigo. Poderíamos formalizar os requisitos arquiteturais da seguinte forma: R1. A aplicação ACME deve interoperar com o servidor Microsoft Exchange 2007 através de protocolos SMTP para envio de emails. R2. O transporte para interoperabilidade com o servidor de emails deve garantir confidencialidade e integridade das informações enviadas através do uso do protocolo SMTP sobre SSL. Ao lermos o livro EAI Patterns, capturamos alguns padrões candidatos para o problema acima. Estes padrões são documentados na Tabela 4. O primeiro padrão da Tabela 4 nos diz que a solução provavelmente será resolvida com um mecanismo assíncrono. Dadas as restrições de protocolos no requisito R1 , vemos que a especificação Java nos sugere a especificação  Java Ma il . O segundo e terceiro padrões nos diz que teremos um canal para o envio e recebimento de informações e este canal deve se conectar a um sistema de email como Edição 69  Java Magazine 

71



Figura 3. Esquema da solução de integração com o MS Exchange Ser ver

Listagem 1. Fragmento de Código para Envio de Email. … Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider()); Properties props = new Properties(); props.put(“mail.smtp.host”, SMTP_HOST_NAME); // Servidor de email props.put(“mail.smtp.auth”, “true”); // Requer autenticacao props.put(“mail.debug”, “true”); props.put(“mail.smtp.port”, SMTP_PORT); // Porto do servidor de email props.put(“mail.smtp.socketFactory.port”, SMTP_PORT); props.put(“mail.smtp.socketFactory.class”,“javax.net.ssl. SSLSocketFactory” ); //Enriquecedor da mensagem com SSL props.put(“mail.smtp.socketFactory.fallback”, “false”); Session session = Session.getDefaultInstance(props, new javax.mail. Authenticator() { protected PasswordAuthentication getPasswordAuthentication() { return new PasswordAuthentication(“username”, “password”); } }); Message message = new MimeMessage(session); InternetAddress addressFrom = new InternetAddress(from); message.setFrom(addressFrom); message.setSubject(“OLÁ EIP”); message.setText(“Padrões EIP organizam e comunicam as soluções Java!”); Transport.send(message); ...

o Microsoft Exchange. Ao examinarmos a classe Transport , da API do JavaMai l, veremos que ela possui esta função. Naturalmente, um Message Endpoint requer uma implementação da especificação JavaMail. Assumamos neste exemplo que usamos o  JBoss AS para esta solução. O quarto padrão nos diz que devemos enviar um documento textual. Ao observamos novamente a classe Transport , notamos que ela possui um método send() que

72 Java Magazine



Edição 69

espera como argumento um objeto do tipo Message , que modela um Document Message. O quinto padrão endereça os requisitos de segurança. Um enriquecedor de conteúdo permite adicionar à mensagem original informações adicionais. No nosso caso, estas informações adicionais serão de segurança, que nos permite que a mensagem seja entregue em servidores que operem sobre protocolo SSL. Ao examinarmos a hierarquia da classe Transport , vemos a classe SMTPSSLTransport. Esta classe fornece a funcionalidade de envio de emails sobre canal seguro (confidencialidade e integridade). O último padrão está fora do escopo Java, mas ele indica que alguém deve configurar o servidor Exchange para não aceitar mensagens SMTP, mas somente mensagens SMTP sobre SSL. O padrão Consumidor Seletivo representa este mecanismo.

Se conectarmos os padrões EIP teremos o desenho da nossa solução apresentado na Figura 3. O trecho de código acima mostra estas peças conectadas. Este fragmento de código pode ser entendido como a realização do esquemático da Figura 3. Para um problema simples, naturalmente, podemos até ir intuitivamente para uma tecnologia ou um código, mas isso é como começar a correr uma maratona sem preparação física adequada. Os padrões representam esta preparação física. Eles permitem que você pense nos aspectos da solução sem se ater aos detalhes da tecnologia. Ao escolheremos uma tecnologia  Java determinada, ela será a conseqüência dos padrões, que naturalmente devem suportar os requisitos arquiteturais especificados. Para problemas complexos de integração do mundo real, entretanto, devemos conhecer e aplicar os padrões EIP. Outra excelente fonte de padrões é o livro POSA [2], que contém mais de uma centena de padrões arquiteturais, entre eles diversos padrões EIP. Como exemplo de padrões EIP usados para modelar aplicações com integração complexa, dita aplicações EAI, poderíamos citar os padrões descritos na Tabela 5.

Um Processo para Interoperar Aplicativos  batalha, ele pode conduzir as suas tropas para até mil milhas, mesmo para uma batalha decisiva. Se ele não sabe nem o lugar nem a hora de uma batalha, então o seu lado esquerdo não pode ajudar a sua direita e a ala direita não pode salvar a esquerda; a tropa da frente não pode auxiliar a tropa da retaguarda, nem a tropa da retaguarda  Sun Tzu.

Conhecer um processo para solucionar problemas técnicos é fundamental. Saber a hora e o lugar das ações é fundamental, especialmente nos mecanismos arquiteturais de interoperabilidade. Podemos resumir o processo de aplicação das estratégias e padrões EIP da seguinte forma: 1. Colete os requisitos arquiteturais de interoperabilidade. Uma boa fonte para

Padrão EAI

Comentários Captura a essência das soluções ESB de mercado.Note que o termo ESB, em sua definição original, é um padrão ou estilo arquitetural e não uma tecnologia ou especificação. Produtos como o JBoss ESB ou Apache ServiceMix podem ser vistos como produtos que implementam o padrão EIP Message Broker .

Message Broker

Captura a essência das soluções BPMS de mercado. O padrão Process Manager  permite que uma integração com múltiplas fontes de dados e aplicações possam ser integradas através de um fluxo de trabalho arbitrário. Produtos como o JBoss BPM ou IBM WebSphere Process Ser ver são exemplos deste padrão. A linguagem BPEL (Business Process Execution Language) é um exemplo de linguagem usada para descrever os fluxos do padrão Process Manager . Process Manager

Padrão usado para implementar a interoperabilidade com múltiplos protocolos em aplicações ESB. Um produto como o JBoss ESB, por exemplo, suporta FTP, HTTP, SMTP, HTTPS e diversos outros formatos para interoperar aplicações. No interior da sua solução, vemos que o padrão Normalizer foi usado para suportar isso.

Normalizer

Tabela 5. Padrões EAI tipicamente usados em aplicações BPM/SOA/ESB.

Nota do DevMan Processo Unificado (UP):

O UP (Unified Process) é um processo para dese nvolvimento de software baseado no conceito de um projeto centrado em arquiteturas de software. Em termos simples isso significa reduzir os riscos técnicos do projeto nas suas fases iniciais através do ataque aos requisitos mais prioritários e complexos através de provas de conceito que busquem mitigar e eliminar estes riscos. O UP possui diversas variantes como por exemplo o popular IBM Rational Unified Process, o Enterprise Unified Process de Scott Ambler ou o processo ágil OpenUP.

isso são atores secundários em diagramas de casos de uso. Eles normalmente revelam sistemas e aplicações que devem ser integrados. Especifique detalhadamente estes requisitos para que não existam dúvidas sobre as versões de servidores, topologias e protocolos exatos a serem utilizados; 2. Desenvolva soluções independentes de tecnologia para cada requisito arquitetural de interoperabilidade. Para isso, identifi-

que os estilos, níveis e topologias de cada requisito arquitetural de interoperabilidade.

Expresse então a sua solução através dos padrões EIP encontrados em [1] e [2]; 3. Estude os exemplos (mais complexos e além do escopo deste artigo) disponíveis em [1]; 4. Para cada solução independente de tecnologia, escolha as tecnologias Java mais adequadas para resolver o seu problema. Use as Tabelas 1, 2 e 3 como ponto

de partida e então estude as especificações de cada tecnologia apresentada e produtos  Java que suportem estas especificações; 5. Prove a sua solução. Talvez a dica mais valiosa, a sua solução deve ser provada com um código real e que possa capturar um cenário de utilização do seu sistema; 6. Teste a sua solução em ambiente idêntico ao de produção. Envolva o usuário e

faça testes reais e significativos, pois este é o passo mais complexo. Aplicações não testadas adiam riscos e podem levar a problemas graves no fim do projeto. Em cenários mais complexos onde você não tem acesso ao aplicativo sendo interoperado, considere o uso de ferramentas como o jMOCK ou EasyMock. Recomendo, neste particular, o excelente artigo Mocks Aren’t Stubs, de

Martin Fowler, e o artigo “Testando com Mocks de forma fácil”, Edição 62; 7. Garanta que você realizou os passos 1-5 no começo do projeto. Requisitos de

interoperabilidade são complexos e devem ser endereçados no  do projeto. Se você usa um processo derivado do UP (Unified Process), os itens 1-5 para todos os requisitos arquiteturais devem estar finalizados até o 3/10 temporal do seu projeto. Se você usa processos ágeis, enderece estes requisitos nos primeiros sprints/iterações.

Conclusões Este artigo apresentou, de forma introdutória, princípios que devem nortear aplicações que requerem integrações de sistemas. Coloco abaixo um guia de estudo para os mais interessados no assunto. 1. Certifique-se de conhecer os fundamentos de integração de sistemas. Estilos, topologias e especificações são fundamentais e livros como [1] e [2] são fontes fundamentais; 2. Estude antecipadamente as ferramentas e APIs Java para suportar os estilos e topologias acima; Edição 69  Java Magazine 

73



3. Nunca acredite em tecnologias que não foram provadas no seu projeto. Negocie tempo do seu gerente de projeto para provar conceitos e realizar testes de integração. Se você não realizar esta negociação no começo do projeto, espere estresses, noites mal dormidas e problemas na entrega do seu código; 4. Lembre-se que o mundo não é centrado em Java. Você precisará conhecer peças e protocolos além da linguagem Java para se tornar um bom arquiteto de integrações; 5. Teste o seu código de integração. Já observei diversos problemas em projetos devido a processos de testes de integração falhos e que aconteceram literalmente na entrega do projeto.

Marco Aurélio S. Mendes [email protected] 

É consultor independente de Arquitetura de Software e Engenharia de Software com mais de 16 anos de experiência em projetos de TI. É também professor de pós-graduação dos cursos de Estratégias de Arquitetura de Sistemas do IGTI e Engenharia de Software do IEC/PUC-Minas. Ele mantém artigos diversos sobre Arquitetura, Java e Engenharia de Software no seu blog http://blog.marcomendes.com.

martinfowler.com/articles/  mocksArentStubs.html  Descreve o conceito de Mocks e que ele pode  ser usado para simular aplicações ex ternas no contexto de projetos de integração de aplicações.

eaipatterns.com/ 

O leitor curioso deve ter notado o uso de ícones diferenciados para representar padrões EIP. Estes ícones estão disponíveis gratuitamente em formato Visio no próprio portal de Gregor Hohpe (EAI Patterns). Para o leitor ainda mais curioso que busca aqui as respostas para as perguntas feitas ao longo do artigo, o problema tem como solução: o estilo Passagem de Mensagens, integração em Nível de Aplicação e topologia Ponto a Ponto. Boas integrações!

74 Java Magazine



Edição 69

 Site central dos p adrões EIP e que resume muito material interessante sobre integração de aplicações.

eaipatterns.com/downloads.html  Recursos sobre EIP e em particular o stencil  (plugin) Microsoft Visio para desenhar EIP.

epf.eclipse.org/wikis/openup/  Open UP. Processo de desenvolvimento gratuito baseado nos conceitos do UP.

  

Referência primária sobre a integração de aplicações corporativas, escrito por Gregor Hohpe, arquiteto de soluções do Google.  

Continuação do clássico livro POSA – vol 01, de 1996. O primeiro livro sobre padrões arquiteturais de IT e referência obrigatória para sistemas que requeiram integrações complexas. 

Clássico livro sobre estratégias e táticas de guerra. Ganhou popularidade recentemente no mundo dos negócios ao ser adaptado por vários autores para situações “militares” vividas em projetos de TI por gerentes, analistas e desenvolvedores.

Dê seu feedback sobre esta edição! A Java Magazine tem que ser feita ao seu gosto. Para isso, precisamos saber o que você, leitor, acha da revista!

  u

  e    s      ê

eed

c  

o      

    a

      o     ã  i   d

Dê seu voto sobre este artigo, através do link:

www.devmedia.com.br/javamagazine/feedback 

   e

Existem momentos onde a estrutura faz toda a diferença. Se o tempo é ruim, você encontra na Alog um porto seguro. Isto porque sua empresa reduz custos e melhora a governança em TI. Entre em contato e descubra porque a Alog é líder em hosting gerenciado.

REDUÇÃO DOS CUSTOS

AUMENTO DA GOVERNANÇA EM TI

0800 282 3330 | alog .com.br  HOSTING GERENCIADO | COLOCATION | CONTINGÊNCIA | E-MAIL CORPORATIVO | CONECTIVIDADE | SERVIÇOS PROFISSIONAIS Edição 69 • Java Magazine

75