Uma VM que usa Java como linguagem de alto nível mas que não usa o mesmo formato (.class, .jar), ou não implementa alguma especificação da Sun - isso lembra o SuperWaba.
[quote=saoj][quote]
já me encheu esse Android…
[/quote]
Isso me parece ser um problema recorrente da galera que trabalha com tecnologia. Se preocupam mais em fazer uma coisa poderosa e toda “bonita” do que uma coisa simples de se usar e entender.
[/quote]
É exatamente o que a Microsoft faz, e todo mundo desce a lenha nela. 
[quote=Leonardo3001][quote=louds]O Android não roda Java, não sei se esqueceram de avisar todo mundo disso. Aquilo não é Java, ponto. Aquilo é uma plataforma fechada e, até segunda ordem, proprietaria. O Android executar binarios próprios para sua plataforma, os tais dex, não class ou jar.
Que plataforma maravilhosa é essa que não permite concorrência e é fechada? Não entendo isso.[/quote]
Não sei o que você quis dizer com não roda Java.
[/quote]
Juridicamente falando, aquilo não poderia ser chamado de Java. Você programa na *** linguagem *** Java, mas usa um subset das APIs Java misturadas com outras do android, e roda tudo isso numa VM que roda esse tal de .dex que é um .class processado.
Curioso é que normalmente a essa hora já deveria ter um batalhão de advogados da Sun batendo na porta do Google. Mas como é O Google, levou um elogio do presidente da Sun: http://blogs.sun.com/jonathan/entry/congratulations_google . Engraçado né?
[quote=thingol]Uma VM que usa Java como linguagem de alto nível mas que não usa o mesmo formato (.class, .jar), ou não implementa alguma especificação da Sun - isso lembra o SuperWaba.
[/quote]
Thingol, faz muito tempo que não mexo c/ Superwaba, mas lembro que o Guilherme Hazan estava mudando a VM dele p/ desvincular de vez c/ qualquer coisa que tivesse a ver c/ Java. Parece que ele ia implementar outro tipo de bytecode, outra VM, e semelhante a esse tal de Dalvik, você ia ter que usar um compilador próprio p/ converter os .class nesse novo formato.
E um dos motivos p/ essa mudança (além de razões técnicas) era p/ evitar eventuais problemas legais c/ a Sun.
É interessante porque a VM Dalvik é orientada a registradores, e a JVM é orientada a pilha.
Isso quer dizer que a tradução .class -> .dex não é trivial, já que você precisa na verdade "descompilar" parcialmente o programa original (para poder pegar a intenção dos opcodes gerados que lidam com a pilha) e recompilar para outros bytecodes, que trabalham com registradores.
Talvez ele deve fazer alguma análise de fluxo também, para poder efetuar algumas otimizações (sabe como é, o javac gera intencionalmente código muito desotimizado, para facilitar o trabalho do JIT Compiler, que pode dessa maneira pegar a "intenção" original do programa.)
A Microsoft teve “alguns” problemas porque ela quis mexer na linguagem em si (delegates, J/Direct); o Google não mexeu na linguagem (é Java 5.0 normal, com generics etc.).
O engenheiro da Microsoft (Anders Hejlsberg) já tinha um histórico “ruim” - ele tinha mexido no C++, incluindo uma construção especial no Borland C++ para poder atender a mensagens do Windows, e ele criou o Delphi a partir do Object Pascal. Se ele não mexesse na sintaxe não se chamaria Anders Hejslberg.
Não sei se ela não tivesse feito essa mexida toda teríamos o .NET tal como o conhecemos. Talvez a Microsoft tivesse simplesmente comprado a Sun e não teríamos essas guerras religiosas Microsoft X Java; só a guerra Microsoft X Open Source.
[quote=thingol]É interessante porque a VM Dalvik é orientada a registradores, e a JVM é orientada a pilha.
Isso quer dizer que a tradução .class -> .dex não é trivial, já que você precisa na verdade "descompilar" parcialmente o programa original (para poder pegar a intenção dos opcodes gerados que lidam com a pilha) e recompilar para outros bytecodes, que trabalham com registradores.
Talvez ele deve fazer alguma análise de fluxo também, para poder efetuar algumas otimizações (sabe como é, o javac gera intencionalmente código muito desotimizado, para facilitar o trabalho do JIT Compiler, que pode dessa maneira pegar a "intenção" original do programa.)
[/quote]
Descompilar não é o termo para isso thingol, tradução ou retargeting servem muito bem. Converter uma máquina de pilha em uma de registradores é razoavelmente simples, veja a parrot para ter uma idéia.
Máquinas Virtuals de registradores não é uma coisa nova e tão pouco um grande avanço em relação ao modelo de pilha. Existem uma série de problemas relacionados:
:arrow: Dificil implementar PCC em um TAS.
:arrow: Sem um arquivo infinito de registradores é PCC é ainda mais dificil
:arrow: Na presença de otimizações pode ser impraticavel.
Algumas otimizações de alto nível exigem que a prova seja anotada IL e verificar isso pode ser bem complexo. Algumas podem exigir instruções adicionais. A otimização mais importante que o compilador faz é a alocação de registradores e isso depende do alvo real, logo esse DEX não seria um formato portavel, como é no caso dos bytecodes Java ou CLR.
PCC - Proof Carrying Code
TAS - Types Assembly System
Leonardo3001, existem muitos celulares que já permitem acesso completo a plataforma, aqui em casa tenho 2: um Nokia que roda symbian, que possui uma API enorme; e um Neo 1973, que é, de fato, o único que suporta uma interface aberta e padronizada: ansi C e posix. Java nem mesmo é padronizada (ISO, ECMA, etc), mas sim um documento criado pela entidade pelega da Sun - o JCP.
Sinceramente, o Android promete ser uma plataforma incrivel para se criar trojan horses. Ou mesmo frustrar usuários quanto tentarem pegar código java (de verdade) e tentar usar no desenvolvimento p/ o dispositivo.
Sérgio, andei olhando o helloworld e não achei nada de tão absurdo de complexo… Será que pegou algo que não vi ? Particularmente achei normal, component based …
Pessoal, sinceramente? É muito xiitismo pro meu gosto!
O wmitsuda disse que “juridicamente falando” não se pode dizer que é Java. Como assim? Houve um contrato jurídico entre a Sun e a comunidade dizendo que não se pode considerar Java os programas cujo “target” não sejam .class? Se tem, me mostra que eu não conheço. E ainda fala que a Sun deveria processar a Google, mas processar pelo que, especificamente? A VM do Google não é a mesma VM da Sun, não dá pra processar por plágio.
E louds, você disse que tem dois celulares com acesso completo, né? Um é um Nokia que roda um Symbian, cujas bibliotecas são proprietárias e que não há a menor possibilidade de abertura e um outro que possui suporte completo através de ansi-C e posix. Tá, pode até ter um acesso completo, mas eu ainda fico do lado do Andrioid pois tem dois apelos a mais: roda em Java e possui a promessa de estar em vários dispositivos.
E com relação a ser plataforma para trojan horses, admita que isso é mais especulação (ou seria desejo?) do que realidade. E eu não entendi essa parte de frustração de usuários por tentar rodar “código java de verdade”. Que eu saiba, o usuário final está cagando pra plataforma utilizada, contanto que a aplicação satisfaça seus desejos. Se você estiver falando de um usuário-desenvolvedor, o fato do .class ser intermediário no processo impede que haja código Java que não seja gerado na VM Dalvik (a menos que haja uma dependência para a classe Servlet, mas isso nem no J2ME é possível).
O que mais me espanta nas opiniões das pessoas, tanto nesse fórum quanto em outros lugares, é a capacidade de ir contra uma nova VM apenas porque não é 100% Java, ou porque é diferente daquilo que já estão acostumados. E isso com uma plataforma que foi publicada a apenas dois dias!
E olha o mais incrível: as mesmas pessoas que reclamam da falta de abetura da plataforma do Google são as mesmas que reclamam da abertura do código Java para outro propósito que não seja a geração de arquivos class. Gente javeira! É preciso aceitar uma abertura mais radical, e irem se acostumando quando alguém criar um compilador que transforme arquivos class para executáveis nativos, para uma VM qualquer ou para o interpretador do framework .NET.
Parece simples mas tenta imprimir algo com System.out ou o tal do Log. Tem que usar um debug maluco via socket! E aquele bando de hello world que aparece na tela? Aquilo esta vindo da onde?
[quote=Leonardo3001]Pessoal, sinceramente? É muito xiitismo pro meu gosto!
O wmitsuda disse que “juridicamente falando” não se pode dizer que é Java. Como assim? Houve um contrato jurídico entre a Sun e a comunidade dizendo que não se pode considerar Java os programas cujo “target” não sejam .class? Se tem, me mostra que eu não conheço. E ainda fala que a Sun deveria processar a Google, mas processar pelo que, especificamente? A VM do Google não é a mesma VM da Sun, não dá pra processar por plágio.
[/quote]
Quem falou em plágio? A questão é que o Google não pode dizer que aquilo roda Java pois é um trademark da Sun. A Sun cobra muito caro para certificar uma implementação como Java e esta deve aderir aos padrões do JCP. O Google simplesmente não quis sofrer anos de briga política dentro do JCP ou então ter que subornar a Sun para licensiar o TCK de maneira diferente. O TCK do JSE não permite que o resultado execute em dispositivos moveis - que é algo que a Apache vem brigando a muito tempo e agora sabemos porque.
Symbian dá na mesma que o Android hoje, fechado e proprietário.
A parte da frustração é por parte do desenvolvedor, do usuário do framework. Uma vez que o Android possui apenas partes das APIs do Java e que elas não passam pelos mesmos testes que VMs JSE (Isso legalmente não tem como acontecer), quanta vai ser a frustração do desenvolvedor quando achar buracos e bugs.
Já na questão da segurança, a Dalvik é uma máquina de registradores, que é muito mais complexo de suportar e implementar PCC. Sem PCC é muito facil ter vulnerabilidades (vide programas escritos em C).
Não é questão de ser xiita, mas se a Dalvik não suporta bytecodes Java, oque acontece com a montanha de ferramentas que se valem de engenharia de bytecodes para funcionar? Diga adeus a todas elas.
[quote=Leonardo3001]O wmitsuda disse que “juridicamente falando” não se pode dizer que é Java. Como assim? Houve um contrato jurídico entre a Sun e a comunidade dizendo que não se pode considerar Java os programas cujo “target” não sejam .class? Se tem, me mostra que eu não conheço. E ainda fala que a Sun deveria processar a Google, mas processar pelo que, especificamente? A VM do Google não é a mesma VM da Sun, não dá pra processar por plágio.
[/quote]
Ei, eu não sou xiita não! 
O que quiz dizer foi que a Sun sempre procurou proteger a marca “Java”, não permitindo que qualquer um que apareça por aí falando que tal coisa é Java sem estar certificado como tal.
O thingol citou como exemplo o rolo que teve c/ a microsoft, em que ela enfiou outras coisas na linguagem e saiu falando que era java. Tomou um belo processo.
Quando o louds fala que isso não é Java, é justamente por isso: o android não se enquadra em nenhuma categoria (ME, SE, EE) do que a Sun chama de Java. Implementa alguns pedaços do SE 5.0, junto c/ APIs próprias do aparelho (não passou pelo JCP? isso é heresia p/ a Sun), e roda numa VM que usa um bytecode cuja especificação ainda ninguém viu, mas não é o bytecode Java.
Não estou julgando a qualidade técnica da plataforma (até porque os fontes ainda não sairam e os aparelhos ainda não existem). Chamei atenção apenas p/ essa situação curiosa em que normalmente a Sun estaria esperneando, mas está fazendo o contrário.
E aí é que tá. Se o Google diz que não roda em Java, a Sun pode processá-lo pelo que?
Eu acho uma pena o Google manter parte do Android fechado, mas o fato desta empresa dizer que um dia vai abri-lo já dá alguma ligeira diferença entre os dois sistemas.
[quote=louds]A parte da frustração é por parte do desenvolvedor, do usuário do framework. Uma vez que o Android possui apenas partes das APIs do Java e que elas não passam pelos mesmos testes que VMs JSE (Isso legalmente não tem como acontecer), quanta vai ser a frustração do desenvolvedor quando achar buracos e bugs.
Já na questão da segurança, a Dalvik é uma máquina de registradores, que é muito mais complexo de suportar e implementar PCC. Sem PCC é muito facil ter vulnerabilidades (vide programas escritos em C).
Não é questão de ser xiita, mas se a Dalvik não suporta bytecodes Java, oque acontece com a montanha de ferramentas que se valem de engenharia de bytecodes para funcionar? Diga adeus a todas elas.[/quote]
Legalmente, salvo raras exceções, nenhuma empresa de software é obrigada é fazer testes dos sistemas que produz, é claro que isso acarretará sérios problemas financeiros para quem fizer tal coisa. O Dalvik possivelmente não terá os mesmos testes da VM da Sun, porém isso não implica que os testes do Dalvik serão ruins, ao mesmo tempo que também não implica que não se encontrarão bugs nas primeiras versões do Dalvik. Simplesmente não temos como saber.
Quanto a questão de segurança, me parece que, por pura retórica, você está se agarrando a um tema que outras pessoas não entendem para fazer uma afirmação aparentemente convincente, apostando na minha falta de conhecimento nesse tema para ganhar a argumentação.
Bom, como você citou programas escritos em C, vou me agarrar a isso: um sistema Linux possui várias bibliotecas escritas em C, e ao mesmo tempo existe a afirmação de que o SO é seguro, como pode acontecer isso?
[quote=wmitsuda]O que quiz dizer foi que a Sun sempre procurou proteger a marca “Java”, não permitindo que qualquer um que apareça por aí falando que tal coisa é Java sem estar certificado como tal.
O thingol citou como exemplo o rolo que teve c/ a microsoft, em que ela enfiou outras coisas na linguagem e saiu falando que era java. Tomou um belo processo.
Quando o louds fala que isso não é Java, é justamente por isso: o android não se enquadra em nenhuma categoria (ME, SE, EE) do que a Sun chama de Java. Implementa alguns pedaços do SE 5.0, junto c/ APIs próprias do aparelho (não passou pelo JCP? isso é heresia p/ a Sun), e roda numa VM que usa um bytecode cuja especificação ainda ninguém viu, mas não é o bytecode Java.
Não estou julgando a qualidade técnica da plataforma (até porque os fontes ainda não sairam e os aparelhos ainda não existem). Chamei atenção apenas p/ essa situação curiosa em que normalmente a Sun estaria esperneando, mas está fazendo o contrário.[/quote]
Eu acho que seria uma situação curiosa se ocorresse o contrário: a Sun esperneando por causa da VM do Google. Afinal, o que que tem a ver uma empresa que defende código aberto querer abrir um processo contra patentes? São duas coisas completamente contraditórias. E afinal, tem tanta coisa que nunca chegou a passar pelo JCP, exemplo: os n frameworks que existem por aí, que até duvido se isso é realmente necessário ou um problema.
Retórica é você tentar argumentar quanto não se tem a mínima idéia do que está falando. Eu estudo e trabalho com isso, então talvez tenha alguma idéia do assunto.
Se o linux é seguro, isso se deve a anos e anos de reviews e testes. A glibc possui mais de duas décadas de existencia, o kernel está com 16, e boa parte dos outros componentes datam da primeira metade da década passada. Segurança real exige que o código seja provado ao longo dos anos. Usar modelos simples e provados também ajuda, o que não é o caso da Dalvik.
Só para informar em diversos reply falaram que não rodava Java que não podiam falar que era Java em lugar nenhum mas oque dizer do primeiro paragráfo na página do Android ?
http://code.google.com/android/what-is-android.html
Alguém tem projeto pra desenvolver com este cara?
Esse “Android” seria uma plataforma de desenvolvimento para mobiles? :?: o que é esse desafio? Tem algum limite máximo de integrantes de cada grupo?
Obrigado! 
[quote=marciocamurati]Só para informar em diversos reply falaram que não rodava Java que não podiam falar que era Java em lugar nenhum mas oque dizer do primeiro paragráfo na página do Android ?
http://code.google.com/android/what-is-android.html
[/quote]
tb vi os videos de apresentação no youtube e ele fala q roda somente java. pelo que eu entendi eles só pegaram a jvm do java e otimizaram para uso em aparelhos moveis. Os pacotes básicos do java são suportados, isso quer dizer que você consegue sim portar codigos java “normal” para ele. E além dessa possibilidade ele oferece tb uma biblioteca própria.
Eu apoio o Android. Até mesmo porque eu nunca presenciei alguma aposta grande da Google que desse errado (essa pode ser a primeira).