Java (langage) - Définition

Introduction

Java
Apparu en	23 mai 1995
Auteur	Sun Microsystems
Paradigme	Programmation orientée objet, structurée et impérative
Typage	Statique, fort, sûr, nominatif
Influencé par	Objective-C, C++, Smalltalk, Eiffel
A influencé	C#, D, J#, Ada 2005, Gambas
Implémentations	Liste de JVM
Système d'exploitation	Multiplateformes
Licence	GNU GPL
Site Web	www.java.com

Le langage Java est un langage de programmation informatique orienté objet créé par James Gosling et Patrick Naughton employés de Sun Microsystems avec le soutien de Bill Joy (cofondateur de Sun Microsystems en 1982), présenté officiellement le 23 mai 1995 au SunWorld.

Aperçu

Le langage Java a la particularité principale que les logiciels écrits avec ce dernier sont très facilement portables sur plusieurs systèmes d’exploitation tels que UNIX, Windows, Mac OS ou GNU/Linux avec peu ou pas de modifications. C’est la plate-forme qui garantit la portabilité des applications développées en Java.

Le langage reprend en grande partie la syntaxe du langage C++, très utilisé par les informaticiens. Néanmoins, Java a été épuré des concepts les plus subtils du C++ et à la fois les plus déroutants, tels que les pointeurs et références, et l’héritage multiple remplacé par l’implémentation des interfaces. Les concepteurs ont privilégié l’approche orientée objet de sorte qu’en Java, tout est objet à l’exception des types primitifs (nombres entiers, nombres à virgule flottante, etc.)

Java permet de développer des applications client-serveur. Côté client, les applets sont à l’origine de la notoriété du langage. C’est surtout côté serveur que Java s’est imposé dans le milieu de l’entreprise grâce aux servlets, le pendant serveur des applets, et plus récemment les JSP (JavaServer Pages) qui peuvent se substituer à PHP, ASP et ASP.NET.

Java a donné naissance à un système d'exploitation (JavaOS), à un environnement de développement (eclipse/JDK), des machines virtuelles (MSJVM, JRE) applicatives multi plates-formes (JVM), une bibliothèque Java (J2ME) avec interface graphique (AWT/Swing), des applications Java (logiciels, servlet, applet). La portabilité du code Java est assurée par la machine virtuelle. JRE – la machine virtuelle qui effectue la traduction et l'exécution du bytecode en code natif – supporte plusieurs processus de compilation (à la volée/bytecode, natif). La portabilité est dépendante de la qualité de portage des JVM sur chaque OS.

Aujourd'hui, Java (sous la forme de JavaFx) trouve une nouvelle niche dans la création d'applications RIA (Rich Internet Applications), des applications qui proposent des fonctionnalités, notamment des interfaces, plus évoluées à la fois sur Internet et sur les téléphones portables. Le langage JavaFx est un langage agile dérivé de Java, sous le contrôle de Sun Microsystems, qui met à profit la portabilité de Java ainsi que les vastes bibliothèques déjà disponibles dans le langage java.

Philosophie

Lors de la création du langage Java, il avait été décidé que ce langage devait répondre à 5 objectifs :

1. simple, orienté objet et familier ;
2. robuste et sûr ;
3. indépendant de la machine employée pour l'exécution ;
4. très performant ;
5. interprété, multi-tâches et dynamique.

Un langage orienté objet et familier

La première caractéristique, le caractère orienté objet (« OO ») et familier, fait référence à une méthode de programmation et de conception du langage et le fait qu'un programme écrit en Java ressemble assez fort à un programme écrit en C++.

Bien qu’il existe plusieurs interprétations de l’expression orienté objet, une idée phare dans ce type de développement est que les différents types de données doivent être directement associés avec les différentes opérations qu’on peut effectuer sur ces données. En conséquence, les données (appelées Propriétés) et le code les manipulant (appelé Méthodes) sont combinés dans une même entité appelée Classe d'objet. Le code devient logiquement découpé en petites entités cohérentes et devient ainsi plus simple à maintenir et plus facilement réutilisable, étant intrinsèquement modulaire.

D’autres mécanismes tels l’héritage permettent d’exploiter toutes les caractéristiques d’une Classe précédemment écrite dans ses propres programmes sans même avoir à en connaître le fonctionnement interne, on n’en voit que l’interface (l'interface décrit les propriétés et les méthodes sans fournir le code associé). Java interdit la notion d'héritage depuis plusieurs classes parent sauf si elles sont des interfaces.

Dans la version 1.5 du langage ont été rajoutés les génériques, un mécanisme de polymorphisme semblable (mais différent) aux templates du langage C++ ou aux foncteurs d’Objective Caml. Les génériques permettent d’exprimer d’une façon plus simple et plus sûre les propriétés d’objets comme des conteneurs (listes, arbres…) : le type liste est alors considéré génériquement par rapport au type d’objet contenu dans la liste.

Mécanisme du ramasse-miettes (Garbage Collector)

Cet élément contribue à la robustesse et à la performance des programmes, le ramasse-miettes est appelé régulièrement et automatiquement pendant l'exécution du programme. Sur les systèmes multi-processeurs et/ou multi-cœurs celui-ci emploie même des threads multiples à faible priorité afin de perturber le moins possible l'exécution de programme. En outre, le programmeur peut au besoin suggérer de lancer le ramasse-miettes à l’aide de la méthode System.gc().

Un grief récurrent à l’encontre de langages comme C++ est la lourde tâche d’avoir à programmer manuellement la gestion de la mémoire. En C++, la mémoire allouée par le programme pour créer un objet est désallouée lors de la destruction de celui-ci (le plus souvent par un appel explicite à l'opérateur delete). Si le programmeur oublie de coder la désallocation, ceci aboutit à une « fuite mémoire », et le programme en consomme de plus en plus. Pire encore, si par erreur un programme demande plusieurs fois une désallocation, ou emploie une zone de mémoire après avoir demandé sa désallocation, celui-ci deviendra très probablement instable et se plantera.

En Java, une grande partie de ces problèmes est évitée grâce au ramasse-miettes. L'espace mémoire nécessaire à chaque objet créé est alloué dans un tas de mémoire (en anglais : memory heap) réservé à cet usage. Le programme peut ensuite accéder à chaque objet grâce à sa référence dans le tas. Quand il n'existe plus aucune référence permettant d'atteindre un objet, le ramasse-miettes le détruit automatiquement — puisque qu'il est devenu inaccessible — libérant la mémoire et prévenant ainsi toute fuite de mémoire.

Le ramasse-miettes emploie un algorithme de marquage puis libération (en anglais : mark and sweep) qui permet de gérer les cas complexes d'objets se référençant mutuellement ou de boucles de références (cas d'une liste à chaînage double par exemple). En pratique il subsiste des cas d'erreur de programmation où le ramasse-miettes considèrera qu'un objet est encore utile alors que le programme n'y accèdera plus, mais dans l’ensemble, le ramasse-miettes rend plus simple et plus sûre la destruction d’objets en Java (en supprimant la nécessité de placer au bon endroit du code l'appel à l'opérateur delete).

Indépendance vis-à-vis de la plate-forme

L’indépendance vis-à-vis de la plate-forme, signifie que les programmes écrits en Java fonctionnent de manière parfaitement similaire sur différentes architectures matérielles. On peut effectuer le développement sur une architecture donnée et faire tourner l’application sur toutes les autres.

Ce résultat est obtenu par les compilateurs Java qui compilent le code source « à moitié » afin d’obtenir un bytecode (plus précisément le bytecode Java, un langage machine spécifique à la plate-forme Java). Le code est ensuite interprété sur une machine virtuelle Java (JVM en anglais), un programme écrit spécifiquement pour la machine cible qui interprète et exécute le bytecode Java. De plus, des bibliothèques standard sont fournies pour pouvoir accéder à certains éléments de la machine hôte (le graphisme, le multithreading, la programmation réseau…) exactement de la même manière sur toutes les architectures. Notons que même s’il y a explicitement une première phase précoce de compilation, le bytecode Java est interprété ou alors converti à la volée en code natif par un compilateur juste-à-temps (just in time, JIT).

Il existe également des compilateurs Java qui compilent directement le Java en code objet natif pour la machine cible, comme par exemple GCJ, supprimant la phase intermédiaire du bytecode mais le code final produit par ces compilateurs ne peut alors être exécuté que sur une seule architecture.

La licence de Sun pour Java insiste sur le fait que toutes les implémentations doivent être compatibles. Ceci a abouti à la plainte en justice contre Microsoft après que Sun ait constaté que l’implémentation de Microsoft ne supportait pas les interfaces RMI et JNI et comportait des éléments spécifiques à certaines plates-formes par rapport à la plate-forme initiale de Sun. Sun obtint des dommages et intérêt (20 millions de dollars) et l’acte de justice renforça encore les termes de la licence de Sun. En réponse, Microsoft arrêta le support de Java sur ses plates-formes et, sur les versions récentes de Windows, Internet Explorer ne supporte pas les applets Java sans ajouter de plug-in. Cependant, Sun met à disposition gratuitement des environnements d’exécution de Java pour les différentes plates-formes Microsoft.

Les premières implémentations du langage utilisaient une machine virtuelle interprétée pour obtenir la portabilité. Ces implémentations produisaient des programmes qui s’exécutaient plus lentement que ceux écrits en C ou en C++, si bien que le langage souffrit d’une réputation de faibles performances. Des implémentations plus récentes de la machine virtuelle Java (JVM) produisent des programmes beaucoup plus rapides qu’auparavant, en utilisant différentes techniques.

La première technique est de compiler directement en code natif comme un compilateur traditionnel, supprimant complètement la phase de bytecode. On obtient ainsi de bonnes performances mais aux dépens de la portabilité. Une autre technique appelée compilation juste-à-temps (just in time, JIT) traduit le byte code en code natif durant la phase de lancement du programme. Certaines machines virtuelles plus sophistiquées utilisent une recompilation dynamique durant laquelle la machine virtuelle analyse le comportement du programme et en recompile sélectivement certaines parties. La recompilation dynamique permet d’obtenir de meilleurs résultats que la compilation statique car les compilateurs dynamiques peuvent optimiser en fonction de leur connaissance de l’environnement cible et des classes qui sont utilisées. La compilation JIT et la recompilation dynamique permettent à Java de tirer profit de la rapidité du code natif sans perdre la portabilité.

La portabilité est techniquement un objectif difficile à atteindre et le succès de Java en ce domaine est mitigé. Quoiqu’il soit effectivement possible d’écrire des programmes pour la plate-forme Java qui fonctionnent correctement sur beaucoup de machines cibles, le nombre important de plates-formes avec de petites erreurs et des incohérences a abouti à un détournement du slogan de Sun « Write once, run anywhere » (« Écrire une fois, exécuter partout ») en « Write once, debug everywhere » (« Écrire une fois, déboguer partout ») !

L’indépendance de Java vis-à-vis de la plate-forme est cependant un succès avec les applications côté serveur comme les services web, les servlets et le Java Beans aussi bien que les systèmes embarqués sur OSGi, utilisant l’environnement Embedded Java.

Exécution sécurisée de code distant

La plate-forme Java fut l’un des premiers systèmes à offrir le support de l’exécution du code à partir de sources distantes. Une applet peut fonctionner dans le navigateur web d’un utilisateur, exécutant du code téléchargé d’un serveur HTTP. Le code d’une applet fonctionne dans un espace très restrictif, ce qui protège l’utilisateur des codes erronés ou mal intentionnés. Cet espace est délimité par un objet appelé gestionnaire de sécurité. Un tel objet existe aussi pour du code local, mais il est alors par défaut inactif.

Le gestionnaire de sécurité (la classe SecurityManager) permet de définir un certain nombre d’autorisations d’utilisation des ressources du système local (système de fichiers, réseau, propriétés système, …). Une autorisation définit

1. un code accesseur (typiquement, une applet - éventuellement signée - envoyée depuis un serveur web) ;
2. une ressource locale concernée (par exemple un répertoire) ;
3. un ensemble de droits (par exemple lire/écrire).

Les éditeurs d’applet peuvent demander un certificat pour leur permettre de signer numériquement une applet comme sûre, leur donnant ainsi potentiellement (moyennant l’autorisation adéquate) la permission de sortir de l’espace restrictif et d’accéder aux ressources du système local.