Java 7 - Tempo demais por pouca coisa?

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?

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)

sergiotaborda:

[…]

(Um dia .NET irá correr na JVM)

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.

sergiotaborda:

A sun sempre primou pela qualidade das suas API e decisões de arquitetura.

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.

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.

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???

asaudate:

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.

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???

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”.

mochuara:

sergiotaborda:

A sun sempre primou pela qualidade das suas API e decisões de arquitetura.

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.

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.

asaudate:

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.

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???

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)

sergiotaborda:

mochuara:

sergiotaborda:

A sun sempre primou pela qualidade das suas API e decisões de arquitetura.

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.

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.

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.

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!

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

Paulo Silveira:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

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

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

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…

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.

mochuara:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

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!

sergiotaborda:

blablabla… Mas ela é necessária porque fizeram cagada antes? Não. blablabla

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.

juliocbq:

mochuara:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

Em cima de outra não. Basta um compilador gerar cil ou bytecode.

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?

sergiotaborda:

asaudate:

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.

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???

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)

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.

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?

mochuara:

juliocbq:

mochuara:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

Em cima de outra não. Basta um compilador gerar cil ou bytecode.

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?

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.

AUser:

mochuara:

juliocbq:

mochuara:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

Em cima de outra não. Basta um compilador gerar cil ou bytecode.

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?

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.

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.

mochuara:

juliocbq:

mochuara:

sergiotaborda:

(Um dia .NET irá correr na JVM)

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

Em cima de outra não. Basta um compilador gerar cil ou bytecode.

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?

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.

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.

sergiotaborda:

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…

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.

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.

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.

bobmoe:

sergiotaborda:

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…

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.

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”.

juliocbq:

bobmoe:

sergiotaborda:

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…

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.

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”.

Não acho que javafx tenha sido perda de tempo. O java precisava de algum recurso multimedia.

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

bobmoe:

juliocbq:

bobmoe:

sergiotaborda:

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…

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.

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”.

Não acho que javafx tenha sido perda de tempo. O java precisava de algum recurso multimedia.

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

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.

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

mochuara:

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.

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!

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

sergiotaborda:

mochuara:

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.

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!

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

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

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.

vai ser dificil mesmo correr atras do prejuizo do Flex…

É… 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.

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…

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…

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.

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í).

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í).

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.

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í).

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.

mochuara:

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.

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.

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á.

O motivo da demora é o que o Sergio falou: eles mudaram muito nas APIs internas pra melhorar a performance, modularizar a JVM e permitir rodar outras linguagens sob a VM. E aproveitaram pra realizarem outras mudanças menores na linguagem.

Por mais que os desenvolvedores queiram, as mudanças no Java nunca vão ser ágeis como as mudanças no .NET, principalmente porque a MS só tem de atender o Windows, enquanto a Sun com o Java tem de atender uma infinidade de plataformas, de SOs para desktop, servidores até celulares, cartão e TV digital.

Da mesma forma que o W3C também demora muito mais, porque o HTML tem de atender mais plataformas que o Java. Tanto que a versão 5 começou em 2002 e a previsão para o padrão sair é 2012. Os browsers que estão anunciando serem ‘compatíveis’, atendem o draft da especificação. Se ela mudar até a versão final, os navegadores ou vão ter de remendar, ou não vão abrir as páginas foram feitas de acordo com os navegadores de hoje.

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í).

Não. Flash não é isso.
Em flash não ha promessa de rodar em celular, pda, TV … flash não é omnipresente. JavaFx será.

Vc pode argumentar que a adobe poderia evoluir o flash para rodar nesses lugares, mas ai seria a adobe correndo atrás da sun. A sun está lançando uma coisa com visão de futuro. A adobe “só agora” despertou para a ideia do flex.
Ou seja, ela acordou para o fato de que poderia usar flash em ambiente coorporativo em não apenas para entretenimento. O JavaFX já nasce para ser tudo isso e mais.

Se fossem ágeis como seria bom. Se fossem como seria um nojo.

sergiotaborda:

Não. Flash não é isso.
Em flash não ha promessa de rodar em celular, pda, TV … flash não é omnipresente. JavaFx será.

O Flex existe a mais tempo que o JavaFX.

Respeito a tua opinião. Mas não sejamos xiitas: JavaFX tem um longo caminho até chegar ao que o Flex / Flash faz hoje. Eu realmente espero que o JavaFX dê certo (e tenho crença de que dará)… Flex com Java não to achando muito interessante quando uso EJBs… Não sei porque, mas não to gostando bastante no cliente… Acho que pra aplicações pequenas ou aplicações na intranet, Flex é perfeito. Pra aplicações web, já é outros quinhentos (aplicações empresariais, comerciais, de nota fiscal e coisa do tipo).

Sei lá cara, minha opinião. Respeitei a tua, você podia respeitar a minha e não ficar falando mal da Adobe assim.

sergiotaborda, como assim? Você quer dizer que Flash não é uma plataforma de multimídia? Flash é a melhor tecnologia pra Streaming de vídeo, a melhor para animação bidimensional e está começando a parte tridimensional.

A Adobe não despertou só agora para o Flex, a questão é que o Flex surgiu desde a versão 6 do FP, mas era um projeto aberto e de muitos testes. A Adobe comprou a Macromedia justamente pra isso, pra poder desenvolver esse lado mais comercial do Flash.

Sergiotaborda, não entendi isso de “a Adobe só despertou agora”. A Adobe comprou a Macromedia justamente por isso, e olha que já fazem anos…

Se fossem ágeis como seria bom. Se fossem como seria um nojo.

Não vamos cair na picuinha de “Minha linguagem é melhor que a sua”. Eu pelo menos já provei um pouquinho de .NET e realmente o bicho é legal. Gosto das duas.

Andre Brito:

Sei lá cara, minha opinião. Respeitei a tua, você podia respeitar a minha e não ficar falando mal da Adobe assim.

Bom André, ai discordo de você.

Falar mal da Adobe é o mínimo a se fazer. Essa política dela de favorecer aplicações pequenas e deixar as realmente big enterprises cheias de gambiarras é ridícula. Nem o desempenho nem a arquitetura do FP favorecem grandes aplicações. Gosto muito de Flex/Flash, mas a Adobe realmente é foda com isso. Série de bugs que existem desde o início e simplesmente esquecem que existem, ou melhor, não consertam.

[]'s!

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í).

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.

É você quem está dizendo isso. No meu trabalho se preza mais qualidade, e não popularidade. Se for escolher uma linguagem ou plataforma para desenvolver, é melhor já ter tido contato com ela, e não porque a mesma é pop.

É mesmo… Um dos fracos da Adobe eu diria que é esse. Mas eu não falei com muita base porque nunca provei ColdFusion com Flex. Se marcar, as tecnologias ‘casam’ melhor, sendo possível fazer aplicações empresariais melhores.

É mesmo… Um dos fracos da Adobe eu diria que é esse. Mas eu não falei com muita base porque nunca provei ColdFusion com Flex. Se marcar, as tecnologias ‘casam’ melhor, sendo possível fazer aplicações empresariais melhores.

O flash realmente é ideal para aplicações casuais. Mas tentaram fazer algo mais robusto como o jogo Dofus, e na minha opinião não ficou legal (falando de Performance, Consumo de Memória).

AUser:

Bom André, ai discordo de você.

Falar mal da Adobe é o mínimo a se fazer. Essa política dela de favorecer aplicações pequenas e deixar as realmente big enterprises cheias de gambiarras é ridícula. Nem o desempenho nem a arquitetura do FP favorecem grandes aplicações. Gosto muito de Flex/Flash, mas a Adobe realmente é foda com isso. Série de bugs que existem desde o início e simplesmente esquecem que existem, ou melhor, não consertam.

[]'s!

Pq é o mínimo a se fazer?
Só porque a Adobe não quer o mercado big enterprise?
Acho isso um direito dela. Se ela não quer ganhar rios de dinheiros com grandes empresas, mas prefere ganhar rios de dinheiro com empresas menores, é escolha dela.
Só não culpem a Adobe porque um gerente acéfalo resolveu que o sistema que ele está bolando vai ter que ser feito em Flex.

Obs.: acho que tomei as dores do xará André eheh

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Se fossem ágeis como seria bom. Se fossem como seria um nojo.

Não vamos cair na picuinha de “Minha linguagem é melhor que a sua”. Eu pelo menos já provei um pouquinho de .NET e realmente o bicho é legal. Gosto das duas.
Nada contra a linguagem (apesar de eu preferir linguagens multiplataformas), mas sim contra as atualizações: problemas de retrocompatibilidade e coisas do gênero. A Sun nunca fez isso com o Java. Já no caso da MS com suas linguagens isso é comum.

clone_zealot:

AUser:

Bom André, ai discordo de você.

Falar mal da Adobe é o mínimo a se fazer. Essa política dela de favorecer aplicações pequenas e deixar as realmente big enterprises cheias de gambiarras é ridícula. Nem o desempenho nem a arquitetura do FP favorecem grandes aplicações. Gosto muito de Flex/Flash, mas a Adobe realmente é foda com isso. Série de bugs que existem desde o início e simplesmente esquecem que existem, ou melhor, não consertam.

[]'s!

Pq é o mínimo a se fazer?
Só porque a Adobe não quer o mercado big enterprise?
Acho isso um direito dela. Se ela não quer ganhar rios de dinheiros com grandes empresas, mas prefere ganhar rios de dinheiro com empresas menores, é escolha dela.
Só não culpem a Adobe porque um gerente acéfalo resolveu que o sistema que ele está bolando vai ter que ser feito em Flex.

Obs.: acho que tomei as dores do xará André eheh

É o mínimo sim a se fazer, pois não sei se você já viu alguma palestra da Adobe ou os vídeos, defendem que o FP suporta qualquer tipo de aplicação, tanto pequenas quanto aplicações enormes. Se falassem “olha, nós não queremos o mercado dos bigs” seria um grande tiro no pé. Ou você acha que pega bem uma empresa ser honesta sobre isso nesse ponto? Ele tem que bater no peito e falar “EU CONSIGO.”

A questão que me irrita na Adobe é a venda que eles colocam em cima dos bugs antigos relativos as coisas básicas como impressão, os problemas de imagem, não ter quase nenhum decoder decente de imagens, os problemas de event dispatching e arquitetura porca que colocaram em cima disso, e ficarem sempre em cima do muro quando a questão é 3d, entre várias outras coisas.

Quer ver um exemplo simples disso? Temos uma situação aqui que precisamos ler um TIFF. Só que o TIFF é bitonal e usa compressão. Vá ver se algum componente da Adobe suporta um TIFF desses. Não, não suporta e não fazem a menor questão. Agora são coisas simples que, se eles defendem que o FP serve para grandes empresas eles deveriam pensar. E porquê não fazem? Simples, o FP não tem essa capacidade de processamento, e não há nada no Framework interno sobre isso quase.

Não entendi essa do gerente acéfalo, visto que Flash, é em tese apenas para View (embora eu já tenha visto um GRID rodando em FP, acreditem, um GRID!).

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Em 2022 vai cair como uma luva?

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Em 2022 vai cair como uma luva?
Não, em 2012 a versão final. Mas já pode ser conferido em alguns lugares. O HTML 5 está mais próximo do que parece.

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Em 2022 vai cair como uma luva?
Não, em 2012 a versão final. Mas já pode ser conferido em alguns lugares. O HTML 5 está mais próximo do que parece.

Sei não, qualquer coisa que tenha a ver com Browser eu encaro com ceticismo… Li em um tópico esses dias do GUJ aqui alguém falando e dando os links que a galera já está entrando em desacordo com relação aos padrões do HTML 5.

[OFF] uma pergunta por curiosidade, teu nick é por causa do álbum do Rush? 2112?

[]'s

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Flash é monomídia. Ela pode ser a melhor tecnologia pra fazer menuzinho animado e streaming de porno, mas é pra desktop browsers com plugin instalado, e isso é tudo. Tão multimidia quanto a TV la de casa.

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Em 2022 vai cair como uma luva?
Não, em 2012 a versão final. Mas já pode ser conferido em alguns lugares. O HTML 5 está mais próximo do que parece.

Sei não, qualquer coisa que tenha a ver com Browser eu encaro com ceticismo… Li em um tópico esses dias do GUJ aqui alguém falando e dando os links que a galera já está entrando em desacordo com relação aos padrões do HTML 5.

[OFF] uma pergunta por curiosidade, teu nick é por causa do álbum do Rush? 2112?

[]'s
Não sei o porque do ceticismo… mais simples e funcional que isso, não dá: você abre a página, o vídeo aparece. Nada de plugins, carregamento do player, etc… e, convenhamos, já está sendo adotado (em fase de teste, mas está) por sites como o YouTube para substituir o FP. Se a função do Flash era fazer streaming de vídeo, ele vai servir pra que agora? Jogos casuais? Está cheio de Java Applets com isso por aí…

[OFF] Resposta: não! Absolutamente nada a ver… nem sei do que se trata!

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Flash é monomídia. Ela pode ser a melhor tecnologia pra fazer menuzinho animado e streaming de porno, mas é pra desktop browsers com plugin instalado, e isso é tudo. Tão multimidia quanto a TV la de casa.

Com essa arrogância toda até parece o Thiagosc, só que sem os bons argumentos que ele tinha as vezes.

Como já lhe disse uma vez em outro tópico e que no mesmo tópico você disse que não tinha experiência com Flash, Flash não é somente pra fazer menuzinho e streaming de pornô, se for aliás a única forma de vídeo que você viu na internet eu já lhe digo: tá mal. O streaming dele é a melhor tecnologia que tem.

Todos os browsers tem a opção de instalar o plugin apenas dando next, e é um plugin muito pequeno. Não volte a decadas passadas dizendo que é um grande problema precisar de acesso a internet para a última versão.

E aliás, se você só pensa em Flash como streaming pornô e menuzinhos, abre a cabeça.

Outra coisa, diga aí, então, qual opção é melhor?

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Em 2022 vai cair como uma luva?
Não, em 2012 a versão final. Mas já pode ser conferido em alguns lugares. O HTML 5 está mais próximo do que parece.

Sei não, qualquer coisa que tenha a ver com Browser eu encaro com ceticismo… Li em um tópico esses dias do GUJ aqui alguém falando e dando os links que a galera já está entrando em desacordo com relação aos padrões do HTML 5.

[OFF] uma pergunta por curiosidade, teu nick é por causa do álbum do Rush? 2112?

[]'s
Não sei o porque do ceticismo… mais simples e funcional que isso, não dá: você abre a página, o vídeo aparece. Nada de plugins, carregamento do player, etc… e, convenhamos, já está sendo adotado (em fase de teste, mas está) por sites como o YouTube para substituir o FP. Se a função do Flash era fazer streaming de vídeo, ele vai servir pra que agora? Jogos casuais? Está cheio de Java Applets com isso por aí…

[OFF] Resposta: não! Absolutamente nada a ver… nem sei do que se trata! :)

Uma tecnologia como essa demora anos pra ser realmente adotada e embarcada. Vai demorar muito até vermos isso funcionando. Talvez eu já tenha até um filho quando isso começar a funcionar.

Isso é um assunto bastante complexo e longo, a VM do FP é extremamente leve e cheia de truques, mas já que é só baixar e já executar com HTML 5, não vejo o porquê ele baixar a VM uma vez e executá-la. E com certeza vão mudar tanto a forma do instalador do FP quanto a forma de visualização. Existem testes bem complexos de 3d sendo feitos por aí com o FP e extremamente leves.

Veja: http://www.google.com.br/#hl=pt-BR&source=hp&q=frameworks+3d+flash&btnG=Pesquisa+Google&meta=&aq=f&oq=frameworks+3d+flash&fp=c192aad691e49f48

http://tankionline.com/ -> Jogo em Flash.

E olha que tem coisas bem melhores que estas que estão aí na Index.

AUser:

…
Uma tecnologia como essa demora anos pra ser realmente adotada e embarcada. Vai demorar muito até vermos isso funcionando. Talvez eu já tenha até um filho quando isso começar a funcionar.

Isso é um assunto bastante complexo e longo, a VM do FP é extremamente leve e cheia de truques, mas já que é só baixar e já executar com HTML 5, não vejo o porquê ele baixar a VM uma vez e executá-la. E com certeza vão mudar tanto a forma do instalador do FP quanto a forma de visualização. Existem testes bem complexos de 3d sendo feitos por aí com o FP e extremamente leves.

Veja: http://www.google.com.br/#hl=pt-BR&source=hp&q=frameworks+3d+flash&btnG=Pesquisa+Google&meta=&aq=f&oq=frameworks+3d+flash&fp=c192aad691e49f48

http://tankionline.com/ -> Jogo em Flash.

E olha que tem coisas bem melhores que estas que estão aí na Index.

Quanto ao 3D, como você mesmo disse, são testes. Ainda sofrem problemas como performance baixa, alto consumo de recursos e projetos muito imaturos na sua maioria. Essa sim é uma área que, sinceramente, não consigo enxergar a Adobe dominando, pelo menos nos próximos 5 anos (e até acontecer, se acontecer, com certeza vai ter muita concorrência à altura).

PS: esse jogo que você me passou o link demora bastante para carregar… espero que realmente valha a pena.

AUser:

sergiotaborda, como assim? Você quer dizer que Flash não é uma plataforma de multimídia? Flash é a melhor tecnologia pra Streaming de vídeo, a melhor para animação bidimensional e está começando a parte tridimensional.

pois…claro… Vc tem um video para processar no servidor e capturar o primeiro frame para fazer um thumbnail. Vc faz com flash. Não me lembrei disso…

A Adobe não despertou só agora para o Flex, a questão é que o Flex surgiu desde a versão 6 do FP, mas era um projeto aberto e de muitos testes. A Adobe comprou a Macromedia justamente pra isso, pra poder desenvolver esse lado mais comercial do Flash.

Sergiotaborda, não entendi isso de “a Adobe só despertou agora”. A Adobe comprou a Macromedia justamente por isso, e olha que já fazem anos…

Vamos lá a ver… O que eu quiz dizer é que a concorrência com o flash é apenas circunstancial. Eles não foram feitos para resolver o mesmo tipo de problemas. Vc pode usar o Fx para criar o mesmo tipo de coisas que o flash e o flex fazem mas isso é uma “coincidência”. Mais do que isso, se vc criar uma applet hoje, amanhã ela poderá rodar na TV. Este tipo de flexibilidade não existe no Flash.

O fato do flash e flex existirem ha mais tempo não importa nada. Importa quem vai existir daqui a 5 , 10 anos.
O BMP é mais antigo que o GIF , mas hoje se usa PNG.

O fato de uma versão simplificada do flash ou do flex rodarem em celulares apenas é indicativo da limitação da plataforma subjacente. O Fx não terá esse problema.

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Flash é monomídia. Ela pode ser a melhor tecnologia pra fazer menuzinho animado e streaming de porno, mas é pra desktop browsers com plugin instalado, e isso é tudo. Tão multimidia quanto a TV la de casa.

Com essa arrogância toda até parece o Thiagosc, só que sem os bons argumentos que ele tinha as vezes.

Como já lhe disse uma vez em outro tópico e que no mesmo tópico você disse que não tinha experiência com Flash, Flash não é somente pra fazer menuzinho e streaming de pornô, se for aliás a única forma de vídeo que você viu na internet eu já lhe digo: tá mal. O streaming dele é a melhor tecnologia que tem.

Todos os browsers tem a opção de instalar o plugin apenas dando next, e é um plugin muito pequeno. Não volte a decadas passadas dizendo que é um grande problema precisar de acesso a internet para a última versão.

E aliás, se você só pensa em Flash como streaming pornô e menuzinhos, abre a cabeça.

Outra coisa, diga aí, então, qual opção é melhor?

Voce tem algum problema com o portugues? Eu apenas respondi que flash não é multimídia pelo fato de não rodar em diferentes midias, o que é obvio, por isso a minha pergunta. FlashLite? Faça-me o favor, a base instalada disso é insignificante.

sergiotaborda:

AUser:

sergiotaborda, como assim? Você quer dizer que Flash não é uma plataforma de multimídia? Flash é a melhor tecnologia pra Streaming de vídeo, a melhor para animação bidimensional e está começando a parte tridimensional.

pois…claro… Vc tem um video para processar no servidor e capturar o primeiro frame para fazer um thumbnail. Vc faz com flash. Não me lembrei disso…

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Java fx trouxe para o java um suporte multimedia robusto. Até então, toda api de media que existia para java eram mapeamentos ou bibliotecas adaptadas e que não funcionavam bem, como jmf.

Como o sergio falou, a área de atuação do fx é e será muito mais ampla que o flash player.
Mas como streamming de vídeo vou concordar que o fp realmente é muito bom, senão o melhor que existe hoje. O java fx não tem suporte a vídeo, ainda, e todas as minhas experiências foram mapeando directshow para capturar vídeo, e javafx para pintar os quadros. Tive ótimos resultados.

http://www.humatic.de/htools/dsj.htm

Por ser uma das poucas que funcionam em um browser. HTML 5 vai cair como uma luva nessa área.

Flash é monomídia. Ela pode ser a melhor tecnologia pra fazer menuzinho animado e streaming de porno, mas é pra desktop browsers com plugin instalado, e isso é tudo. Tão multimidia quanto a TV la de casa.

Com essa arrogância toda até parece o Thiagosc, só que sem os bons argumentos que ele tinha as vezes.

Como já lhe disse uma vez em outro tópico e que no mesmo tópico você disse que não tinha experiência com Flash, Flash não é somente pra fazer menuzinho e streaming de pornô, se for aliás a única forma de vídeo que você viu na internet eu já lhe digo: tá mal. O streaming dele é a melhor tecnologia que tem.

Todos os browsers tem a opção de instalar o plugin apenas dando next, e é um plugin muito pequeno. Não volte a decadas passadas dizendo que é um grande problema precisar de acesso a internet para a última versão.

E aliás, se você só pensa em Flash como streaming pornô e menuzinhos, abre a cabeça.

Outra coisa, diga aí, então, qual opção é melhor?

Voce tem algum problema com o portugues? Eu apenas respondi que flash não é multimídia pelo fato de não rodar em diferentes midias, o que é obvio, por isso a minha pergunta. FlashLite? Faça-me o favor, a base instalada disso é insignificante.

Apenas respondeu isso? Então você tem algum problema de amnésia. A parte de “menuzinho” e filme pornô não foi apenas parte da resposta.

Quem falou de Flashlite aqui?

E celular não é outro tipo de mídia?

Isso não faz sentido. Que eu saiba “formato” diz respeito à organização dos bits dentro do arquivo. BMP , GIF e PNG são diferentes na sua organização de bits, logo não formatos diferentes. BMP = Bit Map. O formato é simples, cada elemento é uma cor (dependendo da codificação o elemento pode ter 2, 2^8 , 2^16 ou 2^34 bits). GIF = Graphics Interchange Format , ele tem um cabeçalho com as cores e um vários corpos. Várias imagems cabem dentro de um gif. Ele aceita um numero limitado de cores (255). alem disso usa um algoritmo de compactação (como o zip).
O PNG = Portable Network Graphic suporte o canal alfa (RGBA) que nenhum dos outros suporta.

Não entendo como vc poder dizer que é tudo a mesma coisa.

sergiotaborda:

juliocbq:

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Isso não faz sentido. Que eu saiba “formato” diz respeito à organização dos bits dentro do arquivo. BMP , GIF e PNG são diferentes na sua organização de bits, logo não formatos diferentes. BMP = Bit Map. O formato é simples, cada elemento é uma cor (dependendo da codificação o elemento pode ter 2, 2^8 , 2^16 ou 2^34 bits). GIF = Graphics Interchange Format , ele tem um cabeçalho com as cores e um vários corpos. Várias imagems cabem dentro de um gif. Ele aceita um numero limitado de cores (255). alem disso usa um algoritmo de compactação (como o zip).
O PNG = Portable Network Graphic suporte o canal alfa (RGBA) que nenhum dos outros suporta.

Não entendo como vc poder dizer que é tudo a mesma coisa.

Eu disse que os outros formatos nada mais são que o bmps codificados. Não disse que são iguais. O bmp é um dib (device independent bitmap). Ele é mais que um formato, é um padrão para sistemas microsoft e os/2.

O avi segue a mesma idéia, assim como o wav.

Esse aqui é o datasheet do bmp.

Quando você converte um gif ou um png para bmp, na verdade está decodificando, e não codificando.

The compression method field (bytes #30-33) can have the following values:
Value Identified by Compression method Comments
0 BI_RGB none Most common
1 BI_RLE8 RLE 8-bit/pixel Can be used only with 8-bit/pixel bitmaps
2 BI_RLE4 RLE 4-bit/pixel Can be used only with 4-bit/pixel bitmaps
3 BI_BITFIELDS Bit field Can be used only with 16 and 32-bit/pixel bitmaps.
4 BI_JPEG JPEG The bitmap contains a JPEG image
5 BI_PNG PNG The bitmap contains a PNG image
Note: BI_JPEG and BI_PNG are for printer drivers and are not supported when rendering to the screen.[3]
Equivalent C-Language Header (Compression Methods)

PS( A tabela não ficou boa aqui).

juliocbq:

sergiotaborda:

AUser:

sergiotaborda, como assim? Você quer dizer que Flash não é uma plataforma de multimídia? Flash é a melhor tecnologia pra Streaming de vídeo, a melhor para animação bidimensional e está começando a parte tridimensional.

pois…claro… Vc tem um video para processar no servidor e capturar o primeiro frame para fazer um thumbnail. Vc faz com flash. Não me lembrei disso…

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Java fx trouxe para o java um suporte multimedia robusto. Até então, toda api de media que existia para java eram mapeamentos ou bibliotecas adaptadas e que não funcionavam bem, como jmf.

Como o sergio falou, a área de atuação do fx é e será muito mais ampla que o flash player.
Mas como streamming de vídeo vou concordar que o fp realmente é muito bom, senão o melhor que existe hoje. O java fx não tem suporte a vídeo, ainda, e todas as minhas experiências foram mapeando directshow para capturar vídeo, e javafx para pintar os quadros. Tive ótimos resultados.

http://www.humatic.de/htools/dsj.htm

E você disse que JavaFx não suporta vídeo ainda? Veja isso.

marcobiscaro2112:

juliocbq:

sergiotaborda:

AUser:

sergiotaborda, como assim? Você quer dizer que Flash não é uma plataforma de multimídia? Flash é a melhor tecnologia pra Streaming de vídeo, a melhor para animação bidimensional e está começando a parte tridimensional.

pois…claro… Vc tem um video para processar no servidor e capturar o primeiro frame para fazer um thumbnail. Vc faz com flash. Não me lembrei disso…

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Java fx trouxe para o java um suporte multimedia robusto. Até então, toda api de media que existia para java eram mapeamentos ou bibliotecas adaptadas e que não funcionavam bem, como jmf.

Como o sergio falou, a área de atuação do fx é e será muito mais ampla que o flash player.
Mas como streamming de vídeo vou concordar que o fp realmente é muito bom, senão o melhor que existe hoje. O java fx não tem suporte a vídeo, ainda, e todas as minhas experiências foram mapeando directshow para capturar vídeo, e javafx para pintar os quadros. Tive ótimos resultados.

http://www.humatic.de/htools/dsj.htm

Só porque é o formato padrão do Windows, não quer dizer que seja amplamente usado. O que o sergiotaborda quis dizer é o seguinte: o principal problema do BMP é o tamanho e, com a ascensão das redes, foi criado o GIF. A briga foi grande na época (Flash X JavaFx agora?) mas agora quem predomina é o PNG, tão leve quanto o GIF e cobre as limitações dos outros dois formatos (como a questão de translucência).

E você disse que JavaFx não suporta vídeo ainda? Veja isso.

O que eu quis dizer é que não tem suporte a captura de vídeo. Eu deveria ter sido mais específico. Por isso citei jmf.
A garnde vantagem do javafx é o processamento em hardware, ou seja, direto na placa de vídeo. Isso traz ganhos de performance.

O que eu fiz foi usar o directshow para capturar de dispositivos como dvcams e pintá-los numa superfície javafx. E deu ótimos resultados…

juliocbq:

sergiotaborda:

juliocbq:

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Isso não faz sentido. Que eu saiba “formato” diz respeito à organização dos bits dentro do arquivo. BMP , GIF e PNG são diferentes na sua organização de bits, logo não formatos diferentes. BMP = Bit Map. O formato é simples, cada elemento é uma cor (dependendo da codificação o elemento pode ter 2, 2^8 , 2^16 ou 2^34 bits). GIF = Graphics Interchange Format , ele tem um cabeçalho com as cores e um vários corpos. Várias imagems cabem dentro de um gif. Ele aceita um numero limitado de cores (255). alem disso usa um algoritmo de compactação (como o zip).
O PNG = Portable Network Graphic suporte o canal alfa (RGBA) que nenhum dos outros suporta.

Não entendo como vc poder dizer que é tudo a mesma coisa.

Eu disse que os outros formatos nada mais são que o bmps codificados. Não disse que são iguais. O bmp é um dib (device independent bitmap). Ele é mais que um formato, é um padrão para sistemas microsoft e os/2.

O avi segue a mesma idéia, assim como o wav.

Esse aqui é o datasheet do bmp.

Quando você converte um gif ou um png para bmp, na verdade está decodificando, e não codificando.

The compression method field (bytes #30-33) can have the following values:
Value Identified by Compression method Comments
0 BI_RGB none Most common
1 BI_RLE8 RLE 8-bit/pixel Can be used only with 8-bit/pixel bitmaps
2 BI_RLE4 RLE 4-bit/pixel Can be used only with 4-bit/pixel bitmaps
3 BI_BITFIELDS Bit field Can be used only with 16 and 32-bit/pixel bitmaps.
4 BI_JPEG JPEG The bitmap contains a JPEG image
5 BI_PNG PNG The bitmap contains a PNG image
Note: BI_JPEG and BI_PNG are for printer drivers and are not supported when rendering to the screen.[3]
Equivalent C-Language Header (Compression Methods)

PS( A tabela não ficou boa aqui).

“PNG is a lossless bitmap image format”. É um formato de imagem que usa um mapa de bits, compressão. Não está relacionado com o formato BMP.

marcobiscaro2112:

juliocbq:

sergiotaborda:

juliocbq:

Só corrigindo. O bmp é o formato padrão e nativo de sistemas como o windows, sendo os outros formatos bmps codificados. Então ele não pode ser antigo.

Isso não faz sentido. Que eu saiba “formato” diz respeito à organização dos bits dentro do arquivo. BMP , GIF e PNG são diferentes na sua organização de bits, logo não formatos diferentes. BMP = Bit Map. O formato é simples, cada elemento é uma cor (dependendo da codificação o elemento pode ter 2, 2^8 , 2^16 ou 2^34 bits). GIF = Graphics Interchange Format , ele tem um cabeçalho com as cores e um vários corpos. Várias imagems cabem dentro de um gif. Ele aceita um numero limitado de cores (255). alem disso usa um algoritmo de compactação (como o zip).
O PNG = Portable Network Graphic suporte o canal alfa (RGBA) que nenhum dos outros suporta.

Não entendo como vc poder dizer que é tudo a mesma coisa.

Eu disse que os outros formatos nada mais são que o bmps codificados. Não disse que são iguais. O bmp é um dib (device independent bitmap). Ele é mais que um formato, é um padrão para sistemas microsoft e os/2.

O avi segue a mesma idéia, assim como o wav.

Esse aqui é o datasheet do bmp.

Quando você converte um gif ou um png para bmp, na verdade está decodificando, e não codificando.

The compression method field (bytes #30-33) can have the following values:
Value Identified by Compression method Comments
0 BI_RGB none Most common
1 BI_RLE8 RLE 8-bit/pixel Can be used only with 8-bit/pixel bitmaps
2 BI_RLE4 RLE 4-bit/pixel Can be used only with 4-bit/pixel bitmaps
3 BI_BITFIELDS Bit field Can be used only with 16 and 32-bit/pixel bitmaps.
4 BI_JPEG JPEG The bitmap contains a JPEG image
5 BI_PNG PNG The bitmap contains a PNG image
Note: BI_JPEG and BI_PNG are for printer drivers and are not supported when rendering to the screen.[3]
Equivalent C-Language Header (Compression Methods)

PS( A tabela não ficou boa aqui).

Você está dizendo que o formato PNG (um formato livre) é um BMP (proprietário) codificado?? Você deve estar confundindo algo.

“PNG is a lossless bitmap image format”. É um formato de imagem que usa um mapa de bits, compressão. Não está relacionado com o formato BMP.

Estou dizendo sim. Quando se diz formato livre, está dizendo que o codificador é livre. Até pouco tempo houve problemas com o jpg, com direitos autorais sobre o formato(codificação e algoritmo).

No datasheet tem a tabela de compressão. Eu coloquei ae no final do post, mas ficou ruim. Vou gerar uma imagem.

Se o BMP pode usar um formato de compressão PNG significa que o BMP pode conter um PNG. Mas não existe necessariamente uma relação inversa.

Aqui a tabela…

2010/1/8/51ffc75dbda02cbbb64161813df440f2_50924.jpg_762×258 69.7 KB

Aqui está a especificação do PNG:
http://tools.ietf.org/html/draft-boutell-png-spec-04. As letras “BMP” não são citadas juntas nenhuma vez e a palavra “bitmap” só aparece em:
“The PNG format provides a portable, legally unencumbered, well-compressed, well-specified standard for lossless bitmapped image files.”
O mesmo que eu já havia postado antes, um formato que representa um bitmap (nada a ver com BMP).

existe sim… você precisa decodificar a mesma imagem para converter para bitmap.

existe sim… você precisa decodificar a mesma imagem para converter para bitmap.
E o que isso tem a ver com o formato BMP?

marcobiscaro2112:

Aqui está a especificação do PNG:
http://tools.ietf.org/html/draft-boutell-png-spec-04. As letras “BMP” não são citadas juntas nenhuma vez e a palavra “bitmap” só aparece em:
“The PNG format provides a portable, legally unencumbered, well-compressed, well-specified standard for lossless bitmapped image files.”
O mesmo que eu já havia postado antes, um formato que representa um bitmap (nada a ver com BMP).

well-compressed = bem codificado.

O png possui uma tabela de simplificação semelhante ao gif, com a diferença de suportar 32bits. Dentro de um png existe bytes de um dib codificado, e é a mesma coisa para todos os outros formatos. O datasheet mostra tudo isso ae.

Aqui o datasheet do codificador jpeg.

Note que o algoritmo é semelhante ao Huffman encoding, que é o mesmo do zip.

Quanto ao método de compressão, o PNG usa uma derivação do LZ77:

5. Deflate/Inflate Compression

PNG compression method 0 (the only compression method presently
defined for PNG) specifies deflate/inflate compression with a 32K
sliding window. Deflate compression is an LZ77 derivative used in
zip, gzip, pkzip and related programs. Extensive research has been
done supporting its patent-free status. Portable C implementations
are freely available.

Absolutamente nenhuma relação com imagens BMP ou DIF. Mais sobre o campo IDAT:

4.1.3. IDAT Image Data

The IDAT chunk contains the actual image data.  To create this
     data:

         * Begin with image scanlines represented as described in
           Image layout (Section 2.3); the layout and total size of
           this raw data are determined by the fields of IHDR.
         * Filter the image data according to the filtering method
           specified by the IHDR chunk.  (Note that with filter
           method 0, the only one currently defined, this implies
           prepending a filter type byte to each scanline.)
         * Compress the filtered data using the compression method
           specified by the IHDR chunk.

     The IDAT chunk contains the output datastream of the
     compression algorithm.

     To read the image data, reverse this process.

     There can be multiple IDAT chunks; if so, they must appear
     consecutively with no other intervening chunks.  The compressed
     datastream is then the concatenation of the contents of all the
     IDAT chunks.  The encoder can divide the compressed datastream
     into IDAT chunks however it wishes.  (Multiple IDAT chunks are
     allowed so that encoders can work in a fixed amount of memory;
     typically the chunk size will correspond to the encoder's
     buffer size.) It is important to emphasize that IDAT chunk
     boundaries have no semantic significance and can occur at any
     point in the compressed datastream.  A PNG file in which each
     IDAT chunk contains only one data byte is legal, though
     remarkably wasteful of space.  (For that matter, zero-length
     IDAT chunks are legal, though even more wasteful.)

     See Filter Algorithms (Chapter 6) and Deflate/Inflate
     Compression (Chapter 5) for details.</blockquote>

Referência completa: http://tools.ietf.org/html/rfc2083

marcobiscaro2112:

Quanto ao método de compressão, o PNG usa uma derivação do LZ77:

5. Deflate/Inflate Compression

PNG compression method 0 (the only compression method presently
defined for PNG) specifies deflate/inflate compression with a 32K
sliding window. Deflate compression is an LZ77 derivative used in
zip, gzip, pkzip and related programs. Extensive research has been
done supporting its patent-free status. Portable C implementations
are freely available.

Existem vários campos em uma imagem PNG, dentre os quais o IDAT se destaca (é nesse campo que fica os bits da imagem comprimida propriamente dita). A especificação desse campo:

Absolutamente nenhuma relação com imagens BMP ou DIF. Mais sobre o campo IDAT:

4.1.3. IDAT Image Data

The IDAT chunk contains the actual image data.  To create this
     data:

         * Begin with image scanlines represented as described in
           Image layout (Section 2.3); the layout and total size of
           this raw data are determined by the fields of IHDR.
         * Filter the image data according to the filtering method
           specified by the IHDR chunk.  (Note that with filter
           method 0, the only one currently defined, this implies
           prepending a filter type byte to each scanline.)
         * Compress the filtered data using the compression method
           specified by the IHDR chunk.

     The IDAT chunk contains the output datastream of the
     compression algorithm.

     To read the image data, reverse this process.

     There can be multiple IDAT chunks; if so, they must appear
     consecutively with no other intervening chunks.  The compressed
     datastream is then the concatenation of the contents of all the
     IDAT chunks.  The encoder can divide the compressed datastream
     into IDAT chunks however it wishes.  (Multiple IDAT chunks are
     allowed so that encoders can work in a fixed amount of memory;
     typically the chunk size will correspond to the encoder's
     buffer size.) It is important to emphasize that IDAT chunk
     boundaries have no semantic significance and can occur at any
     point in the compressed datastream.  A PNG file in which each
     IDAT chunk contains only one data byte is legal, though
     remarkably wasteful of space.  (For that matter, zero-length
     IDAT chunks are legal, though even more wasteful.)

     See Filter Algorithms (Chapter 6) and Deflate/Inflate
     Compression (Chapter 5) for details.</blockquote>

Referência completa: http://tools.ietf.org/html/rfc2083

Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada?

juliocbq:

Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada?

marcobiscaro2112:

juliocbq:

Vou perguntar de maneira diferente, já que você se recusa a ler o datasheet do bmp.
Porque png não tem nada haver com o bmp, já que ele é um método de compressão?
em qual formato de imagem a compressão png ou jpg deve ser aplicada?

São casos diferentes. JPG é um método de compressão que é aplicado em alguma imagem. O PNG é um formato de imagem [color=red]que usa[/color] (usar um não quer dizer ser um) método de compressão (uma derivação do LZ77) sobre um mapa de pixels (armazenado no seu campo IDAT) que representa a imagem.

Vou ser mais claro. Um arquivo png possui cabeçalhos diferentes de um bmp, assim como o jpg, mas a estutura de dados que guarda os bytes de informação dos pixels deve ser gerada através de um algoritmo de compressão, em bytes em estrutura não compactada, ou seja, um dib.

Experimenta passar um jpeg para um codificador de png, ou vice-versa e veja se funciona.

O JPEG, PNG, MNG, todos são métodos e algoritmos de compressão. Alguns são livres e outros pagos.

O livro do Gonzales é muito bom. Digital Image Processing 3ª ed.
Bibliografias:

Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um). Se PNG fosse um algoritmo de compressão, porque eu não poderia comprimir qualquer outro tipo de arquivo?

Perfeitamente.

Perfeitamente.

É aqui que discordamos. Um DIB é um formato de imagem proprietário. O que os formatos de imagem guardam são um Raster graphic, nesse caso, especificamente, é um Bitmap. Um Bitmap (ou pixmap) é exatamente o que você disse:

Ou seja, há um bitmap (ou pixmap) compactado (com um algoritmo diferente, dependendo do formato) dentro do campo de dados de cada formato de imagem, concorda comigo?

O Java 7 vai ter suporte ao PNG e ao BMP?
Caso negativo, acho que a briga de ego de vcs dois já desvirtuou o tópico.

marcobiscaro2112:

Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um).

Exactamente.
Na realidade formatos de arquivo sempre definem 3 coisas: algoritmo de escrita, algoritmo de leitura e formato de arquivo. Os três estão interligados. PNG usa um algoritmo de compactação/descompactação nos algoritmos de I/O, não no arquivo em si.

JPEG é um formato que usa transformada de Fourier para “compressão”, já que a TF não é um algoritmo de compressão, mas é usado como um. O JPEG 2000 usa Transformada de Wavelets, muitos mais poderosa que a TF para processamento de imagem.

A imagem nem é sempre um array de matrizes de canais. Bitmap não é sinónimo de imagem, é sinonimo de “formato de representação” e não tem relação 1-1 com BMP ( BMP usa um bitmap, mas bitmap não é necessáriamente BMP). O contra-exemplo seria o SVG que não usa um mapa de bits e os algoritmos de escrita e leitura não são formas de compressão. Mas tudo são imagens.

GIF , JPEG , PNG , etc … são formatos de arquivo de imagem com seus algoritmos de leitura e escrita. Se esse algoritmo usa compressão isso é apenas um detalhe do padrão do arquivo, não da imagem.

A conversa saiu fora do ponto que era exemplificar que nem sempre coisas que existem ha mais tempo são melhores , nem isso significa que ficaram sendo usadas para sempre.

clone_zealot:

O Java 7 vai ter suporte ao PNG e ao BMP?
Caso negativo, acho que a briga de ego de vcs dois já desvirtuou o tópico.

marcobiscaro2112:

Uma correção sobre algo que eu disse: que JPG é um método de compressão. Na verdade JPG é um formato de imagem que define seu próprio algoritmo de compressão.

Não faz sentido dizer que o PNG é um algoritmo de compressão (seria como fazer um Pessoa extends Carro - só porque usa um não quer dizer que é um). Se PNG fosse um algoritmo de compressão, porque eu não poderia comprimir qualquer outro tipo de arquivo?

Perfeitamente.

Perfeitamente.

É aqui que discordamos. Um DIB é um formato de imagem proprietário. O que os formatos de imagem guardam são um Raster graphic, nesse caso, especificamente, é um Bitmap. Um Bitmap (ou pixmap) é exatamente o que você disse:

Ou seja, há um bitmap (ou pixmap) compactado (com um algoritmo diferente, dependendo do formato) dentro do campo de dados de cada formato de imagem, concorda comigo?

O bmp(dib) não é proprietário. É livre de patentes.

he simplicity of the BMP file format, and its widespread familiarity in Windows and elsewhere, as well as the fact that this format is relatively well documented and free of patents, makes it a very common format that image processing programs from many operating systems can read and write.
While most BMP files have a relatively large file size due to lack of any compression, many BMP files can be considerably compressed with lossless data compression algorithms such as ZIP (in rare cases of non-photographic data, up to 0.1% of original size) because they contain redundant data.

O bmp é um formato livre de compressão, como já concordamos e padrão em sistemas win e os/2. Existem formatos de imagens proprietárias, como é o caso dos dispositivos de captura de vídeo, que eu trabalho aqui, e exigem decodificadores semelhantes ao png e ao jpeg.

Acho que a causa do nosso debate é simplesmente uma palavra. Codificação.

O que eu venho dizer com ela, é que, a codificação produz a estrutura de dados por traz dos arquivos. Um bmp pode conter um jpeg, para isso basta codificá-lo. Basta olhar a referência acima.

Com o png é a mesma coisa. Depois de codificado(O bitmap sem nenhuma compressão), torna-se uma imagem com formato png. Mas o responsável é o codificador. Não importa a procedência, para uma imagem nesses formatos, e imprecindível que haja sua original em estruturas livres de compressão.

Não confunda transformada de furrier com wavelets. Transformadas de furrier são usadas em análise de imagens no domínio da frequência. Wavelets são uma forma de transformada, com uso específico para compressão e não é nada mais poderosa que furrier. São apenas usadas em foco específico. o wavelet pode fazer análise no domínio do tempo. Furrier é muito melhor para análise de frequência.

Aqui tem exemplos com fontes em java.
http://homepages.inf.ed.ac.uk/rbf/HIPR2/tranops.htm

Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.

Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis.

Imagens do memso tipo têm modelos compativeis o que permite diversas operações sobre a imagem ( não o formato) e este modelo não usa mapas de bits, ou melhor, devido ao encapsulamento não ha garantia que use.

O encoder e o decoder são tb separados, sendo possível ler e não escrever ou vice-versa.
Se é JPEG ou PNG depende do encoder/decoder escolhidos. Na memória nenhum desses formatos existe. Nem mesmo o bitmap.

E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF.

Qualquer uma das duas pode fazer analise em tempo ou espaço. A TF 2D usada em processamento de imagem é para espaço (imagems são informações de espaço). O foco não é especifico.

O formato JPeg 2000 usa wavlets ao contrario do formato JPEG normal que usa TF. O novo formato foi criado exactamente para resolver o problema de escala do jpeg normal. O fato do arquivo ficar menor é um detalhe, esse não é o objetivo.

Enfim, são duas ferramentas igualmente importantes em processamento de imagem e ambas têm várias utilizações além da compactação.

sergiotaborda:

juliocbq:

Acho que a causa do nosso debate é simplesmente uma palavra. Codificação.

O que eu venho dizer com ela, é que, a codificação produz a estrutura de dados por traz dos arquivos. Um bmp pode conter um jpeg, para isso basta codificá-lo. Basta olhar a referência acima.

Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.

Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis.

Imagens do memso tipo têm modelos compativeis o que permite diversas operações sobre a imagem ( não o formato) e este modelo não usa mapas de bits, ou melhor, devido ao encapsulamento não ha garantia que use.

O encoder e o decoder são tb separados, sendo possível ler e não escrever ou vice-versa.
Se é JPEG ou PNG depende do encoder/decoder escolhidos. Na memória nenhum desses formatos existe. Nem mesmo o bitmap.

E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF.

Qualquer uma das duas pode fazer analise em tempo ou espaço. A TF 2D usada em processamento de imagem é para espaço (imagems são informações de espaço). O foco não é especifico.

O formato JPeg 2000 usa wavlets ao contrario do formato JPEG normal que usa TF. O novo formato foi criado exactamente para resolver o problema de escala do jpeg normal. O fato do arquivo ficar menor é um detalhe, esse não é o objetivo.

Enfim, são duas ferramentas igualmente importantes em processamento de imagem e ambas têm várias utilizações além da compactação.

Realmente os conceitos estão muito confusos ai …
O que pode estar nos dois é a imagem. A imagem contida no bmp pode estar contida no jpeg, mas dizer que o bmp está contido no jpeg ou vice-versa não faz sentido.

Quando me referi a estrutura de dados, me referi aos bytes da imagem. Dizer que um bitmap está num jpeg faz todo o sentido, porque posso decodificar os bits de um jpeg e formar um novo bmp. Apesar de perder qualidade, como você disse acima.
Você não pode usar uma classe java para descrever o funcionamento de fundamentos de imagem digital, porque cada framework funciona de uma maneira determinada. Dá uma olhada na OpenCV.

Acho que está confundindo bitmap com imagem. Como eu já falei, a imagem não tem que ser um mapa de bits.
O Java tem isto bem entendido. Image é abstracto. E RenderedImage é concreto. RenderedImage é produzida por um Raster que é o nome que o java dá aos leitores do tipo pixel por pixel. Outros tipos, que não os baseados em Rasters como o SVG são possiveis

Justamente o bitmap é o mapa de bits. Ele é a imagem. Ele é parte da estrutura de dados do arquivo. Arquivos de imagens são, cabeçalho e mapa de bits(Não importa a codificação ou tabela de cores que está usando). Mais uma vez, não pode se basear no framework para descrever fundamentos de imagens digitais. Precisa usar cálculo e álgebra linear.

E o nome é Fourier não Furrier(sic).

O que diz não é totalmente correto. Transformada de Wavlet tb é uma analise em espaço de freqüência, mas ela tem propriedades de escala que a de Fourier não tem. Isso é importante. quando vc tem um jpeg ( que usa uma trasnformada de Fourier) e faz um resize a imagem perde qualidade. Pq ? porque a TF não é invariante à escala da imagem e certa informação vai-se perdendo.
Com wavlets isso não acontece porque a TW é invariante à escala. Isso significa, por exemplo, que se vc tiver a imagem do cristo redentor de um helicóptero ou de um satélite tanto faz. Algoritmos de reconhecimento de imagem ( ou melhor, de match de imagem) usam esta propriedade abundantemente, é assim que monumentos são encontradas automáticamente em fotos de turistas. Portanto, TW não é apenas para compressão. é uma ferramenta de analise como a TF.

Furrier é como se pronuncia. Furrier é utilizada em análise de frequências. Uma vez que se tem a frequência, pode-se trabalhar no tempo. Mas você estará extendendo a função. Então usa-se wavelets, que é proprio para isso.

Usa-se laplace, e não furrier, para analizar o diminio espacial.

O fato é que no final, independente de API, formato de compactação, forma de codificação, etc. Um bitmap terá que ser obrigatoriamente gerado. Pelo menos, é assim que a placa de vídeo entende.

Não sei se o Sergio está falando de alguma API de mais alto nível, onde um Image poderia, por exemplo, conter apenas um conjunto de instruções opengl no seu interior.

Mas, ao se falar de manipulação de imagens por cálculo, nunca ouvi falar de uma forma de se transformar imagens sem antes reverter para seus bits.

Exceto no caso de imagens vetoriais, onde pode-se processar os vetores da imagem antes de envia-los para ser transformado em bitmap no vídeo.

:shock: :shock: :shock: :shock: :shock: :shock:

Vc está equivocado. “frequencia” não implica em “tempo”. As distancias tb têm uma frequencia associada ( o seu inverso) A TF é utilizável com qualquer tipo de dimensão.

Vc está equivocado.
http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000
http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm

A transformada de laplace é outra coisa ( muito usada para resolver equações diferenciais)
Acho que vc está confundindo com http://en.wikipedia.org/wiki/Discrete_Laplace_operator que se aplica pela convolução de um operador matricial com a imagem. a convolução por sua vez é um tipo de operações especial que envolve o uso da TF.

Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.

sergiotaborda:

juliocbq:

Furrier é como se pronuncia.

:shock: :shock: :shock: :shock: :shock: :shock:

Vc está equivocado. “frequencia” não implica em “tempo”. As distancias tb têm uma frequencia associada ( o seu inverso) A TF é utilizável com qualquer tipo de dimensão.

Vc está equivocado.
http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000
http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm

A transformada de laplace é outra coisa ( muito usada para resolver equações diferenciais)
Acho que vc está confundindo com http://en.wikipedia.org/wiki/Discrete_Laplace_operator que se aplica pela convolução de um operador matricial com a imagem. a convolução por sua vez é um tipo de operações especial que envolve o uso da TF.

Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.

Ow sergio, você é uma pessoa inteligente. Como frquência não implica em tempo?

Tempo = 1 / frequencia

ou

Frequencia = Velocidade da onda / largura da onda.

É calculo de física colegial.

Vc está equivocado. [url]http://robotics.eecs.berkeley.edu/~sastry/ee20/vision2/node1.html#SECTION00010000000000000000[/url] [url]http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm[/url]

Não estou não. f(x,y) representa cordenadas espaciais da imagem digital.

essas cordenadas dizem respeito ao espaço da frequência da onda, e não da imagem
Laplace é usado em filtros do dmínio espacial, inclusive, um dos melhores isotrópicos possui seu nome.
http://homepages.inf.ed.ac.uk/rbf/HIPR2/log.htm

Eu já trabalhei com processamento de imagem e nunca vi ninguém se referir à imagem em memória como bitmap nem dizer que o bmp ( o formato) pode ser colocado dentro de jpeg( o formato) nem que o bitmap pode. diz-se que a imagem é convertida para o formato X. Ou que a representação em memória da imagem é convertida para o formato X. A representação da imagem na memória não tem que ser um bitmap (exemplo SVG). Isso que fique claro.

Acho que vc está um pouco confuso quanto aos termos e está confundindo todo o mundo e gastando o nosso tempo tentando explicar que vc está confundido.
Vamos esquecer este spinoff.

Em quais projetos de imagem digital trabalhou? Vamos esquecer sim. Eu te passei todas as fontes que podia.

A palavra “frequencia” sozinha, não implica nem espaço, nem tempo. Implica algo que se repete.
No tempo o que se repete é o periodo e a frequencia é o seu inverso. Normalmente a frequencia temporal é denotada pela letra f.
No espaço o que se repete é o comprimento de onda e a frequencia é o seu inverso. k é usado para esta frequencia.

Não velocidade envolvida neste conceito de frequencia.
A relação v = f/lambda pode-se escrever em termos de f e k, mas só se aplica a ondas. Isso leva aos conceitos de velocidade de grupo e velocidade de fase.

Não. Dizem respeito à frequencia espacial. Em duas dimensões usa-se u e v em vez de k.
Não ha ondas nesta historia.
Para a posição (x,y) do pixel ha uma frequencia (u,v) cuja relação é dada pela TF.

Se vc está pensando que a TF se aplica apenas a ondas vc está enganado. Ela se aplica a qualquer função.
Inclusive a funções como o delta de Dirac (que é infinito num ponto e zero no resto).

Filtros, não transformadas. Filtro de Laplace e Transformada de Laplace são coisas diferentes.

Em um projeto de visão assistida por computador para um projeto da ESA (agencia espacial europeia) que enviaria uma sonda a mercúrio usando esses sistema. Meu trabalho era encontrar métricas que pudessem comparar vários algoritmos de feature detection e depois qual deles era melhor na situação de movimento (em que ha uma sucessão de imagens e os pontos encontrados em uma têm que ser os mesmos que na seguinte).

Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?

andre_salvati:

Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?

O que é que ha para ainda falarmos sobre isso?

sergiotaborda:

juliocbq:

Como frquência não implica em tempo?

A palavra “frequencia” sozinha, não implica nem espaço, nem tempo. Implica algo que se repete.
No tempo o que se repete é o periodo e a frequencia é o seu inverso. Normalmente a frequencia temporal é denotada pela letra f.
No espaço o que se repete é o comprimento de onda e a frequencia é o seu inverso. k é usado para esta frequencia.

Não velocidade envolvida neste conceito de frequencia.
A relação v = f/lambda pode-se escrever em termos de f e k, mas só se aplica a ondas. Isso leva aos conceitos de velocidade de grupo e velocidade de fase.

Não. Dizem respeito à frequencia espacial. Em duas dimensões usa-se u e v em vez de k.
Não ha ondas nesta historia.
Para a posição (x,y) do pixel ha uma frequencia (u,v) cuja relação é dada pela TF.

Se vc está pensando que a TF se aplica apenas a ondas vc está enganado. Ela se aplica a qualquer função.
Inclusive a funções como o delta de Dirac (que é infinito num ponto e zero no resto).

Filtros, não transformadas. Filtro de Laplace e Transformada de Laplace são coisas diferentes.

Em um projeto de visão assistida por computador para um projeto da ESA (agencia espacial europeia) que enviaria uma sonda a mercúrio usando esses sistema. Meu trabalho era encontrar métricas que pudessem comparar vários algoritmos de feature detection e depois qual deles era melhor na situação de movimento (em que ha uma sucessão de imagens e os pontos encontrados em uma têm que ser os mesmos que na seguinte).

Muito bem sergio. Nosso debate percorreu desde estruturas de dados a transformadas e filtros. Tenho que concordar com você que transformadas são diferentes de filtros. Também trabalho com visão artificial e uso constantemente.

Agora, só me ajude a entender uma coisa nessa equação. Porque a frequência nela não tem relação com o tempo?

sergiotaborda:

andre_salvati:

Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?

O que é que ha para ainda falarmos sobre isso?

Se ainda há o que falar sobre Java 7, o tópico é este. Se o assunto não é esse, pq não abre outro tópico? Questão de organização…

andre_salvati:

sergiotaborda:

andre_salvati:

Ok Srs,

estava preferindo a discussão sobre Java 7, Flex e JavaFX do que sobre BPM. JPG e PNG.

Que tal voltarmos?

O que é que ha para ainda falarmos sobre isso?

Se ainda há o que falar sobre Java 7, o tópico é este. Se o assunto não é esse, pq não abre outro tópico? Questão de organização…

Pessoal alguem sabe se já existe um link para download do Java 7?

Valeu

Para os binários,

http://dlc.sun.com.edgesuite.net/jdk7/binaries/index.html

Para o fonte,

http://download.java.net/jdk7/

Lendo esta postagem, me deparei com uma pergunta. Então, quais são as diferenças entre o Java 7 e o Java 6. Não estou me perguntando se existem melhorias porque sei que existem, mas quais são elas. Mesmo porque, não acredito no lançamento do Java 7 sem que a Sun planeja-se muito bem elas. Vocês aqui do fórum conseguiriam enumerá-las. Seria de grande valor a enumeração e até uma diferenciação do Java 6 para o Java 7, porque a pergunta do título da postagem seria respondida.

http://java.sun.com/javase/7/webnotes/index.html

Closeable.close implícito é até uma boa feature, mas desconfio que isso vá deixar o pessoal mal acostumado a não fechar resources.

É uma pena que não teremos no Java 7 os named parameters, já que atualmente o compilador perde os nomes dos parametros, sendo necessário recorrer a magias como Paranamer ou annotations @Named. Para mim, depois da JSR310 seria o mais importante.

Falando na JSR310, notei que os trabalhos nela estão de volta. Será que finalmente teremos o javax.date?

Havia também uma iniciativa de criar coisas estilo o Guava Libraries para prover métodos estilo Strings.isNullOrEmpty, Objects.isNull, etc. Mas notei que também não será dessa vez.

Enfim, poucas mudanças na API, mas muitas mudanças no core da VM.

Pessoal, estou com uma duvida, procurei e não encontrei.

A ultima versão do eclipse aceita o Java 7? Ou a ultima do netbeans?

Grato, Lucas

LucasAdri07:

Pessoal, estou com uma duvida, procurei e não encontrei.

A ultima versão do eclipse aceita o Java 7? Ou a ultima do netbeans?

Grato, Lucas

Manda ver que roda de tudo na jre7.

juliocbq:

LucasAdri07:

Pessoal, estou com uma duvida, procurei e não encontrei.

A ultima versão do eclipse aceita o Java 7? Ou a ultima do netbeans?

Grato, Lucas

Manda ver que roda de tudo na jre7.

Eu fiz um teste aqui, colocando String no Switch e ele não permitiu

Dá a seguinte mensagem

Cannot switch on a value of type String. Only convertible int values or enum constants are permitted

Será que não estou configurando certo?

LucasAdri07:

juliocbq:

LucasAdri07:

Pessoal, estou com uma duvida, procurei e não encontrei.

A ultima versão do eclipse aceita o Java 7? Ou a ultima do netbeans?

Grato, Lucas

Manda ver que roda de tudo na jre7.

Eu fiz um teste aqui, colocando String no Switch e ele não permitiu

Dá a seguinte mensagem

Cannot switch on a value of type String. Only convertible int values or enum constants are permitted

Será que não estou configurando certo?

mas ae vc comeu bola, porque na linguagem java somente tipos primitivos e enums podem ser chaveados dessa maneira.
Não tem nada haver com versão de jdk

juliocbq:

LucasAdri07:

juliocbq:

LucasAdri07:

Pessoal, estou com uma duvida, procurei e não encontrei.

A ultima versão do eclipse aceita o Java 7? Ou a ultima do netbeans?

Grato, Lucas

Manda ver que roda de tudo na jre7.

Eu fiz um teste aqui, colocando String no Switch e ele não permitiu

Dá a seguinte mensagem

Cannot switch on a value of type String. Only convertible int values or enum constants are permitted

Será que não estou configurando certo?

mas ae vc comeu bola, porque na linguagem java somente tipos primitivos e enums podem ser chaveados dessa maneira.
Não tem nada haver com versão de jdk

É que eu sou iniciante, então não entendi muito bem, mais valeu então

O compilador do Eclipse NÃO É o javac e ele ainda não aceita código Java 7.

Para compilar um switch com string (de acordo com o exemplo dado em http://thingol-guj.blogspot.com/2010/03/switch-com-strings-no-java-7.html ) é necessário usar o javac do Java 7, não o compilador do Eclipse.

Não sei se é possível fazer com que o NetBeans aceite usar o javac do Java 7; talvez seja possível.

entanglement:

LucasAdri07:

Eu fiz um teste aqui, colocando String no Switch e ele não permitiu

O compilador do Eclipse NÃO É o javac e ele ainda não aceita código Java 7.

Para compilar um switch com string (de acordo com o exemplo dado em http://thingol-guj.blogspot.com/2010/03/switch-com-strings-no-java-7.html ) é necessário usar o javac do Java 7, não o compilador do Eclipse.

Não sei se é possível fazer com que o NetBeans aceite usar o javac do Java 7; talvez seja possível.

Os dois ides usam o jdk que for especificado neles, então o compilador usado em qualquer um será o especificado. Eu tenho tanto netbeans e eclipse funcionando perfeitamente com jdk 7 na minha casa.

Agora se chavear objetos em java é permitido com java7, confesso que não sei porque nem havia pensado em testar. Em casa farei o teste e lhes passo o resultado amanhã cedo.

O compilador do Eclipse é o que você disser a ele que é. Vocẽ pode usar o Javac, Jikes, ou o sei lá qual outro compilador…

Eu gostei do Java 7, principalmente da adição de características funcionais.

Jesuino Master:

Eu gostei do Java 7, principalmente da adição de características funcionais.

Também gostei da evolução. Muita coisa que desenvolvedores pediam, muita coisa que ajuda quem desenvolve componentes e frameworks e outras que só pra necessidades muito específicas alguém vai notar.

E iguala algumas vantagens que o C# tinha sobre o Java, equilibrando melhor a balança. Embora seja muito mais difícil fazer uma linguagem que rode em várias plataformas do que em uma que rode em apenas um SO, gostaria que o Java caminhasse mais rápido.

juliocbq:

Os dois ides usam o jdk que for especificado neles, então o compilador usado em qualquer um será o especificado. Eu tenho tanto netbeans e eclipse funcionando perfeitamente com jdk 7 na minha casa.

Agora se chavear objetos em java é permitido com java7, confesso que não sei porque nem havia pensado em testar. Em casa farei o teste e lhes passo o resultado amanhã cedo.

O Eclipse usa (se você usar em um projeto o “Java Builder” o compilador próprio dele, que é o ECJ (Eclipse Compiler for Java). Esse compilador ainda não suporta o Java 7.
Ele pode gerar código compatível com a especificação 1.6, que rode em uma JRE 1.7 (como está também na minha máquina).
Para que o Eclipse use o javac, você deve usar o “Ant Builder” e criar uma task que use o javac, não o ecj.

Usar switch com STRINGs é uma coisa nova no Java 7; não é possível usar switch com objetos quaisquer. O Java 7 usa um truque com hash codes para implementar um switch com strings que é mais rápido, em média, que um monte de “if / else if” encadeados, e isso está descrito naquele post do Thingol.

Você tem razão, eu não havia percebido isso. Achei que eu estava usando o javac.

Uma coisa que estou esperando que o Joseph Darcy libere logo no JDK 7 é o “automatic resource management”. Infelizmente, ele não funcionará com conexões do banco de dados ou recursos gráficos, mas funcionará para muitas das classes do java.io que lidam com arquivos. Por exemplo (acho que é mais ou menos assim):

try (BufferedReader br = new BufferedReader (new InputStreamReader (new FileInputStream ("teste")));
      PrintWriter pw = new PrintWriter ("saida")) {
     for (String linha = br.readLine(); linha != null; linha = br.readLine()) {
         pw.println (linha);
     }
}

que é equivalente a

BufferedReader br = null;
PrintWriter pw = null;
try {
    br = new BufferedReader (new InputStreamReader (new FileInputStream ("teste")));
    pw = new PrintWriter ("saida")) {
    for (String linha = br.readLine(); linha != null; linha = br.readLine()) {
        pw.println (linha);
    }
} finally {
    if (pw != null) pw.close();
    if (br != null) try { br.close(); } catch (IOException ex) { /* silently quench the exception */ }
}

Isso é mais ou menos parecido com o “using” do C#, mas no C# eu posso pôr apenas uma declaração em cada “using”, não duas como fiz acima.

Pode sim:
http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx

Microsoft:

Multiple objects can be used in with a using statement, but they must be declared inside the using statement, like this:

using (Font font3 = new Font("Arial", 10.0f), font4 = new Font("Arial", 10.0f)) { // Use font3 and font4. }

Ah, falha nossa. Acho que eu me confundi: no C#, posso declarar vários objetos em um mesmo using, mas usar apenas uma declaração (ou seja, todos as variáveis têm de ser do mesmo tipo. ) Portanto, não dá para abrir um arquivo de entrada e um de saída ao mesmo tempo no mesmo using.

Sergio,

Quanto ao JavaFX eu só tenho uma coisa para te falar…

“Deus te ouça” hehehe

Prq pra mim até agora só existe promessas.

chun:

Sergio,

Quanto ao JavaFX eu só tenho uma coisa para te falar…

“Deus te ouça” hehehe

Prq pra mim até agora só existe promessas.

Pois é, JavaFX tem um duro caminho pela frente, mas não deixa de ser melhor que o Swing. E o ritmo de desenvolvimento dele está bom, não está tão lento quanto o Java 7.

Olá pessoal, sou leigo em java ainda estou aprendendo, queria saber quais diferenças do java 6 e java 7 lançado pela oracle?