i n í c i o  |  q u e m  s o u  e u  |  c u r r i c u l u m  v i t a e  |  a r t i g o  |  l i g a ç õ e s  |  e - m @ i l

Página de

    O KVM é uma nova máquina virtual desenvolvida para dispositivos com recursos muito limitados. O seu tamanho vai desde os 40 aos 80 Kbytes, daí o K de Kilobyte em KVM. A ideia de desenvolver o KVM teve origem num projecto chamado Spotless System, que tinha como função criar um motor para um computador de mão (PDA). A equipa responsável por esse projecto, rapidamente se apercebeu que o tamanho do sistema dependia directamente do tamanho das suas bibliotecas, havendo então, necessidade de reduzir o tamanho do sistema retirando tudo o que era considerado não essencial ou critico para o funcionamento do sistema [2, 3].
    Apenas uma pequena parte do código do KVM é dependente da plataforma onde corre, mas está isolado numa zona de fácil alteração. Para implementar o KVM num dispositivo, é necessário alterar apenas estas dependências. Ao contrário dos computadores normais, um dispositivo móvel não possui uma linha de comandos ou uma interface especial onde possa ser executado o programa. Para o conseguir usa-se o Java Aplication Manager (JAM) que serve de interface entre o KVM e o sistema operativo do dispositivo. O JAM executa a aplicação J2ME por cima do KVM, que é previamente descarregada de um servidor http onde esta se encontra. É também incluído um ficheiro metadata que contém informações que o JAM usa para poder descomprimir e instalar a aplicação. A esta aplicação dá-se o nome de MIDlet [3].

    A configuração CLDC define um padrão na plataforma Java para os dispositivos com recursos limitados e, activa de forma dinâmica a distribuição das aplicações e conteúdos para estes dispositivos. A configuração é limitada a um espaço de cerca de 128 Kbytes e é desenhada para correr em vários dispositivos de pequeno porte sem que o programador se tenha de preocupar com o sistema operativo em que a aplicação vai executar. O CLDC é implementado como um conjunto adicional de classes contido numa package separada (a java.io, java.lang, java.util e a javax.microedition.io [5]). Tal facto facilita a portabilidade do CLDC para as diferentes plataformas.
    A configuração CLDC necessita que o JVM possa identificar e rejeitar as classes que sejam inválidas. As formas padrão para fazer este tipo de verificações são muito dispendiosas em termos de memória. Para reduzir as verificações no lado do cliente, o CLDC usa um processo de pré-verificação e verificação, onde parte é feita do lado do servidor antes de se proceder ao descarregamento da aplicação CLDC MIDlet para o dispositivo móvel. Este procedimento de pré-verificação gera um ficheiro chamado stackmap que é descarregado juntamente com a MIDlet para o dispositivo. Este ficheiro contém informações acerca da pré-verificação, nomeadamente sobre o estado válido ou inválido da aplicação. Qualquer aplicação para correr nos dispositivos com a configuração CLDC precisa de estar na forma de JAR (ficheiro comprimido com todas as componentes da aplicação) [2, 5].

    A MIDP é um conjunto de bibliotecas Java que juntamente com o CLDC fornece os requisitos mínimos para a construção de uma aplicação J2ME dirigida para telemóveis, PDAs e pagers com duas vias de comunicação. Este é o único perfil completamente especificado para a configuração CLDC. Existe outro exclusivo para PDAs, mas ainda se encontra em desenvolvimento. A MIDP contém bibliotecas com classes relacionadas com interfaces, armazenamento de dados, comunicações e aplicações modelo. Este perfil também inclui um conjunto de requisitos, dirigido aos fabricantes caso eles queiram que o seu dispositivo seja certificado, para correr com as configurações CLDC e com os perfis MIDP. Por exemplo, o requisito do tamanho mínimo do visor de um dispositivo que use o perfil MIDP terá de ser de 96x54 pixels, a profundidade do ecrãn de 1 bit e o tamanho de cada pixel deverá ser 1x1. Outro requisito deste perfil é ter no mínimo 128 Kbytes de memória RAM [4].
    Para a distribuição de aplicações (MIDlets) por conta de outrem é necessário que os seus programadores gerem um ficheiro metadata, compactem o ficheiro e os seus componentes adicionais num JAR e lhe associem um Java Application Descriptor (JAD - que funciona como uma espécie de identificador). O JAD contém informações que o JAM usa para configurar, verificar e instalar as MIDlets e por sua vez esta usa a informação durante a sua execução. Cada fabricante é livre de incluir bibliotecas especificas para aumentar a funcionalidade do seu equipamento e incluir ou criar também MIDlets que usem estas funcionalidades.