eu não estou acreditando
Um fork para mim seria a melhor opção tecnicamente falando. O problema é que gerentes de projetos que não entendem nada de programação vão sentir medo de que a versão do java retrocompatível com suas aplicações não seja atualizada. Sei que isso não tem nada a ver, não vai ter problema algum, mas sabe como são esses gerentes. Já ouví cada coisa…
Acho que o pessoal se esqueceu que Java é o Cobol da primeira década do século 21 (que está por terminar, por sinal).
E é por isso que a retrocompatibilidade tem de ser mantida a qualquer custo, e é por isso que as alterações propostas na linguagem são meio desajeitadas (como a proposta BGGA de closures), mas em suma não quebram de forma nenhuma a retrocompatibilidade.
Você pode quebrar a retrocompatibilidade com coisas aparentemente bem estúpidas, como incluir uma nova palavra-chave (quantos de vocês não tiveram problema com a nova palavra chave “enum”? É muito comum em programas antigos escrever algo como:
Enumeration enum = ....Mas as alterações propostas não quebram, porque não há modo de escrever um programa no Java 1.4 que seja entendido de outra maneira pelo Java 8.0 (por exemplo).
Em quê você não está acreditando? Que não vai ter closures? Que tem gente sugerindo um fork? Que tem gente querendo quebrar a retrocompatibilidade?
Por sinal, um dia desses no começo do ano passado, eu cheguei a conversar com um amigo sobre a possibilidade de fazer um fork do java (e chamá-lo de sumatra, borneo ou sulawesi). Mas acabamos concluindo que seria mais viável criar uma outra linguagem nova, pois para valer a pena a quantidade de mudanças seria enorme.
Edit: Por sinal, de acordo com a nova ortografia, o certo é retrocompatibilidade ou retro-compatibilidade?
Que tal chamar de Krakatoa (um vulcão próximo a Java que explodiu em 1883), já que é para quebrar a compatibilidade?
[quote=victorwss]
Edit: Por sinal, de acordo com a nova ortografia, o certo é retrocompatibilidade ou retro-compatibilidade?[/quote]
Je ne sais pas - na cartilha do Estadão se diz para aguardar o Vocabulário Oficial que será publicado em fevereiro. 
Sim, exatamente isso, só que um detalhe que tbm é verídico, essas empresas que rodam suas aplicações em Java 1.3, e aqui no Brasil por exemplo tem muitas, não mudaram até hoje não vão mudar seus aplicativos para Java 5 ou 6, então um “novo” Java em 2010 (o que não vai acontecer) não traria esse problemas pra eles, afinal eles ainda rodam uma JVM 1.3.
O fato é que adicionar gambiarras na linguagem não ajuda em nada, acho que pioria na verdade, como já disseram, Java hoje esta cheia de retalhos, se não tiver um ponto de “Stop the Line” será assim eternamente? uma linguagem que tenta evoluir em cima de retalhos e gambiarras? Por que não usar uma “nova” linguagem mais moderna então?
Se a intenção é ter Java só como plataforma mesmo, então tanto faz o qeu fizerem com a linguagem, vamos programar em outras coisas mesmo e só jogar em cima da VM depois.
[]s
Tb acho que usar outras linguagens em cima da VM é uma boa opção para o problema e tb não deixa de ser um fork. :lol:
Segundo a nova ortografia, quando a primeira palavra termina com vogal, e a segunda começa com a mesma vogal, usa-se hífen
?
Analisando o resto da especificação (veja o PDF mencionado acima) , então não é para usar o hífen, e portanto o correto é “retrocompatibilidade”
falando em closures pra java, como voces imaginam que seria a sintaxe??
no ruby por exemplo temos coisas como
String.methods.sort.each{ |s| puts e.upcase if e.is_a? Integer }
logicamente que isso não vai imprimir nada pos a String não possui metodos do tipo inteiro mas a questão é, como seria algo assim em java?
ou como em um outro exemplo
def confere
c = 0
lambda{ c += 1 }
end
10.times{ puts confere.call }
ou
imprime_numero_atual = confere
10.times{ puts imprime_numero_atual.call }
desculpem mas ta meio dificil imaginar como seria uma programação assim no java, o que voces acham?
att,
todas as coisas que você mencionou.
-
closures estou surpreso por não ter ingressado, e ainda não consegui entender porque não a teremos no mustang.
-
quanto ao fork, acho um desastre e pelo pouco que vi não achei boas vantagens, a não ser que me provem o contrário. Pelo ponto de vista de utilizar o compartilhamento de instâncias, se uma cair todas cairão, então qual é a graça afinal ? Como se resolve este problema, acaba-se criando outros ?
ps: até acho interessante múltiplas threads para cada projeto, mas qual a principal aplicação disto ? o pessoal se revoltou com o garbage collection ? esse pessoal parece ter sofrido alguns problemas de escalabilidade resolvidos na tora pelos arquitetos do eBay
Eu sinceramente acharia que Method Delegates são uma feature muito legal que falicitaria a inclusao de closures…