Artigo Java Magazine 69 - Java ME Platform SDK 3

Assim como os seres vivos, os softwares de computador também evoluem a partir do momento em que se inicia um novo ciclo. No caso da principal ferramenta de desenvolvimento da plataforma Java ME, o Wireless Toolkit, este seu novo ciclo trouxe-lhe evoluções bastante expressivas. Mudanças que vão desde o nome, passando pelo novo conceito da ferramenta, até chegar às suas novas funcionalidades.

A ferramenta que antes era considerada um simples toolkit (caixa de ferramenta), agora passa a ser um completo SDK, contando com um ambiente integrado de desenvolvimento. Editor de código, emuladores, nova máquina virtual e APIs são somente algumas das muitas novidades trazidas por esta nova ferramenta. Sem falar que até o seu nome é novidade, pois agora a ferramenta é chamada de Java ME Platform SDK 3.

Com todas essas novidades é possível constatar o grande passo que a plataforma Java ME dá em direção a uma maior popularização da plataforma. Pois com o ambiente de desenvolvimento integrado baseado no NetBeans, novos desenvolvedores terão mais facilidades de criar as suas primeiras aplicações, o que garante uma maior chance de crescimento da comunidade Java ME.

Segundo a Biologia, o processo permanente de mudança que vem transformando a vida na Terra, desde o seu princípio mais simples até a sua atual diversidade, é conhecido como Evolução. A evolução ocorre quando um ser vivo se reproduz, e pequenas mudanças aleatórias nos seus genes fazem com que o seu descendente seja diferente dele próprio. Essas mudanças, se benéficas, fazem com que o indivíduo sobreviva o tempo necessário para se reproduzir, dando início a um novo ciclo de transformações, o que resulta no surgimento de novas espécies.

Num paralelo entre o processo de evolução dos seres vivos com o de um software de computador, verificamos como ambos são parecidos. O software, geralmente, inicia o seu clico de vida de forma bem simples, com poucas funcionalidades, somente com o intuito de atender certa demanda do momento. À medida que vai sendo utilizado, o software, se for bom, acaba aguçando a criatividade dos usuários, que solicitam novas versões mais aperfeiçoadas e com mais funcionalidades. Estas solicitações induzem o software a entrar no clico de evoluções, resultando em novos releases.

Neste artigo, falaremos sobre como este processo evolutivo dos softwares atingiu o Wireless Toolkit (WTK). Apresentaremos algumas das principais novidades que a Sun Microsystems preparou, justificando a mudança do seu nome para Java ME Platform SDK 3.

De Toolkit para SDK

O fato de a Sun ter mudando o nome do WTK não deve causar muito espanto aos desenvolvedores, tendo em vista que esta não é a primeira vez. Desde o surgimento da plataforma Java ME, por volta de 1999, esta já é a segunda vez que a Sun muda o nome da ferramenta. O nome original, Java 2 Platform Micro Edition Wireless Toolkit, foi substituído em 2007, devido à nova versão 1.5 (ou 5) da plataforma Java. Desde então, a Sun retirou o famigerado “2” de todos os nomes de suas plataformas e ferramentas. Com isto, o que era J2ME virou Java ME, o que também acabou refletindo na primeira mudança de nome do WTK para Sun Java Wireless Toolkit.

A mudança do nome na nova versão, que agora insere o termo SDK (Standard Development Kit), se deve ao fato da ferramenta proporcionar um ambiente de desenvolvimento completo, e não somente os emuladores, ferramentas de monitoração (e.g. monitor de memória), códigos de exemplo, documentação, etc. O pacote agora também vem com editor de código com assistência de codificação (veja a seção “Netbeans “Lite”). Além disso, a plataforma Java ME é suportada de forma muito mais completa (o antigo WTK suportava apenas a configuração CLDC, exigindo toolkits separados para CDC e outras variantes). Um arsenal completo que eleva a categoria da ferramenta, justificando o acréscimo do termo SDK.

NetBeans “Lite”

De longe a mais importante e impactante novidade do Java ME Platform SDK 3 é o ambiente de desenvolvimento integrado (veja Figura 1), baseado na plataforma NetBeans. Nas versões anteriores da ferramenta, todo o desenvolvimento das aplicações (e.g. escrita de código) tinha que ser feito numa ferramenta (IDE) à parte, como por exemplo, Eclipse, NetBeans, VistaMax, etc. O trabalho do WTK era executar os emuladores, alterar configurações de ambiente da plataforma, monitoramento de memória, dentre outras funcionalidades auxiliares. IDEs como Eclipse e NetBeans, por exemplo, permitiam que o WTK pudesse ser integrado, possibilitando ao desenvolvedor uma transparência do seu uso.

As principais ferramentas deste ambiente de desenvolvimento integrado são o editor de código, gerenciador de projetos e arquivos, integração com o Ant, configurações do projeto (e.g. propriedades do arquivo JAD), ofuscador de código, além de outras de cunho mais geral, encontradas em qualquer distribuição do NetBeans.

Quem já trabalha com o Netbeans Mobility Pack vai se sentir em casa neste novo ambiente, pois ambos são praticamente o mesmo. Além disso, aqueles que, porventura, decidirem migrar para o NetBeans Mobility Pack futuramente, já que este dispõe de mais funcionalidades, não encontrarão barreiras. Pois o arquivo de projeto do Java ME Platform SDK 3 é totalmente compatível com o Mobility Pack, o que facilita muito a migração entre as ferramentas.

A KVM se Despede

Após quase dez anos desde sua chegada, a máquina virtual da Java ME, a Kilo Virtual Machine (KVM), finalmente encerra o seu ciclo de vida. Este fim já era esperado, já que há alguns anos, a KVM já não estava mais presente nos dispositivos móveis disponíveis no mercado, sendo esta substituída pela CLDC HotSpot Virtual Machine. Um projeto mais moderno e robusto, que já conseguia atender melhor as atuais demandas por desempenho.

O que prolongou um pouco mais a vida da KVM foi o fato da Sun continuar utilizando-a em seus emuladores. Até a última versão do WTK, a 2.5.2, todos os emuladores ainda eram baseados na KVM. No entanto, com a chegada do Java ME Platform SDK 3 a Sun finalmente “aposentou” a KVM, trazendo de uma vez por todas, a CLDC HotSpot Virtual Machine também para os seus emuladores, inclusive para a configuração CDC. Com esta mudança, o comportamento das aplicações no emulador ficou mais parecido ao encontrado nos dispositivos reais.

Dentre as principais vantagens da CLDC HotSpot Virtual Machine, comparada à KVM, estão a compilação dinâmica das instruções de bytecode em instruções nativas (veja o quadro “Compilação Just-in-time (JIT)”), menor consumo e fragmentação de memória, maior economia da bateria, dentre outras. Em termos de números, a execução de uma instrução compilada dinamicamente, chega a ser cinquenta vezes mais rápida do que uma instrução interpretada.

Para conhecer um pouco mais sobre a CLDC HotSpot Virtual Machine e a sua chegada aos dispositivos móveis, veja a seção Links, além do artigo “Java: Uma perspectiva”, da Edição 65.

Descobrindo as Diferenças

Existe na Internet uma iniciativa chamada de Wireless Universal Resource File (WURFL), aonde desenvolvedores e entusiastas vêm tentando catalogar todos os dispositivos móveis disponíveis no mercado, assim como suas características. O objetivo é fornecer uma base de dados centralizada para os desenvolvedores. Neste caso, um arquivo XML, afim de que eles possam conhecer, antecipadamente, as principais diferenças que existem de um dispositivo para outro, além de ter uma idéia da fatia de mercado que suas aplicações estão abrangendo.

Com o objetivo de facilitar o acesso às informações providas pelo WURFL (para saber mais sobre esta iniciativa, veja a seção Links), a Sun desenvolveu uma nova funcionalidade, no Java ME Platform SDK 3, chamada Device Database Search, que acessa essa base de dados de uma forma fácil e rápida. O usuário pode tanto solicitar para ver a lista completa de todos os dispositivos disponíveis, como ele também pode aplicar alguns filtros (e.g. fabricante, modelo, JSRs suportadas, tamanho de tela, etc.), a fim de facilitar a busca pelo dispositivo desejado. O resultado é apresentado numa lista, onde modelo e fabricante são identificados. Para ver os detalhes de um determinado dispositivo, basta selecioná-lo na lista, que todas as suas informações serão exibidas numa outra lista ao lado (veja Figura 2).

LWUIT Ganha Força

A equipe do projeto Lightweight User Interface Toolkit (LWUIT) deve estar orgulhosa com esta conquista. Tendo em vista a grande popularização deste projeto entre os desenvolvedores Java ME, a Sun não perdeu tempo em tentar transformar este projeto numa espécie de padrão dentro da comunidade de desenvolvedores. Os engenheiros da Sun devem ter percebido a quantidade de projetos que existem na Internet, que visam melhorar a vida dos desenvolvedores, no tocante do desenvolvimento de interfaces gráficas mais sofisticadas. Com isso, a Sun não hesitou e incorporou o LWUIT como uma de suas bibliotecas padrão, disponibilizou uma aplicação exemplo e integrou uma de suas ferramentas utilitárias, o Resource Manager, dentro do Java ME Platform SDK 3. Alavancando de vez o nome LWUIT dentro da comunidade Java ME.

O LWUIT, para quem ainda não conhece, é um framework de componentes gráficos inspirado no Swing da plataforma Java Standard Edition (Java SE), especificamente modelado e construído para ambientes restritos em poder de processamento e memória, como o dos dispositivos móveis. O LWUIT traz para o mundo móvel, algumas das funcionalidades para o desenvolvimento de interfaces gráficas já conhecidas no desktop e que são bem características do Swing, como por exemplo, layouts (e.g. FlowLayout), renders (componentes que especificam a forma como um objeto é desenhado na tela), manipuladores de evento (e.g. ActionListener), etc.

Com toda esta integração, para um desenvolvedor acrescentar o suporte ao LWUIT à sua aplicação dentro do Java ME Platform SDK 3, basta somente alguns passos: acessar as propriedades do projeto, selecionar Libraries & Resources, clicar no botão Add Library e selecionar a biblioteca LWUIT, que já aparece na lista, junto com as demais bibliotecas disponíveis na ferramenta. Além disso, a aplicação exemplo é bem completa, o que serve como uma boa referência inicial para os desenvolvedores que estão começando no LWUIT (para saber mais sobre LWUIT, veja a Edição 60 e a seção Links). Ela apresenta diversos exemplos de várias partes do framework.

Encontrando o “Gargalo”

Como se os problema de lógica não fossem o bastante, os problemas de desempenho também tem sido uma constante nas aplicações atuais, principalmente nas móveis, devido às exigentes demandas por mais funcionalidades, sem falar das restrições de processamento, inerentes aos dispositivos móveis.

A fim de também facilitar mais esta tarefa dos desenvolvedores, já que por muito tempo esta também foi executada com o auxilio de APIs como System.out.println() e System.currentTimeMillis(), foram criados os monitores de processamento (profiler). São ferramentas que monitoram toda a execução da aplicação, registrando os tempos de execução e a quantidade de vezes que cada método foi executado. Informações muito valiosas quando se está à procura do “gargalo”de um determinado processo. No Java ME Platform SDK 3, esta ferramenta de monitoração é a mesma encontrada em outras distribuições do NetBeans, também usada para testes em aplicações Java SE e Java EE.

Para ativar o profiler para determinada aplicação no Java ME Platform SDK 3, basta habilitar a opção Enable profiler nas propriedades do emulador utilizado. Durante a execução, o profiler registra num arquivo (e.g. data.prof), todas as informações sobre o código que está sendo executado. Ao final da execução, é preciso informar ao SDK, através da opção Profile > Import Java ME SDK Snapshot, o caminho do arquivo gerado pelo profiler, a fim de que a informação coletada seja apresentada. Nesta nova tela que é mostrada (veja Figura 3), o desenvolvedor pode ver o tempo gasto para executar cada método e a quantidade de vezes em que ele foi executado, além de ainda poder agrupar todas estas informações por classe ou por pacote. Dando uma visão mais macro dos tempos de execução de cada componente da aplicação.

E mais JSRs

A cada dia novas APIs são finalmente especificadas, tornando-se aptas a serem implementadas por algum fabricante, que suporte a plataforma Java ME em seus dispositivos móveis. O que normalmente acontece é a implementação dessas APIs chegarem primeiro às ferramentas de desenvolvimento, tendo em vista uma maior facilidade de implementá-las em plataformas Windows ou Linux, por exemplo, para depois chegarem aos dispositivos.

No Java ME Platform SDK 3, três novas APIs estão finalmente disponíveis para os desenvolvedores: Mobile Sensor API (JSR 256) (veja o artigo da Edição 55), XML API for Java ME (JSR 280) e a Java Binding for the OpenGL ES API (JSR 239). A primeira é responsável por fornecer acesso a alguns sensores (e.g. acelerômetro) disponíveis em certos dispositivos móveis (veja o quadro “Trabalhando com Sensores no Emulador”). A JSR 280, por sua vez, define uma API exclusiva para manipular arquivos XML com parsers SAX2 e DOM. A idéia é acabar com a fragmentação que existe atualmente, onde cada API que precisa manipular XML define o seu próprio mecanismo para desempenhar este trabalho (e.g. Web Services Specification (JSR 172)). E finalmente, a JSR 239 vem para prover o suporte ao desenvolvimento de gráficos 3D através da biblioteca OpenGL ES, a qual é um subconjunto da OpenGL 1.3.

Para fechar o pacote das novas API, o Java ME Platform SDK 3 também disponibiliza aplicações exemplo para cada nova API suportada, inclusive as que já eram suportadas. Um ótimo “pontapé inicial” para quem está começando a trabalhar com as APIs mais recentes.

Quanto mais Emuladores, Melhor

É inquestionável a qualidade dos emuladores disponibilizados pelo Java ME Platform SDK 3, assim como os de suas versões anteriores. Todos eles seguem à risca cada ponto das especificações das APIs, dando maior segurança ao desenvolvedor sobre a corretude do seu código. Se nenhuma exceção for lançada, alertando sobre alguma operação indevida, é porque ele está no caminho certo.

No entanto, por mais que as especificações sirvam para definir uma base comum, além de diminuir as chances de incompatibilidade entre as diferentes implementações, no mundo real as coisas não são tão perfeitas assim. É comum encontrar problemas de incompatibilidade entre uma implementação feita para o Windows, que não funciona no Linux, e vice-versa. No mundo móvel então, é ainda pior. Aplicações feitas para rodar num dispositivo da Nokia podem precisar de ajustes para rodar perfeitamente num Motorola ou Sony Ericsson, por exemplo. Por mais que sigam a risca o que está na especificação, sempre é possível ter algo na implementação (inclusive bugs) que gera um comportamento diferente. A complexidade e as restrições dessas plataformas móveis potencializam ainda mais este problema.

Tendo em vista essas possíveis diferenças, os testes em outras plataformas se tornam muito importantes para uma aplicação Java ME, que deseja rodar em dispositivos de mais de um fabricante. Nesta versão do Java ME Platform SDK 3 é possível importar outros emuladores desenvolvidos, por exemplo, pela Nokia, Samsung, Motorola, Sony Ericsson, dentre outros, para dentro da ferramenta e usá-los para testar suas aplicações. Uma funcionalidade já encontrada no NetBeans Mobility Pack.

Para importar novos emuladores, é preciso informar o caminho do SDK do fabricante, o qual os emuladores pertencem. Para isto, deve-se acessar Tools > Java Platforms, selecionar o tipo de plataforma J2ME, clicar em Add Plaform, selecionar Custom Java ME MIDP Platform Emulador e informar os caminhos solicitados pelo restante do wizard. Após ter configurado a nova plataforma, basta acessar as propriedades do projeto e selecionar a nova plataforma e o emulador a ser utilizado.

Testes em emuladores é realmente uma “mão na roda”, pois facilitam muito o desenvolvimento, tendo em vista a rapidez que é por em execução a aplicação no emulador. Entretanto, eles nunca vão substituir o teste no dispositivo real, pois, se de um emulador para outro já existem diferenças, imagine do emulador para o hardware.

Suporte Oficial

Com exceção do sistema operacional Symbian, outros sistemas como Palm OS e Windows Mobile, também bem populares no mercado, nunca foram referência pelo seu suporte à plataforma Java ME, pelo contrário. Esta questão, acredito, deve-se ao fato que ambos possuem, desde muito cedo, suas próprias plataformas nativas (baseadas em C) de desenvolvimento de aplicações. Ambas muito bem difundidas e poderosas, e que acabou gerando uma comunidade de desenvolvedores duradoura.

Com relação ao Palm OS, a Sun até que se esforçou na época do lançamento da primeira versão do Wireless Toolkit (ainda MIDP 1.0), disponibilizando uma máquina virtual que podia ser instalada nos dispositivos da empresa Palm. No entanto, a investida não vingou, talvez pelo desinteresse da própria Palm, e o projeto ficou pelo caminho. A IBM também tentou, lançando uma máquina virtual chamada Websphere Everyplace Micro Environment (WME), com suporte ao MIDP 2.0. A Palm dessa vez até esboçou um incentivo, publicando a VM da IBM no seu site como um produto homologado. Porém, em 2008, o incentivo acabou e a Palm retirou o apoio. Hoje este projeto está parado no tempo, assim como o próprio Palm OS, que vem sumindo do mercado aos poucos.

A história da plataforma Java ME no sistema operacional da Microsoft não é muito diferente da vivida pela Palm. Esta também é marcada pela dificuldade de encontrar uma máquina virtual robusta e sólida, o que ajudaria a difundir melhor a Java ME nos populares PDAs da empresa de Bill Gates. No entanto, por mais que o suporte seja fraco, o Windows Mobile chega ainda a ser melhor que o Palm OS, com relação a Java ME. Nas versões para smartphones do Windows Mobile, por exemplo, até existe uma máquina virtual que já acompanha o dispositivo. Por mais que seja restrito em recursos, ainda serve para rodar aplicações mais simples. A IBM também investiu na Java ME para o Windows Mobile, disponibilizando uma versão paga da sua máquina virtual, WME, voltada para versões anteriores deste sistema.

Mas agora, as coisas parecem que vão melhorar para os desenvolvedores Java ME que querem rodar suas aplicações no Windows Mobile. A Sun está disponibilizando, no Java ME Platform SDK 3, uma máquina virtual para o Windows Mobile 6, que pode tanto ser instalado em um emulador do próprio sistema operacional no PC, quanto num dispositivo real. Tudo o que o desenvolvedor precisa fazer é instalar a maquina virtual (veja Figura 4), através do arquivo sun-java-cldc-emu.cab, que se encontra disponível no SDK na pasta JavaMESdkHome\on-device\winmobile-arm, no emulador ou no dispositivo. Além de executar as aplicações, o desenvolvedor ainda tem a possibilidade de depurar suas aplicações tanto no emulador quanto no dispositivo real.

Com mais esta plataforma dando suporte à Java ME, agora com a assinatura da Sun, a plataforma Java dá mais um passo muito importante na consolidação do seu nome nas principais plataformas móveis do mercado.

Conclusão

A Sun, com certeza, acertou com o Java ME Platform SDK, pois a falta do ambiente de codificação do Wireless Toolkit atrapalhava, de certa forma, os novos desenvolvedores. O problema era que estes não conseguiam, rapidamente, codificar um Hello, World!. Haja vista que precisavam usar um editor de código externo, importar o projeto para o toolkit, etc.

Com o Java ME Platform SDK tudo ficou mais integrado. A facilidade de criar um projeto, codificar, escolher o emulador e colocar para executar são características muito importantes, que todo iniciante, em qualquer plataforma, gosta de ter. Entretanto, o Java ME Platform SDK é indicado somente para aplicações de teste ou pequenas, pois algumas funcionalidades importantes no desenvolvimento de aplicações mais complexas, como depuração e controle de versão, não estão disponíveis. Nesses casos, o recomendado mesmo é o NetBeans Mobility Pack, que oferece o ambiente completo do NetBeans mais uma série de ferramentas específicas para Java ME.

Compilação Just-in-time (JIT)

A característica da plataforma Java que permite que suas aplicações sejam possíveis de serem executadas em diferentes plataformas (e.g. Windows e Linux), sem necessidade de recompilação, é o fato do seu código-fonte ser compilado para uma representação intermediária, conhecida como bytecode. Mas sua execução depende de outra aplicação, esta sim dependente de plataforma: a máquina virtual, que interpreta o bytecode.

Os ganhos em portabilidade com este código intermediário, por outro lado, gera problemas de desempenho, pois a interpretação é bem menos eficiente que a execução de código nativo. Entretanto, o problema pode ser resolvido com ajuda da técnica de compilação Just-in-time (JIT), que consiste na compilação do bytecode para código nativo durante a execução da aplicação. No momento em que um método vai ser executado, este é convertido numa representação de código de máquina. Por isso o termo Just-in-time que, em português, significa “no momento exato”. Este código compilado fica salvo na memória, pronto para execuções futuras.

Além da plataforma Java, a .NET também utiliza esta técnica. Neste caso, o código intermediário convertido pela máquina virtual .NET é o Microsoft Intermediate Language (MIL). Para saber mais sobre a JIT, veja a seção Links.

Trabalhando com Sensores no Emulador

Existem algumas APIs Java ME que interagem com alguns tipos de hardware ou serviço, que vem integrado a algumas linhas de dispositivos móveis. Por exemplo, a Mobile Sensor API (JSR 256), que interage com sensores (e.g. acelerômetro); a Location API (JSR 179), que captura os dados de um GPS; e a Payment API (JSR 229), que fornece serviço de pagamentos em geral.

Imaginar como se testa uma aplicação desenvolvida com estas APIs, no dispositivo real, não é difícil. Pois neste caso, o hardware ou serviço está presente no dispositivo e a API vai acessá-lo para poder retornar suas informações. Mas o que acontece quando não se tem o dispositivo real em mãos, para testar a aplicação? A resposta é simples: para cada API que interage com um hardware ou serviço, os emuladores do Java ME Platform SDK executam tais papéis, simulando-os.

No caso da JSR 256, para a qual a emulação de sensores é mais uma novidade do Java ME Platform SDK, o desenvolvedor pode alterar as informações que o acelerômetro retorna. Desta forma, o desenvolvedor pode informar novos valores para as coordenadas x, y e z, que representam a leitura tridimensional deste tipo de hardware.

Para acessar as ferramentas de simulação dos emuladores, o desenvolvedor precisa acessar a opção View > External Events Generator, disponível no próprio emulador. Depois disto, uma nova tela será apresentada, com uma série abas nela. Cada aba, por sua vez, representa um tipo de hardware ou serviço que pode ser simulado. No caso do acelerômetro, a aba Sensors é a que fornece os meios para simulá-lo. Nesta mesma aba, o Java ME Platform SDK ainda fornece a simulação de um sensor de temperatura.