Origine du langage

Le langage Java est issu d’un projet de Sun Microsystems datant de 1990 : l’ingénieur Patrick Naughton n’était pas satisfait par le langage C++ utilisé chez Sun, ses interfaces de programmation en langage C, ainsi que les outils associés. Alors qu’il envisageait une migration vers NeXT, on lui proposa de travailler sur une nouvelle technologie et c’est ainsi que le Projet Stealth (furtif) vit le jour.

Le Projet Stealth fut rapidement rebaptisé Green Project avec l’arrivée de James Gosling et de Mike Sheridan. Ensemble, aidés par d’autres ingénieurs, ils commencèrent à travailler dans un bureau de la rue Sand Hill à Menlo Park en Californie. Ils essayèrent d’élaborer une technologie pour le développement d’applications d’une nouvelle génération, offrant à Sun la perspective d’opportunités uniques.

L’équipe envisageait initialement d’utiliser le langage C++, mais l’abandonna pour différentes raisons. Tout d’abord, ils développaient sur un système embarqué avec des ressources limitées et estimaient que l’utilisation du C++ demandait un investissement trop important et que cette complexité était une source d’erreur pour les développeurs. L'absence de ramasse-miettes impliquait que la gestion de la mémoire devait être programmée manuellement, un défi mais aussi une source d’erreurs.

L’équipe était également insatisfaite des lacunes du langage C++ au niveau de la sécurité, de la programmation distribuée, du multi-threading. De plus, ils voulaient une plateforme qui puisse être portée sur tout type d’appareils ou de plateformes.

Bill Joy avait envisagé un nouveau langage combinant le meilleur du langage de programmation Mesa (en) et du langage C. Dans un article appelé Plus loin (Further), il proposa à Sun que ses ingénieurs développent un environnement orienté objet basé sur le langage C++. À l’origine, Gosling envisageait de modifier et d’améliorer le langage C++, qu’il appelait C++ ++ --, mais l’idée fut bientôt abandonnée au profit du développement d’un nouveau langage de programmation qu’ils appelèrent Oak (chêne) en référence, selon la légende, à un arbre planté devant la fenêtre de leur bureau.

À l’été 1992, ils furent capables de faire une démonstration constituée d'une plateforme incluant le système d’exploitation Green, le langage Oak (1992), les bibliothèques et le matériel. Leur première réalisation, présentée le 3 septembre 1992, fut la construction d’un PDA appelé Star7 ayant une interface graphique et un agent intelligent appelé Duke pour prêter assistance à l’utilisateur.

En novembre de la même année, le Green Project fut abandonné pour devenir FirstPerson, Inc, appartenant en totalité à Sun Microsystems et l’équipe fut relocalisée à Palo Alto. L’équipe FirstPerson était intéressée par la construction d’outils hautement interactifs et quand Time Warner publia un appel d’offres en faveur d’un décodeur multifonctions, FirstPerson changea d’objectif pour proposer une telle plateforme.

Cependant, l’industrie de la télévision par câble trouva qu’elle offrait trop de possibilités à l’utilisateur et FirstPerson perdit le marché au profit de Silicon Graphics. Incapable d’intéresser l’industrie audiovisuelle, la société fut réintégrée au sein de Sun.

Java rencontre Internet

Duke, la mascotte de Java

De juin à juillet 1994, après trois jours de remue-méninges avec John Gage, James Gosling, Joy, Naughton, Wayne Rosing et Eric Schmidt, l’équipe recentra la plateforme sur le web. Ils pensaient qu’avec l’avènement du navigateur Mosaic, Internet était le lieu où allait se développer le même genre d’outil interactif que celui qu’ils avaient envisagé pour l’industrie du câble. Naughton développa comme prototype un petit navigateur web, WebRunner qui deviendra par la suite HotJava.

La même année le langage fut renommé Java après qu’on eut découvert que le nom Oak était déjà utilisé par un fabricant de carte vidéo.

Avènement de Java 2

L'apparition de la version 1.2 du langage marque un tournant significatif : c'est en 2000 qu'apparait simultanément la déclinaison en deux plateformes Java :

• Java 2 Standard Edition (J2SE), plateforme avec les API et bibliothèques de bases, devenue depuis Java SE ;
• Java 2 Enterprise Edition (J2EE), extension avec des technologies pour le développement d'applications d’entreprise, devenue Java EE.

Sun les qualifie alors de plateforme Java 2 par opposition aux premières générations 1.0 et 1.1. Toutes les versions ultérieures, de J2EE 1.2 à Java SE ou Java EE 7 restent désignées sous le qualificatif de plateformes Java 2, bien que le '2' ait été depuis officiellement abandonné.

Histoire récente

Utilisation avec les mobiles

Android utilise beaucoup les technologies Java

Oracle annonce début octobre 2012 à la conférence JavaOne sa volonté de proposer des solutions Java pour le domaine des logiciels embarqués, pour processeurs moins puissants que ceux habituellement disponibles sur les PC. Oracle fédère autour d'elle tout un écosystème d'entreprises spécialistes de ces segments de marchés, comme l'éditeur MicroEJ^[9] ou encore STMicroelectronics qui propose du Java sur ses STM32^[10] dont le cœur est un CortexM3/M4.

Java, notamment via Eclipse et NetBeans, offre déjà des environnements de développement intégrés pour mobile. Java est le principal langage utilisé pour développer des applications pour le système d'exploitation libre pour Mobile de Google : Android.

JavaFX peut aussi permettre l'utilisation de Java sur mobiles, bien que ce ne soit pas son objectif principal.

Historique des versions

Le langage Java a connu plusieurs évolutions depuis le JDK 1.0 (Java Development Kit) avec l’ajout de nombreuses classes et packages à la bibliothèque standard. Depuis le J2SE1.4, l’évolution de Java est dirigée par le JCP (Java Community Process) qui utilise les JSR (Java Specifications Requests) pour proposer des ajouts et des changements sur la plateforme Java. Le langage lui-même est spécifié par le JLS (Java Language Specification), les modifications du JLS étant gérées sous le code JSR 901^[20].

Il faut noter que les évolutions successives du langage ne portent guère sur sa syntaxe -relativement stable depuis le début- mais principalement sur l'enrichissement de ses fonctions, avec l'embarquement et l'optimisation de bibliothèques logicielles (API) dans des domaines très variés de l'informatique : bases de données, gestion XML, informatique distribuée et web, multimédia, sécurité…

        void displayWidgets (Iterable<Widget> widgets) {
            for (Widget w : widgets) {
                w.display();
            }
        }

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 que 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 similaire (mais différent) aux templates du langage C++ ou aux foncteurs d’OCaml. Les génériques permettent d’exprimer d’une façon plus simple et plus sûre (du point de vue du typage) 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

Cet élément contribue à la robustesse et à la performance des programmes, le ramasse-miettes (Garbage Collector) 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 du programme^[78]. 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 (par exemple 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 causera une erreur fatale.

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 géré dans un tas de mémoire (en anglais : memory heap) réservé à cet usage. Le programme accède à chaque objet via une 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 — puisqu'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^[78]) 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ère qu'un objet est encore utile alors que le programme n'y accède plus fonctionnellement (mais garde une référence sur l'objet), ce qui constitue un cas particulier de « fuite mémoire ».

Le ramasse-miettes rend sensiblement plus simple et plus sûre la gestion de la mémoire. Les concepteurs et les utilisateurs de programmes ou bibliothèques (en anglais Libraries) n'ont pas à se soucier de la désallocation des objets (opérateur delete en C++), sauf éventuellement pour des raisons de performance.

Indépendance vis-à-vis de la plateforme

L’indépendance vis-à-vis de la plateforme signifie que les programmes écrits en Java fonctionnent de manière parfaitement similaire sur différentes architectures matérielles. La licence de Sun pour Java insiste ainsi sur le fait que toutes les implémentations doivent être compatibles. On peut ainsi théoriquement effectuer le développement sur une architecture donnée et faire tourner l’application finale sur toutes les autres.

Ce résultat est obtenu par :

• des bibliothèques standard 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 ;
• des compilateurs Java qui compilent le code source « à moitié » afin d’obtenir un bytecode (plus précisément le bytecode Java, un langage de type assembleur, proche de la machine virtuelle et spécifique à la plateforme Java).

Ce bytecode a ensuite vocation à être interprété sur une machine virtuelle Java (JVM en anglais), un programme écrit spécifiquement pour la machine cible qui interprète le bytecode Java et fait exécuter par la machine les instructions traduites en code natif.

Noter que même s’il y a explicitement une première phase de compilation, le bytecode Java est soit interprété, soit converti à la volée en code natif par un compilateur à la volée (just in time, JIT).

Exécution sécurisée de code distant

La plateforme 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.

Mots réservés, primitifs et littéraux

abstract else instanceof static try boolean false
assert (1.4) enum (5.0) interface strictfp (1.2) volatile byte true
break extends native super while char
case final new switch double
catch finally package synchronized float
class for private this int
const (*) goto (*) protected throw long
continue if public throws short
default implements return transient void null
do import

Notes :

• (*) ces mots clefs sont réservés mais n'ont pas de signification pour le compilateur (il est juste interdit d'employer ce nom pour une variable par exemple) ;
• (1.2), (1.4) et (5.0) ces mots clefs ont été ajoutés avec la version indiquée du langage.

(source)

Classe, attribut, méthode

Types

Le tableau ci-dessus recense les types de base, cependant il existe en Java d'autres types qui sont des objets et sont à utiliser en tant que tel. Par exemple pour définir un entier on peut utiliser le type 'Integer' dont la valeur d'initialisation par défaut vaudra null

Pour instancier une variable, la syntaxe (ici la même qu'en C) est la suivante :

NomDuType maVariable;

maVariable est alors allouée sur la pile.

Les collections d'objets

Il est souvent nécessaire de stocker de nombreuses données dans des collections : liste d’achats, notes des élèves, etc. Les collections peuvent être consultées, modifiées, on peut les trier, les recopier, les supprimer, etc. Elles peuvent avoir une taille fixe ou variable.

Les collections à taille fixe sont moins lourdes que les collections à taille variable.

int[] tab = new int[10];

int tab[] = new int[10];

int tab[] = {0, 0, 0, 0, 0,
    0, 0, 0, 0, 0};

Structures de contrôle

 while (<expression booléenne>) {
 	instruction(s)
 }

 do {
    instruction(s)
 }
 while (<expression booléenne>);

 for (<initialisation> ; <condition de poursuite> ; <expression d’incrémentation>) {
    instruction(s)
 }

 for (type variable : <expression>) {
    instruction(s)
 }

 for (<Objet récupérant l’occurrence suivante de la collection> : <collection d’objets>) {
    instruction(s)
 }

 if (<expression booléenne>) {
    instruction(s)
 }

if (<condition 1> && <condition  2>) {
    instruction(s) si les conditions 1 et 2 sont vraies
}

if (<condition 1> || <condition 2>) {
    instruction(s) si au moins une des deux est vraie
}

 if (<expression booléenne>) {
     instruction(s)
 }
 else {
     instruction(s)
 }

 if (<expression booléenne>) {
     instruction(s)
 }
 else if (<expression booléenne>) {
     instruction(s)
 }
 else if (<expression booléenne>) {
     instruction(s)
 }
 else {
     instruction(s)
 }

 switch (<expression>) {
    case <constante>:
         instruction(s)
         break;
    case <constante>:
        instruction(s)
        break;
    [...]
    default:
         instruction(s)
         break;
 }

 <expression booléenne> ? <valeur si vrai> : <valeur si faux>

 try {
       instruction(s)
 }
 catch (<type exception> <variable>) {
       instruction(s)
 } 
 [...]
 finally {
       instruction(s)
 }

  
 FileOutputStream fos = null; 
 
 try {
      //Chacune de ces deux instructions peut générer une exception
      // création d'un flux pour écrire dans un fichier
      fos = new FileOutputStream(...);
      // écriture de données dans ce flux
      fos.write(...);
 }
 catch (IOException e) {
      //Gestion de l'erreur de création ou d'écriture dans le flux
      e.printStackTrace();
 }
 finally {
     //Cette section de code est toujours exécutée, qu’il y ait une exception ou pas
     // fermeture du flux s'il a été ouvert
     if(fos != null) fos.close();
 }

 public class ArrayList<E> {
    ArrayList<String> al = new ArrayList<String>();
 }

 public class HelloWorld {
    private String text = "hello world";
 }

Opérateur de comparaison

Failles de sécurité

La plate-forme de développement Java propose un gestionnaire de sécurité^[80] (cf. supra § Exécution sécurisée de code distant) qui permet à un utilisateur de tester un exécutable douteux dans un « bac à sable » pour éviter de contaminer ses périphériques de stockage. Ce mode d'exécution restreint l'accès par l'exécutable à des options et interfaces exploitées par les logiciels malveillants : les manipulations sur les bases de fichiers locaux, plusieurs commandes systèmes ou de bas niveau, ou l'accès au réseau informatique.

Peu après 2010, des chercheurs ont mis au jour plusieurs failles de sécurité dans les versions de Java les plus courantes : celle d'Oracle, par exemple, laisse filtrer du code non-autorisé malgré le mécanisme d’isolation, et expose ses utilisateurs à des piratages. Ces failles n'affectent que les applications Java exécutant aléatoirement des programmes non explicitement approuvés par l'utilisateur : greffons de navigateur web exploitant des applets Java téléchargés depuis des sites ouverts.

Le 31 août 2012, une grave faille de sécurité a été détectée dans Java 6 et 7 pour Microsoft Windows, OS X et Linux, qui permettait de prendre le contrôle à distance en chargeant une page web factice^[81],[82]. La même faille a été retrouvée dans Java 5 par la suite^[83]. Ainsi, le 10 janvier 2013, trois spécialistes de l'informatique prirent position contre Java, affirmant à l'Agence Reuters que ce langage n'était pas sûr et que les internautes feraient bien de le désactiver par défaut. Jaime Blasco, directeurs du laboratoire d'AlienVault Labs, a déclaré : « Java est un vrai fouillis. Ce n'est pas sûr. Il faut le désactiver^[84]. »

En 2014, compte tenu de ces problèmes de sécurité et de vulnérabilité avec Java, l'influenceur Brian Krebs appelait les internautes à retirer le greffon Java de leur navigateur^[85]. « C'était prometteur au début, mais son utilité pour la navigation sur le web a fait long feu, et c'est à présent un cauchemar qui fait les délices des cyber-criminels aux dépens des internautes^[86]. »

Java reste réputé depuis comme peu sécurisé ; et comme il n'est indispensable que pour un petit nombre d'applications en ligne, plusieurs experts en sécurité informatique recommandent de limiter au maximum le recours à ses bibliothèques dans les navigateurs web^[87],[88].

La « classite »

Dans son essai sur la conception des logiciels^[89], J. Ousterhout, l'auteur de Tcl/Tk, diagnostique chez les concepteurs de Java une forme d'idée fixe qu'il appelle « classite » (classitis), à savoir que « comme les classes objet sont favorables à la structuration du code, plus on crée de classes, mieux c'est. » Selon cet auteur, la multiplication du nombre de classes objet, si elle favorise l'écriture de routines individuellement courtes et faciles à analyser, augmente corrélativement la complexité de l'ensemble d'un programme et le rend difficile à comprendre, à corriger et à étendre.

La généricité du langage Java

Lorsque Java 5.0 a été doté de la programmation générique, son répertoire de classes objet (dont plusieurs étaient même déjà désuètes!) était très fourni. Il a été décidé d'utiliser la généricité des procédures en mode « ignorer » (Type erasure) pour favoriser une compatibilité ascendante et réutiliser le code des classes existantes ; mais cette décision a limité les avantages de la programmation générique par rapport à d'autres langages^[90],[91], et l'accumulation de métacaractères dans le typage a rendu Java incohérent^[92].

Types de données manquants

Java n'a pas, en propre, de type d'entier non signé : dans ce langage, ils sont donc souvent produits par des sous-programmes écrits en langage C. Cette lacune s'oppose, du reste, à un passage de paramètre fluide entre les deux langages, C et Java. Enfin, on sait que les grands entiers positifs sont très utilisés, notamment pour la cryptographie, ce qui rend Java moins attractif pour ce genre de traitement^[93]. Bien qu'on puisse en partie contourner ce problème par conversion de code et recours à des types de données plus grands (par exemple en utilisant un entier 64 bits pour coder un entier 32 bits non signé), Java est malcommode pour la manipulation des grands entiers^[94].

Écarts aux normes de codage en virgule flottante

S'il est vrai que l'arithmétique en virgule flottante de Java respecte pour l'essentiel les directives de la norme IEEE 754 (Standard for Binary Floating-Point Arithmetic), elle s'en écarte sur quelques points (par exemple l'indicateur binaire de débordement de type ou la gestion des arrondis), même lorsque l'on active le modificateur strictfp. En outre, les types de flottants de précision étendue reconnus par la norme 754 et déjà disponibles sur de nombreux processeurs, n'existent pas en Java^[95],[96].

Faible performance

Dans les débuts de Java (c'est-à-dire avant le lancement de la machine virtuelle HotSpot dans Java 1.3 en 2000), la lenteur de Java était bien connue. La plate-forme comparative Benchmarks avait notamment relevé que Java était deux fois plus lent que le langage C^{[97],[98],[99]}.

Mais il est vrai que la vitesse d'exécution de Java s'est considérablement améliorée depuis^[100]. La compilation à la volée, moyennant une certaine discipline dans l'écriture du code source, est aujourd'hui à peine inférieure à celle des compilateurs natifs^[100],[101].

JavaStyle

Les JavaStyle sont des conventions de programmation en langage Java définies par Sun. Le respect de conventions strictes assure une homogénéité dans le code source d’une application développée par toute une équipe et favorise la diffusion du code source auprès d’une communauté partageant les mêmes conventions de codage.

Le lower camel case est utilisé pour les noms de méthodes et de variables.

Frameworks et API

Sun fournit un grand nombre de frameworks et d’API afin de permettre l’utilisation de Java pour des usages très diversifiés.

On distingue essentiellement quatre grands frameworks :

• Java SE (anciennement J2SE) : Ce framework est destiné aux applications pour poste de travail ;
• Java EE (anciennement J2EE) : Ce framework est spécialisé dans les applications serveurs. Il contient pour ce faire un grand nombre d’API et d’extensions ;
• Java ME (anciennement J2ME) : Ce framework est spécialisé dans les applications mobiles ;
• JavaFX (à ne pas confondre avec JavaFX) : Ce framework est spécialisé dans les applications liées aux cartes à puces et autres SmartCards. Il recouvre notamment l'ancien Java Card.

La persistance est fondée sur les standards :

• JDBC (Java DataBase Connectivity) ;
• JDO (Java Data Objects) ;
• EJB (Enterprise Java Beans).

On trouve toutefois de nombreuses autres technologies, API et extensions optionnelles pour Java :

• Java Media Framework (en) : framework multimédia, contenant notamment les API Java2D, Java 3D, JavaSound, Java advanced Imaging ;
• Java Telephony API (en) ;
• Java TV (en) ;
• JXTA : Système de peer-to-peer reposant sur Java ;
• Jini ;
• JAIN ;
• Java Dynamic Management Kit (es) (JMDK) ;
• JavaSpeech ;
• JMI ;
• JavaSpaces.

Outils de développement

La programmation peut se faire depuis une invite de commande en lançant un compilateur Java (souvent nommé javac), mais pour avoir plus de confort, il est préférable d’utiliser un environnement de développement intégré ou IDE (qui permet de compiler automatiquement), certains sont gratuits. Par exemple :

Java(target = 'classes', source = 'src')
      Jar(target = 'test.jar', source = 'classes')

     % scons -Q
     javac -d classes -sourcepath src src/Exemple1.java src/Exemple2.java src/Exemple3.java
     jar cf test.jar classes

Bibliographie

• Ken Arnold, James Gosling et David Holmes, Le Langage Java, 2001 (ISBN 978-2-7117-8671-8)
• (en) Bruce Eckel, Thinking in Java, Prentice-Hall, 2002 (ISBN 978-0-13-100287-6). version téléchargeable version électronique en ligne traduction francophone : penser en java
• Alexandre Brillant, Java 5, 2006 (ISBN 978-2-7460-3170-8)
• Jean Brondeau, Introduction à la programmation objet en Java, Dunod, Paris, 1999 (ISBN 978-2-10-004106-0)
• Annick Fron, Architectures réparties en Java, 2007 (ISBN 978-2-10-051141-9)
• Le tutoriel en ligne How To Program In JAVA [lire en ligne]

Articles connexes

Liens externes

• Site officiel
• (en) http://docs.oracle.com/javase/1.5.0/docs : Schéma de l'architecture logicielle de Java