Java для мобильных устройств

Введение.

Платформа Java 2 Micro Edition (J2ME) была разработана для потребительского рынка устройств с ограниченными ресурсами памяти и процессора таких как: сотовые телефоны, пейджеры, смарт карты, органайзеры и миникомпьютеры. J2ME позволяет запускать Java на ресурсо-ограниченных вычислительных устройствах. Для данных целей J2ME адаптирует существующую Java технологию. Расмотрим два ключевых момента J2ME: конфигурацию и профайлы.

Конфигурация.

Конфигурация определяет среду выполнения J2ME. Она включает в себя виртуальную машину ограниченную по сравнению с стандартной VM и набор основных классов, в основном заимствованных из J2SE. В настоящий момент определены 2 конфигурации: Конфигурации коммуникационных устройств с ограниченными ресурсами (Connected Limited Device Configuration, CLDC) и Конфигурация коммуникационных устройств (Connected Device Configuration, CDC). Первая конфигурация ориентированна на микро устройства, оснащеные 16- или 32-битными процессорами с минимальным объемом памяти около 128 Кб. Сердцем J2ME CLDC является виртуальная машина K Virtual Machine (KVM), специально разработанная для сетевых устройств с небольшим объемом памяти и ограниченными ресурсами. Вторая конфигурация J2ME, CDC, ориентирована на более сложные электронные и встроенные устройства, такие как смарт коммуникаторы, сложные "интеллектуальные" пейджеры, персональные цифровые помощники (PDA) и интерактивные цифровые телевизионные приставки. Как правило, такие устройства комплектуются 32-битным микропроцессором/контроллером и оснащены более 2 Мб памяти, используемой для хранения виртуальной машины и библиотек. CDC работает с виртуальной машиной C Virtual Machine (CVM). CDC включает в себя все классы из CLDC и еще больше классов из J2SE. Главное отличие между CDC и CLDC являеться то что CDC VM поддерживает все возможности J2SE VM включая native programming interfaces

Профайл.

Профайл расширяет конфигурацию, добавляя специфичные классы к набору основных классов определенных в конфигурации. Другими словами профайл обеспечивает необходимой функцианальностью которая отсутствует в основной конфигурации. Это может быть пользовательский интерфейс, механизм хранения и т.д. Помимо MIDP профайла существуют и другие профайлы.

Foundation Profile - добавляет набор классов из J2SE к CDC но не вводит пользовательского интерфейса. Данный профайл используеться для построения на нем других профайлов.jsr-46

Personal Basic Profile - обеспечивает Java API для устройств требующих сетевой доступ и графическую презентацию. Данный профайл является подходящим для интерактивного телевидения и содержит API для поддержки Multimedia Home Platform. (JSR129)

Personal Profile - обеспечивает Java API для устройств требующих надежный сетевой доступ построен на Personal Basic Profile и Foundation Profile (JSR62)

Рисунок 1. Архитектура J2ME.

CLDC (Конфигурации коммуникационных устройств с ограниченными ресурсами)

CLDC являеться результатом работы Java Community Process (JSP) экспертной группы JSR-30 в которую составили следующие компании:

America Online

Bull

Ericsson

Fujitsu

Matsushita

Mitsubishi

Motorola

Nokia

NTT DoCoMo

Oracle

Palm Computing

RIM

Samsung

Sharp

Siemens

Sony

Sun Microsystems

Symbian

CLDC технология используеться для постоения на ней различных профайлов. Цель данной технологии определить стандарт использования Java на устройствах с ограниченными ресурсами.

160-500 kb памяти доступной для Java платформы

16-32 битный процессор

низкое потребление энергии

сетевое соединение 9600 bps или меньше.

Ниже представлены аспекты, которые попадают под "юрисдикцию" CLDC:

Java язык и виртуальyная машина KVM

Основные Java библиотеки (java.lang.*, java.util.*)

Security модель

Операции ввода вывода

Сетевая поддержка

Интернализация

Нижеследующие вещи не входят в область рассмотрения CLDC: (Как правило, они определяются профайлами.)

Пользовательский интерфейс

Обработка событий

Жизненный цикл приложений

Взаимодействие пользователя и приложения

Java язык и виртуальyная машина KVM

Основная цель для JVM поддерживающей CLDC быть совместимой с Java Language Specification насколько это возможно. За исключением различий приведенных ниже, JVM которая поддерживает CLDC, совместима с Java Language Specification.

Нет поддержки floating point. Это связано с тем, что в устройствах с ограниченными ресурсами отсутствует поддержка floating point. Поддержка же на программном уровне была бы слишком дорогим удовольствием.
Отсутствует метод finalize() и нет weak references. Это требование связано с необходимостью упрощения механизма сборки мусора.
CLDC поддерживает exception механизм, однако, его арсенал является ограниченным. Это связано с двумя причинами:
- Восстановление после ошибок достаточно специфично для каждого устройства. К тому же многие устройства просто перезагружаются после некоторых своих ошибок. Приложение не может заботиться о таких ошибках.
- Полная реализация механизма является слишком дорогим удовольствием для микро устройств.

KVM

Нет поддержки floating point. Это связано с тем, что в устройствах с ограниченными ресурсами отсутствует поддержка floating point. Поддержка же на программном уровне была бы слишком дорогим удовольствием. В JVM которая поддерживает CLDC отсутствуют байткоды связанный с типами float и double.
KVM не реализует Java Native Interface (JNI). Поддержка JNI была отклонена по двум причинам.
- Ограничения, накладываемые security моделью CLDC. (Данная модель запрещает использовать native вызовы.)
- Полная реализация JNI была признана слишком дорогой для устройств с ограниченными ресурсами.
KVM не позволяет создавать свой class loader. Это ограничения накладываемое security моделью.
KVM не поддерживает Reflection механизм. Java приложения не могут инспектировать классы, объекты, методы, поля, нитки, выполняемые стэки в виртуальной машине. Как следствие сериализация, JVMDI (Debugging Interface), JVMPI (Profiler Interface) и другие технологии J2SE основанные на Reflection механизме отсутствуют в CLDC.
KVM реализует многопоточность, но не поддерживает Thread group и daemon thread. Операции, такие как запуск и остановка могут быть применены только над отдельной ниткой.
Отсутствует метод finalize() и нет weak references. Это требование связано с необходимостью упрощения механизма сборки мусора.
Ограниченный еrror handling механизм по сравнению с J2SE.
Преверификация.

CLDC библиотеки.

CLDC библиотеки можно разделить на две категории:

В первую категорию входят классы, наследованные из J2SE.
Во вторую классы которые вводит CLDC.

Классы, принадлежащие к первой категории находятся, в пакетах java.lang.*, java.util.*, и java.io.*. Эти классы производные из Java 2 Standard Edition версии 1.3. Данные классы являются идентичными соответствующим классам J2SE. Семантика классов и их методов не будет изменяться. К классам не будут добавляться любые public или protected методы, которые не являются доступными в J2SE.

Системные классы.

Данные классы внутренне связаны с виртуальной машиной. Некоторые Java приложения требуют наличия данных классов. Например, J2SE Java compiler (javac) генерируя код, требует наличия определенных функций String и StringBuffer классов. 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
java.lang.Throwable

Классы представлющие типы.

Каждый из этих классов представляют собой подмножество соответствующих классов из J2SE.

java.lang.Boolean
java.lang.Byte
java.lang.Short
java.lang.Integer
java.lang.Long
java.lang.Character

Collection классы.

java.util.Vector
java.util.Stack
java.util.Hashtable
java.util.Enumeration (interface)

Классы ввода вывода.

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
java.io.OutputStreamWriter
java.io.PrintStream

Классы Reader, Writer, InputStreamReader и InputStreamWriter обеспечивают поддержку интернализации.

Механизм их работы такой же, как и в J2SE. Последние два класса имеют точно такие же конструкторы, как и в J2SE.

new InputStreamReader (InputStream is);
new InputStreamReader (InputStream is, String name);
new OutputStreamWriter (OutputStream os);
new OutputStreamWriter (OutputStream os, String name);

В случаях, где присутствует String параметр, используется заданный character encoding, иначе используется character encoding, имя которого содержится в переменной microedition.encoding. Если конвертер не доступен, выкидывается UnsupportedEncodingException.

Следует заметить, что CLDC не поддерживает локализацию. Это говорит о том, что все решения связанные с форматирование даты времени и т.д. находяться вне рамок расмотрения CLDC.

Календарь и время.
CLDC, включает небольшое подмножество стандартных J2SE классов: java.util.Calendar, java.util.Date, and java.util.TimeZone. По умолчанию одна временная зона поддерживается.

java.util.Calendar
java.util.Date
java.util.TimeZone

'Вспомогательные' классы.
java.util.Random класс содержит простой генератор случайных чисел.
java.lang.Math имеет в своем наборе методы abs, max и min для int и long типов.

Exception & Error.
java.lang.Exception
java.lang.ClassNotFoundException
java.lang.IllegalAccessException
java.lang.InstantiationException
java.lang.InterruptedException
java.lang.RuntimeException
java.lang.ArithmeticException
java.lang.ArrayStoreException
java.lang.ClassCastException
java.lang.IllegalArgumentException
java.lang.IllegalThreadStateException
java.lang.NumberFormatException
java.lang.IllegalMonitorStateException
java.lang.IndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
java.lang.StringIndexOutOfBoundsException
java.lang.NegativeArraySizeException
java.lang.NullPointerException
java.lang.SecurityException
java.util.EmptyStackException
java.util.NoSuchElementException
java.io.EOFException
java.io.IOException
java.io.InterruptedIOException
java.io.UnsupportedEncodingException
java.io.UTFDataFormatException

java.lang.Error
java.lang.VirtualMachineError
java.lang.OutOfMemoryError

Propety.
В CLDC отсутствует класс java.util.Properties. Однако, property могут быть доступны при помощи статического метода System.getProperty (String key). Минимальный набор properties предоставляемый CLDC следующий.

microedition.encoding
microedition.platform
microedition.configuration
microedition.profiles

Классы, принадлежащие ко второй категории находятся в пакетах javax.microedition.*. Пакет javax.microedition.io вводит новый механизм сетевой поддержки.

CLDC Connection Framework

java.io.* и java.net.* пакеты J2SE не подходят для микро устройств с их ограниченными ресурсами. Поэтому был разработан новый пакет javax.microedition.io.

Данный пакет имеет только один класс: Connector, 8 интерфейсов и ConnectionNotFoundException.

Класс Connector - это сердце Connection Framework, он имеет ряд статических методов для получения Connection объекта. Если операция происходит успешно метод возвращает объект реализующий Сonnection интерфейс иначе выкидывается IOException. На рисунке 2 представлена иерархия интерфейсов.

Рисунок 2. Иерархия интерфейсов

Объект, реализующий Connection интерфейс, может быть получен при помощи класса Connector, как уже было сказано выше. Интерфейс Connection имеет единственный метод close. Данный метод закрывает сетевое соединение.

InputConnection интерфейс "представляет устройство", из которого можно прочитать данные. Методы openInputStream и openDataInputStream возвращает поток для чтения.
OutputConnection интерфейс "представляет устройство", в которое можно записать данные. Методы openOutputStream и openDataOutputStream возвращают поток для записи.
StreamConnection интерфейс сочетает в себе IntputConnection и OutputConnection.
ContentConnection подинтерфейс StreamConnection.
StreamConnectionNotified ждет, пока соединение будет установлено. Метод acceptAndOpen() возвращает StreamConnection объект.
DatagramConnection интерфейс определяет дейтаграммное соединение.
ConnectionNotFoundException выкидывается, когда соединение не может быть утсановлено.

Connector.

Параметр String метода open класса Connector имеет следующий формат. "protocol:address;parameters".

Вот несколько примеров:

HTTP Connection
Connector.open("http://java.sun.com/developer");

Socket
Sockets: Connector.open("socket://129.144.111.222:9000");

Datagram Connection
Connector.open("datagram://address:port#");

Communicate with a Port
Connector.open("comm:0;baudrate=9600'); 


Open Files

Connector.open("file:/myFile.txt");

Network file systems:
Connector.open("nfs:/foo.com/foo.dat");

Security.

Одно из огромных преимуществ Java динамическая загрузка приложений через сеть, к клиенту используя надежный security механизм. Реализация данного механизма в J2SE превышает возможности доступного бюджета памяти для JVM поддерживающей CLDC. Для CLDC был разработан иной механизм, который можно разбить на два уровня: Уровень виртуальной машины и уровень приложения.

Уровень виртуальной машины - подразумевает, что запускаемое приложение в VM не должно иметь способность каким-либо образом повредить устройство. Данное требование должно обеспечиваться Java classfile verifier, который должен гарантировать, что загружаемый байткод не содержит ссылок к недействительным областям памяти или памяти находящейся вне Java Heap. Verifier должен отклонить загрузку таких классов.

Уровень приложения. Verifier не есть спасение от всех бед, он только проверяет байткод на 'вшивость' но он не может гарантировать, что загруженное приложение не нанесет вред устройству. В J2SE SecurityManager обеспечивает контроль над тем, чтобы приложение не смогло, не санкционировано обратиться к файловой системе, установить соединение и т.д.. Но реализация такого контроля невозможно для мини устройств с их ограничениями.

В JVM поддерживающая CLDC реализована sandbox security модель. В данной модели предполагается, что приложение должно выполняться в ограниченном окружении, в котором приложение может иметь доступ только к тем, API которые определены в конфигурации, профайлах и линензированных классах.

Более точно sandbox модель означает:

Загружаемые Java класс файлы должны пройти верификацию
Приложение может иметь доступ только к тем, API которые определены в конфигурации, профайлах и линензированных классов.
Загрузка приложений может выполняться только native кодом виртуальной машины и не может осуществляться class loader определенным пользователем. Поэтому в CLDC нельзя создать свой class loader.
Приложение не может загрузить native библиотеку, приложение не может иметь доступ к native функциям, которые доступны виртуальной машине, и иметь доступ к native библиотекам, которые не являются Java библиотеками обеспечиваемые CLDC, профайлами или линензированными классами.

Помимо этого профайлы могут добавлять свои ограничения к вышесказанным.

MIDP

Mobile Information Device Profile расширяет CLDC добавляя три новых пакета:

Выдвигает требования к инсталляции мидлетов, которые должны содержаться в MIDlet Suites Добавляет несколько классов в уже имеющиеся пакеты, определенные в CLDC:

javax.microedition.io к java.io пакету добавляет HttpConnection интерфейс.
java.langК java.lang пакету добавляет IllegalStateException (java.lang.IllegalStateException).
java.util Добавляет функциональность, которая позволяет приложениям создавать таймеры. Для этих целей были добавлены классы java.util.Timer и java.util.TimerTask из J2SE.

Автор Mank
www.midlet.ru