terça-feira, 23 de junho de 2009

JavaFX - conceitos básicos

Um pouco de background

O cenário para RIA's está bastante aquecido e JavaFX é a tecnologia desenvolvida pela Sun para disputar este mercado com Flash/Flex e Silverlight. Estas três tecnologias tem em comum o fato de serem disponibilizadas aos usuários através do browser porém executadas numa máquina virtual local. Desta forma é possível oferecer ao usuário interfaces muito mais elaboradas do que é possível com a combinação HTML+JavaScript (o cenário no qual trabalha JSF por exemplo).

A linguagem

Um dos principais diferenciais em relação ao Java é o estilo declarativo de codificação. Por exemplo, compare a forma Java de se instanciar um objeto do tipo SomeObject e sua dependência SomeObjectChild:
SomeObjectChild child = new SomeObjectChild();
child.setValue3(123);
SomeObject ref = new SomeObject();
ref.setValue1(123);
ref.setValue2("123");
ref.setChild(child);
ref.setSomeEventListener(new SomeEventListener() {
void someEvent() {
//do something
}
});
e a forma JavaFX de se instanciar um objeto equivalente:
def ref : SomeObject = SomeObject {
value1: 123
value2: "123"
child: SomeObjectChild {
value3: 123
}
someEvent: function(): Void {
//do something
}
}
O estilo declarativo é visivelmente mais claro e conciso.

Outra recurso interessante é chamado de binding. Através deste recurso é possível amarrar um atributo a outro. Desta forma toda vez que algum atributo é modificado todos os que estiverem amarrados são notificados. Na verdade é mais do que uma notificação, a expressão com a qual foi feita a amarração é executada novamente atualizando assim o valor do atributo amarrado. Vejamos alguns exemplos:
var stage : Stage;
var lbl: Label;

lbl = Label {
font : Font {
size : 20
}
width: 100

translateX: bind (stage.scene.width - lbl.boundsInLocal.width) / 2
translateY: bind (stage.scene.height - lbl.boundsInLocal.height) / 2
text: bind
if (stage.scene.width > 300) then
"LARGE!"
else
"thin..."

textFill: bind
if (stage.scene.width > 300) then
Color.RED
else
Color.BLACK
};

stage = Stage {
title: "Simple Binding"
width: 250
height: 80
scene: Scene {
content: [lbl]
}
}
A variável stage representa uma janela que será exibida para o usuário. Esta janela irá conter apenas um texto representado pela variável lbl. Repare que os atributos do texto estão definidos usando a palavra-chave bind. Isto irá fazer com que toda vez que as propriedades stage.scene.width e stage.scene.height forem modificadas os atributos text, textFill, translateX e translateY sejam calculados novamente. Na prática isto fará com que o texto seja movido para o centro da janela sempre que ocorrer um redimensionamento da mesma e também irá mudar o texto sendo exibido e sua cor de acordo com a largura da janela.

O recurso de binding é bastante poderoso e permite manter o estado dos componentes da janela sincronizados em torno de atributos chaves sem que para isso seja necessário definir listeners de eventos como seria feito numa interface Swing tradicional.

O exemplo acima não reflete isso mas este recurso facilita a construção da interface no padrão MVC. Fica bem simples sincronizar os componentes da View que exibem dados aos atributos do Model que armazenam estes dados. Desta forma ações (Controller) que impactam o Model irão automaticamente atualizar a View sem que isto fico explícito no código das ações. Portanto é possível alcançar um menor acoplamento entre estas camadas ficando de fato possível alterar componentes da View sem impactar as camadas de Model e Controller.

Mixins

Até a versão 1.1 do JavaFX existia suporte a herança múltipla. Este recurso foi eliminado na versão 1.2 em favor de "mixins". Este recurso permite que interfaces tenham uma implementação padrão de um ou mais de seus métodos. Desta maneira, uma classe qualquer que deve implementar uma interface referencia o mixin da interface ao invés da própria interface. Vejamos um exemplo simples composto de duas interfaces, dois mixins, uma classe abstrata e uma concreta:

Interfaces (Java):

public interface Persistable {
void save();
void delete();
}

public interface Identifiable {
String getIdentity();
}

Mixins (JavaFX):

public mixin class IdentifiableMixin extends Identifiable {
public override function getIdentity() : String {
return toString();
}
}

public mixin class PersistableMixin extends Persistable {
public override function save() : Void {
Persister.save(this);
}

public override function delete() : Void {
Persister.delete(this);
}
}

Classe abstrata (Java):

public abstract class Entity {
private Long id;

public Long getId() {
return id;
}

public void setId(Long id) {
this.id = id;
}
}

Classe concreta (JavaFX):

public class SomePersistableIdentifiableEntity extends Entity, PersistableMixin, IdentifiableMixin {
public-init var field: String;

public override function toString() {
return field;
}
}

Desta maneira a classe SomePersistableIdentifiableEntity implementa as interfaces Persistable e Identifiable sem no entanto ter sido obrigado a implementar os métodos da interface pois foram utilizados as definições providas pelos "mixins". Caso necessário é possível sobreescrever os métodos para modificar algum comportamento. Graças a este recurso não foi preciso "sujar" a árvore de herança da classe com implementações dos métodos das interfaces. De uma maneira geral "mixins" promovem reuso de código e consistência nas chamadas a métodos de interfaces. Permitem que diversas classes que querem implementar determinada interface já ganhem de brinde uma implementação padrão de um ou mais de seus métodos.

Num próximo post sobre JavaFX iremos falar sobre novos modificadores de acesso a variáveis, operadores especiais para trabalhar com listas e mais.

domingo, 14 de junho de 2009

A JVM e seu compilador JIT

Até mesmo entre alguns programadores Java, há certas dúvidas sobre como alguns aspectos da JVM funcionam. Em particular, embora muitos saibam que existe um compilador durante a execução do programa, poucos sabem exatamente quais os benefícios. Mais do que isso, não é raro encontrar desenvolvedores procurando um compilador ahead of time (AOT) para java para gerar programas nativos. Este post pretende mostrar algumas vantagens do compilador just in time (JIT), bem como demonstrar um pouco da sua capacidade. As informações contidas neste artigo se referem ao Hotspot, o compilador jit da Sun. Porém, a maior parte da informações contida é aplicável a todas as JVM's.

Hotspot client e server
Antes de falar especificamente sobre o Hotspot, é preciso saber que existem na verdade dois Hotspot's, chamados de client e server.
O client compiler é o compilador presente na JRE de 32 bits. Ele tem como objetivos gerar código nativo rapidamente e, preferencialmente, sem afetar a responsividade do código sendo executado. Seu nome vem do fato de que é preferivelmente utilizado em aplicações clientes que normalmente interagem com usuários. Já o server compiler está presente apenas no JDK (e nas JRE de 64bits) e exige mais tempo para gerar código nativo. Contudo, várias otimizações só estão presentes no server compiler. Seu principal uso é para aplicações que tipicamente executam em servidores, com um tempo de vida maior. Para ativar o server, basta invocar o executável java com a opção -server.

E como funciona o Hotspot?
O Hotspot (nome do compilador jit da máquina virtual da Sun) observa a execução dos programas e, a partir do perfil de execução e da plataforma em que se encontra, gera código nativo para o programa sendo executado. Isso significa que ele pode (e o faz) gerar código específico para o processador em que o programa está sendo executado, se aproveitando de registradores específicos e instruções especiais.

Exemplo prático
Para ilustrar o comportamento do JIT, vamos mostrar um pequeno exemplo. O código abaixo (que também se encontra no repositório de códigos deste blog) é bem simples e mostra bem o que o Hotspot é capaz de fazer:

long bits = 0L;
if(args.length > 0) {
bits = Long.parseLong(args[0]);
}
long start = System.nanoTime();
int n = 2000000001;
boolean shift = bits > 0;
while (n > 0) {
if(shift) {
bits ^= 1 << 5;
}
n--;
}
System.out.println("bits: "+ bits);
long end = System.nanoTime();
System.out.println(TimeUnit.NANOSECONDS.toMillis(end-start) + "ms");

Executando o código acima nos três modos (puramente interpretado, compilado com o client compiler e com o server compiler) passando o número 1 como argumento, temos os seguintes resultados (em um Solaris usando java6u14):

Interpretado (invocado com -Xint): infinito!
Client compiler: 2903ms
Server compiler: 11ms

O resultado do server compiler é impressionante. Para comparar, o código C equivalente (compilado no GCC 3.4.6), no mesmo computador mas com o tempo medido com o utilitário 'time' do UNIX:

gcc: 7422ms
gcc -O1: 2541ms
gcc -O5: 1447ms

A versão server é inclusive muito mais rápida que a versão nativa compilada com -O5 (o 5o nível de otimização do GCC - mais do que isso não trouxe melhorias para este exemplo). Mas mesmo a versão client tem desempenho parecido com o GCC -O1.

Java mais rápido que código nativo?
Para entender o que ocorreu com o programa anterior, serão explicadas algumas das técnicas de otimização feitas pelo Hotspot. Para começar, o Hotspot detecta que é necessário otimizar o corpo do loop. Para isso, ele aplica uma técnica conhecida como loop unrolling com fator de 2. O loop resultante fica parecido com:

if(n % 2 == 1) {
if(shift) bits ^= 1 << 5;
n--;
}
while (n > 0) {
if(shift) {
bits ^= 1 << 5;
}
n--;
if(shift) {
bits ^= 1 << 5;
}
n--;

}

Porém, dentro do loop, o valor de shift não é alterado e o 'n--' não tem efeito sobre a computação sendo feita. O compilador, dessa vez, reordena as instruções para ficar parecido com:

while (n > 0) {
if(shift) {
bits ^= 1 << 5;
bits ^= 1 << 5;
}
n--;
n--;
}

Para que a variável 'bits' não seja carregada mais de uma vez e porque a operação XOR (^) é associativa, o compilador resolve colapsar as duas instruções em uma só:



while (n > 0) {
if(shift) {
bits ^= (1 << 5) ^ (1 << 5);
}
n -= 2;
}


Nesse momento, o Hotspot percebe que a expressão:
(1 << 5) ^ (1 << 5)
na verdade é a constante 0! Assim, a parte interna do loop pode ser eliminada, bastando adicionar as instruções do seu efeito colateral (decrementar o n até 0). Dessa forma, o código final executado é parecido com:

if(n % 2 == 1) {
if(shift) bits ^= 1 << 5;
n--;
}
n = 0;

É claro que esta é uma simplificação do que acontece realmente (o loop na verdade é dividido em três seções, mas estas explicações detalhadas ficam para outro post). A versão client compiler pára antes de fazer todas as otimizações para que o código nativo possa ser executado mais rapidamente. O código gerado, porém, não é o mais otimizado possível - que é um quase noop.

Conclusão
Não se preocupe em escrever o código java mais otimizado possível. É preferível escrever um código mais legível e deixar as otimizações mais estranhas para o Hotspot.
Embora não se possa afirmar que a JVM consiga gerar código tão eficiente quanto os compiladores nativos, é seguro afirmar, pelo menos, que eles tem desempenhos equivalentes.

PS: O exemplo aqui presente e muitas outras discussões bastante interessantes podem ser acompanhadas no google groups de linguagens da jvm.

update: muitos erros de português...

update2: Os tempos da versão java medidos com o time foram omitidos por serem virtualmente identicos ao tempo acima. Em todo caso, o user time é, em média, 100ms superior ao tempo medido de dentro da aplicação.