CLDC 1.0 e CLDC 1.1(JSR-30 / JSR-139)

Grupo 01Paulo Renato de FariaRogério Makiyama Zafalão

Objetivos Especificação CLDCFabricantes de equipamentos (visão negócios)

Estimulo a desenvolvedores terceirizados.Internet: prover conteúdo dinâmico e interativo.Foco: Programação sistemas aplicações.

CLDC enfatiza generalidadeNÃO deve conter APIs específicas:

certas categorias de equipamentosnichos de mercadosfuncionalidades (ex: protocolo comunicação proprietário)

Objetivos Especificação CLDCAltíssima escala produção para fabricantes

Manter custo unitário baixoRestrições de processamento e memória

Dispositivos extensíveis Fáceis de portar software entre novos modelos

CLDC enfatiza portabilidadeEncontrar denominador comum aos equipamentos de mercado

Definir requisitos mínimos de hardware e software

Comparação da Evolução dos Requisitos de CLDC 1.0 e 1.1

Requisito CLDC 1.0 CLDC 1.1 Processador 16 ou 32 bits Consumo energia Baixo consumo de potência,

freqüentemente operando com bateria Conectividade Algum tipo de rede, freqüentemente

sem-fio; conexão intermitente com largura de banda limitada

Memória não volátil disponível para KVM e bibliotecas CLDC

128 Kb 160Kb

Memória volátil disponível para Java runtime e memória de objetos.

>= 32Kb

Tabela 1 - Comparação requisitos hardware

Comparação da Evolução dos Requisitos de CLDC 1.0 e 1.1

Requisito CLDC 1.0 CLDC 1.1 Sistema operacional (controle hardware)

Assume um mínimo sistema operacional hospedeiro ou kernel para gerenciar o hardware.

Sistema operacional (execução Java)

Este sistema deve prover no mínimo uma entidade que possa agendar execuções da máquina virtual Java.

Tabela 2 - Comparação requisitos software

Comparação da Evolução dos Requisitos de CLDC 1.0 e 1.1Requisito CLDC 1.0 CLDC 1.1 Características devem ser aplicáveis a uma grande variedade de dispositivos.

Características específicas a certo mercado vertical (exemplo: negócios, diversão), categorias de equipamento devem ser definidas em uma especificação de perfil J2ME.

Portabilidade e interoperabilidade entre equipamentos com recursos restritos

Este objetivo impõe que configurações não devam definir características opcionais

Tabela 3 - Comparação requisitos J2ME

Evolução CLDC 1.0 e 1.1http://www.mobile-phone-specs.comhttp://pdadb.net/index.php?m=pdacomparer

CLDC 1.0 CLDC 1.1 Característica RAZR V3 (Motorola) Z8 (Motorola) N95 (Nokia)

Perfil MIDP 2.0 MIDP 2.0 MIDP 2.0 Número Cores 65.536 16.777.216 262.144 Resolução (LxA) 176 x 220 240 x 320 240 x 320 CPU Valor não encontrado 32 bits 32 bits Freqüência CPU Valor não encontrado 330 MHz 332 MHz ROM (armazenamento)

Armaz. MIDlet disp: até 5 MB Tam. Máx. MIDlet suite:100 Kb Tam. Máx. Record store: 64 Kb ESPECIFICAÇÃO: ≥ 128 KB

128 MB 77 MB acessíveis ESPEC: ≥160KB

256 MB 157 MB usáveis ESPEC: ≥160KB

RAM (volátil)

Tamanho Heap: 800 Kb ESPECIFICAÇÃO: ≥160KB

64 MB ESPEC: ≥ 32KB

64 MB 22MB acessíveisESPEC: ≥ 32KB

Tabela 4 - Comparação 2 celulares com CLDCs diferentes

Escopo (ponto comum)CLDC 1.0 e 1.1

Áreas de especificaçãoCaracterísticas linguagem Java e máquina virtualNúcleo de bibliotecas Java (java.lang.*, java.util.*)Entrada / Saída (java.io.*)RedeSegurançaInternacionalização

Áreas não cobertas (devem ser definidas nos Perfis):

Gerência de ciclo-de-vida das aplicações (instalação, execução e remoção)Funcionalidade de interface de usuárioControle de eventosModelo de alto nível de aplicações (interação entre usuário e aplicação)

Arquitetura J2ME

Figura 1 - Arquitetura alto-nível J2ME

Gerência de aplicaçõesRequisitos de Gerência de aplicações

CLDC 1.0 CLDC 1.1

Listar Inspecionar aplicações Java existentes armazenadas no dispositivo

Executar Selecionar e executar aplicações Java Remover Remover aplicações Java existentes (se aplicável) Instalação Não requerido Download e instalação de

aplicações Java Tabela 5 - Evolução de requisitos para Gerência de aplicações

Significativas variações entre equipamentos CLDCGerência de aplicações altamente dependente do dispositivoCLDC não especifica como será implementação.

SegurançaProblema: Segurança Java 2 SE não pode ser utilizada

Excede a memória total disponível assumida para CLDC.

Solução: Utilizar solução simplificada. Em 3 níveis:Requisitos Gerência aplicações

CLDC 1.0 CLDC 1.1

Segurança em baixo-nível Especificado Especificado Segurança no nível de aplicação

Especificado Especificado

Segurança fim-a-fim (isto é, para garantir entrega de dados e código entre máquinas servidoras e equipamentos clientes)

Não especificado (dependente de implementação em cada equipamento, fora do escopo CLDC)

Fora escopo CLDC. Assume que será definido pelos perfis que puderem prover esta funcionalidade

Tabela 6 – Requisitos segurança

Segurança na Máquina VirtualGarante que aplicações executando VM:

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

Restrição garantida classfile verifier:Rejeitar classes com referências a localizações inválidas de memória (de execução)Rejeitar classes com referências a áreas fora da área de objetos em memória (Java heap)

Segurança no nível de aplicação

Aplicações devem ter acesso garantido apenas a itens que ambiente Java e o equipamento concederemExemplos:

BibliotecasRecursos do sistema

arquivos, impressoras, Infravermelho, redesOutros componentes

bibliotecas nativas

Segurança no nível de aplicação

Para prover controle a recursos externos:J2EE – conceito de gerente de segurança. J2SE – modelo de segurança: permissões, controladores de acesso e políticas de segurança.consomem muita memória para serem incluídos no CLDC.

Necessidade solução mais simples:Modelo Sandbox

Modelo SandboxAmbiente fechado(recursos do sistema)classes com permissão pelo dispositivo

CLDCMIDPprópria aplicação APIs específicas do fabricante

Requisitos “Sandbox”Download e gerenciamento de aplicações Java: nível VM. Carregador de classe NÃO pode ser definido pelo programador

problemas de execução classe carregada diferentemente padrão KVM

Conjunto de funções nativas acessíveis na VM é fechado. O programador NÃO pode:

fazer download de novas bibliotecas contendo funcionalidades nativasacessar quaisquer funções nativas que não sejam parte do CLDC, perfis MIDP ou classes específicas do fabricante

Protegendo classes do sistemaRequisito central CLDC: suporte a download dinâmico

de aplicações Java. Para evitar problemas de segurança, CLDC deve garantir que o programador de aplicações NÃO possa:

sobrescrever, modificar ou adicionar classes aos pacotes de sistema protegidos ( java.*, javax.microedition.*, específicos perfil ou fabricantes) manipular ordem de busca de classfiles [ex.: poderia colocar classes Boolean do usuário antes de Boolean do java.*].

IMPORTANTE: Se implementação CLDC NÃO suportar pré-carregamento de classes do sistema

Classes do sistema sempre devem ser procuradas primeiro quando fizer busca de classfiles.

Suporte execução múltiplas apps Java simultaneamente

(restrição presente apenas CLDC 1.0)Implementação CLDC pode :

permitir / proibir execuções concorrentes. decidir se execução múltiplas de aplicações

Java será suportada via:utilização funcionalidades multitasking do SO ou;instanciação de múltiplas VM lógicas para executar aplicações concorrentes.

Restrição de carregamento de classes dinamicamente

(item presente apenas CLDC 1.1)Aplicação Java pode carregar classes apenas de seu próprio arquivo JAR

evita que aplicação interfira ou roube dados de outrasevita que aplicações de terceiros ganhem acesso a componentes privados

fabricantes provedores de serviços

Formato Class File & Carregamento de ClassesFormatos suportados pela implementação CLDC:

classfiles padrão do Javaarquivos de compressão Java Archive (JAR) files.

Formato JAR provê 30-50% de nível de compressão sobre classfiles:

sem perda de quaisquer informações simbólicassem problemas de compatibilidade.

Representação pública de aplicações Java e recursosAplicação Java publicamente acessível distribuição

Formato JAR deve ser utilizado

Recursos específicos da aplicação (exemplo, imagens, sons) dentro arquivo JAR podem ser carregados na VM pelo método:Class.getResourceAsStream(String name)

Pré-carregamento / pré-ligação(não está no escopo do CLDC – dependente da

implementação)

Implementação CLDC pode optar por pré-carregar algumas classes. Tipicamente VMs de pequeno porte escolhem:

pré-carregar todas as classes do sistema (configuração ou perfil) realizar o carregamento de aplicações dinamicamente.

O único efeito visível do pré-carregamento deve ser apossível redução no tempo para início de execução de aplicação Java.

Otimização formatos de aplicações(não está no escopo do CLDC – dependente da implementação)

Classfiles NÃO são otimizados para transporte em largura de banda limitados.Classfile é unidade independente: próprio pool de constantes (tabela de símbolos), métodos, campos e tabelas de exceção, bytecodes e outras informações.Vantagem: Permite aplicações compostas de múltiplos pedaços que podem residir em diferentes locais (e ser estendidas dinamicamente).

Se aplicações Java fossem tratadas como unidades seladas muito espaço poderia ser economizado: remoção de redundância.Não haveria necessidade de conversão entre representação estática para a representação de execução

Aderência à linguagem JavaLimitações

Suporte a ponto flutuanteSem suporte na CLDC 1.0 Suporte adicionado na CLDC 1.1

Sem suporte a finalizaçãoObject.finalize()

Tratamento de errosRedução do número de classes de erro/exceção

Erros específicos dos próprios dispositivosTratamento também específico (handling/soft reset)

Aderência à linguagem JavaTratamento de erros

Comportamento em caso de erroInterromper execução da VM de uma maneira apropriada; ouLançar um erro mais próximo possível da superclasse Error

Classes de Errojava.lang.Errorjava.lang.NoClassDefFoundError (CLDC 1.1)java.lang.OutOfMemoryErrorjava.lang.VirtualMachineError

Classes de ExceçãoRedução: 189 26 CLDC 1.0 / 28 CLDC 1.1

Aderência à JVM Limitações

Sem suporte a exceções assíncronas (Ctrl-C interromper) programa)Sem suporte a Java Native Interface (JNI)Sem carregadores de classe definidos por usuáriosSem suporte a Reflexão

RMI / Serialização / JVMCI (Debug) / JVMPI (Profiling) Threads

Sem suporte a grupos de threadsusar collections explicitamente

Sem suporte a daemon threadsThreads com nome a partir da CLDC 1.1

Aderência à JVM Limitações

Sem suporte a referências fracasSuporte a WeakReference na CLDC 1.1

Weak reference objects, whichdo not prevent their referents from being made finalizable,

finalized, and then reclaimed.

Aderência à linguagem JavaBibliotecas CLDC

Classes derivadas da J2SE 1.3.1Mesmo nome e semântica

Classes própriasjavax.microedition.*

Classes derivadas J2SE

Classes de sistema (java.lang.*)Intimamente relacionadas com JVMObject, Class, Runtime, System, Thread, Runnable,String, StringBuffer, Throwable

Classes de tipos de dados (java.lang.*)Boolean, Byte, Short, Integer, Long, CharacterCLDC 1.1: Float, Double

Classes de collections (java.util.*)Vector, Stack, Hashtable, Enumeration[não temos HashMap, LinkedList, HashSet]

Classes derivadas J2SE

Classes de Entrada / Saída (java.io.*)InputStream / OutputStream,ByteArrayInputStream / ByteArrayOutputStreamDataInput / DataOutputDataInputStream / DataOutputStreamReader / WriterInputStreamReader / OutputStreamWriterPrintStream

Classes derivadas J2SE

Classes de Calendário / Tempo (java.util)Somente uma time zone suportada por default. Calendar / Date / TimeZoneCLDC 1.1: Timer / TimerTask

Classes adicionaisjava.util.Randomjava.lang.Math

Adições CLDC 1.1 e CLDC 1.1.1

Classes de referência fraca (CLDC 1.1)java.lang.ref.Referencejava.lang.ref.WeakReference

Classes derivadas J2SE

Classes de SegurançaCLDC 1.1.1 MIDP 3.0

java.security.AccessControlExceptionjava.security.AccessControllerjava.security.BasicPermissionjava.security.Permissionjava.security.PermissionCollectionjava.util.PropertyPermissionjava.lang.RuntimePermission

Targets: somente exitVM e modifyThread

Classes derivadas J2SEClasses de Exceção

java.lang: Exception, ArithmeticException, ArrayIndexOutOfBoundsException, ArrayStoreException, ClassCastException, ClassNotFoundException, IllegalAccessException, IllegalArgumentException, IllegalMonitorStateException, IllegalStateException, IllegalThreadStateException, IndexOutOfBoundsException, InstantiationException, InterruptedException, NegativeArraySizeException, NullPointerException, NumberFormatException, RuntimeException, SecurityException, StringIndexOutOfBoundsException, UnsupportedOperationExceptionjava.util: EmptyStackException, NoSuchElementExceptionjava.io: EOFException, InterruptedIOException, IOException, UnsupportedEncodingException, UTFDataFormatException

Classes específicas do CLDC

Motivação:Parte significativa das classes I/O e funcionalidade de rede do J2SE NÃO era diretamente aplicável aos dispositivos, que não provê:

TCP/IP conexões específicas como IrDA (infravermelho) ou Bluetooth.

cada vez mais isso já não é uma restrição.

Framework conexão GenéricoCLDC NÃO define requisito sobre protocolos a implementar.

Define inteface genérica que deve conter no mínimo:Conexão básica que pode ser aberta ou fechada. (Connection)Dispositivo de entrada serial (InputConnection)Dispositivo de saída serial (OutputConnection)Dispositivo de comunicação orientado a datagrama(DatagramConnection)Conexão orientado a circuito (ex: TCP) (StreamConnection)Um mecanismo para informar um servidor de conexões cliente/servidor (StreamConnectionNotifier)Uma conexão básica de serviço Web (ContentConnection)Uma classe de exceção (ConnectionNotFoundException).

Framework conexão Genérico

Framework conexão GenéricoCriação conexões (retorna objeto que implementa Connection). Connector.open("<protocol>:<address>;<parameters>");

Exemplos: (OBS: perfis podem NÃO implementar estes 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ãoPrincipais pontos aprendizado grupo:

segurança (em especial o conceito de “Sandbox”) especificação do framework genérico de conexões.descoberta de sites para obter informações técnicas de

diferentes fabricantes.

Evolução CLDC 1.0 para 1.1 vs. dispositivos mercadoespecificação conservadora em relação a requisitos memória.

Restrições assumidas (I/O e rede) vêm sendo ultrapassadas

não existência de suporte a TCP/IP e conexões IrDA(infravermelho) ou Bluetooth.

Perguntas1) Cite 3 objetivos principais CLDC?2) Quais as áreas especificação cobertas CLDC?3) Quais os 2 níveis de segurança com requisitos definidos no CLDC e seus requisitos principais? 4) Qual deve ser o formato de aplicação Java publicamente acessível para distribuição? Como acessar recursos dentro desse item?5) Qual as principais restrições do CLDC em relação Java SE (na parte de Collections)?6) Quanto a I/O e rede, como criar uma Connection a partir do framework genérico de conexões?