Introduction
La plateforme Java 2 Micro Edition (J2ME) a été créée pour le marché
de consommateur d'équipement à ressources limitées de mémoire et de
processeur tels que : téléphones portables, smart cartes, palms,
organizers et mini-ordinateurs. J2ME permet de lancer Java sur
l'équipement à calculer à ressources limitées. Pour cet objectif,
J2ME adapte la technologie de Java qui existe. Voyons 3 points de J2ME :
la configuration, les profiles et le Midlet.
L'information détailler vous pouvez trouver sur le site officiel de
Sun Microsystems:
http://java.sun.com/j2me/
1.La configuration
Elle détermine le milieu d'exécution de J2ME. Elle inclut une machine virtuelle
limitée par rapport à VM standard et d'un nombre des classes principales, en
général, empruntées à J2SE.Actuellement, il y a 2 configurations déterminées :
configuration des mobiles de communication à ressources limitées (Connected
Limited Device Configuration, CLDC) et configuration des mobiles de
communication (Connected Device Configuration, CDC). La première configuration
est orientée vers le mini mobile équipé de processeurs à 16/32 bits dont le
mémoire est de 128 KB minimum.
Le point avantageux de J2ME CLDC consiste en une machine virtuelle K Virtuel
Machine (KMV), mise au point spécialement pour les interfaces de réseau
à mémoire et ressources limitées. La deuxième configuration de J2ME CDC est
orientée vers les modèles électroniques prévues à être montés à l'intérieur,
plus compliqués tels que : smart communicateurs, pagers, PDA,
(Sony PlayStation, XBox, etc.). Normalement, les mobiles
pareils inclus les processeurs à 32 bits fonctionnant comme contrôleur et
de mémoire de plus de 2 Mb utilisé pour sauvegarder la machine
virtuelle et la bibliothèque. CDC met en marche la machine virtuelle
C Virtuel Machine (CVM).
CDC est composé de toutes les classes de CLDC et contient encore plus de
classes de J2SE. La différence principale entre CDC et CLDC est ce que
CDC VM maintient toutes les possibilités de J2SE VM y compris native
programming interfaces.
2. Profile
Le profile élargit la configuration en ajoutant des classes spécifiques
au nombre de classes générales, définies dans leur configuration. Autrement
dit, le profile assure la fonctionnalité indispensable qui manque dans la
configuration générale. Cela peut être une interface d'utilisateur,
un mécanisme de sauvegarde, etc. A part MIDP profile ( Mobile Information
Device Profile) il en existe d'autres.
2.1. Foundation Profile
" Foundation Profile " sert à ajouter un certain nombre de classes de J2SE
à CDC, mais il ne s'agit pas d'introduire une interface d'utilisateur.
A base de ce profile, on construit d'autres profiles
2.2. Personal Basic Profile
" Personal Basic Profile " sert à assurer Java API pour les mobiles qui
demandent l'accès au réseau et une présentation graphique. Ce profile est
très utile pour la télévision interactive car il contient également API
pour le maintien de Multimedia Home Platform (JSR 129).
2.3. Personal Profile
" Personal Profile " sert à assurer Java API pour les mobiles qui demandent
un accès au réseau solide fondé sur "Personal Basic Profile " et
" Foundation Profile " (JSR62).
Architecture J2ME. * - ou développement.
3. CLDC
(Configuration des mobiles de communication à ressources limitées)
CLDC est un résultat du travail de Java Community Process (JCP), un groupe
d'expert JSR-30, qui représente les compagnies suivantes :
° America Online
° Bull
° Ericsson
° Fujitsu
° Matsushita
° Mitsubishi
° Motorola
° Nokia
° NTT DoCoMo
° Oracle
° Palm Computing
° RIM
° Samsung
° Sharp
° Siemens
° Sony
° Sun Microsystems
° Symbian
CLDC technologie s'emploie pour y créer d'autres fichiers différents.
Le but de cette technologie est de déterminer le standard d'utilisation
de Java sur les mobiles à ressources limitées :
° 160-500 Kb de mémoire accessible à plateforme Java
° Processeur à 16-32 bits
° basse consommation de l'énergie
° connexion au réseau de 9600 bps ou moins.
Ci-dessous, sont présentés des aspects qui tombent sous la " juridiction "
de CLDC :
° Java langue et la machine virtuelle KVM
° Bibliothèques de Java principales (java.lang.*, java.util.*)
° Modèle de sécurité
° Opération I/O
° Support du réseau
° Internalisation
Cité ci-dessous n'est pas à voir avec CLDC (en général, ils sont
déterminés par des profiles) :
° Interface d'utilisateur
° Traitement des événements
° Période de validité des applications,
° Liaison entre un utilisateur et une application.
4. Java langue et la machine virtuelle KVM
L'objectif pour JVM maintenant CLDC c'est d'être compatible avec Java
Language Specification autant que possible. Excepté les différences citées
ci-dessous, JVM maintenant CLDC peut être considéré compatible avec Java
Language Specification.
° il n'y a pas de support floating point. Dans les mobiles à ressources
limitées cela n'existe pas parce que le support floating point au niveau de
programmation comporte des frais supplémentaires
° il n'y a pas de méthode finalize() et weak references non plus.
Cette exigence est liée à la nécessité de simplifier le mécanisme de nettoyage
° CLDC maintient exception mécanisme. Pourtant, son sa capacité est limitée
pour 2 raisons suivantes :
- le rétablissement après les fautes est toujours spécifique pour chaque
mobile ; certains d'eux se redémarrent tous seuls après avoir détecté
les fautes. L'application ne peut pas s'occuper de ces fautes.
- La réalisation complète du mécanisme est trop chère pour les micro mobiles.
4.1. KVM
° il n'y a pas de support de floating point. Il n'existe pas dans les mobiles
à ressources limitées pour la raison qu'il serait trop cher de le maintenir au
niveau de programmation. Dans JVM maintenant CLDC il n'y a pas non plus de
byte codes liés aux types float et double.
° KVM ne réalise pas Java Native Interface (JNI). Le support JNI a été rejeté
pour 2 raisons :
- security modèle de CLDC interdit l'utilisation des appels native
- réalisation complète de JNI a été considérée trop chère pour les mobiles
à ressources limitées.
° KVM ne permet pas de créer son class loader. Cette interdiction est
imposée par la modèle de sécurité.
° KVM ne maintient pas Reflection mécanisme. Les applications de Java ne
peuvent pas inspecter les classes, les objets, les méthodes, les champs,
les fils exécutés par la machine virtuelle. Par conséquent, les technologies
comme JVMI (Debugging Interface), JVMPI (Profiler Interface) et d'autres
technologies de J2SE, basées sur Reflection mécanisme sont absentes dans
CLDC.
° KVM réalise la multiplex, mais elle ne supporte pas Thread group et
daemon thread. Les opérations comme le lancement et l'arrêt peuvent être
appliquées uniquement dans un seul Thread
° Il ne peut pas utiliser la méthode finalize(), ainsi que weak references
car cette condition est indispensable pour que le mécanisme de nettoyage
soit moins compliqué.
° Le mécanisme error handling est moins développé par rapport à celui
de J2SE.
° Pré vérification.
5. Les bibliothèques de CLDC
On distingue 2 catégories de bibliothèques de CLDC:
° Dans la première catégorie sont incluses les classes de J2SE.
° Dans la deuxième - les classe introduites par CLDC.
Les classes de la première catégorie se situent dans les paquets
java.lang.*, java.util.* et java.io.* . Ces classes sont dérivées de
Java 2 Standard Edition version 1.3. Elles sont identiques à celles de
J2SE. La sémantique des classes et de leurs méthodes ne changera pas.
Les méthodes public () ou protected (), qui ne sont pas accessibles à
J2SE, ne s'y ajouteront pas.
5.1. Les classes de système
Les classes données sont liées intérieurement à la machine virtuelle.
Certaines applications de Java demandent l'assistance des classes données.
Exemple: J2SE Java compiler (javac), en générant le code, demande la
présence de certaines fonctions de String et StringBuffer classes.
Les classes représentant des types.
Chacune de ces classes se représente une sous multitude des classes
correspondantes de J2SE.
Collection classes.
I/O classes.
Les classes Reader, Writer, InputStreamReader et InputStreamWriter permettent
d'assurer le support de l'internalisation.
Le mécanisme de leur travail est le même que celui de J2SE. Ses 2 dernières
classes ont les mêmes constructeurs comme dans J2SE.
Dans les cas où le paramètre String est présent, il faut utiliser character
encoding, dont le nom est inscrit dans une variable de microedition.encoding.
Si le converteur n'est pas accessible, UnsupportedEncodingException apparaît.
Il faut bien noter que CLDC ne supporte pas la localisation. Donc, ce fait
prouve que toutes les décisions liées à l'action de formatage de la date,
de l'heure, etc. se trouvent hors de l'examen de CLDC.
5.2. Le calendrier et l'heure
CLDC inclut une certaine sous multitude de des classes de standard de J2SE :
java.util.Calender, java.util.Date et java.util.TimeZone. Par défaut,
il maintient le même fuseau horaire.
5.3. Les classes secondaires
Java.util.Random, une classe qui contient le générateur de nombres fortuits
Java.lang.Math dispose des méthodes comme abs, max et min pour int et
long types.
5.4. Exception & Error
6. Propriété
Dans CLDC il n'y a pas de classe java.util.Properties. Cependant, propriéte
peut être accessible à l'aide d'application d'une méthode statique
System.getProperty (String key). Le nombre minimal de propriété, donné
par CLDC est suivant :
microedition.encoding
microedition.platform
microedition.configuration
microedition.profiles
Les classes qui appartiennent à la deuxième catégorie se trouvent dans
les paquets de Java.microedition.*.
Le paquet javax.microedition.io introduit un nouveau mécanisme d'un
support de réseau.
7. CLDC Connection Framework
Java.io.* et java.net.* sont des paquets de J2SE qui ne conviennent pas
pour les mobiles à cause de leurs ressources limités. Voilà pourquoi,
il a été développé un nouveau paquet java.microedition.io.
Ce paquet ne contient qu'une seule classe : Connector, 8 interfaces
et ConectionNotFoundException.
La classe Connector - c'est le " coeur " de Connection Framework.
Il a une série de méthodes statiques pour la réception de l'objet de
Connection. Si l'opération est réussite, la méthode rend l'objet qui
réalise la connexion à l'interface, ou bien, IOException s'apparaît.
La hiérarchie des interfaces
L'objet réalisant la connexion à l'interface peut être reçu grâce à
la classe Connector comme on l'avait dit ci-dessus. L'interface
Connection a la seule méthode close() qui ferme la connexion au réseau.
° InputConnection, c'est l'interface qui permet de lire les données.
Les méthodes openInputStream et openDataInputStream retournent les données
pour la lecture
° OutputConnection, c'est l'interface qui permet d'enregistrer les données.
Les méthodes openOutputStream et openDataOutputStream retournent les
données pour l'enregistrement
° StreamConnection, c'est l'interface qui réunie en soi InputConnection et
OutputConnection.
° ContentConnection est le sous interface de StreamConnection
° SteamConnectionNotified attend que la connexion soit établie. La méthode
acceptAndOpen() rend le StreamConnection objet
° DatagrameConnection interface détermine la connexion datagramme
° ConnectionNotFoundException s'apparaître quand la connexion ne peut pas être
établie
8. Connecter
Le paramètre String appartenant à la méthode de la " open " classe de
Connecter a un format suivant : " protocole:adresse:paramètres "
Exemples du code :
9. Sécurité
L'un des plus grands avantages de Java, c'est le chargement dynamique
des applications par le réseau chez le client en utilisant un mécanisme
solide de sécurité. La réalisation de ce mécanisme en J2SE dépasse les
ressources de mémoire de JVM qui supporte CLDC. Pour cette dernière,
il a été développé un autre mécanisme qui peut être divisé en 2 niveaux
: le niveau de machine virtuelle et
celui d'application.
Le niveau de machine virtuelle sous-entend que l'application démarrée
dans la machine virtuelle ne doit avoir aucune possibilité d'endommager
le mobile. Cette condition assurée par Java classfile Vérifier doit
garantir que le byte code démarré ne contient pas de liens vers les domaines
non valables de la mémoire. Vérifier doit rejeter le chargement de
ces classes.
Le niveau d'application. Vérifier n'est pas le moyen universel contre
tous les problèmes. Sa fonction est justement de vérifier le byte code
de façon générale, mais cela ne peut pas garantir que le mobile ne
sera pas endommagé par une application démarrée. Dans J2SE, Security
Manager effectue le contrôle sur ce que l'application ne puisse pas sans
autorisation s'adresser au système, établir la connexion, etc. Mais les
mobiles ne peuvent pas réaliser un contrôle pareil à cause de leurs
ressources limités. Dans JVM que CLDC supporte, a été réalisé une
sandbox security modèle. Là, il est supposé que l'application doit
s'effectuer dans un environnement déterminé où elle a l'accès uniquement
à ceux API qui ont été déterminés lors de la configuration, dans les
profiles et dans les classes autorisées.
Pour être plus précis, le sandbox modèle signifie que :
- les fichiers de la classe de Java démarrés doivent passer
la vérification
- l'application peut avoir l'accès uniquement à API qui sont déterminés
dans la configuration, les plofiles et les classes autorisées
- le chargement des applications peut être effectuer avec native code
de la machine virtuelle et ne peut pas réaliser class loader par
l'utilisateur. Donc, il est impossible de créer son propre class loader.
- l'application ne peut pas charger la native bibliothèque. L'application
ne peut pas avoir d'accès aux native fonctions qui sont accessibles pour
la machine virtuelle, ainsi qu'aux native bibliothèques qui ne sont pas
les bibliothèques de Java maintenues par CLDC, les profiles et classes
autorisées. La réalisation de CLDC doit assurer l'impossibilité de
redémarrage de paquets de système java.*, javax.microedition.*.
Outre cela, les fichiers peuvent rajouter leurs propres restrictions
à celles, mentionnées ci-dessus.
10. MIDP
Mobile Information Device Profile élargit CLDC y ajoutant de 3
nouveaux paquets :
° javax.microedition.midlet
° javax.microedition.lcdui
° javax.microedition.rms
Il est exigé des certaines conditions lors de l'installation des MIDlet.
On ajoute une série de classes aux paquets déjà existants et déterminés
dans CLDC :
javax.microedition.io :
au paquet de java.io on ajoute HttpConnection interface.
java.lang :
au paquet de java.lang on ajoute IllegalStateException
(java.lang.IllegalStateException).
java.util :
on ajoute de la fonctionnalité qui permet aux applications de créer
des timers. Dans ces buts, on a ajouté aussi les classes de
java.util.Timer et java.util.TimerTask qui viennent de J2SE.
Le composant principal d'interface d'utilisateur MIDP est screen.
11. Midlet
Mobile Information Device Profile n'a pas de ressemblance avec le modèle
Applet introduite en J2SE. MIDP introduit un nouveau modèle, construit à
la base de CLDC, qui permet à la multitude des applications de Java de
se démarrer concurremment sur KVM et partager les données.
Voyons, donc, l'examen de MIDP sur l'exemple le plus simple Hello World.
Son code est présenté ci-dessous.
Étudions l'exemple donné en détail :
Premièrement, ce qu'on fait, c'est la création de la classe qui réalise
une classe abstraite java.microedition.midlet.Midlet. Pour réaliser cette
classe, il est indispensable de réaliser 3 méthodes abstraites starApp,
pauseApp et destroyApp. Ces 3 méthodes déterminent le cycle de vie du midlet.
Mais tout d'abord, quelques mots sur l'histoire de la création de
l'objet MIDlet. Dans le modèle MIPD, le système éveille dans le public
constructeur sans arguments pour créer un objet MIDlet. Si vous voulez lui
donner des initiales, c'est justement l'endroit où il faut saisir le code.
La méthode starApp est appelée par le système pour démarrer ou redémarrer
le midlet. Son but est la préparation du midlet au travail, par exemple,
la répartition des ressources et la création de l'interface d'utilisateur
nécessaire. La méthode starApp peut être finir par 2 façons qu'on appelle
transient et non transient. Transient, ce n'est pas un cas fatal, le midlet
peut " dire " au système qu'il a été lancé encore une fois plus tard.
Pour cela le midlet fait lancer MIDletStateChangeException. Non-transient ,
c'est le cas quand il arrive quelque chose d'extraordinaire qui n'a pas été
planifié, un problème, par exemple, une Error ou RuntimeException.
Dans ce cas, le midlet devra se détruire à l'aide de la méthode destroyApp.
Ces 2 situations sont présentées ci-dessous.
La méthode pauseApp est appelée par le système pour suspendre
l'activité du midlet. Dans cette situation, le midlet doit s'arrêter et
rendre disponibles les ressources dont il n'a plus besoin. Ce dernier est
très important car les ressources de KVM sont assez limitées. La méthode
pauseApp, en général, doit fonctionner en même temps que la méthode startApp.
Et la dernière méthode destroyApp s'éveille par le système pour
" annoncer " au midlet, qu'il sera détruit et qu'il se prépare à
la procédure: fermer les ressources et sauvegarder l'information
nécessaire.
12. Cycle de vie d'une Midlet
Maintenant, passons à l'étude du cycle de vie du midlet.
Quand il est en veille, il peut avoir l'un des 3 états suivants :
12.1. Paused State
Dans l'état Paused State, le midlet peut demeurer, premièrement,
s'il vient d'être créé, et la méthode startApp n'a pas encore été mise
en circuit/service, et deuxièment, en résultat des appels à pauseApp ou
des méthodes notifyPaused. Dès que le midlet aura retrouvé cet état, il
devra rendre disponibles les ressources dont il n'a plus besoin. Mais il
reste toujours " en vie " car il peut toujours recevoir des messages
asynchrones comme, par exemple, celui du Timer. Cependant, il faut bien
noter que le système peut ne pas réaliser cet état. À titre d'exemple
prenons une situation où le midlet a été démarré, et en même temps le
mobile a reçu un appel. Dans ce cas, le mobile peut simplement " tuer "
la machine virtuelle si ce mobile ne peut pas réalisé l'état Paused.
12.2. Active State
Le midlet étant en état Active après la mise en service de la méthode
startApp, ou bien, après avoir quitté l'état Paused en résultat de
l'appel à resumeRequest.
12.3. Destroyed State
L'état de Destroyed State, le midlet se retrouve après l'appel à
destroyApp ou notifyDestroyed. Étant dans cet état, le midlet ne peut
pas passer à un autre état. Le passage d'un état à un autre se produit
par le système ainsi que par le midlet même.
Maintenant, résumons l'information sur 6 méthodes des classes
MIDlet. (La septième méthode, getAppProperty, ne concerne pas
" le cycle de vie " d'une midlet).
° startApp - c'est la méthode s'appelle par le système pour le mettre
une midlet dans un état Active, ou pour le remettre en service après
l'état Paused. Il ne faut pas confondre la méthode startApp et la
méthode main : la méthode startApp peut être appelé plus qu'une fois
° pauseApp - c'est la méthode qui peut être appelé par le système
dans 2 cas : si le mobile reçoit un appel, ou bien, s'il manque
de mémoire. Dans ce dernier cas, le midlet doit " libérer "
les ressources.
° destroyApp - c'est une voie " normal " de terminer le travail
du midlet. Cette méthode a un paramètre boolean (unconditional).
Ce paramètre montre si l'appel est " inconditionnel ".
Autrement dit, si l'appel est égal fasle et le midlet n'est pas
prêt à terminer son travail, il peut " demander la vie " au système,
ayant lancé MIDletStateChangeException. Le système, alors, peut
exécuter cette demande , donc, l'état du midlet ne changera pas.
Dans le cas où le paramètre serait égal true, le midlet doit " obéir "
sans " demander la vie ", et rendre disponibles toutes les ressources.
Les 3 méthodes suivantes peuvent être appelés par le midlet même
pour changer son état en cours.
° resumeRequest : en utilisant cette méthode, le midlet peut
initier le passage de l'état Paused à l'état Active. Cette occasion
peut arriver, par exemple, à l'expiration d'un délai de Timeout
° notifyPaused : cette méthode permet au midlet de passer
librement de l'état Active à l'état Paused
° notifyDistroyed : le midlet peut appeler cette méthode pour
annoncer qu'il a terminé le travail, sauvegardé les données nécessaires
et rendu disponibles les ressources, et avec cela la méthode destroyApp
ne sera pas appelée.
Conclusion
En conclusion, je voudrais dire quelques mots en faveur de la technologie
de Java ou pour être plus précis J2ME. En la comparant avec d'autres
technologies, comme par exemple .NET, proposé par Microsoft, etc. je trouve que la
technologie Sun apporte plus d'avantages : elle est simple et facile
d'utilisation (technique de programmation) à un large niveau d'utilisateurs
(en tant que logiciel et documentation) .Java pour les mobiles a un énorme
potentiel surtout grâce à l'utilisation des mobiles dans la vie quotidienne,
ce qui lui a déjà ouvert l'accès dans tous les domaines et sur le marché
mondial. L'utilisation de Java(J2ME) dans les mobiles la fait de plus en plus
populaire parmi les utilisateurs et les programmeurs.
|
