10 Nov 08 Java Enterprise Edition 6.0 esta ficando bem legal

O Java EE esta cada vez mais simples de se utilizar, então por definição esta cada vez melhor.
O motivo deste post são algumas melhorias vindas da especificação do EJB 3.1 que eu achei espetaculares:
Interface local opcional
Exatamente isto, agora a interface local dos EJBs é Opcional. Isto permite que o seguinte código seja válido:

1
2
3
4

@Stateless
public class HelloBean {
   public String hello() { return "hello"; }
}

E o cliente utiliza isto mais ou menos assim:

1
2
3

@EJB Hello helloRef;
...
helloRef.hello();

Mesmo a classe sendo acessada diretamente, o cliente nunca instância o objeto com um “new”, ele recebe um proxy, exatamente como se estivesse trabalhando com uma interface, mas mesmo assim o modelo fica mais simples e é menos trabalho para o programador

Nomes globais JNDI portáveis
Não sei se fui apenas eu, mas é um inferno desenvolver aplicações Java EE que precisem acessar EJBs em mais de um container, exceto se elas puderem fazer isto via anotações o que não cobre 100% dos casos, cada container utiliza um nome global diferente para o EJB, agora no Java EE 6 o nome global dos EJBs faz parte da especificação, então vai ser igual para todos os containers
Só quero ver como eles vão fazer para manter a compatibilidade com versões anteriores dos mesmos containers, acho que os EJBs vão ter nome e apelido
A sintaxe para os nomes globais dos EJBs vai ser a seguinte:
java:global[/<app-name>]/<module-name>/<bean-name>
E caso o session bean exponha mais de uma interface, o nome vai ser:
java:global[/<app-name>]/<module-name>/<bean-name>/<intf-name>
Isto quer dizer que para o EJB abaixo:

1
2

@Stateless
public class FooBean implements FooRemote { ... }

Publicado em um arquivo de nome foobar.jar, podemos acessa-lo com o seguinte código:

1

FooRemote foo = (FooRemote) =  new InitialContext().lookup("java:global/foobar/FooBean")

E acabou o nome especifico para cada container, ou pior, nome para cada deployment como alguns containers faziam.

Empacotamento de EJBs Simplificado
No Java EE 6 não será mais necessário em uma aplicação criar um .war para a aplicação web, um .jar para os EJBs e empacotar tudo isto em um .ear só para acessar alguns EJBs pela aplicação WEB, vai bastar colocar os EJBs dentro do WEB-INF/classes ou até mesmo em um jar dentro do WEB-INF/lib da aplicação WEB e tudo vai funcionar como mágica

Singleton EJBs
Esta última novidade eu não sei se é boa ou ruim …
Singletons são a forma mais podre de programação não orientada a objetos em uma linguagem OO.
Claro que em raros casos um singleton é realmente utilizado como um singleton e neste caso ele é realmente útil, mas eu vi apenas uns dois ou três casos destes até hoje, todas as outras aplicações que tem diversos singletons utilizam os mesmos como um repositório de métodos que não pertencem a objeto nenhum. Ou seja, uma entidade não OO na aplicação …
Mas fora a discussão filosófica, o pior é achar que você tem um singleton e a aplicação possuir duas instâncias do mesmo, por que na implementação clássica de singletons no java, eles são singletons apenas por classloader, o que causa diversos problemas …
Para solucionar este problema, o Java EE 6 possui EJBs Singletons
Exatamente isto.
Eles são utilizados como qualquer outro EJB, mas existira apenas uma instância dele no container ou no cluster, ou seja, apenas uma instância na aplicação …
Para criar um EJB Singleton, o código vai ser mais ou menos este:

1
2
3
4
5
6
7
8
9
10
11
12
13

package com.sun.ejb31.test;
 
import javax.ejb.Singleton;
@Singleton
public class CounterBean {
    private int hitCount;
 
    //Perceba a utilização de synchronized aqui
    public synchronized int incrementAndGetHitCount() {
        return hitCount++;
    }
 
}

E era isto, utilize como no primeiro exemplo!

Bom, por enquanto era isto, estou achando que o Java EE 6 vai matar a pau, ainda mais juntando com a especificação de WebBeans que deve sair junto!

Tags: ejb, Java EE, preview