Article complet: Avec Android, Google réinvente Java ME ?

La semaine dernière, Google annonçait en grande pompe l'Open Handset Alliance, regroupant une trentaine de compagnies avec l'objectif d'accélérer l'innovation dans le monde de la téléphonie mobile. Le tout basé sur Android, un système d'exploitation pour téléphone portable de nouvelle génération. Ce dernier comprendra un ensemble d'application de série (comme un client email, un gestionnaire de contacts, un calendrier, un navigateurs, etc.) mais surtout qui promettait la mise à disposition rapide d'un kit de développement pour les applications tierces, qui serait traité à l'identique des applications de base (c'est à dire que n'importe quelle application du système pourrait éventuellement être remplacé par une autre).

Un initiative bienvenu lorsque l'on sait que le fameux iPhone d'Apple ne permet toujours pas d'installer d'applications tierces sans recourir à des solutions plus ou moins légales et pratiques...

Déjà, dans la séléction hebdomadaire du 9 novembre, la rédaction java envisageait qu'une machine virtuelle Java pourraient être intégré en standard avec Android. Et en ce 12 novembre, alors que le premier SDK a vu le jour, force est de constater que ce n'est pas exactement le cas...

C'est nettement plus intéressant puisque Java se retrouve au coeur même du système d'Android ! Enfin presque...

[Suite:]

Contrairement à ce que l'on aurait pu penser, ce n'est pas Java ME qui a été choisit, mais bel et bien Java SE. Ou plus précisément un étrange fork qui ne porte pas vraiment le nom de Java... mais qui en a bien toute la saveur.

Il n'y a pas donc pas véritablement de machine virtuelle Java, mais une machine virtuelle Dalvik au coeur même du système, qui est chargée d'exécuter toutes les applications du système (y compris les applications de base). Cette machine virtuelle n'exécute pas des fichiers *.class comme le ferait une JVM, mais des fichiers *.dex qui se trouve être en fait des classes Java transformées spécialement pour Dalvik via un outil de son SDK.

Ainsi les développeurs Java ne devraient pas être trop dépaysé puisqu'ils pourront continuer à utiliser leurs EDIs/compilateurs favoris : tout le développement est ainsi fait avec Java 5.0. D'ailleurs un plugin pour eclipse est déjà fourni par Google, et étant donné l'ouverture du système, des plugins pour les autres EDIs ne devraient pas tarder à suivre...

Comme toutes machines virtuelles, Dalvik est lié à un "runtime" qui contient toutes les librairies de base utile à la conception des applications. Et ce runtime comporte les principales librairies de Java 5.0. Plus exactement il s'agit d'un Java 5.0 épuré des packages suivants (le signe '*' indique que tous les sous-packages sont également absent) :

• java.applet
• java.awt *
• java.beans *
• java.lang.management
• java.rmi *
• javax.accessibility
• javax.activity
• javax.imageio *
• javax.management *
• javax.naming *
• javax.print *
• javax.rmi *
• javax.security.auth.kerberos
• javax.security.auth.spi
• javax.security.sasl
• javax.sql.rowset *
• javax.swing *
• javax.xml * (sauf javax.xml.parsers)
• org.ietf.jgss
• org.omg * (CORBA/IOP)
• org.w3c.dom.bootstrap
• org.w3c.dom.events
• org.w3c.dom.ls

Mis à part l'absence des librairies graphiques standards de Java (AWT et Swing) et de ImageIO, la plupart des librairies manquantes sont d'un intérêt assez limité dans le cadre d'un système embarqué, et même très peu utilisé dans le cadre d'une application de bureau. Leurs absences ne devraient pas trop géner les développeurs Java...

En contrepartie on retrouve la quasi-totalité des librairies de base de Java, avec bien entendu java.lang mais aussi Java IO ou NIO pour les entrées/sorties, java(x).net pour le réseau, l'API de Collection au grand complet, JDBC, la réflection ou encore la nouvelle API de concurrence... Bref bien plus que ce que ne propose Java ME !

Mais ce n'est pas tout puisque le runtime d'Android se voit également enrichi par d'autres librairies sous les packages android.*, avec un "Application Framework" regroupant un scope assez large de fonctionnalité, allant de l'intégration de SQLite à un toolkit UI adapté pour les systèmes embarqués (que je trouve d'ailleurs plutôt agréable à l'oeil), en passant par des fonctions de téléphonie plus ou moins spécifique (appel téléphonique, SMS, GPS, caméra/appareil photo, etc.), la gestion des formats multimédia les plus courant, la reconnaissance vocale et bien d'autres éléments qui pourraient varier selon le matériel...

Et il ne faut pas oublier non plus l'ajout d'un certain nombre de librairie annexe au coureur même du runtime d'Android :

• javax.microedition.khronos.opengles, une implémentation de la JSR 239 qui propose un binding pour OpenGL ES. C'est d'ailleurs la seule API en provenance de Java ME.
• JUnit, la bibliothèque de test unitaire bien connu du monde Java.
• Jakarta Commons Codec, une série de codeurs/décodeurs commun tels que Base64, Hex, etc.
• Jakarta Commons HttpClient, permettant d'intérroger un site Web le plus simplement possible.
• org.bluez pour la gestion du Bluetooth.
• org.json afin de gérer le format de données JSON.
• Sans oublier deux librairies propre à Google, com.google.android.maps qui permet de manipuler et d'afficher les données de Google Map, et com.google.android.xmppService qui intègrera le protocole de communication XMPP, utilisé notemment à travers Jabber et Google Talk.

Bref tout le nécessaire pour développer des applications bien adaptées aux systèmes embarqués...

Mais Android c'est quoi en fait ?

Android correspond en fait au système d'exploitation complet qui sera utilisé sur les appareils mobiles compatibles, et il se décomposent en 4 couches principales comme le montre le schéma ci-dessous :

Android se base donc sur un kernel Linux en version 2.6, qui se chargera des services de base tel que la gestion des processus, de l'énergie, de la couche réseau ou encore des pilotes matériels. Il englobe également un ensemble de librairies natives couvrant un scope assez large allant de la librairie standard C aux librairies graphiques 2D/3D, en passant par le support multimédia des formats image/audio/vidéo les plus courant ou encore WebKit, le fameux moteur de rendu de page web (utilisé entre autre par le navigateur Safari ou l'iPhone).

Au même niveau, on retrouve la machine virtuelle Dalvik, qui se chargera donc d'exécuter toutes les applications du système, ainsi que les librairies de base du runtime.

On retrouve ensuite l'Application Framework (représenté dans l'API par les packages android.*) qui se chargera à la fois de proposer un cadre pour le développement d'application, mais également de fournir l'accès aux fonctionnalités avancées de l'appareil en se basant sur les librairies natives de la couche inférieur.

Enfin, la couche supérieur regroupera toutes les applications du téléphone, que ce soit les applications de base ou des applications tierces...

Qu'est-ce que cela apporte par rapport à Java ME ?

D'un premier abord, Android à vraiment l'air très prometteur, et semble offrir tout le nécessaire pour développer des applications aussi diversifié que possible.

En comparaison avec Java ME on remarquera surtout une API bien plus riche et surtout moins éparpillé : Java ME est basé sur un ensemble de JSR optionnelle plus ou moins présente d'un appareil à l'autre, ce qui ne facilite pas vraiment la tâche du développeur.

Ici on dispose d'une grosse API commune, qui permet de gérer la présence ou non des éléments trop dépendant du matériel (comme la présence ou non d'une caméra/appareil photo, du WiFi, d'un GPS ou d'une accélération 3D).

Par contre j'ai hâte de connaitre la position exacte de Sun vis à vis de cette plateforme, basé sur Java mais qui ne l'est pas vraiment... et surtout ce que cela implique quand à l'avenir de Java ME !

• Va-t-on rencontrer les mêmes problèmes qu'à l'époque de la JVM de Microsoft ?
• Sun va-t-il s'investir dans Android ?
• Et que va devenir JavaFX ?

Java 7 devrait apporter un système de module : n'y aurait-il pas une belle occasion à prendre pour modulariser les différentes composantes de Java et faire d'Android une vrai plateforme Java ?

Cela n'est pas sans poser un certain nombre de question, mais il semble clair que le monde de la téléphonie est en train de bouger !

Et il est intéressant de noter que contrairement à Apple et son iPhone qui reste encore assez fermé aux développeurs, Google a choisit une approche diamétralement opposée en publiant un SDK très tôt, et surtout en faisant de l'oeil aux développeurs via l'Android Developer Challenge, un concours de développement doté de 10 millions de dollars de lots...

Sans oublier une documentation qui semble relativement complète et bien garni en exemple.

Bref Google semble avoir mis tous les moyens de son coté, et il ne reste plus qu'à voir ce que cela va donner... mais personnellement je suis déjà conquis !

Et vous ?