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.
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.
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
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.
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!!!
Acabei de pensar numa feature que seria muito boa para J3SE: uma nova API para GUI. Mas esta API serviria para criar tanto aplicativos desktop (à la Swing), ou para web (à la JSP/JSF) ou para dispositivos móveis (à la…). Na verdade, vc criaria o seu aplicativo do jeito que é criado atualmente e cria-se um “deployment descriptor” para este aplicativo dizendo a forma em que ele vai ser renderizado: desktop, web, mobile. E caberia a alguém (provavelmente à JRE) a criação dos formulários.
Talvez a idéia nem seja tão original assim e nem tão madura, mas fica a dica (editando… o Paulo disse que o NotYET já tem isso, os famigerados Forms).
Algumas ideia sao boas, outras sao completamente infundadas.
Tirar os tipos primitivos eh abrir mao de qualquer possibilidade de java ter uma performance aceitavel, vide smalltalk, eh bunitinho e tudo mais, mas pra uso no mundo real eh descartavel.
longs e doubles devem continuar nao sendo atomicos, ou entao vamos tornar operacoes com eles absurdamente lentas os plataformas 32 bits. Por curiosidade, quantos aqui usam predominantemente ambientes 64 bits?
Desacomplar os monitores dos objetos nao eh ruim, vai simplificar bastante o codigo de locking da JVM, porem vai exigir a criacao explicita de objetos pra realizar contencao. O argumento que um objeto nao pode ter mais de 1 monitor eh enrolacao, hoje em dia tem de criar varios Objects somente pra fazer essa tarefa, desacomplando os monitores teria de criar monitores para todas situacoes. O bom eh que nao iria mais ocorrer erros comuns como escolher o objeto errado pra sincronizar quando for realizar uma operacao atomica.
Ja converter os arquivos de properties pra xml acho inutil tb, isso vai na mesma linha dos problemas com ejb, de usar por puro modismo, se faz algum sentido usar ok, perfeito, mas se isso so vai piorar as coisas, ai nao. No caso do arquivo de properties, ate seria interessante se tiver a opcao de adiconar beans serializados como valor de uma property.
Sobre a parte de arruma o mecanismo de classloading, eh sim confuso, porem a interface do ClassLoader funciona ok e o problema que o autor se refere eh falha do software dele, onde os 2 classloaders carregar a mesma interface…
De resto, as propostar dele pra uma limpesa na linguagem e nas ais sao otimas, primeiro deveriamos resolver o problema doque fazer com as aplicacoes legado.
Pq nao usar um esquema de switching? De tal forma que a VM pudesse operar em modo classico e novo dependendo das classes carregadas
[quote=“louds”]
Tirar os tipos primitivos eh abrir mao de qualquer possibilidade de java ter uma performance aceitavel, vide smalltalk, eh bunitinho e tudo mais, mas pra uso no mundo real eh descartavel.[/quote]
Não é por causa dos tipos primitivos que o Java hoje tem uma performance boa. É por causa do HotSpot, e este continua indo muito bem, obrigado, e não tem nenhuma dependência vital em cima de tipos primitivos pra funcionar direito. Depois, é possível ter tipos primitivos no bytecode, sem tê-los na linguagem.
[quote=“louds”]
longs e doubles devem continuar nao sendo atomicos, ou entao vamos tornar operacoes com eles absurdamente lentas os plataformas 32 bits. Por curiosidade, quantos aqui usam predominantemente ambientes 64 bits?[/quote]
De novo, HotSpot neles!
[quote=“louds”]
Ja converter os arquivos de properties pra xml acho inutil tb, isso vai na mesma linha dos problemas com ejb, de usar por puro modismo, se faz algum sentido usar ok, perfeito, mas se isso so vai piorar as coisas, ai nao. No caso do arquivo de properties, ate seria interessante se tiver a opcao de adiconar beans serializados como valor de uma property.[/quote]
Hmmm…nao tinha pensado nisso, mas, realmente, usando properties em XML, iria ser perfeitamente possível definir um bean como valor de uma propriedade, se o bean estiver serializado em XML (usando a serializacao de beans que vem na 1.4 em diante)
[quote=“louds”]
Sobre a parte de arruma o mecanismo de classloading, eh sim confuso, porem a interface do ClassLoader funciona ok e o problema que o autor se refere eh falha do software dele, onde os 2 classloaders carregar a mesma interface…[/quote]
O problema não é se funciona, é se funciona da melhor maneira possível e se é fácil de usar. Todos nós sabemos que os ClassLoaders hoje funcionam, mas eles são mesmo a melhor solução?
[quote=“louds”]
De resto, as propostar dele pra uma limpesa na linguagem e nas ais sao otimas, primeiro deveriamos resolver o problema doque fazer com as aplicacoes legado.
Pq nao usar um esquema de switching? De tal forma que a VM pudesse operar em modo classico e novo dependendo das classes carregadas[/quote]
nao se esquecam que a gente ja tem switch de features hoje em dia: java-ea e java -da
sobre o boxing e unboxing. Acalmem-se, a gente nao vai perder os tipos primitivos, mas eles poderao ser embrulhados automaticamente dentro das classes Wrappers, sem precisar escrever. Eh soh isso.
HotSpot não faz nenhuma magica, é simplesmente um JIT’er que faz compilação seletiva. Não sei sobre seu conhecimento técnico no assunto, mas pelo que você disse, pouco sabe.
Se java não tivesse tipos primitivos sua performance numérica seria mais de 1 ordem de magnitude inferior ao equivalente em C, oque não é verdade. E pq isso? Mágica? Ou pelo fato que operações com tipos primitivos são traduzidas em menos instruções de máquina, instruções mais rapidas tb. Considere os seguintes pseudo-código:
(1)
int a = 10;
int b = 20;
c = a + b; //c é uma variavel estatica
(2)
Integer a = 10; //autoboxed
Integer b = 20; //autoboxed tambem
c = a + b; //mesmo c do outro snippet.
Se você possui algum conhecimento sobre assembly e o formato de bytecode usado por java/.net/etc vai entender o seguinte, que seria o resultado traduzido pelo compilador. (em pseudo instrucoes de java bc, pq nao tenho referencia a mao)
(1)
push 10
push 20
add_i
store_static [c]
(2)
push 10
new Integer(int)
push 20
new Integer(int)
call_vfunc [add]
store_static [c]
(1) em assembly pode ser traduzido (pra asm intel):
mov eax, 10
add eax, 20
mov [c], eax
(2) em contrapartida
//contruimos o primeiro Integer
mov eax, 10
call [new_integer_int]
//construimos o segundo Integer
mov ebx, eax
mov eax, 20
call [new_integer_int]
//chamamos o metodo virtual add da classe Integer
push eax
push ebx
lea eax, [eax + 20 ] //suponhamos que 20 seja o offset do metodo add
call eax
sub esp, 8
mov [c], eax
Isso é algo bem por cima, tou supondo que temos 1 standard call sequence (eax volatil, parametros pela pilha pushed da esquerda pra direita, caller da pop), como era na vm da 1.3 se lembro bem…
Ou seja, trocamos uma sequencia de 3 instrucoes por uma de 11 sem contar oque ocorre dentro das 3 chamadas de funcao, que vai envolver alocacao de memoria 2x pelo menos.
Nem utilizando técnicas como desvirtualização e stack object allocation a performance chega perto do equivalente tendo tipos primitivos.
O cara da reportagem não quer programar em java, mas sim em python, la isso ocorre, la vc vai aceitar 1 programa que roda mais de 100x mais lento que o equivalente em C.
[quote=“louds”]
longs e doubles devem continuar nao sendo atomicos, ou entao vamos tornar operacoes com eles absurdamente lentas os plataformas 32 bits. Por curiosidade, quantos aqui usam predominantemente ambientes 64 bits?[/quote]
Não vou colocar 1 monte de código assembly dessa vez pq não precisa, que diabos a VM pode fazer pra milagrosamente tornar operações em long e double atômicas num pc ou mac? A única maneira é tendo sincronização automática, oq vai tornar criptografia, por exemplo, razoavelmente mais lenta, imagina que o compilador, pela suas costa iria fazer o seguinte:
long x = 10;
long y = 20;
synchronized(BIG_VM_LOCK) {
y = x;
}
[quote=“louds”]
Sobre a parte de arruma o mecanismo de classloading, eh sim confuso, porem a interface do ClassLoader funciona ok e o problema que o autor se refere eh falha do software dele, onde os 2 classloaders carregar a mesma interface…[/quote]
Que escrever 1 classloader legal é a coisa mais dificil que a 1.4 oferece, sem dúvidas, mas é dificil pensar em uma alternativa que também nao seja horrivel de usar…
[quote=“cv”]
Pode ser… algo como:
[]'s
-cv[/quote]
Sera nao rolava ser algo automatico baseado nos header da classe?
algo do tipo
__attribute(java3) class Main { … }
Ok, tou roubando sintaxe do gcc, mas oq vale é a ideia.
Oque seria muito legal num java3 seria completar a parte de reflection, criar 1 forma de poder obter as mesmas informacoes que da via a API mas interagindo diretamente com a classe (Integer.class x this.getClass())
seria muuuito util se desse pra fazer isso com todo o resto, metodos, variaveis, etc. Isso iria causar 1 boom na utilização de reflection.
Outra coisa seria permitir anexar metadata a classes, metodos e variaveis, ./- como rola no c#.
Isso ia permitir que muita da semantica que precisamos passar via arquivos xml pros programas ficasse na classe.
Um exemplo seria colocar toda informação de persistencia como metadata pro OJB usar…
Hotspot nao eh um JIT. O termo Java HotSpot Client Compiler eh apenas algo fashion, A Hostpot age em outra Thread alias. Ela fica dando pitaco ao JIT, indicando quem ele deve compilar.
Voce nao deveria atacar os outros pessoalmente. Voce poderia, educamente, ter apontado o engano, e mostrado que, alem de conhecer muito de computacao, sabe lidar com as pessoas.
a relacao 3 para 11 eh constante. Se java fosse sempre 3x mais lento q C++, ja estava otimo.
A VM atual coloca objeto na stack sim, e faz desvitualizacao de acordo com o classloading (se aparecer alguem com overriden mais profundo). A performance novamente aqui seria um fator constante em relacao ao C e C++. Se java com soma de objetos fosse 100x mais lento que c++, ainda assim a funcao assintotica era a mesma.
Nao sei porque o pessoal gosta tanto de pequenas otimizacoes. Nem o nerd do Knuth gosta, como diz a minha assinatura.
[quote=“louds”]Oque seria muito legal num java3 seria completar a parte de reflection, criar 1 forma de poder obter as mesmas informacoes que da via a API mas interagindo diretamente com a classe (Integer.class x this.getClass())
seria muuuito util se desse pra fazer isso com todo o resto, metodos, variaveis, etc. Isso iria causar 1 boom na utilização de reflection.
[/quote]
nao entendi. ja da pra fazer isso.
[quote=“louds”]
Outra coisa seria permitir anexar metadata a classes, metodos e variaveis, ./- como rola no c#.
Isso ia permitir que muita da semantica que precisamos passar via arquivos xml pros programas ficasse na classe.
Um exemplo seria colocar toda informação de persistencia como metadata pro OJB usar…[/quote]
Tipo, nao entendo muito do assunto, mas ter autoboxing nao afetaria a performance nem pra cima nem pra baixo, nao?? Pq pra manter a compatibilidade com as outras versoes, isso tem algo que eh “transformado” em tempo de compilacao pra, teoricamente, os mesmos casts que fazemos atualmente, nao?!
Portanto, se hoje fazemos
int x = 10;
meuMap.put(new Integer(x), "dez");
com autoboxing podera ser feito
int x = 10;
meuMap.put(x, "dez");
isso, nao?! O que o compilador faria seria simplesmente ver que x eh um primitivo e fazer o cast, o que acabaria gearndo um binario “identico” … se isso estiver correto, entao boxing nao vai fazer diferenca na performance.
Se pareceu que eu ataquei, peço desculpas. Porem, se você olhar na documentação da sun, ela cita o tempo todo o termo ‘The Java HotSpot Dynamic Compiler’ entre outras coisas, ou seja um Just In Time compiler.
Ok que é apenas o nome da tecnologia, mas ainda assim não é sinonimo de milagre.
Se java fosse 3x mais lento que c++ pouca gente estaria usando hoje em dia. So não entendi qual a pertinencia disso em relação com oque comentava, que é a diferença de implementar operações matematicas com Objetos e com tipos primitivos.
Hmm, de qual VM vc ta falando? Não a 1.4.x que a Sun distribui ne? Pq essa não aloca objetos na pilha e faz muito pouca desvirtualização, so não lembro se era via ssa ou grafo de dependencias. Pode ir e verificar no fonte da VM.
Eu não considero um perda de performance de mais de 2x ‘pequena’, não posso me dar a esse luxo.
Agora, a diferença é assintotamente linear e não contante, pq se for 100x mais lenta, como citado, 10 operações não vão levar a mais o mesmo tempo que uma operação, oque é falso.
Uma das características que mais atrai em java é o baixo custo em termos de performance em relação a linguagens compiladas, hoje um programa de computação cientifica escrito em java é so alguns % mais lento que o equivalente em c++, se de repente esses, sei lá, 20%, se tranformam em 500%, muita gente vai questionar se java realmente vale a pena.
[quote=“louds”]Oque seria muito legal num java3 seria completar a parte de reflection, criar 1 forma de poder obter as mesmas informacoes que da via a API mas interagindo diretamente com a classe (Integer.class x this.getClass())
seria muuuito util se desse pra fazer isso com todo o resto, metodos, variaveis, etc. Isso iria causar 1 boom na utilização de reflection.
[/quote]
nao entendi. ja da pra fazer isso.
Me expressei mal então, ou dá pra fazer e não sei.
Hoje o único objeto de reflecção que pode ser obtido sem ser via api é Class (Integer.class), porem não existe sintaxe pros demais objetos, como Method, se pudesse fazer algo como 'Method m = Integer.parseInt;'
usar reflection seria infinitamente melhor, não acha?
