Programação Java ME
Parte 2: Ferramentas e Primeiros Passos
E
ste artigo continua a série
iniciada na edição anterior,
na qual introduzimos toda
a complexa variedade de confi-
gurações, perfis e APIs que fazem
parte da plataforma Java, Micro
Edition. (Note que este artigo é
bastante independente do anterior,
podendo ser acompanhado inteira-
mente tendo-se apenas conhecimen-
to inicial sobre Java ME.)
Como anunciado, daqui em diante
iremos nos concentrar na configu-
ração CLDC e no perfil MIDP,
por serem os mais populares – e
de aplicabilidade mais provável
– devido à enorme disponibili-
dade dos dispositivos que imple-
mentam este perfil, os telefones
celulares.
Aliás, se você tem um celular
razoavelmente recente, este é um
aparelho tão poderoso que usá-lo
para fazer ligações de voz parece
um desperdício! Algo como usar
uma Ferrari para ir comprar pão na
esquina. Vamos, então, pôr as mãos
à obra e dar um bom uso à surpreen-
dente capacidade de processamento
que carregamos no bolso.
Ferramentas para MIDP
O programador Java moderno está
habituado a ferramentas de desenvol-
vimento de alto nível, e se precisamos
delas para criar sofisticadas GUIs
(interfaces gráficas) ou gigantescos
servidores “Enterprise Edition”, não
é porque o Java ME é “micro” que nos
contentaremos com ferramentas rudi-
mentares. Pelo contrário, existe hoje uma
boa variedade de IDEs com bom suporte
para esta variante do Java.
Conheceremos três destas ferramentas
aqui: o Wireless Toolkit (WTK) da Sun,
8 Java Magazine • Edição 45
Java45.indb 8
e os plug-ins para Eclipse MTJ e Eclipse-
ME. Vamos explorar as funcionalidades
disponíveis nestes programas, a sua
configuração, e usar um projetinho “alô
mundo” para nos ambientarmos. No pró-
ximo artigo da série, cobriremos também
o NetBeans Mobility Pack, e construiremos
uma MIDlet completa (mas sem depender
de nenhum IDE ou plug-in específico,
somente do WTK).
Trabalhando com o Java Wireless
Toolkit
O WTK é o “JDK do Java ME”, por dois
motivos. Primeiro, contém ferramentas
essenciais para desenvolvimento para
Java ME, como o pré-verificador (bin/pre-
verify), o emulador de dispositivos CLDC
(bin/emulator), e as bibliotecas necessárias
para compilar e testar seus programas. Se-
gundo, ferramentas mais avançadas, como
plug-ins de IDEs, costumam depender do
WTK. Se você instalar algum IDE ou mes-
mo um plug-in Java ME que não exige uma
instalação prévia do WTK, tipicamente é
porque o WTK já vem embutido.
O WTK pode ser baixado de java.sun.
com/products/sjwtoolkit. Neste artigo apre-
sentamos o WTK 2.5, cujo release final
foi recentemente disponibilizado. Este
release necessita do Java SE 5.0 ou supe-
rior. Se você já usou versões anteriores
do WTK, veja o quadro “As novidades do
WTK 2.5”.
Após a instalação, execute o Wireless To-
olkit (ktoolbar). Ao contrário do JDK, que só
oferece ferramentas de linha de comando, o
WTK inclui muitas ferramentas gráficas. A
Figura 1 mostra a principal delas, o emulator,
em ação, logo após compilar e executar um
projeto. Para fazer esta execução de teste,
selecione Open Project, abra um projeto (é
apresentada uma lista com todos os demos
incluídos no WTK), e execute-o com Run.
Você verá um emulador de celular, como
25.03.07 20:42:54
 Comece a programar
para a plataforma Java
ME, com o Wireless
Toolkit e o Eclipse, MTJ
e EclipseME

OSVALDO PINALI DOEDERLEIN

mostrado na Figura 2. As teclas do aparelho

emulado podem ser acionadas pelo teclado
ou clicando sobre as mesmas com o mouse.
Após a execução, serão exibidas algumas
estatísticas de desempenho.
Finalmente, o botão Settings permite
visualizar e modificar a configuração de
um projeto. A Figura 3 mostra uma das pá-
ginas do extenso diálogo de configuração.
Este diálogo configura tanto as opções de
compilação (que ficam num project.proper-
ties no diretório-raiz do projeto) quanto os
descritores de deployment (MANIFEST. Figura 1. Tela principal do WTK.
MF) que as MIDlets exigem.
Não investiremos tempo criando pro-
gramas com o WTK, que não é, sozinho, encontrados no seu diretório bin, cujo
um IDE completo. Mas apresentaremos conhecimento é útil mesmo que na maior
uma visão geral das suas ferramentas. parte do tempo você use IDEs. Os IDEs,
A Tabela 1 lista todos os programas em grande parte, irão automatizar o uso

Ferramenta Descrição
Seleciona o dispositivo default que será usado pelo emulator, caso seu parâmetro
DefaultDevice
-Xdevice: não seja usado.
Emulador de Java Card. Necessário para rodar aplicações que interagem com smart-
cref
cards, através do package APDU da SATSA (JSR 177).
Simula um dispositivo Java ME. Ver Figura 2. Tem várias opções de diagnóstico e
pode simular dispositivos variados. Os dispositivos são definidos por arquivos sob
emulator wtklib/devices, o principal destes sendo um .properties que determina vários aspectos
do dispositivo como o tamanho da tela, mapeamento de teclas, fontes disponíveis e
outros aspectos.
Gerenciador de recursos de internacionalização (I18N). Também disponível pelo
i18ntool
launcher utils.
ktoolbar GUI principal do WTK. Ver Figura 1.
Variante do keytool do JDK, específico para Java ME. Necessário para aplicações que
mekeytool
trabalham com criptografia, assinaturas digitais etc.
Seleciona opções de funcionamento dos dispositivos: servidor de proxy, velocidade
prefs de emulação, confiabilidade da rede, perfis de segurança, propriedades para várias
APIs específicas.
Faz a pré-verificação de bytecode já compilado pelo javac. Isto enriquece os arquivos
preverify
.class com informações adicionais exigidas pelas JVMs ME.
Servidor e Registrar de SIP (Session Initiation Protocol). Ver Figura 5. Também disponível
siptool
pelo lançador utils.
Permite lançar 12 diferentes utilitários para dispositivos: monitores de memória ou
utils rede, gerenciamento de certificados e recursos, geradores de stubs para web services,
serviços de rede móvel etc. Ver Figura 4.
wscompile Compilador de WSDL específico para Java ME.
Tabela 1. Programas executáveis do WTK 2.5. Figura 2. Emulador de celular, exibindo o demo JBricks.

Edição 45 • Java Magazine 9

Java45.indb 9 25.03.07 20:42:55

 Programação Java ME - Parte 2
destas ferramentas, portanto os concei-
tos e capacidades são um aprendizado
reusável.
Um fato que já podemos deduzir desta
relação de ferramentas, ainda mais se você
executá-las e explorá-las um pouco, é que
o desenvolvimento de aplicações para ce-
lulares, seja com Java ou outra plataforma,
pode ser bastante complexo, porque não
envolve somente o aparelho. Muitas APIs
e operações necessitam também da infra-
estrutura da rede móvel.
Por exemplo, o projeto SIPDemo ilustra
comunicação P2P com o protocolo SIP
(Session Initiation Protocol). Mas isso só vai
funcionar se houver um Registrar – uma
espécie de serviço de nomes do SIP – na
rede. Isso será tipicamente implementado
pela própria operadora ou por parceiros
que operem na sua rede privada. Já no am-
biente de desenvolvimento, tudo precisa
ser emulado: o fone, a rede, e quaisquer
serviços de rede de que necessitemos. Os
diversos utilitários lançados pelo progra-
ma utils (Figura 4) fazem isso; na Figura
5, vemos o servidor de SIP.
Funcionalidades de rede que dependem
somente dos dispositivos não exigem pro-
gramas adicionais; por exemplo, se você
carregar o projeto BluetoothDemo, pode
executá-lo duas vezes, e os dois celulares
Figura 3. Propriedades de um projeto do WTK.
10 Java Magazine • Edição 45
Java45.indb 10
emulados irão se “enxergar” e se comuni-
car, como se fosse via Bluetooth.
Outra capacidade do WTK que devemos
destacar é seu extenso suporte a monitora-
ção de rede. Com o utilitário prefs, página
Monitor, você pode ativar diversas opções
de monitoração. Após a ativação, inicie
novamente o BluetoothDemo no emulador
para ver o Network Monitor. Testando com
o SIPDemo, podemos examinar o tráfego
do protocolo SIP na rede móvel emulada.
Veja isso na Figura 6: o monitor faz uma
exibição detalhada e bem estruturada não
só desse, mas de doze protocolos (afinal,
o ponto forte de um celular é a comuni-
cação, não?).
No quesito de desempenho, podemos
ativar também um profiler muito com-
pleto (também ativado em prefs>Monitor).
Veja o quadro “Primeiras palavras sobre
desempenho”.
Trabalhando com o Eclipse, opção 1:
Mobile Tools for Java
Apesar de todas as capacidades do WTK,
precisamos de um ambiente de desen-
volvimento mais completo: com editor,
depurador e outras ferramentas, tudo isso
integrado às facilidades do WTK. Investi-
garemos em primeiro lugar o suporte para
Java ME do IDE Eclipse.
Figura 4. O lançador utils, mos-
trando várias ferramentas e serviços
de rede móvel.
O suporte para Java ME é um ponto fra-
co histórico do Eclipse, que até há pouco
tempo nem tinha subprojetos específicos
para as plataformas “micro”, deixando
seus usuários dependentes de soluções
de terceiros. Felizmente havia o projeto
EclipseME, também open source, porém
não muito avançado. Isso além de outras
soluções comerciais.
Ainda que com atraso, a Fundação Eclipse
acordou para a demanda, disparando em
2006 uma série de projetos para construir
ferramentas que suportem plataformas
limitadas. O projeto-master é o Device Sof-
tware Development Platform (DSDP), que
contém os subprojetos Device Debugging,
eRCP, Mobile Tools for Java (MTJ), Native
Application Builder e Target Management.
Note que nem todos estes projetos se ocu-
pam exclusivamente de Java ME, pois o
escopo da Fundação Eclipse é mais amplo
do que a plataforma Java ou, ainda que
usando apenas Java, mais amplo do que as
APIs abençoadas pelo JCP. Mas neste artigo
inicial vamos examinar somente o MTJ, que
é o principal: uma extensão do JDT para
desenvolver aplicações Java ME.
O MTJ ainda está em desenvolvimento,
sendo a versão 1.0 esperada para junho de
2006 (data do release do “Europa” – Eclipse
3.3). Na data em que escrevo, o melhor
release estável do MTJ é o 0.7, que ainda
é compatível com o Eclipse 3.2.x. Testei o
MTJ 0.7 com o Eclipse 3.2.2.
Instalando e configurando o MTJ
Para instalar, basta descompactar o
mtj-runtime-<versão>.zip sobre a sua ins-
talação do Eclipse. Ao reiniciar o Eclipse
você verá um novo menu MTJ na barra de
menu principal, mas isso só contém duas
opções, para deployment e gerenciamento
de segurança. A configuração principal
do MTJ fica em Window>Preferences, veja
a Figura 7.
O MTJ precisa de pelo menos uma “de-
finição de plataforma Java ME”; isto é, o
Wireless Toolkit. Na página Mobile Tools
for the Java Platform>Device Platform, acione
Add e selecione o diretório de instalação do
WTK, que deverá finalmente aparecer na
lista de Device Platforms. Abaixo desta, será
exibida a lista de Devices suportados pela
plataforma selecionada. Deveremos ver as
25.03.07 20:42:56
 quatro definições de dispositivos que são funcionalidades, especialmente capacidades de do pelo MTJ. Pelo menos para mim, o
incluídas no Sun WTK 2.5. depuração no aparelho real (que pode exigir mais MTJ selecionou por default a opção MTJ
Em seg u ida, vá à pág i na Runtime plug-ins, cabos seriais e novas configurações, Security Manager for IBM’s JRE (v.5.0.0)
Platform e selecione Add. Dessa vez detalhes que não cobriremos aqui). Keytool. Isso só é boa idéia se você estiver
você não escolherá um diretório, e sim utilizando a JVM da IBM para executar o
uma das Device Platform já cadastradas. Na página Security, podemos escolher Eclipse. Se você é como 95% dos usuários
A diferença é que a Device Platform é qual gerenciador de segurança será usa- do Eclipse e usa a JVM da Sun, selecione
utilizada para compilar os projetos, e a
Runtime Platform é usada para executá-
los. Na lista de Device Platform, o botão
Info permite visualizar detalhes de cada
plataforma, ou seja as APIs suportadas.
Já na lista de Runtime Platform, o botão
correspondente Edit permite visualizar
e também customizar o runtime selecio-
nado, como na Figura 8.

Se você tiver feito o download dos SDKs para

Java ME específicos para algum fornecedor de
aparelhos – como Nokia, SonyEricsson etc. – estes
costumam conter versões customizadas do WTK
(provavelmente do WTK 2.2, pois o 2.5 ainda é
muito recente na data em que escrevo). A vanta-
gem destes WTKs customizados é que eles possuem
definições de dispositivo que correspondem mais
fielmente a todos os modelos de celulares daquele
fornecedor. Se quiser, você pode configurar o MTJ
para utilizar também estas definições. Verifique a
documentação do SDK do celular quanto a outras
Figura 5. O serviço SIP Proxy & Registrar, necessário para executar aplicações SIP.

Figura 6. O Network Monitor, destacando a aba do protocolo SIP.

Edição 45 • Java Magazine 11

Java45.indb 11 25.03.07 20:42:57

 Programação Java ME - Parte 2
a opção MTJ Security Manager for SUN’s
JRE (v.1.4.2) Keytool. Da mesma forma, na
página Signing, se você não usa a JVM da
IBM, selecione o MTJ Signing Provider for
SUN’s WTK(v2.2)jadtool.
Primeiras palavras sobre Desempenho
...ah não, lá vem o Osvaldo com sua obsessão por
desempenho, mal começou a série e ainda nem
vimos uma linha de código! Bem, neste caso isso é
justificado. Os dispositivos não são chamados “limi-
tados” devido ao seu tamanho, e sim devido à falta
de gigahertz, gigabytes, e gigabits-por-segundo. Pro-
gramadores habituados com técnicas, ferramentas e
frameworks de altíssimo nível – que fazem tudo ficar
mais fácil, porém maior e mais lento – têm dificulda-
de em entrar no mundo do Java ME, onde não existe
nenhum “giga”. Será preciso ter parcimônia ao gastar
tempo, espaço e banda. O exemplo que se segue é
um primeiro pontapé para acordar seus instintos de
hacker escovador de bits!
Figura Q1. Profiler de métodos. No lado esquerdo vemos a árvore de invocações de métodos, com o tempo relativo gasto por cada um. No lado direito, estatísticas detalhadas de execução de
todos os métodos dentro do nó selecionado na árvore.
12 Java Magazine • Edição 45
Java45.indb 12
Criando um projeto
Tudo configurado, na perspectiva Java (o
MTJ não cria uma perspectiva específica
para Java ME), crie um novo projeto do tipo
Mobile Tools for the Java Platform>MIDlet
A Figura Q1 mostra o resultado do profiling
do demo JBricks (Figura 2), o milésimo clone do
clássico jogo Breakout*. O resultado do profile é
extremamente revelador: parece que o programa
está gastando nada menos que 47% do tempo
de processamento (cycles) num único método de
API, Graphics.drawArc(). Suspeitei, e verifiquei nos
fontes (Ball.java), que o jogo usa este método para
desenhar a bolinha, o único elemento animado na
maior parte dos frames. Se fosse numa VM Java
SE, cujas operações gráficas são aceleradas pela
Java 2D e por modernas placas de vídeo, isso não
teria importância: desenhar uma bolinha com
uma dúzia de pixels de diâmetro teria um custo
Project. Na primeira página de proprieda-
des do projeto, escolha algum nome, como
“AloMundoMTJ”. Na segunda página
(Java ME Runtime Platform), escolha uma
plataforma. A terceira página também
desprezível. Mas no Java ME não é bem assim. e
Muitos celulares já têm boa aceleração de gráficos d
2D, mas isso não é algo com que você possa contar, G
especialmente nos aparelhos mais baratos. (E só
os modelos de última geração, ainda muito caros,
têm aceleração 3D.) Então, essa forma de desenhar J
a bolinha do jogo é absurdamente ineficiente**. p
Ineficiente e sem nenhuma justificativa: a bolinha f
nunca muda, e quanto à qualidade, veja a Figura q
Q2: é péssima, pois algoritmos de rasterização f
de curvas são notoriamente ruins com tamanhos P
muito pequenos e especialmente sem antialiasing.
Esta bolinha certamente teria um aspecto muito S
melhor se fosse desenhada à mão, pixel por pixel, m
25.03.07 20:42:57
 não apresenta novidades e não exige cus-
tomizações. A quarta página (Configure
MIDlet Suite) apresenta várias proprie-
dades descritivas da MIDlet, como nome
do JAR, autor e versão, e principalmente,
o perfil (mantenha o default MIDP-2.0) e
configuração (mantenha CLDC-1.1). Na
quinta e última página (Templates), você
tem a opção de selecionar um template de
projeto; faça isso, escolhendo o único tem-
plate disponível: Hello_World_MIDP. Este
template fará o projeto já ser preenchido
com o mínimo de código exigido para uma
MIDlet. Acione Finish.
O template Hello_World_MIDP gera um

e gravada numa imagem estática como resource

do programa, exigindo apenas um (eficiente)
Graphics.drawImage() a cada frame.
Morais da história:
1. As plataformas mais limitadas suportadas pelo
Java ME nos obrigarão a esquecer alguns vícios de
programação para desktop e servidores, como
ficar muito à vontade com técnicas tão lentas
quanto desenho de curvas, parsing de XML, ou
frameworks ultra-abstratos que parecem teses de
PhD em design patterns.
2. Use os programas de monitoração do WTK.
São ferramentas excepcionais, e irão poupá-lo de
muita dor de cabeça.

Figura Q2. A bolinha do jogo JBricks, ampliada. Como

descobrimos, o programa desenha esta bolinha, incluindo
efeitos de sombra e brilho, com várias operações gráficas,
inclusive a drawArc() que consome quase metade de
Figura 7. Configuração do Mobile Tools for Java no Eclipse.
toda a CPU usada pelo programa. E tudo isso para um
resultado imperfeito.
As Novidades do WTK 2.5
* De 1976, da Atari. Onde trabalhava um tal Steve
Jobs, que contratou o amigo Steve Wozniak para pro-
jetar o hardware. ‘Woz’ fez o projeto em quatro dias
– só lógica discreta TTL, sem processadores – e usan-
A pós um longo período sem releases es-
táveis – o WTK 2.3 nunca saiu de beta, e
a versão anterior foi o 2.2 no final de 2004 – a
novas classes no classpath. Ferramentas do
WTK, em especial o emulador, precisam ser
modificadas para dar suporte a muitas das
do muito menos chips do que a Atari estimara. Isso
rendeu um bônus de US$ 5.000, que Jobs embolsou versão 2.5 restaura o status de produção ao novas APIs, e algumas dessas APIs precisam de
quase todo. (O que nos ensina que só programar bem toolkit do Java ME. A lista de novidades, com- ferramentas novas (ex.: a SIP API necessita da
não garante nada.). E o design premiado de Wozniak?
Era tão compacto que a Atari não conseguiria fabricá-lo parando com o WTK 2.2, é extensa. siptool). Por isso, a adição de novas APIs Java ME
em quantidade. Por isso acabou fazendo outro design Muitos itens são suporte para novas APIs: Secu- costuma exigir novas versões do WTK.
muito mais “feio”, com mais que o dobro de chips, e foi rity and Trust Services (JSR 177), Location (JSR 179), A ktoolbar, que pode ser considerada um
um sucesso. (O que nos ensina que time-to-market é
mais importante do que purismo técnico.) SIP (JSR 180), Content Handler (JSR 211), Scalable mini-IDE – não possui editor de código ou
2D Vector Graphics (JSR 226), Payment (JSR 229), depurador, mas inclui facilidades de gerencia-
** Pelo menos no emulador, que não necessaria- Advanced Multimedia Supplements (JSR 234), mento de projeto, compilação e testes – foi re-
mente tem as mesmas características de desempenho
que o hardware real. Mas isso não invalida o exemplo. Mobile Internationalization (JSR 238), Java Binding construída sobre a NetBeans Platform. Também
Observe que o desenho de arcos e círculos não exige for the OpenGL ES (JSR 239). (Veja o artigo anterior há melhoras no emulador e em praticamente
ponto flutuante, pois há algoritmos que fazem isso só desta série para mais sobre estas APIs.) todas as demais ferramentas.
com aritmética inteira (procure na web por “Digital Di-
fferential Analyzer” e “Bresenham”). Mas até mesmo estes O suporte às APIs da plataforma ME costuma Outra novidade importante é o suporte à
algoritmos são muito mais lentos do que o simples “ca- ser mais difícil que em Java SE/EE: normalmente MSA. Veja o quadro “JTWI e MSA: As novas
rimbo” de uma imagem já pronta na tela. não basta apenas adicionar um JAR com as especificações da plataforma CLDC”.

Edição 45 • Java Magazine 13

Java45.indb 13 25.03.07 20:42:58

 Programação Java ME - Parte 2
JTWI e MSA: As novas especificações da plataforma CLDC
N o artigo anterior comentamos todas as
configurações, perfis e extensões do Java
ME, o que é um panorama confuso, pois mesmo
havendo API padronizadas para quase tudo, os
dispositivos variam no número de APIs que cada
um implementa. Em alguns casos a variação é
inevitável devido à fragmentação do próprio
hardware: por exemplo, não adianta obrigar
todos os dispositivos CLDC/MIDP a implementar
a JSR 82 (Bluetooth & OBEX), pois nem todos os
aparelhos possuem as interfaces físicas corres-
pondentes. E a maioria dos que não possuem
nem permite adicioná-las – celulares e PDAs
em geral não são uma arquitetura aberta como
os PCs, onde milhares de periféricos podem ser
adquiridos posteriormente e conectados a slots
PCI, portas USB e outras interfaces.
No entanto, os dispositivos estão em constante
evolução, e também os serviços e protocolos
utilizados nas redes wireless. E há muitas APIs
que não são dependentes de capacidades
específicas de hardware, e só não são obriga-
tórias hoje devido a fatores como o tamanho
(consumo adicional de ROM). Além disso, existe
uma necessidade de maior padronização de
comportamentos detalhados: por exemplo,
quais variações do formato de arquivo JPEG
são obrigatoriamente suportadas, ou qual
a resolução mínima do clock (usada por
System.currentTimeMillis() e Timer, e importante
para qualquer manipulação de mídia ou jogo
animado). Para melhorar esta situação existem
duas especificações de plataforma adicionais,
a JTWI e MSA, que por motivo de espaço não
comentamos no artigo anterior.
A JTWI
A JTWI procurou reduzir a fragmentação do
mercado de dispositivos por volta de 2003,
14 Java Magazine • Edição 45
Java45.indb 14
package hello_world_midp_package com uma
classe Hello_World_MIDP; nomes bastante
inadequados e fora do padrão de estilo
do Java, sem dúvida de propósito para
lembrar-nos de começar a customizar o
código. A Listagem 1 mostra esta classe
já um pouco alterada: adicionei código
para criar um Command (acionado por uma
soft-key do celular), que quando acionado,
adiciona uma nova mensagem ao form.
agregando o CLDC 1.0 e MIDP 2.0 (ou versões
superiores) a uma coleção um pouco maior de
APIs obrigatórias: JSR 135 (Mobile Media) e 205
(Wireless Messaging).
Mais que exigir novas APIs, a JTWI também
inclui esclarecimentos de algumas questões de
interoperabilidade e segurança, e exigências
maiores de capacidade dos dispositivos. Por
exemplo, a tela deve ter no mínimo 128x128 pi-
xels com 4.096 cores / tons de cinza. (O MIDP 2.1
ainda se contenta com 96x54, preto e branco.)
Também há exigências de comportamento
mais estritas para algumas API: por exemplo, a
resolução do clock deve ser de pelo menos 40
milissegundos; cada aplicação deve poder criar
pelo menos cinco Record Stores, e pelo menos
cinco timers simultâneos... e por aí vai. Estas
exigências extra significam que os dispositivos
identificados como compatíveis com a espe-
cificação JTWI oferecerão ao desenvolvedor
uma quantidade maior de APIs e capacidades
padronizadas, melhorando a portabilidade das
aplicações.
A JTWI, agora com quatro anos de idade, já
pode ser considerada como nível mínimo de
compatibilidade para qualquer aparelho MIDP
fabricado nos últimos dois anos.
A MSA
A JTWI foi um bom tapa-buraco para deficiên-
cias das especificações CLDC 1.0 e MIDP 2.x. Mas
para a nova geração de aparelhos a partir deste
ano, há uma nova especificação mais ambiciosa,
a MSA – Mobile Systems Architecture (JSR 248)*
– cujo release final saiu em dezembro de 2006.
A primeira boa notícia é que a MSA exige a
CLDC 1.1 e a MIDP 2.1, enterrando de vez o CLDC
1.0 (que não suporta números float e double,
um enorme impedimento para portabilidade;
As partes da listagem em negrito são o
código que adiconei. Observe que, para
tratar o evento de command, fiz a própria
classe de MIDlet implementar a interfa-
ce CommandListener. Num programa Java
SE com uma GUI Swing, normalmente
criaríamos uma inner class para isso; mas
embora seja possível usar inner classes
em Java ME, este não é o procedimento
normal. Uma inner class aumenta o tama-
mas felizmente, o CLDC 1.1 já é padrão de fato
no mercado, e na prática já não precisamos nos
preocupar com dispositivos CLDC 1.0).
Em cima disso, a MSA torna seis extensões
obrigatórias: as duas do JTWI e mais as JSRs
75 (FileConnection & PIM), 82 (Bluetooth), 184
(M3G) e 226 (SVG). Também relaciona mais oito
APIs opcionais: 172 (Web Services), 177 (Security
& Trust), 179 (Location), 180 (SIP), 211 (Content
Handler), 229 (Payment), 234 (Multimedia Sup-
plements) e 238 (I18N).
Um dispositivo “MSA” deve conter todas estas
14 APIs extra; um dispositivo “MSA Subset”
deve conter as seis obrigatórias. Comparando
com os aparelhos hoje no mercado, a maioria
dos aparelhos intermediários já possui as APIs
da MSA Subset, pois Bluetooth, MMAPI, SVG e
mesmo M3G já são amplamente suportadas. Já
a MSA “full” inclui várias APIs ainda raras em apa-
relhos mais comuns. Em compensação, daqui a
1-2 anos quando a maioria dos aparelhos já for
aderente à MSA “full” com todas estas 14 APIs
além de outras exigências, os desenvolvedores
poderão contar com uma oferta muito maior
de APIs cuja presença poderá ser presumida em
qualquer aparelho.
A MSA é uma extensão da JTWI, pois além
de exigir as mesmas APIs e mais outras 12, a
MSA também inclui as mesmas clarificações e
exigências de comportamentos de APIs. E inclui
ou aumenta outras. Por exemplo, a tela deve
suportar pelo menos 65.536 cores, o número
mínimo de Record Stores por aplicação sobe
de cinco para 10, etc. Veja muito mais detalhes
nesta edição, no artigo de Marlon Luz.
* Também há uma especificação paralela, MSA Ad-
vanced (JSR 249), que difere principalmente por usar a
configuração CDC e não CLDC.
25.03.07 20:42:59
 nho do programa, muito mais do que um
novo método na mesma classe. Vá se acos-
tumando com estas novas regras... caso
contrário, suas aplicações nem vão instalar
nos dispositivos reais (muitos rejeitam
qualquer JAR com mais de 300 Kb1).
Para executá-lo, você poderá se surpreen-
der porque o menu do projeto Run As não
apresenta nenhuma opção para MIDlet ou
Java ME, só as opções convencionais como
Java Application, que não funcionarão. Pode
ser uma limitação ou bug da versão 0.7 do
MTJ. Então, me acompanhe: Acione Run
As>Run, e no final da lista de configurações
de lançamento, selecione o nó MTJ Applica-
tion e escolha New no seu menu de contexto.
Isso cria a configuração de lançamento apro-
priada, já configurada para o seu projeto e
classe de MIDlet. Modifique somente o nome
da configuração, que deve ser algo como
“New Configuration”; veja a Figura 9.
Execução e Deployment
Execute Run na configuração. O resul-
tado não será muito surpreendente: o já
familiar emulador de celular em execução,
exibindo uma tela em branco exceto pelo
título, e o item de comando “Clique-me!”,
que quando acionado exibe uma mensa-
gem. Se ao acompanhar a seção sobre o
WTK você ativou os monitores de rede ou
de memória, estes serão lançados junto com
o emulador. Assim, todo o poder das princi-
pais ferramentas do WTK fica disponível a
partir do nosso IDE. Mas como o MTJ ainda
não possui páginas de configuração ou ações
correspondentes a todas as opções e ferra-
mentas do WTK, você às vezes pode ter que
acionar o WTK diretamente, por exemplo,
lançando o programa prefs para habilitar
ou desabilitar os monitores.
A Figura 10 mostra o ambiente de de-
senvolvimento completo, com o programa
AloMundoMTJ sendo executado no emu-
lador; a view Output do Eclipse mostrando
mensagens do emulator, e outras views
comuns de depuração (veja a subseção
“Depurando” a seguir).
1 300 Kb é a capacidade mínima especificada pela es-
pecificação MSA, que embora recentemente completada,
já é atendida em certos pontos por muitos dispositivos (a
JTWI só exigia 64Kb). A maior parte dos produtos recen-
tes aceitará JARs maiores, mas isso não é um comporta-
mento portável e padronizado.
Java45.indb 15
Na árvore de projetos, vemos que além META-INF/MANIFEST.MF. (Não adianta
da pasta de fontes (src), META-INF e re- editar o MANIFEST.MF que aparece no
sources (res), que são elementos comuns projeto, pois o MTJ o recria sem a linha
em projetos Java SE ou EE (ainda que o “MIDlet-1...”.)
layout dos projetos em IDEs possa variar),
temos alguns novos elementos. A pasta Depuração
verified contém classes que já passaram Para executar a MIDlet no depurador do
pelo pré-verificador (o MTJ invoca o Eclipse, você terá primeiro que modificar
programa preverify do WTK). E a pasta algumas configurações default do Eclipse,
deployed contém os arquivos finais para para contornar limitações do emulador do
instalação num celular (ou execução num WTK: Em Window>Preferences>Java>Deb
emulador). Resumindo, o fluxo de depen- ug, desative as opções Suspend execution
dências dos de arquivos é: src (código-fon- on uncaught exceptions e Suspend execution
te Java editado por você) _ bin (arquivos on compilation errors, e aumente Debugger
.class compilados pelo Eclipse) _ verified timeout (ms) para 15000 ou mais.
(arquivos .class processados pelo MTJ, que Estas instruções são baseadas na docu-
aciona o preverify) _ deployed (arquivos mentação do EclipseME, mas se aplicam
JAR e JAD gerados pelo MTJ). a ambos os plug-ins cobertos neste artigo,
No sistema de deployment das MIDlets, e provavelmente a qualquer outro depu-
temos sempre um arquivo JAR e um arqui- rador para Java ME que use o WTK. Se
vo JAD, sendo que este último é um descri- você tentar utilizar o depurador sem ter
tor que os aparelhos lêem antes de baixar executado estes “preparativos”, o resultado
o JAR – para quem já conhece os arquivos será uma variedade de erros, de crashes da
JNLP do WebStart, é algo
parecido. (No seu sistema
operacional, ao clicar no
arquivo JAD, o emulator
será lançado, desde que o
JAR correspondente esteja
no mesmo diretório.) A
Figura 10 também mostra
o editor de arquivos JAD do
MTJ. Se você quiser instalar
o programa AloMundoMTJ
no seu celular para testá-lo
“pra valer”, só precisa do
AloMundoME.jar.
A configuração mínima
que devemo s fa z er no
arquivo JAD é adicionar,
na página MIDlets, uma
ent rada como: Name =
Alô Mundo, Class = alo.
AloMIDP. A coluna Icon
pode ficar em branco. Isto
deveria fazer o MTJ gerar
u m M ETA - I N F/M A N I -
FEST.MF com uma linha
como “MIDlet-1: Alô Mun-
do, alo.AloMIDP”, só que
isso não funciona. Se você
gerar os arquivos de de-
ploy, terá que abrir o JAR
e acrescentar esta linha ao Figura 8. Customizando uma definição de runtime do MTJ.
Edição 45 • Java Magazine 15
25.03.07 20:43:00
 Programação Java ME - Parte 2

KVM2 até breakpoints sendo ignorados.
Para fazer um teste, crie um breakpoint no
método comandAction() e acione o comando
“Clique-me!” no emulador. A execução
deverá ser interrompida, permitindo rodar
2 A JVM para Java ME da Sun, onde ‘K’ significa Kilobyte,
em referência ao modesto consumo de memória do Java
ME. Como o nosso ambiente de desenvolvimento é emu-
lado, o programa emulator lança duas VMs que trabalham
em conjunto: a JVM Java SE normal (um processo java ou
javaw), e um processo com o curioso nome de zayit que
contém componentes da KVM.
o programa passo-a-passo, ver variáveis e
pilha de invocações etc., como mostrado na
Figura 10. Surpreendentemente, até alguns
recursos avançados como breakpoints con-
dicionais funcionam. Mas nem tudo; por
exemplo, a facilidade “hot code replace” (edi-
tar-e-continuar) não funciona – já seria exigir
demais da KVM, otimizada para dispositi-
vos enxutos. (Como estas são limitações da
máquina virtual, não adianta procurar outro
IDE ou plug-in para Java ME.)
MTJ: Em construção...
Já verificamos que o MTJ suporta as
funcionalidades essenciais para criar
aplicações MIDP, mas este é um projeto
ainda em desenvolvimento. Na versão
preliminar que testamos (0.7), o MTJ ainda
tem algumas limitações:
• O MANIFEST.MF não é gerado corre-
tamente. Isso não impede o lançamento
do programa a partir do IDE / emulador,
mas um arquivo JAR sem este arquivo cor-
reto será rejeitado por dispositivos reais.
Pode-se contornar o problema editando os
manifestos à mão.
• Não há suporte para funcionalidades e
ferramentas externas importantes, como
ofuscadores de bytecode, Mobile JUnit ou
Antenna (comentados adiante, na seção do
EclipseME).
• Não existe editor visual de GUIs.
• Para aborrecimento dos entusiastas que
gostam de acompanhar os mais recentes
releases de desenvolvimento do Eclipse, o
MTJ ainda não é compatível com o Eclipse
3.3 (testei com o 3.3M5eh). Será necessário
usar o Eclipse 3.2.

Como o MTJ 0.7 é de novembro de 2006

e escrevo em março, é bem possível que,
quando você ler este artigo, uma versão
Figura 9. Criando uma configuração de lançamento para o projeto AloMundoME. melhor esteja disponível (o release 1.0 é
esperado para junho). Mas até lá, se você já
Listagem 1. Código completo da MIDlet AloMundoME. tiver passado da fase de investigação e qui-
ser trabalhar seriamente em projetos Java
package alo;
import javax.microedition.lcdui.Command; ME, pode ser melhor procurar uma ferra-
import javax.microedition.lcdui.CommandListener; menta alternativa como o EclipseME.
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.Form;
import javax.microedition.midlet.MIDlet;
Trabalhando com o Eclipse II: EclipseME
import javax.microedition.midlet.MIDletStateChangeException; O EclipseME é um projeto open source
public class AloMIDP extends MIDlet implements CommandListener {
protected Form form;
independente, disponível em eclipseme.
protected void startApp () throws MIDletStateChangeException { org, e que tradicionalmente tem servido às
Display d = Display.getDisplay(this);
d.setCurrent(getForm()); necessidades dos usuários do Eclipse que
} precisam de suporte à plataforma Java ME.
protected void pauseApp () {
} Assim, enquanto o MTJ não fica pronto,
protected void destroyApp (boolean flag) throws MIDletStateChangeException { podemos usar o EclipseME.
}
protected Form getForm () { Os dois plugins são parecidos, por isso
if (form == null) { descreveremos rapidamente a configu-
form = new Form(“Título da Form”);
form.addCommand(new Command(“Clique-me!”, Command.ITEM, 1)); ração do EclipseME. (Ambos podem ser
form.setCommandListener(this); instalados simultaneamente no Eclipse; fiz
}
return form; isso e não tive problemas.) No Update Ma-
}
public void commandAction (Command c, Displayable d) {
nager, utilize a URL http://www.eclipseme.
form.append(“Alô... tem alguém aí?\n”); org/updates para instalar o EclipseME.
}
}
Vá então em Window>Preferences>J2ME.
Na página principal, no grupo Antenna

16 Java Magazine • Edição 45

Java45.indb 16 25.03.07 20:43:01

 Settings, sete o WTK Root para o diretório-
raiz do WTK, e Antenna JAR para o arquivo
antenna-bin-<versão>*.jar (que você obterá
de antenna.sourceforge.net). Esta biblioteca
Antenna é uma coleção de tasks do Ant para
Java ME, que é suportada pelo EclipseME.
Seu uso não é obrigatório, mas é muito
conveniente para os fãs de scripts do Ant (o
EclipseME gera os scripts de build).
Na página Device Management, clique Im-
port, forneça o diretório do WTK e acione
Refresh; aguarde a detecção dos devices e
confirme com Finish.
Na página Packaging / Obfuscation, forneça
o diretório de instalação do ProGuard, um
ofuscador e otimizador de bytecode open
source (baixe de proguard.sourceforge.net). O
ofuscamento não é obrigatório, mas é reco-
Figura 10. O Eclipse & MTJ em ação.
Java45.indb 17
mendado para MIDlets. Mesmo que você não
precise de proteção contra descompiladores,
a redução de tamanho dos JARs proporciona-
da por ofuscadores é importante. A Figura 11
mostra as páginas de configuração do Eclip-
seME, destacando as opções de ofuscador
(muitas podem ser sobrepostas nas páginas
de propriedades de cada projeto).
Criando o projeto
Crie um projeto do tipo J2ME>J2ME
MIDlet Suite; aceite os defaults para as
propriedades específicas ao EclipseME.
O projeto criado será semelhante ao do
MTJ, com as mesmas pastas res, verified e
deployed (este último criado sob demanda
quando for feito o primeiro build). Não
haverá fontes nem source folder, pois o
EclipseME não oferece templates. Crie um
source folder src e copie para lá os mesmos
fontes do projeto do MTJ.
Edite também o arquivo JAD para registrar
a nossa MIDlet. O EclipseME não tem o mes-
mo bug do MTJ, e irá gerar o MANIFEST.MF
corretamente nos arquivos JAR criados.
Testando
Para executar a MIDlet com o Eclipse-
ME, também será preciso criar à mão a
configuração de lançamento, só que o
tipo será Wireless Toolkit Emulator. Note
que nesta configuração, na aba Midlet, o
default da opção Executable é Over-the-Air;
isto significa que o emulador é lançado
com uma opção que simula a instalação da
MIDlet através da rede móvel. Mas eu tive
Edição 45 • Java Magazine 17
25.03.07 20:43:01
 Programação Java ME - Parte 2
problemas com esta opção. Com Executable
= Midlet <classe>, tudo funcionou corre-
tamente. A execução em modo de debug
exige as mesmas configurações do Eclipse
que comentamos ao discutir o MTJ.
Escolhendo seu plug-in Java ME para
Eclipse
Apesar do atual status – o MTJ em pré-
release com algumas limitações e bugs
importantes, e o EclipseME mais maduro
(sem contar outros plug-ins / IDEs comer-
ciais baseados no Eclipse), não tenha dúvi-
da: o MTJ é o futuro do desenvolvimento
Java ME na plataforma Eclipse, pois faz
parte de um plano mais abrangente, e é
suportado pela Fundação Eclipse.
Há semelhanças entre os dois proje-
tos, ex.: o editor de JAD é exatamente
igual. Isso não é coincidência, pois o
código-fonte do EclipseME foi uma das
contribuições iniciais para o projeto MTJ.
(Outra foi o Carbide.J da Nokia.) O autor
do EclipseME, Craig Setera, também faz
parte da equipe do MTJ, assim como
desenvolvedores da Nokia, SonyErics-
son, IBM, e vários outros fornecedores
de IDEs e/ou tecnologia de dispositivos
móveis. O MTJ (ou mais precisamente o
Device Software Development Platform
como um todo) é mais um “rolo compres-
sor” da Fundação Eclipse, unificando os
esforços de praticamente toda a comu-
nidade e que certamente resultará num
ferramental extremamente completo. Os
planos do MTJ incluem, especialmente,
Figura 11. Configuração do ofuscador ProGuard, suportado pelo EclipseME.
18 Java Magazine • Edição 45
Java45.indb 18
a edição visual de GUIs MIDP, que tam-
bém falta no EclipseME.
Uma das vantagens da absorção destes
projetos de terceiros pela Fundação é a
maior integração entre todos os seus com-
ponentes. Se a equipe do MTJ precisar de
um aperfeiçoamento no núcleo do Eclipse
ou em seus frameworks (Platform, JDT,
VE...), este pedido será atendido com uma
presteza bem maior do que seria para
uma solicitação externa (a não ser que o
interessado implementasse a melhoria
por conta própria, o que é possível pois o
Eclipse é open source – mas não necessa-
riamente fácil!).
Comprovando isso, já existem discussões
sobre algumas destas melhorias. Por exem-
plo, muitos desenvolvedores de aplicações
Java ME utilizam ferramentas de pré-pro-
cessamento e compilação condicional. Esta
é uma facilidade de linguagens como C/
C++ que foi banida do design do Java, mas
é importante tanto para reduzir o tamanho
dos programas quanto para conviver com
uma oferta de dispositivos nem sempre
tão compatíveis quanto deveriam com as
especificações Java ME. O EclipseME já
suporta isso – igual a C/C++, com diretivas
#include, #define, #ifdef etc. Mas não é um
suporte ideal, por exemplo as diretivas de
pré-processamento precisam ser colocadas
dentro de comentários “//”, ferramentas do
JDT como o outliner não reconhecem as di-
retivas, a compilação exige um novo folder
oculto com os fontes pré-processados e é
mais lenta, etc. Já no MTJ, estas restrições
serão resolvidas porque componentes do
JDT, como o editor de código, compilador
Java, outliner e outros, serão modificados
para dar suporte a pré-processamento. Isso
não quer dizer necessariamente que o JDT
passe a suportar fontes Java com diretivas
de pré-processador; basta que os plug-ins
do JDT, como o editor, outliner, depurador
e outros, disponibilizem “pontos de exten-
são” estratégicos que permitem que um
outro plug-in, como o MTJ, faça isso.
Conclusões
No primeiro artigo desta série, apre-
sentamos e analisamos a impressionante
amplitude de tecnologias, especificações
e APIs que formam a plataforma (ou mais
precisamente, família de plataformas) Java
ME. Neste artigo, começamos a pôr as mãos
na massa, vendo que esta plataforma exige
um arsenal de ferramentas que não fica
devendo nada aos IDEs para aplicações
Enterprise Edition. (Quem eles estão tentan-
do enganar com esse termo “dispositivos
limitados”? Podem ser um pouco limitados
em CPU e memória, mas certamente, nem
tanto em funcionalidades!)
Espero ter ajudado o leitor a vencer a
barreira inicial de tantas definições, espe-
cificações e ferramentas novas, e a partir
daqui, começar a desenvolver aplicações
para dispositivos MIDP, o perfil de foco da
série deste artigo em diante. No próximo
artigo completaremos o assunto de IDEs
com o NetBeans Mobility Pack, e começa-
remos a programar para valer.
java.sun.com/javame
Página oficial do Java ME
java.sun.com/products/midp
Página oficial do perfil MIDP
java.sun.com/products/cldc
Configuração CLDC
Osvaldo Pinali Doederlein
(opinali@gmail.com)
é Mestre em Engenharia de
Software Orientado a Objetos,
membro individual do Java Community
Process e trabalha na Visionnaire Informática como
arquiteto e desenvolvedor.
25.03.07 20:43:02