Arquivo Discussoes de Programacao e Tecnologia 
O Gavin King (criador do Hibernate, Seam e desenvolvedor da Red Hat/JBoss Inc. ) está publicando uma série de artigos sobre as coisas que ele gostaria de ver na próxima edição do Java EE.
Notícia completa: What Should be In JEE 6? Gavin King’s Wish List
eu acho que ele viajou um pouquinho nesta wish list (principalmente querendo fazer com que por padrão os EJBs não suportem concorrencia), mas até que tem algumas coisinhas interessantes 
Eu achei legal…compartilho a mesma ideia do urubatan… essa parte de concorrencia foi realmente meio sem sentido… para que eu iria querer uma arquitetura de objetos distribuidos onde por padrao eu tenho que fazer o controle de concorrencia ? nao entendi… claro que existem casos… mas disso até deixar padrão… tem um grande pulo…
Outra coisa que nao entendi… é o @Logger… po… esta atribuindo coisas ao container que não cabem a ele… mais configuracao (para caso eu queira usar outro tipo de logger ex: log4j) a troca de que ?
Achei elgal a parte da heranca de anotações entre interfaces (eh assim que se chama ?)
@Stateful
@TransactionAttribute(MANDATORY)
@Scope(CONVERSATION)
@RolesAllowed(USER)
@ConcurrencyManagement(CONTAINER)
public @interface AjaxConversation { .... }
@AjaxConversation
@Name("createOrder")
public class CreateOrderBean implements CreateOrder { .... }
Acho que ele ficou bem bitolado no Seam… ele até sugeriu que as interfaces remotas e locais fossem opcionais… como ele disse “em ambientes como Seam elas sao dispensaveis” , po… vao ser dispensaveis quando os webbeans estiverem prontos… mas HOJE na arquitetura dele são dispensaveis devido a ele usar um SessionBean como action para tudo…
Resumindo 30% do que ele sugeriu eu acho realmente importante…
ps: OPINIAO PESSOAL DETECTED , please don’t flame !
Este é o tipo de pensamento que impede a produtividade em java, se tem uma API padrão para Logging, simplesmente usa ela! a mesma coisa para MVC, …
isto só funciona em java com objetos distribuidos por que ninguem foi insano o suficiente para criar uma alternativa aos EJBs …
por exemplo, Persistencia, cada um quer fazer do seu jeito, ja em RoR por exemplo, todos aceitam usar o ActiveRecord mesmo que não goste de alguma coisa dele …
e quando querem algo diferente, escrevem um “addon” em vez de fazer uma alternativa …
Na verdade isto seriam meta anotações, ou seja, meta dados de meta dados
Tipo o @Target que temos hoje
Acho que ele ficou bem bitolado no Seam… ele até sugeriu que as interfaces remotas e locais fossem opcionais… como ele disse “em ambientes como Seam elas sao dispensaveis” , po… vao ser dispensaveis quando os webbeans estiverem prontos… mas HOJE na arquitetura dele são dispensaveis devido a ele usar um SessionBean como action para tudo…Resumindo 30% do que ele sugeriu eu acho realmente importante…
ps: OPINIAO PESSOAL DETECTED , please don’t flame !
Existe sim uma API de Log padrao no Java SE… mas a pergunta é… que projeto OpenSouce(ou nao) usa ela ? até o GlassFish da Sun usa log4j… quando a API se mostra muito fraca… sempre é bom ter alternativas… se for pensar desta forma… pra que usar Hibernate com EJB 2.x ? o negocio é afundar-se nos Entity Beans.
Olha… acho que ninguem escreve algo diferente prq vai ter que trabalhar dentro o Rails… o universo é totalmente diferente… estamos falando de uma plataforma toda…e nao de trabalhar dentro de um framework… e repito… esse negocio de usar sempre uma coisa só e esquecer o resto não funciona em Java… CONCORDO PLENAMENTE que isso deixa as coisas “menos produtivas” , na minha opiniao eu acho que as pessoas deveriam usar Java EE 5 do jeito que ele é… porem já vi nego usando Java EE 5 com Hibernate… e sem usar JPA , fazendo fabricas na mao e tudo mais… isso sim acaba com a produtividade…
E alternativas vão surgir… é inevitável (e louvável) , e esse @Logger vai te impor uma implementação unica ou criar mais xml’s de configuracao no servidor… não sei qual o pior…
Isso realmente é legal 
Na verdade eu até gostei da ideia de não obrigar a usar as interfaces locais e remotas
Tudo bem, as remotas eu acho que não deveriam ser opcionais, mas as locais não vejo por que serem obrigatorias :D
Interfaces locais não são obrigatorias… UMA interface é obrigatoria… OU remota OU local…
Acho importante as locais… principalmente no caso de FACADES…
O que eu quis dizer foi: se eu for chamar o EJB apenas de modo local, acho que realmente não precisaria de interface alguma em alguns casos, por exemplo para chama-lo apenas a partir da minha camada WEB …
Mas concordo que na maioria dos casos é uma boa pratica ter esta interface
Concordo contigo.
Foi um avanço fenomenal do EJB2 para o 3 essa questão de definição de interfaces e classes base (salvem as annotations!), e acho que este tipo de “simplificação” poderia continuar, sempre que fosse possível, dadas as ressalvas já discutidas.
Opa… uma nova linguagem de programacao? Annotation? Com suporte a Java?
ps: opiniao pessoal tambem
Opa… uma nova linguagem de programacao? Annotation? Com suporte a Java?
Eu acho bem melhor que 4-7 classes/interfaces por SFSB. =D
Sim… eu tinha pesadelos no tempo do EJB2… Eu ainda tenho, quando cruzo com algum sistema legado. Eu amo as annotations 
Eu acho bem melhor que 4-7 classes/interfaces por SFSB. =D
Sim… eu tinha pesadelos no tempo do EJB2… Eu ainda tenho, quando cruzo com algum sistema legado. Eu amo as annotations :P
o codigo do Seam esta beirando o ridiculo de tanta anotacao! é anormal. ele quer colocar logica de negocio la!
@Resposta @Ironia @Meta @Sarcasmo @Brincadeira @Citacao (Negativa) nao (Verbo) tem (Negativa) nada (Substantivo) errado (ConjuncaoAdverbial) nisso, (Interjeicao) oras!
Hehehehehehe… point taken 
Eu também uso o Seam e concordo; Mas restringi os comentários à especificação do Java EE. Tudo que puder ser simplificado merece atenção especial, desde que não traga mais problemas do que os que pretende resolver.
Bom, isto esta meio inerente a computação em si …
ou vocês nunca ouviram aquela famosa frase:
“O computador veio pra solucionar todos os problemas que não existiam antes dele”
hehehehe
O Seam tá virando o proximo Spring ehehehe… para fazer uma APP web simples vc vai precisar de 415 jars e um framework que leva-se 5 semanas para aprender direito…
ps: elefante branco ?