[Java 7] As alterações aprovadas:

Assuntos Gerais Notícias
#81

[quote=JavaLivros][quote=sergiotaborda]
Espera-se que a equipe monte uma plataforma de aplicação em cima disso. E ai cada empresa pode montar a sua e proteger os seus investimentos. O uso de api de terceiros é uma opção a montar a sua plataforma de aplicação mas com o detalhe do vendor lock-in. [/quote]
Pergunto,

O MiddleHeaven framework futuramente, tende a ser um vendor lock-in ?
[/quote]

Sempre que você usa qualquer framework ou API nos seus projetos que não foi desenvolvida in house e/ou não é parte da JSE , JEE ou das outras edições padrão então, você já caiu no vendor lock-in. Deste ponto de vista sim.

Se você usa qualquer framework ou API que é opensource, então você pode pegá-lo e mantê-lo ( aquilo que se chama um fork). Claro que isso não é tão simples quanto parece, mas pelo menos não o deixará na mão. Desde ponto de vista não. Você não terá problemas com vendor-lock in. O MiddleHeaven tem licença BSD que é bastante flexivel.

#82

Acho muito legais todas as novidades…

Coisas novas nos fazem acreditar que Java, como linguagem, não está morta.

Java como plataforma, IMHO, está cada vez mais certo como um bom caminho, principalmente com cada vez mais linguagens suportadas em cima da JVM.
Já como linguagem, torço por cada vez mais simplicidade, assim como temos visto em Groovy, Rails, Scala…

Pras aplicações web, torço também por não ter mais que esperar por váaarios segundos por um redeploy da aplicação. :stuck_out_tongue:

Abraços.

#83

Olá:

Neste artigo Stephen Colebourne discute a sugestão de uma série de métodos utilitários para os pacotes java.util e java.lang baseado no Apache Commons Lang.

Grato,

#84

Continuo lamentando a ausência de closures nessa nova versão :frowning:
Mas confesso que, assim como muitos, era uma coisa que eu nem sentia falta, pois não conhecia. Já tinha usado em Scheme uma vez, quando ainda não havia esse “hype” em cima de closures.

Bem vindo de volta, Marcio Duran :smiley:

#85

"

#86

Resumindo: não quer ficar “locked in”? Crie sua própria linguagem, ferramentas, frameworks, compiladores, tudo… e pelamordedeolz pare de choradeira e mimimi.
PRONTOFALEIDENOVO.

#87

eu acho que o JAVA poderia ter uma forma de deixar o tipo byte unsigned… pq para comunicar com placas via udp, as vezes vc tem que enviar um valor que o tipo byte nao suporta… ai complica a vida

#88

Evite ressuscitar tópicos. Esse era de 2009.

Mas concordo com vc. No mínimo tinha que ter funções que fizessem a promoção ou redução de tipos maiores para seus respectivos unsigned nas classes de Stream e na classe ByteBuffer (como ter na própria classe ByteBuffer o que a classe ByteBufferWorker que postei no GUJ faz).

#89

Olá

Viva a diversidade de opiniões!

Eu por exemplo acho saudável ressuscitar tópicos que discutem temas ainda atuais e que não acabaram em trollagens. O Java 7 ainda não lançado mas que eu já estou usando depois de baixar em http://jdk7.java.net/preview/ (novas features em http://openjdk.java.net/projects/jdk7/features/ ), é um tema mais do que atual. Para mim foi bom trazer de volta todos os links aqui postados.

Quanto a sua pergunta, além da ótima resposta do Vini sobre os ByteBuffers, lembro que este tópico é uma antiga reinvidicação dos desenvolvedores Java como se pode ver pelo tanto de links que a gente encontra em http://www.google.com.br/search?q=java+unsigned

[]s
Luca

#90

Achei bem interessante a mudança do switch ficou bem mais amigável usar o if era triste.
Quanto as demais mudanças eu ainda não entendi, pois do java tiro apenas o arroz feijão.
Muito bom o post

#91

Excelente post.

#92

Alguém encontrou a parte que fala (se é que fala) da substituição de verificação por null pelo caracter “?”, como acontece no Grails? Assim

Olhando aqui não encontrei nada a respeito.

#93

Se não for o caso, torna-se irrelevante, dá para fazer assim:

O contrato de equals prescreve que qualquer chamada de equals com parâmetro nulo devolve falso, em outras palavras, NPE Free.

[quote=Andre Brito]Alguém encontrou a parte que fala (se é que fala) da substituição de verificação por null pelo caracter “?”, como acontece no Grails? Assim

Olhando aqui não encontrei nada a respeito.[/quote]

#94

Evite ressuscitar tópicos. Esse era de 2009.

Mas concordo com vc. No mínimo tinha que ter funções que fizessem a promoção ou redução de tipos maiores para seus respectivos unsigned nas classes de Stream e na classe ByteBuffer (como ter na própria classe ByteBuffer o que a classe ByteBufferWorker que postei no GUJ faz).
[/quote]

Eu já implementei rotina de ponto flutuante em Java onde utilizava todos os 32 bits do int e todos os 64 bits do long, ignorando o sinal. No Java basta ignorar o sinal do tipo se tudo o que você quer é utilizar operações de bit.

Todos os números em Java (e em diversos hardwares) são guardados no formato “complemento de 2”, ou seja, cada posição de bit é um peso diferente e a soma total dos pesos dá o valor do número. Por exemplo, 0x80, que vem logo após 0x7f, é -128 e por aí vai.

Na VM que criei uso bytes em um ByteBuffer para guardar as instruções, e uso todos os 8 bits do byte.

O sinal só é necessário para operações aritméticas, mas nesse caso um tipo mais largo como int seria o mais indicado. Quem usa byte, geralmente só quer passá-lo via rede ou utilizá-lo para algo baixo nível.

#95

[quote=chun]Posso estar errado… mas não ter inclusido closures foi a cagada do ano na tencologia java… talvez a maior dos ultimos anos…

[/quote]

Que nada. Closures são uma das coisas mais hypeadas nos últimos tempos, acho que quem acredita que isso é a solução para todos os problemas realmente não entende como funciona.

Closures nada mais são do que um objeto de pobre. Isto é, o ambiente léxico é como os campos de uma classe e o tal objeto tem apenas um método que não aceita argumentos. Não existe absolutamente nada que closure faça que não seja possível fazer com objetos.

Closure apenas simplifica o código em alguns casos, mas no Java, como eles não podem remover nada, acho que acabaria complicando ainda mais. Para tudo existiriam duas ou mais formas de se fazer.

Acho que seria melhor criar uma linguagem nova do zero ao invés de adicionar closure no Java.

#96

"

#97

Otima mudanças mesmo!

#98

Concordo, acho que é mais um Hype. Uso lambdas no C# e Ruby e programo sem problemas no Java 6 sem elas. Programação funcional está hypeado como disse o Longino, contudo acho que tem seu valor. As expressões usadas no JPA seriam mais simples, enxutas, e legíveis até, se fossem escritas com lambdas, bem como a implementação do padrão Strategy, onde hoje usamos interfaces (ver Comparator).

Também acho que inseriram muito Syntactic sugar, como a notação diamante, uso de índice para coleções, verificação de nulo, etc, em outras palavras, uma adição de facilidades para diminuir o Boilerplate Code (e consequentemente o código).

Penso que a promiscuidade (não entendam mal) atual dos programadores com linguagens (ver dica do Pragmatic Programmers: aprenda uma linguagem por ano) faz com que haja uma pressão por mudanças e um medo de perder espaço. Eu por exemplo me identifico muito com Java mas não sou Evangelista ao ponto de ficar cego (como muitos fazem) e me entrego “aos prazeres” de outras linguagens, plataformas, soluções.

Resumindo, acho que os releases do Java EE, do 1.4 para o 5 e depois para o 6 foram muito mais substanciais que as mudanças no Java SE (que são boas, nunca disse o contrário), equiparáveis a mudança do Java SE 1.4 para o 5, mas pouco expressivo do 5 para o 6 e agora do 6 para o 7.

[quote=marcosalex][quote=Longino]
Que nada. Closures são uma das coisas mais hypeadas nos últimos tempos, acho que quem acredita que isso é a solução para todos os problemas realmente não entende como funciona.

Closures nada mais são do que um objeto de pobre. Isto é, o ambiente léxico é como os campos de uma classe e o tal objeto tem apenas um método que não aceita argumentos. Não existe absolutamente nada que closure faça que não seja possível fazer com objetos.
[/quote]

Também penso assim sobre Closures. Não vejo como a vida dos programadores mudariam tanto quando o Java suportar closures. Em algumas poucas situações você vai digitar algumas linhas a menos de código, em outras vai ficar um código um pouco mais legível, mas nada revolucionário.

Essa briga de recursos me lembra os tempos de VB x Delphi, onde uma delas incorporava algum recurso pouco usado e usava isso como marketing, então a outra incorporava o mesmo recurso e adicionava outro ainda mais obscuro pra inverter a situação. No final ficaram duas linguagens totalmente cheia de coisas que ninguém usa, poluídas e confusas. Até chegar uma nova geração de linguagens com o intuito de simplificar a vida do desenvolvedor.

Agora com .NET x Java estou vendo a mesma coisa, e já está cheio de linguagens muito mais simples vindo na sequência. E a fila continua andando…
[/quote]

#99

Com essa nova versão do Java, vai sair uma nova certificação? Estou na faculdade e pretendo tirar minha primeira certificação. Devo tirar a SCJP 6 ou devo esperar a 7?

#100

Galera boa tarde,

Aproveitando o tópico, alguém viu se saiu alguma solução como o FileSystemWatcher no java 7?

Abraço.