10 razões por que precisamos do Java 3

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).

Abraços

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

louds wrote:
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.

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.

louds wrote:
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?

De novo, HotSpot neles!

louds wrote:
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.

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)

louds wrote:
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...

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?

louds wrote:
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

Pode ser... algo como:

[]'s
-cv

ei pessoal

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.

cv wrote:
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.

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.

louds wrote:
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?

cv wrote:

De novo, HotSpot neles!

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;
}

louds wrote:
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...

cv wrote:
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?

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...

cv wrote:
Pode ser... algo como:
java -api=classic MyOldClass
java -api=new MyShinyNewClass

[]'s
-cv

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...

louds wrote:
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.

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.

louds wrote:
....
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.

a relacao 3 para 11 eh constante. Se java fosse sempre 3x mais lento q C++, ja estava otimo.

louds wrote:
Nem utilizando técnicas como desvirtualização e stack object allocation a performance chega perto do equivalente tendo tipos primitivos.

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.

louds wrote: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.

nao entendi. ja da pra fazer isso.

louds wrote:
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...

Vai ter isso no java 1.5.

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

com autoboxing podera ser feito

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.

Rafael

Paulo Silveira wrote:
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.

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.

Paulo Silveira wrote:

a relacao 3 para 11 eh constante. Se java fosse sempre 3x mais lento q C++, ja estava otimo.

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.

Paulo Silveira wrote:
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.

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.

louds wrote: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.

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?

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