Re: [androidbrasil-dev] Android, Java e outras Linguagens

Até onde sei, o Android SDK não converte código java para bytecode dalvik, ele converte bytecode JVM para bytecode dalvik, sendo assim qualquer linguagem que tenha um compilador que gere bytecode JVM da pra programar para o Android com ela. E é por isto que tem gente programando para android com  Scala, Ruby(JRuby), Python(Jython), Clojure e outras mais.

Resumindo tudo que falei, a teoria é: se a linguagem roda na JVM então daria pra programar para Android com ela.

Sent from Galaxy SII

Em 06/02/2012 06:43, "Erick Petrucelli" <erickpetru@gmail.com> escreveu:

Clebão, com todo respeito, mas sua explicação possui alguns equívocos. Vou tentar esclarecer melhor:

C# (ou VB.NET, Delphi.NET, Cobol.NET, J#, C++.NET, etc, e todas as outras mais de 50 linguagens suportadas pela plataforma .NET) também geram código intermediário como o Java (chamado MSIL, mas exatamente com o mesmo conceito do bytecode Java). Existem algumas outras linguagens/plataformas que se utilizem desta mesma ideia, embora Java e .NET sejam as mais conceituadas e relevantes.

Enfim, para qualquer uma destas linguagens, do ponto de vista estritamente técnico sobre a codificação, seria totalmente plausível para um compilador gerar código intermediário bytecode ao invés de MSIL, contanto que o compilador fosse criado para isso. Obviamente, para a máquina virtual Dalvik do Android, o código intermediário gerado é um pouco diferente, porém a estratégia seria a mesma. Caberia ao compilador da linguagem ser programado para gerar o código intermediário apropriado. Ou seja, se o Google quisesse, poderia criar compiladores para várias linguagens, transformando C# em bytecode Dalvik, por exemplo.

A dificuldade não está exatamente aí. Ocorre que transformar a sintaxe e a semântica de uma linguagem em um código intermediário é só uma parte da questão. O principal "detalhe" são realmente as bibliotecas de apoio, onde estão definidos todos os tipos, classes e métodos nativos do ambiente.

Então vamos a um exemplo prático, supondo um código C# como este:

using System;

... 

var hoje = DateTime.Now.ToString("dd/MM/yyyy");

E agora um código similar em Java:

import java.util.Date;
import java.text.DateFormat;
import java.text.SimpleDateFormat;
...
DateFormat dateFormat = new SimpleDateFormat("dd/MM/yyyy");
Date date = new Date();
string hoje = dateFormat.format(date);

Transformar os tokens de cada linguagem e sua sintaxe em um código intermediário não seria problema. Mas o que fazer em relação às bibliotecas utilizadas (usings e imports)? O Android possui seu próprio conjunto de bibliotecas (que mudam a cada versão do sistema), então escrevemos os códigos acessando essas bibliotecas. Claro que essas bibliotecas são muito parecidas com as bibliotecas do Java tradicional, afinal se basearam nele de certa forma.

Agora, para uma pessoa codificar em C# e compilar para Android, ou o compilador teria que conhecer os códigos equivalentes para traduzir todas as bibliotecas .NET utilizadas em bibliotecas Android equivalentes, o que é impossível, já que não existe equivalência para tudo, ou o programador teria que conhecer as bibliotecas da plataforma Android, o que é obviamente o mais indicado.

Mas então, se o programador vai ter de aprender a trabalhar com a plataforma de qualquer maneira, que diferença faz simplesmente permitir outra sintaxe? Tá, é uma questão de gosto e costume, mas acaba sendo a menor parte do aprendizado se acostumar com outra sintaxe de codificação (embora as linguagens do exemplo sejam muito parecidas em sintaxe de qualquer maneira, afinal são ambas baseadas no C++ e o C# em si foi totalmente criado "copiando" as boas ideias do Java).

Resumindo a história: o Google não teria grande trabalho para criar compiladores que traduzissem sintaxe e semântica das mais diversas linguagens do mercado em bytecode Dalvik. Por sua vez, o Google poderia se matar tentando fazer cada compilador entender uma chamada à biblioteca X e converter à biblioteca equivalente do Android e mesmo assim não ficaria confiável o suficiente (e muitas vezes não teria equivalência de qualquer maneira). Então, o programador teria de conhecer todas as bibliotecas Android de qualquer forma. Enfim, o ganho prático seria tão pequeno que o investimento não é justificável.

A única vantagem seria marketing, que é o motivo pelo qual a Microsoft criou (ou apoiou a criação) de tantos compiladores para tantas dezenas de linguagens para o MSIL da plataforma .NET. Mesmo assim, forçando todas elas a usarem as bibliotecas da plataforma, obviamente.

Espero que a explicação tenha ficado clara para todos. Ou seja Luiz, seu amigo tinha razão. Mas não tinha, ao mesmo tempo. Agora você já pode argumentar com ele para defender ou atacar a ideia. Boa sorte.