Então vc esta no caminho errado, tem que trabalhar com SAP que paga pelo menos 3x mais que Java, C#, Rails, onde minha namorada trabalha tem consultor que ganha mais de R$150 / hora.
[]s[/quote]
SAP não consegui entrar no mercado, mas se aparecer oportunidade, não vou dispensar “por amor ao Java”.
Conheço consultor Java que ganha 180/hora, mesmo assim não posso afirmar que é o que paga melhor, porque o cara é mais excessão do que regra.
[quote=mario.fts]Que bom que é no meio do ano né? da pra usar 6 meses antes do fim do mundo. 
Marque um X na opção com mais probabilidade de virar realidade:
[ ] Java 7
[ ] Gran Turismo 5
[ ] Duke Nuken Forever
Será que é tão dificil assim implementar estas mudanças ?
[/quote]
[X] Todas as alternativas acima
Eu acho que produtividade NÃO É TUDO, produtividade É UMA PARTE DO TUDO.
Quando alguem cria uma linguagem de programação é inevitável pensar e usar produtividade. Pois a nova linguagem irá tornar algum processo/tarefa mais produtiva ou não, quando o requisto é totalmente aquilo e pronto.
E a segurança de uma linguagem de programação é menos importante que a produtividade ? a performance ? a distribuição do sistema como um todo ?
Talvez estas novas linguagens dinâmicas, ou seja produtivas, tem um impacto para as pessoas de que tudo que tem de ser feito, tem de ser feito com a tal produtividade em primeiro lugar, sendo que este é o jeito certo e pronto! e isto na realidade não é verdade. Por isso que eu te disse, a minha opnião é que produtividade NÃO É TUDO!
Tem também o fato que todo mundo diz que programados são preguiçosos por natureza, logo pega-se um exemplo qualquer de produtividade em alguma instuição de qualquer linguagem por exemplo, ( o metodo ‘+’ da Class FixNum em Ruby) tem de ser analizado cada requisito de cada projeto. Se eu precisar de performance,segurança, etc. ? Do que adianta eu ter um excelente recurso com produtividade que é lento em comparação com outro recurso que não tem produtividade como prioridade? Ou seja, é preciso de velocidade na execução e não facilidade na hora de programar. Logo cada caso é um caso, por isso cada linguagem tem o seu propósito. Repito: Produtividade não é TUDO, é parte de um TUDO.
Voltando a primeira discussão, em nenhum momento eu quis dizer sobre produtividade e sim quis dizer sobre “fazer alguma coisa” até o Java 7 sair do forno.
[]'s
[quote=O Grande Bé]@fmamud
Eu não disse que 99% dos problemas dos programadores já é a produtividade. Eu disse q estudar APIs não vai resolver nossos problemas.
Mas já que você disse:
Tudo se resume a produtividade
Em java é possível fazer qualquer coisa que se faz em qualquer outra linguagem, com mais ou menos facilidade e mais ou menos rápido que outras linguagens. Facilidade acaba se convertendo em tempo e no final das contas produtividade.
Qualquer característica que ajuda o programador de qualquer forma, no final se converte em produtividade. Seja uma API simplificada, uma maneira mais “divertida” de programar, um jeito mais fácil de ganhar performance (afinal você não vai ficar 3 dias quebrando a cabeça pra deixar aquela rotina mais rápida)
Mesmo o argumento de que Java é uma plataforma largamente utilizada e é mais fácil de arrumar mão de obra especializada, da menos pau, e bla bla bla. Se resume em produtividade, linguagem menos utilizada DEMORA mais pra arrumar alguém e DEMORA mais pra corrigir um problema.
No final das contas, a produtividade é tudo.
Eu gostaria de um dia dizer ao meu computador com minha linguagem natural o que eu queria e ele elaborasse pra mim.[/quote]
[quote=fmamud]Eu acho que produtividade NÃO É TUDO, produtividade É UMA PARTE DO TUDO.
Quando alguem cria uma linguagem de programação é inevitável pensar e usar produtividade. Pois a nova linguagem irá tornar algum processo/tarefa mais produtiva ou não, quando o requisto é totalmente aquilo e pronto.
E a segurança de uma linguagem de programação é menos importante que a produtividade ? a performance ? a distribuição do sistema como um todo ?
Talvez estas novas linguagens dinâmicas, ou seja produtivas, tem um impacto para as pessoas de que tudo que tem de ser feito, tem de ser feito com a tal produtividade em primeiro lugar, sendo que este é o jeito certo e pronto! e isto na realidade não é verdade. Por isso que eu te disse, a minha opnião é que produtividade NÃO É TUDO!
[]'s
[/quote]
Não. São tão importantes quanto, concordo com vc. Acontece que a maioria destas “novas linguagens dinâmicas” (nem todas são dinâmicas e nem todas são tão novas assim!) rodam na JVM e portanto possuem a mesma performance, segurança, e distribuição que a linguagem Java tem. O que nos resta discutir então é aquilo que se diferencia, e na questão de produtividade não há qualquer dúvida que Java fica no chinelo.
Bom, em todo o caso, considero positivo que a Oracle esteja preocupada em acelerara a evolução da linguagem e plataforma, tornando-a mais competitiva.
Cara, acho que a alteração mesmo que eu queria era a questão dos exceptions.
Antes era assim:try{
//...
changeBirthDate();
} catch(DateFormatException dfe){
//...
}catch(NumberFormatException nfe){
//...
}E vai paratry{
//...
changeBirthDate();
} catch(DateFormatException | NumberFormatException ex){
//...
} Adeus mega blocos de catchs! 
[quote=jakefrog]Cara, acho que a alteração mesmo que eu queria era a questão dos exceptions.
Antes era assim:try{
//...
changeBirthDate();
} catch(DateFormatException dfe){
//...
}catch(NumberFormatException nfe){
//...
}E vai paratry{
//...
changeBirthDate();
} catch(DateFormatException | NumberFormatException ex){
//...
} Adeus mega blocos de catchs! [/quote]
Muito bom, vai ajudar pra caramba quanto for necessário realizar tratamentos idênticos a exceções diferentes!
[quote=fmamud]Eu acho que produtividade NÃO É TUDO, produtividade É UMA PARTE DO TUDO.
E a segurança de uma linguagem de programação é menos importante que a produtividade ? a performance ? a distribuição do sistema como um todo ?
[/quote]
Linguagem não tem performance, ela apenas descreve a lógica de um algoritmo. Quem dita desempenho de execução é o compilador, dependendo do quanto ele otimizou o código no resultado final, que é o assembly(independente de vm).
A função da linguagem é suprir uma ferramenta confortável a resolver determinado tipo de problema e nada além disso.
Segurança se refere a tipos de dados seguros? Se for, em uma linguagem como c é perfeitamente possível se criar esses tipos, mas ae caimos no conceito que estava citando - a produtividade.
serah q o eclipse vai travar tb nesta nova versao ? 
Se os desenvolvedores testarem nos builds novos antes, não. Agora, se ficarem esperando sair a versão nova pra só depois agirem…
Não porque já corrigiram o bug do nome do fornecedor da JVM (detalhe: só acontecia em Windows).
Se os desenvolvedores testarem nos builds novos antes, não. Agora, se ficarem esperando sair a versão nova pra só depois agirem…[/quote]
Quanto que você ganha para participar de todos os fórums e comentários? está em todos os lugares, br-linux e outros, sempre defendendo a Oracle, certeza que ganha da Oracle uma comissão.
Se os desenvolvedores testarem nos builds novos antes, não. Agora, se ficarem esperando sair a versão nova pra só depois agirem…[/quote]
Quanto que você ganha para participar de todos os fórums e comentários? está em todos os lugares, br-linux e outros, sempre defendendo a Oracle, certeza que ganha da Oracle uma comissão.[/quote]
ué. quem deveria testar são eles. a oracle fez muitos repensarem sobre o java. o desenvolvimento da plataforma/linguagem java vai continuar serio como era levado pela sun, ou vai ser apenas um joguete para os sapatos/shoooes e e outros ‘antenados’ das empresas da grama bem verde levantarem a bandeira q o java não deve ser usado antes de outras linguagens ?
a oracle eh uma empresa seria, mas nos desenvolvedores somos tratados como lixo por eles. isso tem q parar.
os produtos tem q ser bem testados e os prazos cumpridos. ou mata logo o java, ou declara q nao eh mais do interesse deles continuar. chega de patifaria, tricas e futricas.
E lá se vai outro flame. Concordo que foi um escorregão bem dado. Só não vejo porque ficarmos desmerecendo o Eclipse ou a Oracle ou qualquer outro só por causa disso. Principalmente quando isso não tem nada a haver com o tópico.
as críticas ajudam no processo de melhoria continua. 
Conserteza, grandes beneficios para nós desenvolvedores, vamos torcer para que o lançamento sai antes do previsto.
É isso aí. Faz anos que o Java vinha evoluindo devagar com a Sun, finalmente abriram o problema com os desenvolvedores e estão ouvindo a opinião pra discutir a evolução da linguagem E plataforma visando acelerar as mudanças.
E tem gente que ainda fica fazendo mimimi com a Oracle…
E para os profetas do apocalipse de plantão:
Aquisição da Sun pela Oracle foi a melhor coisa que poderia ter acontecido com o Java.
No meio ai desse monte de opiniões, uma do kicolobo aê é justamente o que eu penso:
[quote=“kicolobo”]Já uso o “Java 7” há um bom tempo. Se chama Groovy.
A tal “decadência do Java (linguagem)” pelo que posso ver, é muito mais relacionada a hype do que a fatos concretos. O que vejo é o surgimento de algumas linguagens com features bem bacanas, como Groovy, Scala, Clojure, JRuby comparadas com a linguagem Java.
O que eu pergunto é: será que eu realmente quero todos estes recursos na linguagem Java? Será que é REALMENTE uma boa entupir a linguagem de features só pra satisfazer o desejo (na minha opinião infantil) de “também tenho”? Afinal de contas, você pode mesclar linguagens em um projeto. Eu por exemplo tenho mesclado muito Clojure com Java em algo no qual venho trabalhado recenemente, aproveitando assim o melhor de dois mundos.
Sinceramente não vejo necessidade de mais recursos no Java (linguagem) após a versão 5. Se for pra pedir novas possibilidades, que estas sejam incluidas na JVM, pois assim satisfaz uma gama BEM MAIOR de desenvolvedores.
Mas no frigir dos ovos, Java é como o C do século XXI. Seu valor é inegável - você tem de ser muito ingênuo para ignorar - e você não é obrigado a trabalhar com ela. Mas que o bom conhecimento vai te fornecer um fundamento muito melhor sobre a plataforma, ah, isto vai.
(aliás, se for pra de fato satisfazer o desejo de ter mais e mais features na linguagem, a única alternativa é ir pro Lisp e seus derivados, aonde o programador inclui o que deseja na linguagem, sem precisar ficar dependendo do implementador padrão) [/quote]
Java tá bom do jeito que tá. Se ficar enxendo de coisa na linguagem só vai é ficar atrasando e o povo ficando puto. É muito tenso manter compatibilidade e adicionar recursos. Ou faz uma versão alternativa ou o pessoal continua a usar outras linguagens. Melhorar a JVM e implementar novas features em linguagens que realmente estão PREPARADAS para suportá-las é muito mais interessante que demorar 5 anos pra implementar uma gambiarra que não vai implementar um conceito em sua plenitude (vide Generics). Chega uma hora que não dá mais, algo como C/C++ fizeram. Apareceram com o tal de OO e queriam porque queriam botar de qualquer jeito no C, dai fizeram o C++. Alguns aqui podem me xingar, mas com certeza fazer uma linguagem do zero que tenha o conceito em sua essência é bem mais interessante do que “acoplar” conceitos que não foram propostos e arquitetados anteriormente. Certeza que vão ficar reclamando das closures do java 7 (ou 8) e comparando com as de Ruby ou de Groovy. E esses que estarão reclamando serão os mesmos que ficaram choramingando pra adicionarem as closures em java.