Resumo e comparação CLDC 1.0 e 1.1 - DCA
Propaganda
UNICAMP - Universidade Estadual de Campinas Faculdade de Engenharia Elétrica e de Computação IA368M – Tópicos em Engenharia de Computação V – 1º semestre/2008 Prof. José Mario De Martino Resumo e comparação CLDC 1.0 e 1.1 Trabalho comparativo entre as especificações JSR-30 (Connected Limited Device Configuration 1.0) e JSR-139 (Connected Limited Device Configuration 1.1), Para a disciplina de desenvolvimento de jogos utilizando Java ME. Grupo 01: Paulo Renato de Faria Rogério Makiyama Zafalão Campinas, 22 de Abril de 2008 Índice Introdução............................................................................................................................... 4 Objetivos das especificações CLDC ................................................................................... 4 Desenvolvimento do tema ...................................................................................................... 4 Comparação da Evolução dos Requisitos de CLDC 1.0 e 1.1 ............................................ 4 Contexto histórico............................................................................................................ 4 Requisitos de Hardware ................................................................................................... 4 Requisitos de Software .................................................................................................... 5 Requisitos J2ME .............................................................................................................. 5 Escopo ................................................................................................................................. 6 Áreas de especificação..................................................................................................... 6 Áreas não cobertas (devem ser definidas nos Perfis): ..................................................... 6 Arquitetura de alto-nível e segurança.................................................................................. 6 O Conceito aplicação Java (ponto entrada execução)...................................................... 7 Gerência aplicação ........................................................................................................... 7 Segurança ............................................................................................................................ 8 Segurança em baixo-nível................................................................................................ 8 Segurança em nível de aplicação ..................................................................................... 9 Modelo “Sandbox” .......................................................................................................... 9 Requisitos sandbox: ....................................................................................................... 10 Protegendo classes do sistema ....................................................................................... 10 Suporte à execução de múltiplas aplicações Java simultaneamente.............................. 10 Restrição adicional sobre carregamento de classes dinamicamente .............................. 10 Aderência à especificação da linguagem Java .................................................................. 11 Não há suporte a ponto flutuante ................................................................................... 11 Aderência à especificação da Máquina Virtual Java......................................................... 11 Características eliminadas da Máquina Virtual ............................................................. 11 Verificação de Class File ............................................................................................... 12 Processo de Verificação................................................................................................. 12 Definição do attributo “stack map”................................................................................ 13 Formato Class File e Carregamento de Classes............................................................. 13 Representação pública de aplicações Java e recursos.................................................... 13 Pré-carregamento / pré-ligação (“ROMizing”).............................................................. 13 Otimização formatos de aplicações ............................................................................... 14 Bibliotecas CLDC ............................................................................................................. 14 Classes derivadas da Java 2 SE...................................................................................... 15 Classes específicas do CLDC ........................................................................................ 17 Background e motivação ............................................................................................... 17 Framework de conexão Genérico .................................................................................. 17 Conclusão ............................................................................................................................. 19 Referências ........................................................................................................................... 20 Índice de tabelas Tabela 1 - Comparação requisitos hardware .......................................................................... 4 Tabela 2 - Comparação requisitos software ........................................................................... 5 Tabela 3 - Comparação requisitos J2ME................................................................................ 5 Tabela 4 - Comparação entre celulares com CLDCs diferentes............................................. 5 Tabela 5 - Evolução requisitos para Gerência de aplicações.................................................. 7 Tabela 6 – Resumo da evolução requisitos segurança ........................................................... 8 Tabela 7 – Classes derivadas da Java SE ............................................................................. 15 Introdução Objetivos das especificações CLDC Fabricantes de equipamentos cada vez mais desejam estimular a criação de aplicações que suportem conteúdo rico, dinâmico e interativo por operadoras e desenvolvedores terceirizados. Contudo, o foco da APIs nesse cenário migra da programação de sistemas (responsabilidade dos fabricantes) para a programação de aplicações. Por isso a especificação CLDC enfatiza a importância da generalidade, não contemplando APIs que são específicas de certas categorias de equipamentos, nichos de mercados ou funcionalidades dedicadas. Além disso, equipamentos como telefones celulares são fabricados em altíssima escala e são freqüentemente vendidos a preços muito baixos. Para manter as margens de lucro, os fabricantes precisam manter o custo por unidade tão baixo quanto possível. Por isso, existem restrições de processamento e memória que levam à necessidade de encontrar um denominador comum entre os dispositivos existentes no mercado para definir uma API que permita portabilidade de aplicações. Isto torna também atende outra necessidade dos fabricantes ao diminuir o tempo para liberação no mercado, pois devido a padronização as aplicações podem ser adaptadas mais rapidamente. Desenvolvimento do tema Comparação da Evolução dos Requisitos de CLDC 1.0 e 1.1 Contexto histórico CLDC 1.0 - Primeira versão completa lançada em maio de 2000. CLDC 1.1 - Versão pública final disponibilizada em março de 2003, traz uma natural evolução da versão 1.0 decorrente da própria evolução dos dispositivos que a suportaria. CLDC 1.1.1 - Lançada em outubro de 2007 como uma versão de manutenção da CLDC 1.1, procura incluir itens relacionados ao modelo de segurança de Java para suporte ao MIDP 3.0. Requisitos de Hardware As tabelas a seguir (Tabela 1, Tabela 2 e Tabela 3) resumem a variação entre as duas versões de configuração CLDC para os requisitos de Hardware, Software e J2ME: Tabela 1 - Comparação requisitos hardware Requisito Processador CLDC 1.0 16 ou 32 bits CLDC 1.1 Consumo energia Conectividade Baixo consumo de potência, freqüentemente operando com bateria; Algum tipo de rede; freqüentemente sem-fio; Conexão intermitente com largura de banda limitada 128 Kb 160Kb Memória não volátil disponível para máquina virtual Java e bibliotecas CLDC Memória volátil disponível >= 32Kb para Java runtime e memória de objetos. Requisitos de Software Tabela 2 - Comparação requisitos software Requisito CLDC 1.0 Sistema operacional (controle hardware) Sistema operacional (execução Java) Assume um mínimo sistema operacional hospedeiro ou kernel para gerenciar o hardware. Este sistema deve prover no mínimo uma entidade que possa agendar execuções da máquina virtual Java. CLDC 1.1 Requisitos J2ME Tabela 3 - Comparação requisitos J2ME Requisito CLDC 1.0 CLDC 1.1 Características devem ser aplicáveis a uma grande variedade de dispositivos. Portabilidade e interoperabilidade entre equipamentos com recursos restritos Características específicas a certo mercado vertical (exemplo: negócios, diversa), categoria de equipamento devem ser definidas em uma especificação de perfil J2ME. Este objetivo impõe que configurações não devem definir características opcionais A Tabela 4 contém exemplos de telefones celulares e a variação das características devido ao CLDC[5] . Comparando-a com a Tabela 1, é possível identificar que a especificação requer valores muito abaixo do que os dispositivos pesquisados disponíveis no mercado atual. Em vermelho estão marcados os requisitos para facilitar a visualização de quanto o celular atende ao especificado. Tabela 4 - Comparação entre celulares com CLDCs diferentes Característica CLDC 1.0 RAZR V3 (Motorola) CLDC 1.1 Z8 (Motorola) CLDC 1.1 N95 (Nokia) Perfil Número Cores MIDP 2.0 65536 MIDP 2.0 16777216 MIDP 2.0 262144 Resolução (L x A) CPU Freqüência CPU ROM (armazenamento) RAM (volátil) 176 x 220 32 bits 43 MHz Armaz. MIDlet disponível: até 5 MB Tamanho MIDlet suite Max.: 100 Kb Tamanho Record store Max.: 64 Kb [especificação: ≥128 KB] 240 x 320 32 bits 330 MHz 128 MB 77 MB acessíveis 240 x 320 32 bits 332 MHz 256 MB 157 MB usáveis [espec.: ≥160 KB] [espec.: ≥160 KB] Tamanho Heap: 800 Kb 64 MB [especificação: ≥ 32 Kb] [espec.: ≥32 KB] 64 MB 22 MB acessíveis [espec.: ≥32 KB] Escopo Áreas de especificação Este é um ponto comum entre CLDC 1.0 e 1.1 - Características linguagem Java e máquina virtual - Núcleo de bibliotecas Java (java.lang.*, java.util.*) - Entrada / Saída (java.io.*) - Rede - Segurança - Internacionalização Áreas não cobertas (devem ser definidas nos Perfis): - Gerência ciclo-de-vida aplicações (instalação, execução e remoção) - Funcionalidade de interface de usuário - Controle de eventos - Modelo de alto-nível de aplicações (interação entre usuário e aplicação) Arquitetura de alto-nível e segurança Figura 1 – Arquitetura alto nível J2ME [1] O Conceito aplicação Java (ponto entrada execução) JVM suportando CLDC inicia execução de aplicação Java chamando método main, que deve ser declarado como abaixo:. public static void main(String[] args) Gerência aplicação Assume-se que equipamentos implementando CLDC tenham capacidade para gerenciar aplicações Java que são armazenadas no dispositivo. Em alto nível, os requisitos de gerência de aplicação têm algumas variações de CLDC 1.0 e 1.1 conforme abaixo: Tabela 5 - Evolução requisitos para Gerência de aplicações Requisitos Gerência aplicações CLDC 1.0 Listar Inspecionar aplicações Java existentes armazenadas no dispositivo Selecionar e executar aplicações Java Remover aplicações Java existentes (se aplicável) Não requerida Download e instalação de aplicações Java Executar Remover Instalação CLDC 1.1 IMPORTANTE: Devido às significativas variações e diferenças de características entre equipamentos CLDC, os detalhes de gerência de aplicações são altamente dependentes do dispositivo e da implementação. Por isso, CLDC não especifica como será esta implementação. Segurança Quantidade de código relacionado à segurança na plataforma Java 2 SE de longe excede a memória total disponível assumida para CLDC. Com isso temos necessidade das seguintes simplificações: 1. Segurança em baixo-nível (segurança na máquina virtual). Garante que aplicações executando na máquina virtual: • Sigam a semântica da linguagem de programação Java • Classes com código mal formado ou malicioso não quebrem ou prejudiquem o equipamento 2. Segurança no nível de aplicação. Aplicações têm acesso garantido apenas a itens que o ambiente Java e o equipamento concederem, como por exemplo: bibliotecas, recursos do sistema e outros componentes. 3. Segurança fim-a-fim. Modelo que garante que qualquer transação iniciada em um equipamento é protegida em relação ao caminho completo chegando / partindo da entidade provedora de serviços (por exemplo, serviço disponível na Internet). a) Criptografia ou outro meio pode ser necessário para atingir este objetivo. Tabela 6 – Resumo da evolução requisitos segurança Requisitos Gerência aplicações CLDC 1.0 CLDC 1.1 Segurança em baixo-nível Segurança no nível de aplicação Segurança fim-a-fim (isto é, para garantir entrega de dados e código entre máquinas servidoras e equipamentos clientes) Especificado Especificado Não especificado (dependente de implementação em cada equipamento, fora do escopo CLDC). Especificado Especificado Fora escopo CLDC. Assume que será definido pelos perfis que puderem prover esta funcionalidade. Segurança em baixo-nível No J2SE, esta restrição é garantida pelo Java classfile verifier. Este garante que bytecodes e outros itens armazenados em arquivos de classes: a) não podem conter referências a localizações inválidas de memória (de execução) ou; b) referências a áreas fora da área de objetos em memória (Java heap) Como será mostrado no item Verificação de Classfiles, a JVM suportando CLDC deve ser capaz de rejeitar classfiles inválidos. Segurança em nível de aplicação Existem outros potenciais riscos à segurança que não são detectados pelo verificador de classfiles. Por exemplo: a) acesso a recursos externos como arquivos do sistema, impressoras, equipamento de infravermelho, bibliotecas nativas ou redes. Para prover controle a recursos externos, temos: a) J2EE – conceito de gerente de segurança. Chamado quando aplicação ou sistema de execução Java precisa de acesso a recursos protegidos. b) J2SE – provê modelo de segurança consistindo das noções de permissões, controladores de acesso e políticas de segurança. Infelizmente, uma solução mais simples foi adotada, pois os modelos de segurança acima descritos consomem muita memória para serem inclusos no CLDC. Modelo “Sandbox” Aplicação Java deve executar em um ambiente fechado no qual pode acessar apenas aquelas APIs que foram definidas pela configuração, perfis e classes com permissão liberadas pelo dispositivo (exemplo: específicas do fabricante). Aplicações Java não podem escapar ou acessar bibliotecas ou recursos que não são parte de funcionalidades pré-definidas. A sandbox garante que uma aplicação maliciosa ou possivelmente errônea não consiga ganhar acesso a recursos do sistema. Figura 2 – Modelo Sandbox Requisitos sandbox: - Java classfiles devem ser verificadas e validadas como aplicações Java válidas - Apenas um conjunto limitado e predefinido de APIs está disponível para o programador de aplicações. - Download e gerenciamento de aplicações Java no dispositivo ocorre em nível de máquina virtual. - Nenhuma carregador de classe pode ser definido por usuário, para prevenir a substituição ou “bypass” dos padrões de carregamento das classes na VM (o que causaria problemas na execução pois a classe está carregada diferentemente do padrão esperado pela KVM). - O conjunto de funções nativas acessíveis na VM é fechado, isto é, programador de aplicação não pode : a) fazer download de novas bibliotecas contendo funcionalidades nativas ou; b) acessar quaisquer funções nativas que não são parte do CLDC, perfis MIDP, ou classes específicas do fabricante Protegendo classes do sistema Requisito central CLDC é o suporte a download dinâmico de aplicações Java. Para evitar problemas de segurança, implementações do CLDC devem garantir que o programador de aplicações não possa: a) Sobrescrever, modificar ou adicionar quaisquer classes aos pacotes de sistema protegidos (por exemplo, java.* , javax.microedition.* ou outros pacotes específicos do perfil ou dos fabricantes) b) Manipular ordem de busca de classfiles. [ex.: do contrário programador poderia colocar classes Boolean do usuário antes de Boolean do java.*]. Dependendo se implementação CLDC suporta ou não pré-carregamento / pré-ligação das classes do sistema, pode também ser necessário requerer que classes do sistema sempre sejam procuradas primeiramente quando a busca de classfiles for feita. Suporte à execução de múltiplas aplicações Java simultaneamente (restrição presente apenas CLDC 1.0) Dependendo dos recursos disponíveis no dispositivo, um sistema CLDC pode permitir ou proibir execuções concorrentes. Fica também a critério da implementação do CLDC decidir se a execução de múltiplas aplicações Java será suportada: a) pela utilização de funcionalidades multitasking do sistema operacional do dispositivo ou; b) pela instanciação de múltiplas máquinas virtuais lógicas para executar aplicações concorrentes. Restrição adicional sobre carregamento de classes dinamicamente (item presente apenas CLDC 1.1) Uma aplicação Java pode carregar classes apenas de seu próprio Java Archive (JAR) file. Esta restrição garante que uma aplicação não interfira ou roube dados de outras aplicações. Adicionalmente, isto protege que aplicações de terceiros ganhem acesso a componentes privados ou protegidos de classes Java que o fabricante ou provedor de serviços disponibilize como parte do sistema de aplicações. Aderência à especificação da linguagem Java Não há suporte a ponto flutuante (restrição presente apenas na CLDC 1.0) O motivo principal da não inclusão do suporte a operações em ponto flutuante decorre da falta deste suporte no hardware da época. Com esta limitação, restaria apenas o suporte via software, mas esta alternativa foi considerada custosa para os dispositivos vigentes e portanto descartada da CLDC 1.0. Com o decorrer do tempo, não só o suporte torna-se efetivo pelos processadores mas também é aumentada a capacidade do processamento. Portanto, na definição da CLDC 1.1, não se aplicam mais estas restrições, sendo incluídas as seguintes modificações relacionadas: • Adicionado o suporte a operações em ponto flutuante; • Classes Float e Double foram incluídas; • Vários métodos de bibliotecas que utilizavam float e double em suas assinaturas foram reintegrados. Não há suporte a finalização CLDC 1.0 não inclui o método Object.finalize(), o que exclui a possibilidade de controle da aplicação ao gerenciamento automático de memória (garbage collection). Limitações para lidar com erros O tratamento de erros é bem limitado em relação ao conjunto oferecido pela J2SE. Não há suporte a exceções assíncronas.e o conjunto de classes de erro é mais limitado. Isto decorre geralmente pelo fato de erros em dispositivos embarcados serem comumente específicos aos próprios dispositivos e a implementação de todas as funcionalidades de tratamento de erro necessitariam de uma quantidade de recursos preciosa para o modelo. Ao encontrar algum erro, a implementação de CLDC deve: • Interromper a execução da máquina virtual de uma maneira específica ou; • Lançar um erro que seja mais próximo possível da superclasse Error suportada pela CLDC. A relação de classes de exceções e erros suportadas estão relacionadas na Tabela 7, em classes de erro e classes de exceções. Aderência à especificação da Máquina Virtual Java Características eliminadas da Máquina Virtual A máquina virtual compatível com CLDC, por possuir sérias restrições de memória e um modelo de segurança menos custoso em termos de recursos, também eliminou algumas características encontradas na versão completa J2SE. • • • • • • • Referências Fracas – Na CLDC 1.0 não havia nenhum suporte a referências fracas. NA CLDC 1.1 foi adicionado suporte a referências fracas do tipo Weak Reference. Grupos de threads e daemon threads – existe o suporte a threads, mas não a grupos de threads e daemon threads. A CLDC 1.1 passa a suportar também threads com nome. Exceções assíncronas – Não há suporte a exceções assíncronas e o próprio conjunto de exceções e (principalmente) erros é bem reduzido em relação à J2SE. Segundo a especificação da JVM[4] , exceções assíncronas são disparadas somente quando o método stop de uma Thread ou ThreadGroup for invocado, ou quando ocorrer um erro na implementação da máquina virtual. Como os casos estão cobertos, não há razão para tal suporte. Java Native Interface (JNI) – JNI não é suportado uso de chamadas nativas. Reflexão – Sem suporte do CLDC. Isto significa que RMI, serialização, JVMCI (interface de depuração), JVMPI (interface de profiler), ou quaisquer características que dependam de características reflexivas (informações sobre classes, métodos e invocação dinâmica) não serão suportadas. Finalização de instâncias de classes – como descrito na seção anterior, não há método Object.finalize(). Carregadores de classes definidas por usuário – Além da restrição de recursos, a restrição a esta funcionalidade também foi imposta devido ao próprio modelo de segurança Sandbox adotado pela CLDC. Verificação de Class File Uma JVM que suporte CLDC precisa realizar a verificações de classfiles inválidos. Novamente, a restrição dos recursos disponíveis pelos dispositivos limita a utilização do modelo de verificação utilizado pela Java SE. Processo de Verificação O processo de verificação descrito abaixo é significativamente menor e mais eficiente em dispositivos de recursos restritos do que o verificador do J2SE. Classfiles pré-processados são aproximadamente 5% maiores do que os classfiles originais (não modificados). O verificador realiza apenas uma varredura linear sobre o bytecode, sem a necessidade de um algoritmo fluxo de dados com iterações custosas. Figura 3 –Processo de verificação Definição do attributo “stack map” A ferramenta de pré-verificação modifica classfiles para inserir atributos especiais. O nome “stack map” vem em virtude de esses atributos descreverem os tipos de variáveis locais e itens operadores da pilha (em cada offset do bytecode), todos residentes na pilha de interpretação. Formato Class File e Carregamento de Classes Formatos suportados pela implementação CLDC: a) classfiles padrão do Java b) arquivos de compressão Java Archive (JAR) files. Formato JAR provê 30-50% de nível de compressão sobre arquivos classfiles Java regulares sem perda de quaisquer informações simbólicas ou de problemas de compatibilidade com sistemas Java existentes. Representação pública de aplicações Java e recursos Toda vez que uma aplicação Java for destinada para ser publicamente acessível para distribuição em equipamentos CLDC, o formato JAR deve ser utilizado. Adicionalmente, o arquivo JAR pode conter arquivos de recursos específicos da aplicação (exemplo, imagens, sons) que podem ser carregados na máquina virtual Java pela chamada de método: Class.getResourceAsStream(String name) Pré-carregamento / pré-ligação (“ROMizing”) (esse item não está no escopo do CLDC – dependente da implementação) Uma JVM suportando CLDC pode optar por pré-carregar ou pré-ligar algumas classes. Esta técnica é informalmente conhecida como ROMizing. Tipicamente VMs de pequeno porte escolhem pré-carregar todas as classes do sistema (configuração ou perfil) e realizar o carregamento de aplicações dinamicamente. Não pode haver nenhum outro efeito visível do pré-carregamento que não seja a possível redução no tempo para início da execução de uma aplicação Java. Otimização formatos de aplicações (esse item não está no escopo do CLDC – dependente da implementação) Classfiles Java regulares não são otimizados para transporte em ambientes de largura de banda limitados. Motivos: • Classfile é uma unidade independente: com seu pool de constantes (tabela de símbolos), métodos, campos e tabelas de exceção, bytecodes e algumas outras informações. o Vantagem: Permite aplicações compostas de múltiplos pedaços que podem residir em diferentes locais (aplicações podem ser estendidas dinamicamente). o Desvantagem 1: Por não serem unidades seladas, muito espaço é usado com redundâncias o Desvantagem 2: Necessidade do processo de conversão entre representação estática para a representação de execução Bibliotecas CLDC Dois tipos básicos compreendem as bibliotecas CLDC: classes derivadas de Java SE (podendo ser um conjunto total ou apenas parcial) ou classes específicas da configuração. A Figura 4 ilustra esta relação entre classes suportadas. Figura 4 –Relação entre classes J2SE e configurações J2ME Classes derivadas da Java 2 SE A versão da Java Standard Edition utilizada para referência é a 1.3.1, e a implementação CLDC deve manter o mesmo nome do package e a semântica das classes e seus métodos. Na Tabela 7 são mostradas as classes derivadas da Java SE, classificadas por tipo. Comentários pertinentes estão na segunda coluna (se não houver comentário, tanto a CLDC 1.0 quanto 1.1 e 1.1.1 suportam a classe correspondente). Tabela 7 – Classes derivadas da Java SE Classes de sistema java.lang.Object java.lang.Class java.lang.Runtime java.lang.System java.lang.Thread java.lang.Runnable (interface) java.lang.String java.lang.StringBuffer Classes de tipos de dados java.lang.Boolean java.lang.Byte java.lang.Short java.lang.Integer java.lang.Long java.lang.Float java.lang.Double java.lang.Character Classes de collections java.util.Vector java.util.Stack java.util.Hashtable java.util.Enumeration (interface) Classes de entrada/saída java.io.InputStream java.io.OutputStream java.io.ByteArrayInputStream java.io.ByteArrayOutputStream java.io.DataInput (interface) java.io.DataOutput (interface) java.io.DataInputStream java.io.DataOutputStream java.io.Reader java.io.Writer java.io.InputStreamReader Somente a partir da CLDC 1.1 Somente a partir da CLDC 1.1 java.io.OutputStreamWriter java.io.PrintStream Classes de calendário e tempo java.util.Calendar Subconjunto da API padrão Java SE. Somente uma time zone suportada, por default. Time zones adicionais são permitidas java.util.Date em implementações específicas de CLDC, desde que de java.util.TimeZone acordo com a especificação Java SE. java.util.Timer Somente a partir da CLDC 1.1 java.util.TimerTask Somente a partir da CLDC 1.1 Classes de segurança java.security.AccessControlException Somente a partir da CLDC 1.1.1; um java.security.AccessController subconjunto destas classes é java.security.BasicPermission suportado. java.security.Permission java.security.PermissionCollection java.util.PropertyPermission java.lang.RuntimePermission Somente a partir da CLDC 1.1.1 Somente a partir da CLDC 1.1.1; inclui somente os targets exitVM e modifyThread Classes adicionais java.util.Random java.lang.Math CLDC 1.1 incluiu suporte a funções trigonométricas, raiz quadrada, piso e teto CLDC 1.1.1 incluiu ainda funções trigonométricas inversas (asin, acos, atan and atan2). Classes de exceção java.lang.Exception java.lang.ArithmeticException java.lang.ArrayIndexOutOfBoundsException java.lang.ArrayStoreException java.lang.ClassCastException java.lang.ClassNotFoundException java.lang.IllegalAccessException java.lang.IllegalArgumentException java.lang.IllegalMonitorStateException java.lang.IllegalStateException java.lang.IllegalThreadStateException java.lang.IndexOutOfBoundsException java.lang.InstantiationException java.lang.InterruptedException java.lang.NegativeArraySizeException java.lang.NullPointerException java.lang.NumberFormatException java.lang.RuntimeException java.lang.SecurityException java.lang.StringIndexOutOfBoundsException Somente a partir da CLDC 1.1 java.lang.UnsupportedOperationException java.util.EmptyStackException java.util.NoSuchElementException java.io.EOFException java.io.InterruptedIOException java.io.IOException java.io.UnsupportedEncodingException java.io.UTFDataFormatException Somente a partir da CLDC 1.1 Classes de erro java.lang.Error java.lang.NoClassDefFoundError java.lang.OutOfMemoryError java.lang.VirtualMachineError Somente a partir da CLDC 1.1 Classes de referência fraca java.lang.ref.Reference java.lang.ref.WeakReference Somente a partir da CLDC 1.1 Somente a partir da CLDC 1.1 Classes específicas do CLDC Background e motivação Uma parte significativa do padrão (J2SE) I/O e funcionalidade de rede não é diretamente aplicável aos dispositivos, que não provê TCP/IP e não têm conexões específicas como IrDA (infravermelho) ou Bluetooth. [comentário grupo] cada vez mais isso já não é uma restrição. Framework de conexão Genérico CLDC não define qualquer requisito sobre quais protocolos devem ser implementados. Ele define uma inteface genérica que deve conter no mínimo estes itens (conforme figura ) : • Conexão básica que pode ser aberta ou fechada. (Connection) • Device entrada serial (InputConnection) • Device saída serial (OutputConnection) • Device de comunicação orientado a datagrama (DatagramConnection) • Conexão orientado à circuito – exemplo: TCP (StreamConnection) • Um mecanismo para informar um servidor de conexões cliente/servidor (StreamConnectionNotifier) • Uma conexão básica de serviço Web (ContentConnection) • Um classe de exceção (ConnectionNotFoundException) Figura 5 – Framework de conexão Todas as conexões são criadas usando um único métodos estático em uma classe do sistema javax.microedition.Connector. Se bem sucedido, este método retornará um objeto que implementa uma das interfaces genéricas. Connector.open("<protocol>:<address>;<parameters>"); Exemplos: (perfis podem não implementar estes protocolos e optar pelo suporte a outros protocolos) • HTTP records: Connector.open("http://www.foo.com"); • Sockets: Connector.open("socket://129.144.111.222:9000"); • Communication ports: Connector.open("comm:0;baudrate=9600"); • Datagrams: Connector.open("datagram://129.144.111.333"); • Files: Connector.open("file:foo.dat"); • Network file systems: Connector.open("nfs:/foo.com/foo.dat"); Conclusão CLDC é uma camada de software do J2ME situada logo acima da máquina virtual. Ela define os requisitos que estabelecem um denominador comum entre a vasta gama de dispositivos móveis disponível no mercado. Como se tratam de dispositivos com recursos limitados, e que freqüentemente diferem entre si, várias simplificações foram realizadas para sua viabilização. Como exemplo, pode-se citar a utilização de apenas um subconjunto das bibliotecas da plataforma Java SE e modificações no modelo de segurança adotado com a adição de uma etapa de pré-verificação de classfiles. Apesar de complexa, considera-se esta tarefa como concluída satisfatoriamente. Programadores habituados com a plataforma Java padrão não encontrarão dificuldades na utilização da linguagem. Diferentes classes de dispositivos podem utilizar diferentes versões da CLDC, ou se evoluírem consideravelmente, até migrarem para uma configuração mais complexa como a CDC. Fabricantes também ganham na medida em que ganham mais aplicações independentes, além de portarem as suas próprias mais rapidamente. Os principais pontos que contribuíram para o aprendizado do grupo após esta monografia foram a parte de segurança (em especial o conceito de “Sandbox”), a especificação do framework genérico de conexões e a descoberta de sites (veja seção referências) para descobrir informações técnicas sobre os modelos. A principal percepção que tivemos em especial ao comparar as especificações com os dados de modelos existentes no mercado, foi que a especificação tem sido bem conservadora em relação aos requisitos de memória. Quanto ao item I/O e funcionalidades de rede a especificação também assume algumas restrições que têm sido eliminadas como a não existência de suporte a TCP/IP e conexões IrDA (infravermelho) ou Bluetooth. Referências [1] JSR-30 – Connected Limited Device Configuration 1.0 [2] JSR-139 – Connected Limited Device Configuration 1.1 [3] J2ME Building Blocks for Mobile Devices - White Paper on KVM and the Connected, Limited Device Configuration (CLDC) http://java.sun.com/products/cldc/wp/KVMwp.pdf [4] The JavaTM TMVirtual Machine Specification. Second Edition. Tim Lindholm and FrankYellin. Disponível em: http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#24614 [5] Especificações dos telefones utilizados para comparação: http://www.mobile-phone-specs.com/model/mot_v3b_ver1 http://developer.motorola.com/docstools/specsheets/MOTORAZR_V3_CLDC1.0_Sp ec_Sheet.pdf http://www.mobile-phone-specs.com/model/nokia_n95_ver1 http://pdadb.net/index.php?m=specs&id=967&view=1 O site http://www.mobile-phone-specs.com apresenta uma lista de celulares e permite descobrir a configuração CLDC e MIDP. O site http://pdadb.net/index.php?m=pdacomparer permite comparar informações técnicas sobre os modelos (em especial PDAs).
