Retirando coisas da plataforma Java

Li sobre isso no java.net também, aqui: http://blogs.sun.com/mr/entry/removing_features

Uma coisa que comentaram e achei interessante é do http://jcp.org/en/jsr/detail?id=277Java Moduling System, assim as partes que fossem retiradas da jre mas são usadas por um aplicativo poderiam ser adquiridas.

Aí isso depende de cada um, de definir o que é útil. Eu pelo menos uso muito mais a api midi do que security e crypto.

O que cada um de vocês tiraria se pudesse?

flw

Eu diria que essa foi a principal feature que nos adicionamos ao Mustang. Eh especialmente um bom momento para adiciona-la agora que alguns acham que CORBA deveria ser removido porque temos webservices, ao mesmo tempo que alguns acham que webservices nao deveriam estar na plataforma para comeco de conversa

Olá

Não vejo como retirar nada. Há muitos sistemas legados que podem se prejudicar retirando alguma coisa que a gente imagina que ninguém usa mais.

Mas como estamos falando de futuras versões que acho que provavelmente estes sistemas legados nunca chegarão a ser portados, vou lembrar a todos o que ocorreu quando o Java lançou o Java 2.

O lançamento do Java 2 foi para mim a maior ruptura que a Sun fez com o código Java desde a versão 1.0.2 que foi quando comecei a usá-lo. Passar para o Java 2 era simplesmente inviável em muitos casos e alguns sistemas ficaram no jdk1.1.6 por muito tempo. Porém, na época o Java não era universalmente adotado como agora e não foram muitas as vítimas do Java 2 (eu entre elas).

Cada um de nós tem suas coisas preferidas no Java. No meu caso são as APIs de servlets e de JMS que me encantam. Eu até gostaria que fizessem parte do JDK e que fossem exigidas fortemente nas provas e certificação de programador. Mas como gosto cada um tem o seu, já conheci gente que adorava CORBA. Acho que eles não gostariam de ver o suporte à CORBA ser eliminado.

[]s
Luca

Luca:

Não vejo como retirar nada…

Acho que eles não gostariam de ver o suporte à CORBA ser eliminado…

Ola Luca,

O modelo proposto pela JSR preve que um expert group soh pode recomendar a remocao de uma funcionalidade, jamais remove-la diretamente. Para que a remocao ocorra, o EG deve verificar a opiniao da comunidade sobre o assunto.

Por fim, o termo “remocao” nao eh exatamente correto no contexto (sim, e usei duas vezes antes…). Essas APIs passariam a ser opcionais, ou seja, a Sun pode, se quiser, disponibilizar uma versao da JVM com o CORBA. Alem disso, a ideia eh que seja possivel usar uma implementacao da API caso ela nao esteja disponivel.

Olá

Valeu a explicação. Acho que na própria Summa ainda tem torcedores do CORBA.

[]s
Luca

Eu, por exemplo (ou voce acha que CORBA nao estah na lista por que? :-P)

Engraçado, é o que eum penso há 2 anos.

Adicionando uma sugestão ao que o Michael já falou, sei lá, de repente a Sun podia dividor a JVM em dois pacotes, um tipo um “modo legado”, e o outro tipo um “modo bola pra frente”…

Seria muito legal se acontecesse assim: Você instala o Java ultra-novo numa máq., aí bem depois tem que rodar uma app legada do 1.4 por exemplo, aí quando rodasse o programa, que seria quando a gente ia descobrir que a feature X é muito velha e não tem mais, aí a JVM instalava na hora o módulo necessário, ia ser maneiro assim…

A ideia, quando a JSR-277 foi criada, eh que ela resolvesse esse problema. Se isso vai acontecer, no entanto, depende do EG.

Acho uma boa também, assim quem quiser distribuir a aplicação em CD pode instalar tudo se quiser, ou personalizar e instalar os “pacotes” que deseja.

Seria talvez algo como o winamp, com versão lite e versão full, certo?

Parece que querem criar uma Java dentro de Java!

Eu, particularmente, adoraria uma jsdk-without-deprecated-api. Ou seja, (métodos|classes|*)-deprecateds ficam todas de fora.

Falando nisso, alguém sabe se tem alguma forma milaborante de desabilitar métodos deprecated no auto-complete do Eclipse?

plentz:

Eu, particularmente, adoraria uma jsdk-without-deprecated-api. Ou seja, (métodos|classes|*)-deprecateds ficam todas de fora.

Falando nisso, alguém sabe se tem alguma forma milaborante de desabilitar métodos deprecated no auto-complete do Eclipse?

plentz:

Eu, particularmente, adoraria uma jsdk-without-deprecated-api. Ou seja, (métodos|classes|*)-deprecateds ficam todas de fora.

o caso que isso iria gerar ja seria suficientemente grande apenas com a remocao dos metodos deprecated da java.util.Date. ia ser usina nuclear explodindo em tudo que eh canto

Usina nuclear nao pode usar Java pra nada missao-critica, de acordo com a EULA