Retirando coisas da plataforma Java

Depois de 10 anos de muitas idéias sendo estudadas, discutidas e implementadas, a plataforma Java foi se inchando e inchando e muitas soluções que não deram certo e/ou foram consideradas ultrapassadas permaneceram na plataforma juntando poeira pela política de backward compatibility. Pois bem, parece que agora a tendência é começar a retirar tudo o que não é útil: http://www.infoq.com/news/java-platform-feature-removal

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.

Pois bem, parece que agora a tendência é começar a retirar tudo o que não é útil

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

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

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

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

Luca wrote: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á

mister__m wrote:[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.

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

[]s
Luca

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

Luca wrote:Acho que na própria Summa ainda tem torcedores do CORBA.

Eu, por exemplo (ou voce acha que CORBA nao estah na lista por que?

)

GUJ Master Membro desde: 16/12/2004 17:09:19 Mensagens: 1787 Offline

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

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 736 Offline

renato3110 wrote:EVocê 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.

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

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

tem uma opção que vc pode selecionar, avisando o compilador lançar um error ou warning se tiver algum deprecated ... fuça la em Window -> Preference ...

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

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