Java 7 - Tempo demais por pouca coisa?

Assuntos Gerais
#1

Olá pessoal,

Procurei alguns tópicos sobre isso, mas não encontrei tanta coisa. Creio que seria legal uma discussão exata sobre o assunto.

Recentemente fui em um evento aonde um cidadão lá da Sun (que eu esqueci o nome, acho que era Samuel não sei o quê) apresentou as novidades do Java 7. Mas não sei, quase todas as coisas que ele apresentou eram coisas que se você for pensar não são tão trabalhosas em comparação com o tempo que o Java 7 consumiu.

Porquê isso? O que pensam sobre isso? Partilham da mesma opinião?

[]'s!

#2

[quote=AUser]Olá pessoal,

Procurei alguns tópicos sobre isso, mas não encontrei tanta coisa. Creio que seria legal uma discussão exata sobre o assunto.

Recentemente fui em um evento aonde um cidadão lá da Sun (que eu esqueci o nome, acho que era Samuel não sei o quê) apresentou as novidades do Java 7. Mas não sei, quase todas as coisas que ele apresentou eram coisas que se você for pensar não são tão trabalhosas em comparação com o tempo que o Java 7 consumiu.

Porquê isso? O que pensam sobre isso? Partilham da mesma opinião?
[/quote]

Ficou meio no ar isso ai… dê exemplos.

Lembre-se tb que o java 7 não tem uma jsr ao contrário do 6. Isso signifca menos organização e cada um correndo para um lado. Por outro lado, é o que não está no java 7 que deu trabalho e não o que está. A discussão de closures, por exemplo e sua relação à api de processamento paralelo. elas não estão diretamente relacionadas, mas na prática estão. (por isso estão voltando atrás com a ideia de não incluir closures). O alerta veio da comunidade, de discussões, blogs, em resumo do agito da comunidade (que imensa). E isso demora tempo.

A sun sempre primou pela qualidade das suas API e decisões de arquitetura. Isso vem de muito trabalho e muita conversação. O Java 7 é um marco no java porque apartir dele a jvm não será apenas do java e sim uma VM “agnostica” e isso é um passo do nivel do Java 2 vs java 1.1. É muito grande para ser rápido. Não é uma coisa de paixão. É uma coisa de consenso. E mesmo assim a sun está de cara “virada” (por não ter lançado uma jsr)

(Um dia .NET irá correr na JVM)

#3

[quote=sergiotaborda][…]

(Um dia .NET irá correr na JVM)[/quote]

Ai caramba! :shock:

Sérgio, concordo com você em cada palavra do post. Tenho acompanhado as discuções que envolvem o JDK e mesmo “demorando” tanto tempo não estou preocupado. Prefiro que os debates necessários sejam feitos e que tenhamos uma API com qualidade, assim como foi no JEE6.

#4

[quote=sergiotaborda]
A sun sempre primou pela qualidade das suas API e decisões de arquitetura.[/quote]

API do Java é imensa e conta com partes bem projetadas e outras que são dignas de piada. Assim como sua afirmação. Java 7 não traz nenhuma inovação e nem conserta as cagadas ja feita na API de datas por exemplo.

#5

[quote=sergiotaborda]
Lembre-se tb que o java 7 não tem uma jsr ao contrário do 6. Isso signifca menos organização e cada um correndo para um lado. [/quote]

Alguém tem idéia do porque??? Porque alguém pega um processo de engenharia de software (razoavelmente) bem estabelecido e simplesmente joga no lixo???

#6

[quote=asaudate][quote=sergiotaborda]
Lembre-se tb que o java 7 não tem uma jsr ao contrário do 6. Isso signifca menos organização e cada um correndo para um lado. [/quote]

Alguém tem idéia do porque??? Porque alguém pega um processo de engenharia de software (razoavelmente) bem estabelecido e simplesmente joga no lixo???[/quote]
Não to podendo responder com mais detalhes (quando chegar em casa eu respondo), mas que eu saiba, a grande maioria (pra não dizer todos - não tenho certeza) dos componentes do JEE 6 estão em uma JSR.

#7

O que quis dizer que o avanço para os programadores Java mesmo, nós, aqui da ponta, não foi tão grande coisa, algumas coisas que como aceitar String em Switch (que não sei como não haviam mudado antes). A melhor coisa que vi foi a performance do GC. Mas fora isso? Apenas mudanças para tornar a VM “agnóstica”.

#8

[quote=mochuara][quote=sergiotaborda]
A sun sempre primou pela qualidade das suas API e decisões de arquitetura.[/quote]

API do Java é imensa e conta com partes bem projetadas e outras que são dignas de piada. Assim como sua afirmação. Java 7 não traz nenhuma inovação e nem conserta as cagadas ja feita na API de datas por exemplo.[/quote]

Espero que vc ria muito com o seguinte…

Caso não saiba Java 7 é sobre : deixa qq linguagem rodar na jvm , mesmo que seja dinâmica.

Para isso ele introduz um bytecode novo. Vc lembra quando foi a ultima vez que um bytecode foi introduzido ? Pois é. Isso já lhe dá uma visão da importância, peso e responsabilidade do java 7.(aliás do jdk7)
O InvokeDynamic é a estrela do java 7. Outra estrela é performance. A JVM está mais rápida do que nunca.
E não apenas a jvm em si,mas o seus links nativos, a , por exemplo, a API de desenho sobre o Swing.

Se vc somar tudo o que está sendo feito na jvm, vc entende o objetivo dela: suportar JavaFX com um nivel de performance igual ou melhor que outras tecnologia “nativas”.
Alem disso o jdk não é apenas a jvm. Existem ferramentas sendo atualizadas como o javadoc, o pre-processador de anotações e o java plugin - que é a tecnologia responsável pelos applets e JWS, que foram fundidos num so, mais uma vez para melhorar o javaFX.

A API de tempo e datas está exatamente ai para prover uma melhor APi paras os desenvolvedores.
Ela não está sendo facilmente aceite porque - ao contrário do que o desenvolvedor junior pensa - trabahar com datas de forma internacionalizada é dificil e complexo.
O problema é exactamente esse. A sun sempre considerou que aPI deste tipo deveriam ser da responsabilidade dos programadores. Afinal trabalhar com datas envolve uma matemática séria que poderia virar uma API. E virou (joda time, money and time), api deste tipo seriam mandatorias em qq sistema. Mas a globalizção implica em questões de organização e eevolução temporal porque muita da dificuldade se prende com a geografia e a politica dos locais. A tabela de time-zones, por exemplo , depende da data (uma coisa temporal que depende de outra…).
Não é simples. E por isso a JSR de tempos está ai. ela é necessária.
Mas ela é necessária porque fizeram cagada antes? Não. É necessária porque a maioria dos desenvolvedores é preguiçoso (no mau sentido) ou simplesmente alienado para entender que precisa de uma API dessas. E pior, não a saberia escrever se precisasse. Ou seja, a JSR vem colmatar uma deficiência intelectual da comunidade ao mesmo tempo que melhora a SPI por detrás do mecanismo geocgrafico/politico - afinal isso depende dos updates regurares do JRE.

#9

[quote=asaudate][quote=sergiotaborda]
Lembre-se tb que o java 7 não tem uma jsr ao contrário do 6. Isso signifca menos organização e cada um correndo para um lado. [/quote]

Alguém tem idéia do porque??? Porque alguém pega um processo de engenharia de software (razoavelmente) bem estabelecido e simplesmente joga no lixo???[/quote]

O porquê é simples e tem nome :JavaFX

Esta nova plataforma java não é baseada na linguagem java. ele tem sua propria api, mas roda na mesma jvm.

O objetivo é simples: muda tudo o que for necessário para que o javaFX aniquile a concorrência onde ela existir.
As desculpas do costume (não é nativo, não é rápido, não integra com mecanismo gráfico) não vão pegar desta vez.

O invokeDinamic embora se passe a ideia que é para facilitar o ruby é na realidade para facilitar o javafx.
Todos os tweks de performance, muitos deles já nos updates 6 da jvm
Todo o projeto jigsw (load mais rápido)
Todo o rearrajo dos applets e do jws (fundidos pelo java plugin).

API de paralelismo , closures, time api, etc… é fichinha comparado com o impacto que as novas features da jvm vão dar no desenvolvimento web , dektop, tv e movel da decada vindoura.

E curiosidade, falamos do java 7, mas na realidade é o jdk7. Exatamente porque não ha jsr não ha especificação “formal” e isso facilita a alteração da jvm , mas complica a adoção das novas apis.

P.S. A JEE6 não tem nada a ver com o assunto. A JEE6 tem atualizações derivadas da introdução de anotations em servlets e outras coisas que já existem desde o java 5 (var arg por exemplo). além disso ha um alinhamento tecnologico com REST , assincronocidade, etc… mas nada que dependa directamente das novas features da jvm ( nem poderia, afinal essa é a diferença entre EE e SE)

#10

[quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
A sun sempre primou pela qualidade das suas API e decisões de arquitetura.[/quote]

API do Java é imensa e conta com partes bem projetadas e outras que são dignas de piada. Assim como sua afirmação. Java 7 não traz nenhuma inovação e nem conserta as cagadas ja feita na API de datas por exemplo.[/quote]

Espero que vc ria muito com o seguinte…

Caso não saiba Java 7 é sobre : deixa qq linguagem rodar na jvm , mesmo que seja dinâmica.

Para isso ele introduz um bytecode novo. Vc lembra quando foi a ultima vez que um bytecode foi introduzido ? Pois é. Isso já lhe dá uma visão da importância, peso e responsabilidade do java 7.(aliás do jdk7)
O InvokeDynamic é a estrela do java 7. Outra estrela é performance. A JVM está mais rápida do que nunca.
E não apenas a jvm em si,mas o seus links nativos, a , por exemplo, a API de desenho sobre o Swing.

Se vc somar tudo o que está sendo feito na jvm, vc entende o objetivo dela: suportar JavaFX com um nivel de performance igual ou melhor que outras tecnologia “nativas”.
Alem disso o jdk não é apenas a jvm. Existem ferramentas sendo atualizadas como o javadoc, o pre-processador de anotações e o java plugin - que é a tecnologia responsável pelos applets e JWS, que foram fundidos num so, mais uma vez para melhorar o javaFX.

A API de tempo e datas está exatamente ai para prover uma melhor APi paras os desenvolvedores.
Ela não está sendo facilmente aceite porque - ao contrário do que o desenvolvedor junior pensa - trabahar com datas de forma internacionalizada é dificil e complexo.
O problema é exactamente esse. A sun sempre considerou que aPI deste tipo deveriam ser da responsabilidade dos programadores. Afinal trabalhar com datas envolve uma matemática séria que poderia virar uma API. E virou (joda time, money and time), api deste tipo seriam mandatorias em qq sistema. Mas a globalizção implica em questões de organização e eevolução temporal porque muita da dificuldade se prende com a geografia e a politica dos locais. A tabela de time-zones, por exemplo , depende da data (uma coisa temporal que depende de outra…).
Não é simples. E por isso a JSR de tempos está ai. ela é necessária.
Mas ela é necessária porque fizeram cagada antes. é necessária porque a maioria dos desenvolvedores é preguiçoso (no mau sentido) ou simplesmente alienado para entender que precisa de uma API dessas. E pior, não a saberia escrever se precisasse. Ou seja, a JSR vem colmatar uma deficiência intelectual da comunidade ao mesmo tempo que melhora a SPI por detrás do mecanismo geocgrafico/politico - afinal isso depende dos updates regurares do JRE.

[/quote]

Melhor que o nativo não tem jeito de ficar. Swing já usa opengl na sua api de pintura e desenho. O que pode acontecer é a parte de alto nível ser otimizada. Mas o acesso as bibliotecas nativas sempre existirão, pois elas são essenciais.

Eu já ficaria feliz com a otimização do GC e o pinvoke. Na minha opinião isso fazia muita falta.

#11

Certo, entendo e concordo com você sergiotaborda em muitas coisas.

Mas e bem, quando diabos vão tirar o pé do acelerador do futuro e consertar o que está errado para trás? O exemplo mais clichê: API de data. Será que vai ficar tanto tempo quanto ficou sem String em Switch? São essas coisas que eu não entendo, a Sun dá um passo gigantesco pra mudar o bytecode da JVM, modo de leitura, etc, mas deixa coisas “pífias” comparadas a isso pra trás. Não sei, isso me cheira como fazer um prédio e deixar a parte de baixo com acabamento, a de cima perfeita, e a do meio faltando colocar os vidros…

[]'s!

#12

[quote=sergiotaborda]
(Um dia .NET irá correr na JVM)[/quote]

Tambem acredito nisso, mas chegaremos BEM atrasados:
http://www.ikvm.net/

#13

[quote=Paulo Silveira][quote=sergiotaborda]
(Um dia .NET irá correr na JVM)[/quote]

Tambem acredito nisso, mas chegaremos BEM atrasados:
http://www.ikvm.net/
[/quote]

O projeto mono ja utiliza ela. Eu não sei tem boa performance, pois nunca usei. Vou fazer um teste.

#14

[quote=sergiotaborda]
(Um dia .NET irá correr na JVM)[/quote]

Uma plataforma vai rodar em cima de outra plataforma? Cada idéia sem noção viu…

#15

[quote=AUser]Certo, entendo e concordo com você sergiotaborda em muitas coisas.

Mas e bem, quando diabos vão tirar o pé do acelerador do futuro e consertar o que está errado para trás? O exemplo mais clichê: API de data. Será que vai ficar tanto tempo quanto ficou sem String em Switch? São essas coisas que eu não entendo, a Sun dá um passo gigantesco pra mudar o bytecode da JVM, modo de leitura, etc, mas deixa coisas “pífias” comparadas a isso pra trás. Não sei, isso me cheira como fazer um prédio e deixar a parte de baixo com acabamento, a de cima perfeita, e a do meio faltando colocar os vidros…
[/quote]

Vc sabe onde data e tempo estão na api ? java.util
Embora importantes em muitos sentidos tudo o que está na util não é importante por si mesmo. É apenas um utilitário. Vc não precisa de java.util.List , vc pode escrever o seu ppr list ( vide apache collections). Mas é util que isso esteja na api padrão.Mas veja, a api padrão continua devolvendo arrays e não lists, collections ou sets…

Com date é o mesmo. Vc ainda não criou uma api para trabalhar com data e tempo corretamente ? a falha é sua, não da sun (como já expliquei antes). E nunca vai mudar. O util é para ser util, não para ser a lei. A sun não tem culpa se vc usa como se fosse a lei.

Remoção de coisas não vai acontecer … é uma das diretivas do java logo a seguir a “orientado a objetos”. É a mesma diretiva que nunca quebrou um codigo e nunca evitou que versões compiladas em vm antigas rodem em vm modernas. Vc quer que o java evolua como o .NET - sem retrocompatibilidade? eu não quero. e muita da comunidade tb não especialmente a comunidade da IBM, ORACLE, SAP…

Quer viver com quebras e api ? use .NET.
Quer longividade do seus componetes ( .class, jar,etc… ) use java.

#16

[quote=mochuara][quote=sergiotaborda]
(Um dia .NET irá correr na JVM)[/quote]

Uma plataforma vai rodar em cima de outra plataforma? Cada idéia sem noção viu…[/quote]
Em cima de outra não. Basta um compilador gerar cil ou bytecode.

#17

Ou seja, voce escreveu, escreveu e não disse qual o avanço que Java 7 trouxe em termos de linguagem. Usar strings no switch ? Oh grande coisa!

[quote=sergiotaborda]
blablabla… Mas ela é necessária porque fizeram cagada antes? Não. blablabla[/quote]

Calma. Eu só disse que a API do Java não é um sonho como vc disse a 5 minutos atras.

Voce acabou de reconhecer que fizeram cagada, portanto é uma contradição tua. Mas não precisa cortar os pulsos só porque vai ter que esperar o Java 8 pra ter uma misera API de Data decente.

#18

[quote=juliocbq][quote=mochuara][quote=sergiotaborda]
(Um dia .NET irá correr na JVM)[/quote]

Uma plataforma vai rodar em cima de outra plataforma? Cada idéia sem noção viu…[/quote]
Em cima de outra não. Basta um compilador gerar cil ou bytecode.[/quote]

E porque alguém fazer C# rodar na JVM ou Java rodar na CLR seria algo importante, vc esta trocando 6 por meia duzia, Java e C# são a mesma coisa, que mundo vcs vivem? Que tipo de grande problema essa solução pretende resolver?

#19

[quote=sergiotaborda][quote=asaudate][quote=sergiotaborda]
Lembre-se tb que o java 7 não tem uma jsr ao contrário do 6. Isso signifca menos organização e cada um correndo para um lado. [/quote]

Alguém tem idéia do porque??? Porque alguém pega um processo de engenharia de software (razoavelmente) bem estabelecido e simplesmente joga no lixo???[/quote]

O porquê é simples e tem nome :JavaFX

Esta nova plataforma java não é baseada na linguagem java. ele tem sua propria api, mas roda na mesma jvm.

O objetivo é simples: muda tudo o que for necessário para que o javaFX aniquile a concorrência onde ela existir.
As desculpas do costume (não é nativo, não é rápido, não integra com mecanismo gráfico) não vão pegar desta vez.

O invokeDinamic embora se passe a ideia que é para facilitar o ruby é na realidade para facilitar o javafx.
Todos os tweks de performance, muitos deles já nos updates 6 da jvm
Todo o projeto jigsw (load mais rápido)
Todo o rearrajo dos applets e do jws (fundidos pelo java plugin).

API de paralelismo , closures, time api, etc… é fichinha comparado com o impacto que as novas features da jvm vão dar no desenvolvimento web , dektop, tv e movel da decada vindoura.

E curiosidade, falamos do java 7, mas na realidade é o jdk7. Exatamente porque não ha jsr não ha especificação “formal” e isso facilita a alteração da jvm , mas complica a adoção das novas apis.

P.S. A JEE6 não tem nada a ver com o assunto. A JEE6 tem atualizações derivadas da introdução de anotations em servlets e outras coisas que já existem desde o java 5 (var arg por exemplo). além disso ha um alinhamento tecnologico com REST , assincronocidade, etc… mas nada que dependa directamente das novas features da jvm ( nem poderia, afinal essa é a diferença entre EE e SE)[/quote]

OK, mas isso não significa que isso tudo não poderia correr dentro de JSRs, certo? Lembrando que o tema do tópico é a velocidade que levou para o lançamento dessa nova jdk - o que, me parece , está diretamente relacionado ao fato de não ter JSRs.

#20

Isso não quer dizer que a Sun não poderia fazer uma API para facilitar a coisa. Quer dizer, EJBs remotos, por exemplo, têm sockets por trás - isso não quer dizer que todos que precisem usar as facilidades de remoting precisem implementar um mecanismo de invocação remota toda vez que precisem disso. O mesmo é válido para datas - OK, tem todo o mecanismo de internacionalização, e tudo mais… mas acredito que um número grande de projetos utilize sempre datas para um mesmo local (Locale). Assim, não seria mesmo interessante ter uma API para lidar com esse caso?