Java 7 - Tempo demais por pouca coisa?

Assuntos Gerais
#21

[quote=mochuara][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?[/quote]

Mochuara,

Rodar C# em uma JVM é algo de extrema importância já que um C# não roda nativamente em Linux. Agora imagina quanto se economizaria só em licenças aí? E nem é isso, performance é muito importante, também.

#22

[quote=AUser][quote=mochuara][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?[/quote]

Mochuara,

Rodar C# em uma JVM é algo de extrema importância já que um C# não roda nativamente em Linux. Agora imagina quanto se economizaria só em licenças aí? E nem é isso, performance é muito importante, também.[/quote]

Não entendi a questão da performance, poderia detalhar mais?

E quanto as licensas, quem escolhe C# sabe dos custos da licensa e que não vai rodar no linux. Se isso representasse algum problema eles não seriam clientes da MS primeiramente.

#23

[quote=mochuara][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?[/quote]

Java e C# são a mesma coisa como, amigo? São linguagens completamente diferentes. C# suporta ponteiros, sobrecarga de operadores, Delegates, Preprocessadores e muitas outras funcionalidades. Fora que poderia existir uma máquina virtual que entendesse cil ou bytecode, descartando o uso de duas vms em uma só máquina.

#24

Mochuara,

Eu passo por isso, e vou lhe mostrar. Aqui na empresa usamos um software da A2iA para reconhecimento de imagens, entretanto todas as DLLs deles só rodam em Windows, logo, nós somos obrigados a usar Windows pois dependemos da aplicação deles. Agora se eles rodassem em Linux, com ctz iamos botar em Linux pois perdemos no minimo 300 reais de licença a cada estação. A cada 100 estações, perdemos um carro popular equipado. As vezes somos reféns.

Performance pois, em alguns casos algumas aplicações rodam melhor em Linux que em Windows. Um exemplo são renderers 3d.

Ninguém desenvolve um software grande de forma independente. Logo, se um só usa Windows, você tem que usar Windows, é uma cadeia.

#25

[quote=sergiotaborda][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.[/quote]
Realmente segurança e liberdade são duas coisas que não combinam. O problema é tomarem uma direção que ninguém pediu, pois simplesmente foi empurrada. Veja o caso do javafx que você mesmo tinha comentado, ninguém quer saber daquilo. javafx é totalmente forçado e ainda por cima insistem em gastar tempo e esforço nessa direção. Mas depois que fazem a cagada, lá na frente usam a mesma desculpa que a sua: “O problema é de vocês”.

#26

[quote=AUser]Mochuara,

Eu passo por isso, e vou lhe mostrar. Aqui na empresa usamos um software da A2iA para reconhecimento de imagens, entretanto todas as DLLs deles só rodam em Windows, logo, nós somos obrigados a usar Windows pois dependemos da aplicação deles. Agora se eles rodassem em Linux, com ctz iamos botar em Linux pois perdemos no minimo 300 reais de licença a cada estação. A cada 100 estações, perdemos um carro popular equipado. As vezes somos reféns.

Performance pois, em alguns casos algumas aplicações rodam melhor em Linux que em Windows. Um exemplo são renderers 3d.

Ninguém desenvolve um software grande de forma independente. Logo, se um só usa Windows, você tem que usar Windows, é uma cadeia.[/quote]

Voce roda o sistema de reconhecimento de imagens em 100 estações? Vc trabalha no facebook?

Cara, se quiser podemos conversar, posso implementar reconhecimento-de-imagens-as-a-service pra vcs num final de semana desses.

#27

[quote=bobmoe][quote=sergiotaborda][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.[/quote]
Realmente segurança e liberdade são duas coisas que não combinam. O problema é tomarem uma direção que ninguém pediu, pois simplesmente foi empurrada. Veja o caso do javafx que você mesmo tinha comentado, ninguém quer saber daquilo. javafx é totalmente forçado e ainda por cima insistem em gastar tempo e esforço nessa direção. Mas depois que fazem a cagada, lá na frente usam a mesma desculpa que a sua: “O problema é de vocês”.[/quote]
Não acho que javafx tenha sido perda de tempo. O java precisava de algum recurso multimedia.

#28

[quote=juliocbq][quote=bobmoe][quote=sergiotaborda][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.[/quote]
Realmente segurança e liberdade são duas coisas que não combinam. O problema é tomarem uma direção que ninguém pediu, pois simplesmente foi empurrada. Veja o caso do javafx que você mesmo tinha comentado, ninguém quer saber daquilo. javafx é totalmente forçado e ainda por cima insistem em gastar tempo e esforço nessa direção. Mas depois que fazem a cagada, lá na frente usam a mesma desculpa que a sua: “O problema é de vocês”.[/quote]
Não acho que javafx tenha sido perda de tempo. O java precisava de algum recurso multimedia.[/quote]

sucesso total :? pra começar é só parar pra ver quanta dúvida e quanta gente curiosa sobre isso aqui no fórum…

#29

[quote=bobmoe][quote=juliocbq][quote=bobmoe][quote=sergiotaborda][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.[/quote]
Realmente segurança e liberdade são duas coisas que não combinam. O problema é tomarem uma direção que ninguém pediu, pois simplesmente foi empurrada. Veja o caso do javafx que você mesmo tinha comentado, ninguém quer saber daquilo. javafx é totalmente forçado e ainda por cima insistem em gastar tempo e esforço nessa direção. Mas depois que fazem a cagada, lá na frente usam a mesma desculpa que a sua: “O problema é de vocês”.[/quote]
Não acho que javafx tenha sido perda de tempo. O java precisava de algum recurso multimedia.[/quote]

sucesso total :? pra começar é só parar pra ver quanta dúvida e quanta gente curiosa sobre isso aqui no fórum…[/quote]

Você está se preocupando com popularidade de uma ferramenta. Se ninguém usa não seria exatamente um problema, e sim se algum dia você precisar de recursos multimedia para java e precisar usar, que é o meu caso.

Precisei reproduzir imagens cameras, e usando jmf, que usa vfw tinha a pior performance que vi na minha vida.
O javafx é acelerado no hardware e tem ótima performance, e consegui resolver meu problema.

#30

O JEE6 não pode ser uma das razões pelo atraso também?

#31

[quote=mochuara][quote=sergiotaborda]
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.
[/quote]

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]

Ou vc não entendeu ou vc está se fazendo desentendido.
Java seguido de um numero de versão designa uma plataforma, não uma linguagem.

O avanço não é na linguagem é na plataforma.

Mas se vc quer uma linguagem nova : javaFX script

#32

[quote=sergiotaborda][quote=mochuara][quote=sergiotaborda]
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.
[/quote]

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]

Ou vc não entendeu ou vc está se fazendo desentendido.
Java seguido de um numero de versão designa uma plataforma, não uma linguagem.

O avanço não é na linguagem é na plataforma.

Mas se vc quer uma linguagem nova : javaFX script

[/quote]

Ah, mas venhamos e convenhamos: apesar do puta esforço da Sun, estamos todos incrédulos (com razão) quanto ao futuro do javaFX.

#33

[quote=asaudate]

Ah, mas venhamos e convenhamos: apesar do puta esforço da Sun, estamos todos incrédulos (com razão) quanto ao futuro do javaFX. [/quote]

vai ser dificil mesmo correr atras do prejuizo do Flex…

#34

É… Só que se o JavaFX fornecer todo o artefato que o JSF (Ice) fornece (em relação com EJBs) e criar um arquivo pra download menor que os swfs do Flex, existem grandes chances de um pessoal usar ele pra aplicações empresariais. Alguém poderia me dar um exemplo de uma gigante que usa Flex num sistema empresarial?

[Editado]
Alguns livros de Flex ‘pressionam’ (no sentido de tentação) o desenvolvedor a começar a programar em ColdFusion, por exemplo. As facilidades de Flex com ColdFusion poderiam ser ‘refletidas’ com o JavaFX e Java. Seria uma boa maneira de ganhar mercado com o JavaFX.

#35

Acho que essa confusão de que o JavaFX é um tipo de flash só atrapalha. JavaFX é mais do que isso.
Ele é uma plataforma para multimedia, com tratamento de media. Som,video, animações.
Ele tem suporte nativo a REST, mas isso é apenas porque sempre os produtos da sun dão prioridade ao HTTP
o REST é o passo logico seguinte a HTTP.

Mas o objetivo do fx é mais que competir com flash. É ser uma plataforma de UI para qq lugar onde haja uma jvm.
O javacard 3.0 irá possuir servlets (servlets no seu ship de cartão de crétido, já imaginou?) e nada impede de meter uma applet lá (exceto o tamanho).
E applet é Fx.

Outro campo é a TV. TV interactiva é um fenomeno mundial e a sun precisa fornecer uma plataforma unificada para isso. É o write one, run on any display.
Esse é o principal objtivo, mas para que ele pegue as pessoas tem que usar e gostar do FX na web e no desktop ( gadget no desktop feito com Fx ?)
Mas os objetivos são maiores…

#36

[quote=sergiotaborda]Acho que essa confusão de que o JavaFX é um tipo de flash só atrapalha. JavaFX é mais do que isso.
Ele é uma plataforma para multimedia, com tratamento de media. Som,video, animações.
Ele tem suporte nativo a REST, mas isso é apenas porque sempre os produtos da sun dão prioridade ao HTTP
o REST é o passo logico seguinte a HTTP.

Mas o objetivo do fx é mais que competir com flash. É ser uma plataforma de UI para qq lugar onde haja uma jvm.
O javacard 3.0 irá possuir servlets (servlets no seu ship de cartão de crétido, já imaginou?) e nada impede de meter uma applet lá (exceto o tamanho).
E applet é Fx.

Outro campo é a TV. TV interactiva é um fenomeno mundial e a sun precisa fornecer uma plataforma unificada para isso. É o write one, run on any display.
Esse é o principal objtivo, mas para que ele pegue as pessoas tem que usar e gostar do FX na web e no desktop ( gadget no desktop feito com Fx ?)
Mas os objetivos são maiores…[/quote]

O problema de popularidade do jfx é apenas uma questão de tempo e adaptação. A maioria aqui do guj ainda nem sabe usar o jmf, e olha, que ele foi descontinuado a anos, além de nunca ter funcionado corretamente.

O jfx é muito robusto, e pelos benchmarks que andei fazendo já está melhor que o siverlight.

#37

E Flash não é isso também? Tem a plataforma (no caso do Flash \ Flex o Flash Player ou o Adobe Air) que suporta as tecnologias… É a mesma coisa. JavaFX e Silverlight são concorrentes do Flex… O Silverlight é crap. Vamos ver se o JavaFX consegue bater de frente (espero que consiga porque vai evoluir as duas tecnologias aí).

#38

E Flash não é isso também? Tem a plataforma (no caso do Flash \ Flex o Flash Player ou o Adobe Air) que suporta as tecnologias… É a mesma coisa. JavaFX e Silverlight são concorrentes do Flex… O Silverlight é crap. Vamos ver se o JavaFX consegue bater de frente (espero que consiga porque vai evoluir as duas tecnologias aí).[/quote]

Faz os benchmarks… É a melhor maneira de se escolher uma tecnologia para usar. Ou vir o que a media diz não é sensato, pois eles querem ibope e também querer vender seus produtos.


http://piliq.com/javafx/?p=943
http://www.taranfx.com/why-choose-javafx-how-to-code-benchmark-graphics-cpu-memory

#39

E Flash não é isso também? Tem a plataforma (no caso do Flash \ Flex o Flash Player ou o Adobe Air) que suporta as tecnologias… É a mesma coisa. JavaFX e Silverlight são concorrentes do Flex… O Silverlight é crap. Vamos ver se o JavaFX consegue bater de frente (espero que consiga porque vai evoluir as duas tecnologias aí).[/quote]

Faz os benchmarks… É a melhor maneira de se escolher uma tecnologia para usar. Ou vir o que a media diz não é sensato, pois eles querem ibope e também querer vender seus produtos.


http://piliq.com/javafx/?p=943
http://www.taranfx.com/why-choose-javafx-how-to-code-benchmark-graphics-cpu-memory[/quote]
entenda popularidade como mercado. vc vive disso.

#40

[quote=mochuara][quote=AUser]Mochuara,

Eu passo por isso, e vou lhe mostrar. Aqui na empresa usamos um software da A2iA para reconhecimento de imagens, entretanto todas as DLLs deles só rodam em Windows, logo, nós somos obrigados a usar Windows pois dependemos da aplicação deles. Agora se eles rodassem em Linux, com ctz iamos botar em Linux pois perdemos no minimo 300 reais de licença a cada estação. A cada 100 estações, perdemos um carro popular equipado. As vezes somos reféns.

Performance pois, em alguns casos algumas aplicações rodam melhor em Linux que em Windows. Um exemplo são renderers 3d.

Ninguém desenvolve um software grande de forma independente. Logo, se um só usa Windows, você tem que usar Windows, é uma cadeia.[/quote]

Voce roda o sistema de reconhecimento de imagens em 100 estações? Vc trabalha no facebook?

Cara, se quiser podemos conversar, posso implementar reconhecimento-de-imagens-as-a-service pra vcs num final de semana desses.[/quote]

Mochuara,

Obviamente não, não trabalho no Facebook e em alguns casos é interessante processar o reconhecimento de imagens no cliente. Porquê? Pois, se a sua rede é limitada (redes bancárias por exemplo, tem uma agência lá no meio do Rio Amazonas que só tem internet por satélite) e o tráfego não pode ser alto, compensa mais processar no cliente e julgar se a imagem está boa para enviar ao servidor ou não. E além disso você distribui o processamento que iria pra uma máquina só em várias.

Mas, como você consegue implementar um reconhecimento-de-imagens-as-a-service em um final de semana, deveria saber disso pelo menos. Agora engraçado é que temos gente que é muito boa em redes neurais, documentos bancários aqui, etc, e só essa parte demorou no mínimo 6 meses pra chegar no estágio que está.