10 razões por que precisamos do Java 3

Curioso como tem pouco software 3.0 por aí...parece um número místico

Daniel Quirino Oliveira wrote:agora, viajando mais um pouquinho, já que estamos discutindo/propondo as mudanças que podem/gostaríamos de ver no Java3, como seria a J3EE?

morte dos ejbs, que acha?

e obrigar o uso de JMX em tudo que eh canto, HUAUHUAHUHA. ia ser DOIDO. tipo, toda configuracao de qquer coisa tem de ser jmx.

Paulo Silveira wrote:morte dos ejbs, que acha?

Eu acho que EJBs já vão tarde

Paulo Silveira wrote:e obrigar o uso de JMX em tudo que eh canto, HUAUHUAHUHA. ia ser DOIDO. tipo, toda configuracao de qquer coisa tem de ser jmx.

...o que levaria à introdução de novas APIs, chamadas JMXX (Java Management Extensions Extensions), o que nos levaria a querer o Java 4

concordo que os EJBs vão tarde, principalmente os EB (seja CMP ou BMP). A idéia de JMX tbm é muito boa, mas acho que eu proporia umas melhorias sobre o JCA, que deveria se assemelhar mais ao JDBC. Aliás, talvez uma fusão entre JDBC e JCA, tratando os DBMS como legados (acho que o Carlos e o Klaus iriam gostar de tratar os bancos de dados como legados

).

alguem pode me explicar pra que JCA exist e dar uma exemplo real que eu utilizaria?
valeu

As novidades na especificação EJB 2.1 são bem legais, o suporte aos webservices será total, com a inclusão das novas APIS(JAX-RPC e JAXM) , será possívem exportar os Stateless Session Beans e Message-Driven Beans como webservices baseados em SOAP, fazendo com que fique disponível para qualquer cliente compativel com SOAP.

Também teremos inovações nos Message-Driven Beans com suporte a J2EE Connector Architecture , os MDBs podem ser extendidos atravez de conectores para trabalhar com qualquer protocolo de mensagens e não só JMS.

Tambem será possível modelar um fluxo de mensagens com o destination linking.

A API Timer Service , que vai funcionar como um Cron do UNIX para agendar tarefas nos servidores EJB. Com essa API será possível escrever eventos-temporizados ligados a Beans para realizar tarefas com datas, períodos de tempo e intervalos específicos.

A polêmica EJB QL também tem melhoras para facilitar mais o seu uso.

Bem, sei que tem muita gente que não gosta de EJB, mais eu pessoalmente gosto, sei que não é perfeita e não serve para resolver todos os problemas do mundo, essa nova especificação já soluciona alguns problemas mais não resolve tudo. Fica aí a dica para quem curte o mundo dos EJBs.

Paulo em JMX mesmo vc usa JCA. Lembra que vc possue os Adapters para expor os MBeans para os clientes, pois é vc pode fazer novos adaptadores com a JCA. Por exemplo o jmx do JBoss só possui RMIAdapter e HTTPAdapter, não possuindo um adaptador SNMP, caso vc precise vai precisar usar JCA para fazer o adaptador.

Mais sei isso de teoria, nunca usei isso, tem um amigo meu que até estava fazendo justamente isso que falei (escrvendo um AdapterSNMP para JBoss) ele até ia mandar um tutorial de JCA para o guj, não sei pq ele não mandou ainda.

Richardson wrote:sei que não é perfeita e não serve para resolver todos os problemas do mundo

acho que ai esta a questao
ela SERVE para resolver TODOS problemas do MUNDO.

entao fica que nem o R3. Um ERP que serve para TODAS as empresas do MUNDO. matar mosca com canhao.

uma vez eu sai perguntando pro pessoal, quem ja tinha usado ejb em que o cliente fizesse o acesso remoto ao bean. um cara respondeu que uma vez fez. Entao pra que? (nao vale falar que seu webapp acessava via jndi, tem de ser cliente)

bem, como conheco pouco ejb, nao posso ficar argumentando muito.

o velho dilema do "to ejb or not to ejb?"... pessoalmente, acho que 90% dos projetos quem atualmente usam EJB poderiam muito bem ser feitos sem eles, usando (só para citar um exemplo) o Hibernate para substituir os EB. Tudo isso movido pelo hype tecnológico e pela sedução das letrinhas(EJB, JMS, JCA...).
No final de tudo, acabam deixando características realmente interessantes e que tornam a spec. EJB útil (como controle de transação, possibilidade de distribuição de carga entre vários nós de um cluster, bla bla bla) de lado.

aliás... http://www.javaworld.com/javaworld/jw-12-2001/jw-1207-yesnoejb.html

Não queria que esse topico se transformasse em um EJB vs Não-EJB, mas já que estamos nesse assunto, vamos a algumas pesquisas interessantes que o pessoal do JBoss tem feito:

- Nem todo mundo precisa de todas as features do EJB: alguns precisam só da persistência, outros precisam do controle de segurança, outros de transações, e por aí vai

- Muita gente nao gosta de desenvolver EJBs por causa do tempo de desenvolvimento (e pela dificuldade de depuração e de se fazer testes automatizados realmente decentes)

- Muita gente gosta de EJBs pq acha eles uma mão na roda

Logo...

Por que não implementar a coisa de uma maneira que qualquer POJO (Plain Old Java Object) possa se "transformar" em EJB, dadas informações suficientes no deployment descriptor? Assim, não mataríamos a herança (EJBs hoje estendem EJBObject, lembram-se?) nem pesaríamos muito no desenvolvedor pra conhecer a semântica de passivação, nem boas partes do life-cycle de um EJB.

Entra o JBoss AOP...

No novo release do JBoss, Marc Fleury, Rickard Oberg & friends não estão pensando só em seguir os padrões da J2EE, mas sim em esticá-los para aceitar o uso, vindo de qualquer POJO, das features que hoje são dadas apenas e EJBs, através da arquitetura de serviços e microkernel do JBoss e uns belos truques de AOP (Aspect-Oriented Programming).

Resultado: tudo o que se queria (bom, eu, pelo menos, queria) na J3EE

PS: Este post foi altamente especulativo. Não estou prometendo nada, e também não tenho nenhuma ligação com o JBoss além de "reles usuário". Mas, definitivamente gostei da idéia, se é que eu a entendi direito, e queria passar pra frente. Então, se eu falei merda, por favor me corrijam

Daniel Quirino Oliveira wrote: pessoalmente, acho que 90% dos projetos quem atualmente usam EJB poderiam muito bem ser feitos sem eles

Então vc concorda que os 10% que estão sobrando devem ser feitos com EJB. Então são para esses 10% que ele deve ser usado, ou até não, vc pode viver sem eles, porém não vamos culpar o "hype" a tecnologia, quem usar mal a tecnologia é único responsável por isso, qualquer tecnologia pode ser usada indevidamente.
Por exemplo: Só pq um sistema foi feito em JSP, todo em scriptlets com um código macarrão, não quer dizer que o jsp é ruim, a culpa é únicamente de quem resolve desenvolver assim.

===
Bem ja estou falando muito sobre essa questão, hehehe estou até me achando um chato, mais foi por debates como esses que tenho conhecido outras tecnologias, pois isso faz com que desperte minha curiosidade para conhecer e testar outras alternativas.

Depois que entrei no fórum do GUJ, passei a usar Eclipse (Putz e ja meti o pau no coitado, sem nunca ter usado para valer), e hoje reconheco que o danado é bom mesmo. Então ninguem deve ser xiita com relação a tecnologia, eu posso não saber usar determinada tecnologia e sair metendo o pau enquanto outro cara faz maravilhas com ela.

E cv, o pessoal da JBoss é realmente 10, o lance de usar JMX foi idéia deles e a SUN ja pensa em tornar padrão, quem sabe essas idéias um dia podem vingar.

Por exemplo: Só pq um sistema foi feito em JSP, todo em scriptlets com um código macarrão, não quer dizer que o jsp é ruim, a culpa é únicamente de quem resolve desenvolver assim. (Richardson)

Respondendo: não. Diria, acho que como a maioria, que ruim não é a tecnologia usada (JSP no caso do exemplo, EJB no caso da discussão) mas quem a usou não sabia como usá-la. E é isso que quero dizer quando digo que em 90% dos projetos, usar EJB é matar mosca com tiro de canhão (nota: esta frase tão usada é do filósofo chinês Confúcio). Mas, como eu disse em síntese no tópico "Morte aos EJBs", na seção J2EE, é um radicalismo dizer que EJBs não prestam e são só puro marketing. Mas acho que deveriam realmente usá-los só quando fossem necessários.
E por enquanto chega...

Se não me angano na nova versão, vc vai poder fazer operações entre classes, como em tipos primitivos....
ex: a classe Integer e o primitivo int, ele vai tipo fazer o cast automaticamento, e realmente, isso é uma coisa que é mala!!!!

Alexandre Martins.

Notícias, artigos e o maior fórum brasileiro sobre Java