Présentation de Java SE 6

La JSR 223 définit un framework permettant d'utiliser n'importe quel langage de script au sein d'une application Java.
Elle permet ainsi de connaitre la liste des interpréteurs disponibles sur la machine virtuelle, d'invoquer des scripts depuis une application Java (et vice-versa), de rendre les objets Java visibles et utilisables par ces scripts.

Par exemple, le code suivant permet grâce à l'interpréteur JavaScript, d'exécuter un script et de récupérer le résultat :

        int intValue = 5;
       
        ScriptEngineManager manager = new ScriptEngineManager();
        // On récupère l'interpréteur de script JavaScript²   
        ScriptEngine engine = manager.getEngineByName("JavaScript");
        // On crée une association pour la variable Java 'intValue'
        engine.getBindings(ScriptContext.ENGINE_SCOPE).put("intValue", intValue);
        // Évaluation d'un script :
        Object result = engine.eval(" ( 15 + intValue ) / 2 ");
        // Affichage du résultat :
        System.out.println("Résultat : " + result);

Ce qui nous donnera comme résultat :

       Résultat : 10.0

Toutefois, il faut savoir que les spécifications n'imposent pas le support d'un langage de script en particulier. Ainsi chaque machine virtuelle peut proposer le support du/des langage(s) de son choix, et il faudra utiliser l'API pour vérifier la présence de l'interpréteur de script. Malgré cela, la JVM de Sun proposera d'office le support de JavaScript via l'interpréteur rhino de la fondation Mozilla, il y a donc de fortes chances que ce dernier se retrouve sur la plupart des JVM.

À noter également l'existence du projet « scripting » qui se chargera d'implémenter et de référencer les interpréteurs de script compatibles avec cette JSR. Elle comporte déjà plus de 20 langages de script dont Python, Ruby, BeanShell ou encore Groovy : https://scripting.dev.java.net/

Cette JSR, représentée par le package javax.script, permet donc théoriquement l'utilisation de n'importe quel langage de script au sein de vos applications Java, et offre ainsi un large panel de nouvelles perspectives.

Pour plus de détails sur cette JSR, vous pouvez télécharger les spécifications sur la page de la JSR : http://jcp.org/en/jsr/detail?id=223

Cette API définit un service permettant aux programmes Java d'invoquer un compilateur Java directement dans une application Java, et de récupérer toutes les informations retournées par le compilateur (erreurs, warnings, messages, etc.).

Cette JSR ne devrait pas vraiment concerner directement le développeur « de base », mais cible principalement les éditeurs d'outils Java :

• les implémentations de moteur JSP pourront l'utiliser afin de compiler ces dernières sans invoquer de programme externe. Les premiers tests avec GlassFish (l'implémentation de référence de Java EE 5) ont donné des temps de compilation trois fois plus rapides (toute la compilation s'effectue en mémoire sans opération d'entrée/sortie) ;
• les IDE pourront utiliser le compilateur directement, en utilisant une API standardisée (ce qui n'était pas le cas jusqu'à maintenant) ;
• d'autres outils ou API auront la possibilité de générer des fichiers *.class via la génération et la compilation de code source à la volée.

Son API utilise le package javax.tools et vous trouverez ses spécifications sur la page de la JSR : http://jcp.org/en/jsr/detail?id=199

Cette API permet de traiter les annotations lors de la compilation des codes source, en interaction avec le compilateur. Il ne s'agit pas d'une nouveauté en soi, puisqu'un tel mécanisme était présent dans Java 5.0 avec APT (Annotation Processing Tool). Toutefois, son API et les possibilités offertes ont été étendues et standardisées.

Cette API autorisera l'écriture de « bibliothèques intelligentes » qui communiqueront avec le compilateur afin de signaler des erreurs d'utilisation ou encore de générer dynamiquement des classes et/ou des fichiers de configuration.

Elle utilise les packages javax.annotation.processing (pour le traitement des annotations à l'exécution) et javax.lang.model.* (qui représente le code lors de sa compilation).

Pour plus de détail : http://jcp.org/en/jsr/detail?id=269

Cette JSR vient définir cinq nouvelles annotations standard qui pourront également être utilisées par la plateforme entreprise (Java EE).

• @Generated servira à marquer les codes (ou les portions de codes) qui ont été générés par un outil, afin de les différencier de ceux qui ont été écrits par un développeur.
• @PostConstruct et @PreDestroy sont liées à la persistance des données, et permettent respectivement de définir une méthode qui sera appelée soit après la construction de l'objet (et éventuellement après l'injection de données), soit juste avant sa destruction.
• @Resource permet d'associer des ressources à des composants (classes, attributs ou méthodes), qui seront automatiquement injectés par les outils de déploiements. L'annotation @Resources quant à elle permettra simplement d'associer plusieurs ressources à un même composant.

Encore une fois, cette JSR n'est pas directement destinée aux développeurs, mais aux outils divers, qui devront les utiliser pour simplifier la vie du développeur.

Le détail des spécifications est librement téléchargeable : http://jcp.org/en/jsr/detail?id=250

Le format des fichiers *.class a été mis à jour afin de supporter la « split verification », une architecture déjà présente dans la plateforme mobile de Java (Java ME), et qui apporte des avantages inhérents aux performances, aussi bien en termes d'espace utilisé (90 %) que du temps de chargement de ces dernières (approximativement deux fois plus rapide). Ce schéma est également plus simple et plus robuste, et facilitera les évolutions futures de la plateforme.

Bien entendu, tout cela est transparent pour le développeur, et la compatibilité ascendante reste d'actualité.

Toutes les informations sur ce nouveau format sont librement téléchargeables : http://jcp.org/en/jsr/detail?id=202

Les spécifications de l'API JDBC 4.0 viennent apporter un vent de fraicheur sur l'API d'accès aux bases de données de Java, en utilisant les facilités du langage apportées par Java 5.0 (Generics et Annotations en tête). Elle met l'accent sur les éléments suivants :

• chargement automatique des drivers JDBC en utilisant le mécanisme de fournisseur de services ;
• utilisation d'annotations permettant de manipuler les tables facilement via un mapping object/relationnel très simple. Il est désormais possible d'exécuter des requêtes XML en écrivant un minimum de code Java ;
• support du type SQL ROWID, qui donne la possibilité de stocker l'index d'une ligne d'une table de la base de données ;
• amélioration du support des BLOB (Binary Large Object) et CLOB (Character Large Object) ;
• support du type SQL XML défini dans le standard SQL 2003 ;
• le gestionnaire de connexion a été amélioré et permet de détecter les connexions devenues invalides ;
• la hiérarchie des exceptions a été revue, et la classe SQLException possède désormais deux classes filles de base dont hériteront toutes les exceptions liées à JDBC. Ainsi SQLTransientException représentera les exceptions « passagères » (comme les problèmes de connexion, les timeouts). À l'inverse, les exceptions qui hériteront de SQLNonTransientException indiqueront un problème plus grave lié à une erreur irrémédiable qui devra être corrigée (argument invalide, erreur de syntaxe, etc.). De plus, toutes les SQLException sont désormais itérables et peuvent donc être utilisées dans une boucle for afin de dépiler la chaîne d'exception :

    catch (SQLException e) {
        for (Throwable cause : e) {
            cause.printStackTrace();
        }
    }

Les spécifications de JDBC 4.0 sont bien sûr également disponibles : http://jcp.org/en/jsr/detail?id=221

Comme prévu, Java SE 6 sera fortement axé vers XML et les Web Services, avec ni plus ni moins que cinq JSR sur le sujet, brièvement présentées ici :

• JSR 105 : XML Digital-Signature API
  Cette API, représentée par le package javax.xml.crypto, est une implémentation de la norme XML Digital-Signature du W3C (http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/) et est une clef importante de la sécurité des Web Services. De plus elle est requise par d'autres JSR de cette section.
  
  Plus d'info : http://jcp.org/en/jsr/detail?id=105
  
  
  
• JSR 173 : Streaming API for XML (StAX)
  StAX est une API permettant d'exploiter les documents XML tout comme DOM ou SAX dont elle reprend les principaux avantages. StAX lit le document de manière linéaire afin de ne pas encombrer la mémoire (comme SAX), par contre la lecture du document n'est pas évènementielle, mais c'est l'application qui détermine les éléments à lire (à l'instar de DOM). Bref StAX prend le meilleur des deux…
  
  Plus d'info : http://jcp.org/en/jsr/detail?id=173
  
  
  
• JSR 181 : Web-Services Metadata for the Java Platform
  Cette JSR définit un ensemble d'annotations permettant de décrire facilement des Web-Services au niveau du code source. Ces annotations détermineront comment les serveurs d'applications déploieront ces Web-Services.
  
  Plus d'info : http://jcp.org/en/jsr/detail?id=181
  
  
  
• JSR 222 : Java Architecture for XML Binding (JAXB) 2.0
  Il s'agit d'une révision majeure des spécifications de JAXB 1.1, l'API permettant de générer des classes Java à partir de schéma XML et inversement. Cette version met l'accent (entre autres) sur le support de la norme des XML Schema.
  
  Plus d'info : http://jcp.org/en/jsr/detail?id=221
  
  
  
• JSR 224 : Java API for XML-Based Web Services (JAX-WS) 2.0
  Cette spécification étend JAX-RPC 1.0 afin de simplifier le développement, de mieux s'intégrer avec JAXB 2.0 et d'apporter le support des derniers standards (SOAP 1.2, WSDL 2.0 et WS-I Basic Profile 1.1).
  
  Plus d'info : http://jcp.org/en/jsr/detail?id=224
  
  

La mauvaise intégration des applications Java dans le système d'exploitation est un des points noirs des applications Java. Cette nouvelle version comble un peu ce déficit, notamment en ce qui concerne l'intégration au système.

La classe java.awt.SystemTray permet d'ajouter une icône dans la zone de notification du système (la plupart du temps il s'agit des icônes à côté de l'horloge) afin d'interagir avec l'utilisateur (clic, menu déroulant, affichage d'infobulle évoluée).

La classe java.awt.Desktop permet d'intégrer l'application au bureau du système d'exploitation, et permet trois principales actions :

• ouvrir le navigateur par défaut sur une page précise (spécifiée par une URI) ;
• ouvrir la fenêtre de saisie d'email du client de courrier électronique par défaut (éventuellement en y renseignant les différents champs via une URI de type mailto:) ;
• utiliser l'association de fichier du système d'exploitation afin de lancer le programme associé pour effectuer des actions de base (ouvrir, éditer et imprimer).

Les boites de dialogues bénéficient d'un nouveau système de modalité plus élaboré. Ainsi on distingue désormais quatre types de modalités représentés par l'énumération ModalityType :

• MODELESS : la boite de dialogue n'est pas modale, elle ne bloquera donc aucune autre fenêtre ;
• APPLICATION_MODAL : la boite de dialogue bloquera toutes les autres fenêtres et boites de dialogue de l'application (sauf ses éventuelles fenêtres filles). Il s'agit du comportement actuel des boites de dialogues modales ;
• DOCUMENT_MODAL : la boite de dialogue bloquera toutes les fenêtres de la même hiérarchie, c'est-à-dire toutes ses fenêtres parentes, mais ne bloquera pas les autres fenêtres de l'application ;
• TOOLKIT_MODAL : la boite de dialogue bloquera toutes les fenêtres du même toolkit (sauf ses éventuelles fenêtres filles). Par exemple toutes les applets d'un navigateur sont exécutées dans le même toolkit.

Il est également possible de définir, indépendamment pour chaque fenêtre, des exceptions à ces règles (représentées par l'énumération ModalExclusionType) :

• NO_EXCLUDE : la fenêtre ne bénéficiera d'aucune exclusion et sera bloquée selon les règles en vigueur ;
• APPLICATION_EXCLUDE : la fenêtre ne sera pas bloquée par les boites de dialogue de type APPLICATION_MODAL ;
• TOOLKIT_EXCLUDE : la fenêtre ne sera pas bloquée par les boites de dialogues de type TOOLKIT_MODAL.

À première vue ces fonctions n'ont rien de révolutionnaire et pourraient même surprendre les développeurs non java puisqu'il s'agit d'éléments qui peuvent sembler basiques. Il s'agit pourtant de notions qui ne sont pas forcément présentes sur tous les systèmes d'exploitation, et qui n'étaient donc pas intégrées dans l'API standard afin de ne pas casser la sacro-sainte loi « Write once, run anywhere » (« Écrire une fois, exécuter partout »).

Afin de ne pas trop mettre à mal cette règle, et étant donné que ces fonctionnalités peuvent carrément être absentes du système d'exploitation, il est à la charge du développeur de vérifier dynamiquement le support de ces éléments via des méthodes adéquates, ainsi :

• avant d'ajouter une icône dans la zone de notification, il faut vérifier que cela est bien supporté par le système avec la méthode SystemTray.isSuported() ;
• avant d'utiliser la classe Desktop, il faut vérifier si elle est supportée avec la méthode Desktop.isDesktopSupported(), puis pour chacune des actions possibles avec la méthode Desktop.isSupported(Action) ;
• avant d'utiliser un type de modalité ou d'exclusion, il faut vérifier que celui-ci est supporté par le système avec les méthodes Toolkit.isModalityTypeSupported(ModalityType) et Toolkit.isModalExclusionTypeSupported(ModalExclusionType).

Si la fonctionnalité est utilisée alors qu'elle n'est pas supportée, le comportement varie selon les cas. Ainsi pour les classes Desktop et SystemTray, une exception sera remontée, alors que lors de l'utilisation des types de modalité ou d'exclusions une valeur par défaut sera utilisée à la place (respectivement MODELESS et NO_EXCLUDE). Ainsi, il est à la charge du programmeur de proposer une méthode alternative si besoin.

Il est intéressant de noter que le même principe a été appliqué pour la méthode setAlwaysOnTop() introduite dans Java 5.0 avec l'apparition des méthodes Window.isAlwaysOnTopSupported() et Toolkit.isAlwaysOnTopSupported().

Note : toutes ces fonctionnalités concernent le package java.awt, mais elles s'appliquent également aux applications Swing (n'oublions pas que Swing « hérite » d'AWT).

Swing a également subi pas mal d'améliorations, dont voici les principales.

• Tout d'abord les LookAndFeels natif Windows et GTK ont subi de nettes améliorations. Ils ne se contentent plus de recopier l'apparence du système, mais utilisent leurs API système respectives afin de récupérer les divers éléments de l'interface. Ils s'intègrent donc parfaitement dans l'environnement de l'utilisateur, quel que soit son thème. Bien sûr cela fonctionne parfaitement sous Windows Vista.
• La classe java.awt.SplashScreen permet de gérer un « splash screen » natif au démarrage de l'application en spécifiant une image (via le manifest du jar ou une option de la ligne de commande). Ce dernier sera automatiquement détruit lorsque la première fenêtre de l'application sera ouverte.
• L'API destinée aux LayoutManager et aux outils d'interface graphique permet désormais de connaitre la ligne de base et les espacements préférés des composants, afin de mieux les disposer. De plus la famille des LayoutManager standard est agrandie par l'arrivée de javax.swing.GroupLayout, le manager utilisé par Matisse, le GUI-Builder de NetBeans, qui permet de grandement simplifier la création d'interfaces graphiques Swing.
• Tous les composants textes de Swing (héritant de JTextComponent) bénéficient désormais d'un support évolué de l'impression qui leur manquait cruellement.
• Il est dorénavant possible d'utiliser n'importe quel composant Swing en guise d'onglets sur les JTabbedPanes grâce à la méthode setTabComponentAt().
• Les données des JTables pourront être triées ou filtrées simplement via javax.swing.RowSorter et javax.swing.RowFilter.
• Le drag and drop (glisser-déposer) a été grandement amélioré et simplifié afin de permettre d'utiliser plusieurs modes de fonctionnement via l'énumération javax.swing.DropMode.
• La classe SwingWorker permettant une gestion facile des traitements sans bloquer l'interface graphique est enfin intégrée en standard (cette classe faisait partie des tout premiers tutoriels officiels sur Swing).
• À ce propos, l'affichage via le double-buffer de Swing comblera désormais en partie le bug du rectangle gris (« gray rect ») lorsque vous bloquez le thread d'affichage (EDT) : la fenêtre sera quand même complètement dessinée et n'affichera plus l'affreux rectangle gris (mais bien sûr votre interface sera quand même figée).
• La qualité de l'affichage des textes a été améliorée, notamment en utilisant la configuration système en ce qui concerne l'antialiasing.
• Le pipeline de rendu OpenGL (intégré avec Java 5.0) a été revu afin d'utiliser un mode STR (Single-Threaded Rendering).

Du côté de l'API de Collection, on note l'arrivée de cinq nouvelles interfaces :

• Deque : une queue à double sens, qui étend l'interface Queue de Java 5.0 afin de supporter les insertions/suppressions à ses deux extrémités ;
• BlockingDeque : une Deque avec des opérations bloquantes lors de l'ajout et suppression d'élément ;
• NavigableSet, qui étend SortedSet afin de permettre une navigation en ordre croissant ou décroissant et des méthodes de recherches évoluées ;
• NavigableMap, qui étend SortedMap afin de permettre une navigation en ordre croissant ou décroissant et des méthodes de recherches évoluées ;
• Enfin, ConcurrentNavigableMap permet les mêmes possibilités tout en étant naturellement sécurisée en environnement multithread.

Cela s'accompagne également de nouvelles implémentations concrètes :

• ArrayDeque : une implémentation de Deque basée sur l'utilisation de tableau redimensionnable ;
• ConcurrentSkipListSet et ConcurrentSkipListMap, implémentent respectivement NavigableSet et ConcurrentNavigableMap ;
• LinkedBlockingDeque : une implémentation de BlockingDeque basée sur une liste chainée.

Sans oublier l'existence de deux implémentations de Map.Entry qui devrait faciliter l'écriture d'implémentation de Map personnalisée :

• AbstractMap.SimpleEntry est une implémentation de base ;
• AbstractMap.SimpleImmutableEntry est une implémentation immuable (dont on ne peut pas modifier le contenu après la création).

À noter également la présence des méthodes Arrays.copyOf() et Arrays.copyOfRange() permettant de redimensionner/tronquer/copier des tableaux de tous types plus simplement qu'avec la méthode System.arraycopy() quelque peu complexe…

• La classe java.io.Console, dont l'unique instance est accessible via la méthode System.console(), nous permet une gestion un peu plus fine de la console, comme la lecture de mots de passe sécurisés et l'accès aux objets Reader/Writer associés. On regrettera toutefois l'impossibilité de manipuler le curseur et/ou d'effacer certaines portions de texte.
• La classe File permet désormais d'obtenir plus d'informations concernant l'utilisation du système de stockage, avec les méthodes suivantes :
  
  getTotalSpace() indique la taille totale de la partition (en bytes) ;
  getFreeSpace() indique la taille disponible sur la partition (en bytes) ;
  getUsableSpace() indique la taille utilisable sur la partition (en bytes). Ceci inclut la vérification des droits d'accès et d'éventuelles restrictions systèmes.
• De plus, il est désormais possible de modifier les attributs des fichiers (pour l'utilisateur courant ou pour tout le monde) via les méthodes setWritable(), setReadable() et setExecutable() de la classe File. En toute logique, la réussite de ces méthodes dépend du système d'exploitation.
• java.net.IDN apporte le support des noms de domaine internationalisé (IDN) au format Unicode et de leurs équivalents ASCII.
• L'interface java.net.NetworkAddress a été étendue afin de fournir plus d'informations sur le réseau (adresse de broadcast, masque réseau, adresse MAC, taille du MTU, état activé ou désactivé, etc.), notamment via l'interface java.net.InterfaceAddress.
• Java 5.0 avait introduit la classe abstraite java.net.CookieHandler permettant de gérer les Cookies lors des connexions HTTP, mais ne proposait aucune implémentation par défaut. C'est désormais chose faite avec java.net.CookieManager qui propose une implémentation qui devrait suffire à la plupart des applications.

• Pluggable locale : la gestion de locale du JRE permet désormais l'installation de Locale non supportée via un système de plugin.
• Les ResourceBundles ont bénéficié de quelques améliorations en proposant un dispositif permettant de contrôler la gestion et le comportement du cache, ou encore le support de n'importe quel type de formats en entrée (comme XML par exemple).
• La classe java.text.Normalizer permet la transformation de chaines de caractères Unicode dans une forme composée ou décomposée, selon les standards de l'Unicode. En utilisant la même forme d'encodage, on peut manipuler les chaines avec des caractères spéciaux ou des alphabets exotiques plus simplement. À titre d'exemple, le caractère À peut être représenté par la forme composée \u00C1 (A majuscule avec accent grave) ou par la forme décomposée \u0041\u0301 (A majuscule combiné avec un accent grave). En utilisant la même forme pour toutes les chaînes, on facilite la comparaison de ce type de formation.
• Ajout du support du calendrier impérial chinois et de nombreuses nouvelles locales (zh_SG, en_MT, en_PH, en_SG, el_CY, id_ID, ga_IE, ms_MY, mt_MT, pt_BR, pt_PT, et es_US).

• Les outils d'analyse auront dorénavant la possibilité d'accéder au contenu de la mémoire heap via JVMTI.
• Attach-on-demand : Java 5.0 avait apporté la possibilité de surveiller le comportement d'une JVM lorsqu'elle était lancée avec certains paramètres. Il sera désormais possible de surveiller n'importe quelle application Java, quelle que soit la manière dont elle a été démarrée (et donc de démarrer une surveillance sur une application sans la redémarrer).

• Calcul à virgule flottante : ajout de méthodes recommandées par l'IEEE 754. Ainsi les classes Math et StrictMath se sont vues rajoutées des méthodes scalb(), getExponent(), nextAfter(), nextUp(), et copySign() pour les types float et double.
• Le package java.util.concurrent introduit dans Java 5.0 a reçu quelques correctifs mineurs, comme l'ajout de nouvelles unités de temps dans la classe TimeUnit : MINUTES, HOURS et DAYS.
• La nouvelle classe java.util.ServiceLoader permet de gérer un système de service tel qu'il est déjà utilisé par plusieurs classes de l'API standard, en recherchant toutes les implémentations concrètes d'une interface (ou d'une classe abstraite) déclarée dans un des fichiers des répertoires META-INF/services de chacun des éléments du CLASSPATH. Ceci est utilisé par exemple pour rechercher automatiquement les drivers JDBC.
• On retiendra également le support des images au format GIF en écriture (jusqu'à présent seul le support en lecture était disponible en standard) qui est devenu possible avec l'expiration des brevets le concernant (le format est dorénavant dans le domaine public).
• Enfin la définition du CLASSPATH supporte désormais le wildcard * qui représente toutes les archives jar/zip d'un répertoire. Ainsi si le CLASSPATH (via la ligne de commande, la variable d'environnement ou l'attribut du manifest du Jar) comporte par exemple lib/* toutes les archives du répertoire lib seront ajoutées au Classpath de l'application, et il sera donc inutile de les nommer une à une.