IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

Java 9 est disponible, la plateforme se met aux modules tour d'horizon des nouveautés


Sujet :

Java

  1. #1
    Rédacteur

    Avatar de Mickael Baron
    Homme Profil pro
    Ingénieur de Recherche en Informatique
    Inscrit en
    Juillet 2005
    Messages
    14 974
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Vienne (Poitou Charente)

    Informations professionnelles :
    Activité : Ingénieur de Recherche en Informatique
    Secteur : Service public

    Informations forums :
    Inscription : Juillet 2005
    Messages : 14 974
    Points : 72 948
    Points
    72 948
    Par défaut Java 9 est disponible, la plateforme se met aux modules tour d'horizon des nouveautés
    Java 9 est disponible, la plateforme se met aux modules
    tour d'horizon des nouveautés

    Après l'arrivée de Java 8 et ses nombreuses fonctionnalités en 2014, Java 9 pointe enfin le bout de son nez ce 21 septembre 2017. Java 9 inclut plus de 80 nouveautés toutes décrites dans un ensemble de JEP (Java Enhancement Proposal) disponibles à cette adresse : http://openjdk.java.net/projects/jdk9/.

    Nom : java9V2.png
Affichages : 76644
Taille : 37,3 Ko

    À travers cette annonce, l'équipe Java de Developpez.com va vous donner un aperçu de ce qu’apporte le JDK 9 ; voici quelques-unes de ces nouveautés qui pourraient avoir un impact sur votre façon de programmer avec Java. Nous finirons par nos avis personnels respectifs. Ensuite cela sera votre tour ;-)

    La modularisation via le projet Jigsaw

    La modularisation annoncée depuis de nombreuses années, plusieurs fois repoussée, est LA grande nouveauté de Java 9. Elle a été décrite principalement dans la JEP 201. D’autres JEP sont liées à celle-ci tant le projet de modularisation est important. L’objectif principal du système des modules est de fournir un JDK qui puisse être structuré et de pouvoir charger seulement les modules nécessaires. Les applications du domaine de l’Internet des Objets (IOT en anglais) sont très demandeuses, car les systèmes hôtes sont généralement limités en ressources matérielles (mémoire, CPU…). Les développeurs Java pourront donc spécifier les modules du JDK et des bibliothèques tierces qui sont requis par leur application.

    Sur le plan théorique, le système de module apporte également de nombreux autres avantages :

    • une plateforme plus facilement évolutive et maintenable ;
    • des gains en termes de performance et d'exécution puisque seuls les modules nécessaires sont chargés ;
    • des gains en termes de sécurité, car le principe modulaire permet de fournir le juste assez nécessaire au système. De plus, l’utilisation d’API privées est impossible si celles-ci ne sont pas explicitement exportées.


    Comment ça fonctionne ?
    Pour considérer une application tirant parti du système de modules, un fichier module-info.java est requis à la racine de votre projet. Un exemple de contenu de fichier module-info.java est proposé ci-dessous :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    module com.developpez {
        requires java.sql;
        export fr.developpez.com.services;
    }
    Nous remarquons l’usage de nouveaux mots clés comme module, requires et export. Le premier étant utilisé pour nommer le module, le deuxième pour exprimer les modules nécessaires et le troisième pour indiquer les packages du module qui seront visibles à l’extérieur. Pour le dernier point, les packages souvent nommés impl pourront désormais être vraiment considérés comme privés.

    Les personnes ayant une connaissance de OSGi ne seront pas surprises par la syntaxe hormis l’absence de numéro de version. En effet dans cette première version, Jigsaw a fait l’impasse sur les versions. Cet aspect est délégué aux outils de build comme Maven ou Gradle.

    Bien sûr, comme toute grosse nouveauté, il y a quelques problèmes. On peut citer par exemple l’utilisation de la méthode setAccessible(boolean) qui permet d’accéder à des champs privés par réflexion. Cette méthode ne fonctionnera plus pour accéder à un champ privé contenu dans un module pour des raisons de sécurité et vous obtiendrez donc une belle exception de type : IllegalAccessError. Pour résoudre cela, il faudra « ouvrir » le module en utilisant le mot clé open sur le package ou plus globalement sur le module (voir ci-dessous).

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    module fr.developpez.com {
        requires java.sql;
        opens fr.developpez.com.services;
    }
    ou

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    open module fr.developpez.com {
        requires java.sql;
        exports fr.developpez.com.services;
    }

    Les outils ?
    Au niveau des outils, il y a eu également des changements. Les commandes java et javac disposent naturellement de paramètres spécifiques pour prendre en compte le système de module. L’outil jlink (JEP 282) permet d'assembler plusieurs modules Java entre eux en tenant compte de leurs dépendances. Le résultat consiste en une image spécifique du runtime Java (JDK ou JRE) en intégrant son application. Enfin, sans être exhaustif, l’outil jdeps permet de connaître les modules dont dépend votre projet.

    Fabriques pour les collections
    La nouvelle version de Java 9 apporte de gros changements au niveau des API dédiées aux collections. Des méthodes statiques ont été ajoutées sur les interfaces de List, Set et Map pour initialiser des collections. Par ailleurs, les objets créés sont immutables (les attributs les contenant ne sont pas modifiables). L'objectif visé par cette amélioration décrite dans la JEP 269 étant bien sûr la création de petites collections et d'éviter une lourdeur syntaxique.

    Avant Java 9, nous étions obligés de faire cela :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    List<String> myList = new ArrayList<String>();
    myList.add("Developpez.com");
    myList.add("Aime");
    myList.add("Java");
    myList = Collections.unmodifiableList(myList);
    Il y avait bien sûr l’exception de la classe Arrays pour créer des listes toutes prêtes. Malheureusement, il faut bien avouer qu’il n’est pas intuitif de faire appel à la classe Arrays pour créer des listes. Par ailleurs pour Set et Map, il n’y avait pas d’équivalent à la classe Arrays.

    Avec Java 9, la création devient plus simple.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    List<String> newList = List.of("Developpez.com", "Aime", "Java")
    API pour la gestion des processus
    Cette amélioration, décrite dans la JEP 102 permet à Java de mieux coexister avec le système. Initialement le développeur Java utilisait l’API Runtime.getRuntime().exec() puis avec Java 5 est apparue l’API ProcessBuilder. Malheureusement, il n’était pas possible de connaître le PID du processus courant, connaître les sous-processus, détruire des processus ou obtenir d’autres informations comme les paramètres d’exécution. Avec Java 9, les choses ont évolué dans le bon sens avec des nouvelles classes comme ProcessHandle et des ajouts dans la classe Process.

    Pour récupérer le processus courant :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    System.out.println(ProcessHandle.current())
    Pour afficher le PID et les informations de la ligne de commande de tous les processus :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    ProcessHandle.allProcesses().forEach(p -> System.out.println(p.getPid() + " " + p.info().commandLine()));
    1 Optional[/usr/lib/jvm/java-9-openjdk-amd64/bin/jshell -v]
    45 Optional[/usr/lib/jvm/java-9-openjdk-amd64/bin/java -agentlib:... jdk.jshell.execution.RemoteExecutionControl 34065]
    137 Optional[/usr/bin/sleep 1h]
    Multi-release des fichiers JAR
    Le format du fichier JAR évolue. Celui-ci permet de gérer plusieurs implémentations d'une même classe au sein d'une archive unique. Avant Java 9, il était donc impossible de gérer plusieurs versions d’une même bibliothèque au sein d’une même archive.

    Il était important d'apporter une solution pour assurer la compatibilité descendante, car Java 9 intègre de nouvelles API permettant de coder différemment . À l'exécution, la bonne version de la classe sera chargée automatiquement en fonction de la version de Java utilisé. Cette solution est décrite dans la JEP 238, elle est appelée Multi-Release JAR (MR JAR pour les intimes).

    Si on considère deux classes Foo et Bar. La seconde contient deux implémentations une pour Java 9 et une autre pour toutes les versions antérieures à Java 9. La structure du JAR sera la suivante :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    JAR root
    - Foo.class
    - Bar.class
    + META-INF
       - MANIFEST.MF
       + versions
         + 9
           - Bar.class

    Comme on peut constater la racine (JAR root) n'évolue pas et Foo.class et Bar.class seront utilisées par toutes les versions de Java ne supportant pas MR JAR. Au contraire Foo.class et Bar.class localisée dans META-INF/versions/9/Bar.class seront utilisées pour la version 9 de Java.

    Cette fonctionnalité a demandé des améliorations au niveau des outils de compilation et d'analyse. Les outils du JDK (javac, javap, jdeps...) ont été bien entendu impactés. Les outils de build comme Maven ou Gradle ont dû s'adapter pour la construction de cette nouvelle structure de JAR. Sur le papier tout fonctionne pour preuve dans ce dépôt GIT où des tests ont été réalisés.

    Un shell Java : REPL jShell
    De nombreux langages sont actuellement très populaires grâce à leur simplicité pour l’apprentissage ; à titre d’exemple le langage Python. Cette simplicité est en partie due à la présence d’une implémentation appelée REPL (Read Evaluate Print Loop). Grâce à ce mode de fonctionnement basé sur une boucle, l’interpréteur :

    1. Lit une expression (le R pour Read) ;
    2. Évalue une expression (le E pour Evaluate) ;
    3. Imprime sur la sortie standard (le P pour Print) ;
    4. Recommence (le L pour Loop).

    Pour pallier ce manque, la version Java 9 offre un REPL appelé JShell (JEP 222) permettant une programmation interactive. JShell interprète directement des expressions sans avoir besoin qu’elles soient enveloppées dans une classe ou une méthode.

    Outre l’aspect apprentissage, JShell pourra être utilisé pour tester du code rapidement en quelques lignes de code. Par exemple, vérifier si un service web est présent ou tester des agents de placement pour JavaFX. Il est également prévu de pouvoir intégrer JShell directement dans du code Java. On peut même envisager une alternative aux bons vieux scripts Bash et pourquoi pas des langages de script de la JVM comme Groovy.

    Meilleure gestion du deprecated
    L’annotation @Deprecated a été étoffée par deux attributs : l’un de type String since et l’autre de type boolean forRemoval (JEP 277). L’attribut since permet de préciser à partir de quand l’API a été annotée par @Deprecated et forRemoval précise que l’API en question risque d’être supprimée. Nous montrons ci-dessous un exemple de classe qui précise que cette API a été annotée @Deprecated depuis la version 2.5 et qu’elle n’est pas prévue pour être supprimée.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    @Deprecated(since="2.5" forRemoval=false)
    public class MaClassAMoi {}
    Moteur de rendu Marlin
    La JEP 265 a permis l’intégration d’un nouveau moteur de rendu Marlin permettant aux boîtes à outils Java (Java2D et JavaFX) d'être plus rapides. Précédemment les moteurs de rendu Pisces et Ductus étaient utilisés (Oracle JDK). Comme le moteur de rendu Marlin surpasse en termes de performance ces deux moteurs historiques (2006 et 1998), l'équipe de l'OpenJDK 2D a décidé de l'utiliser par défaut dans l'OpenJDK 9 et Oracle de son côté a fait de même pour Oracle JDK9 pour se débarrasser à terme de Ductus.

    Sur le graphique ci-dessous, on remarque que les résultats obtenus par le moteur de rendu Marlin sont toujours plus efficaces que les autres rendus. On atteint parfois des ratios de l'ordre de 650 %.

    Nom : marlincomparison.png
Affichages : 40827
Taille : 327,8 Ko

    MarlinFX a été finalement intégré en décembre 2016 (à la dernière minute), mais il reste désactivé par défaut dans JDK 9 (Java Pisces ou Native Pisces restent utilisés). L’équipe Java de Developpez.com a pu réaliser une interview de Laurent Bourgès, l’auteur principal de cette fonctionnalité : https://java.developpez.com/interview/laurent-bourges/

    Améliorations en vrac
    Les nouveautés de Java 9 sont nombreuses. Nous aurions aussi pu citer les points suivants :

    • Stream : de nouvelles méthodes ont été ajoutées dans les classes Stream et Collectors ;
    • Concurrence (JEP 266) : Java 9 est désormais un langage réactif dans le sens où une implémentation des Reactive Streams a été proposée. La nouvelle classe Flow propose trois interfaces intégrées pour le producteur (Publisher), consommateur (Subscriber) et une dernière pour la connexion entre le producteur et le consommateur ;
    • une nouvelle JavaDoc estampillée HTML 5 avec la possibilité de rechercher du contenu dans une zone de texte. C’est déjà une grosse évolution. Malheureusement, la recherche fulltext n’existe pas. Par ailleurs, les frames oldschool sont toujours présentes ;
    • un vrai client HTTP/2 (JEP 110) ;
    • G1, le garbage collector par défaut (JEP 248). Le garbage collector G1 est par défaut sur les architectures 32 et 64 bits. Il remplacera Parallel GC avec une approche plus intéressante pour les utilisateurs, car il diminuera les latences et son impact sur les ressources ;
    • Milling Project Coin (JEP 213). Ce projet a trait à de nombreuses évolutions de la syntaxe de Java. On notera la possibilité d’avoir des méthodes privées dans les interfaces afin de mutualiser du code utilisé dans les méthodes par défaut. On notera aussi la possibilité d’utiliser des variables finales dans le bloc Try-With-Resources ;
    • meilleure performance pour les chaînes de caractères proposées dans JEP 254, JEP 250 et JEP 280 ;
    • InputStream : trois nouvelles méthodes utilitaires ont été ajoutées dans la classe InputStream. readAllBytes() pour lire tout un flux, readNBytes() pour lire une portion d'un flux et transferTo() pour directement envoyer un flux d'entrée vers un flux de sortie.


    Les avis
    Nous avons demandé aux membres de l’équipe Java de donner leur avis concernant cette nouvelle version de Java. Que pensent-ils de cette version, quelles nouveautés ont-ils préférées et celles qu'ils trouvent décevantes ?

    Avis 1 : Mickael Baron, responsable Java sur Developpez.com

    On parle de Java 9 depuis longtemps. Cela se traduit par de nombreux articles et de présentations sur le sujet. Jigsaw LA fonctionnalité majeure de Java 9 est souvent présentée. Dans la plupart des cas, j’ai l’impression que le retour sur cette fonctionnalité est souvent négatif. D’une part, elle inquiète par le risque que les développements réalisés avant Java 9 ne fonctionnent plus et d’autre part, elle inquiète par le risque que les outils de l’écosystème Java (Maven, Gradle, IDE…) ne soient pas du tout prêts à ce grand changement. Je pense qu’il faudra beaucoup de temps pour que cette fonctionnalité arrive à percer, un peu comme les génériques de Java 5 à l’époque.

    De mon côté, la nouveauté préférée reste REPL. C’est déjà un bon début, on peut facilement tester sans avoir à passer par la phase de compilation et d’exécution. Toutes les expérimentations faites pour la préparation de cette news ont été faites via ce REPL. Par contre, fournir une fenêtre AWT pour l’édition ce n’est pas terrible. Il aurait mieux valu se baser sur un éditeur du système par défaut.

    La plus décevante c’est Jigsaw, non pas sur l’aspect technique, mais plus sur la mauvaise image de Java qu’elle a pu engendrer. Il ne faut pas oublier que la sortie de Java 9 a été repoussée à cause de cette fonctionnalité.

    Avis 2 : Robin56, responsable Java sur Developpez.com
    Comme Mickaël, quand on me parle Java 9, je pense modularité et donc je pense Jigsaw. Son intention est louable. Là où certaines versions ne révolutionnaient vraiment pas l’écosystème Java, je pense que ce n’est pas du tout le cas de l’arrivée de Java 9. Ceci va bousculer nos habitudes et aussi l’écosystème en général. On peut déjà remarquer les IDE et les outils de builds comme Maven devoir s’adapter à ces avancées.

    Revers de la médaille, je crains aussi la montée en version sur Java 9. J’ai bien peur qu’elle se fasse dans la douleur. Rien que le planning de livraison de Java 9 témoigne des impacts de Jigsaw. Son retard de plusieurs mois prouve que cette évolution a des impacts majeurs sur Java. Gare aux projets qui vont migrer en Java 9, je crains qu’ils essuient les plâtres.

    Dans tous les cas, la fonctionnalité que j’attends de voir avec l’arrivée de Java 9 est clairement le projet Jigsaw.

    Avis 3 : bouye, rédacteur et modérateur Java sur Developpez.com
    Mon avis rejoint celui de Mickael concernant les soucis engendrés par Jigsaw et de Robin56 pour le besoin de tout l'écosystème Java de s'adapter à ce nouveau mode de fonctionnement. Bien que n'étant pas un grand utilisateur de Maven, Graddle et co (surtout compte tenu des limitations de mon environnement de travail pro) je reconnais que ces outils sont désormais prédominants dans le monde Java et que le nouveau venu Jigsaw semble mal s'intégrer à l'existant. Je pense attendre que les IDE et outils soient un peu plus matures avant de tenter de porter mes projets vers le JDK9... ou, si je m'y lance, le premier jet sera sans doute sans support des modules.

    À vous de jouer !!

    Et vous :

    • Que pensez-vous de l’arrivée de Java 9 sur le marché ?
    • Quelles sont les évolutions où vous avez le plus d’attentes ?


    Télécharger la nouvelle version de Java

  2. #2
    Modérateur
    Avatar de joel.drigo
    Homme Profil pro
    Ingénieur R&D - Développeur Java
    Inscrit en
    Septembre 2009
    Messages
    12 430
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 55
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D - Développeur Java
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Septembre 2009
    Messages : 12 430
    Points : 29 131
    Points
    29 131
    Billets dans le blog
    2
    Par défaut
    Salut,

    Je suis décu que la JEP 301 ne soit finalement pas implémentée dans Java 9. J'attendais ces évolutions avec impatience.

    En revanche, les nouveautés de la classe Desktop sont bienvenues, en particulier pour l'intégration MacOSX.

  3. #3
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Points : 672
    Points
    672
    Par défaut
    REPL permet à Java de se mettre à la hauteur de Python en terme d'accessibilité sur la ligne de commande.
    Les enseignants vont bien l'apprécier : pour faire des démonstrations rapides de quel effet a telle instruction par rapport à telle autre, c'est très bien.

    Parmi les progrès que j'ai vu, il y en a un qui passe inaperçu et qui va nous soulager pourtant : le passage en UTF-8 des fichiers de propriétés.
    Beaucoup méconnaissaient l'utilitaire native2ascii et s'échinaient à entrer des \u0241 dans ces fichiers, s'épuisant, tout en les rendant illisibles.
    C'en est fini de cela.

  4. #4
    Membre extrêmement actif
    Profil pro
    Développeur
    Inscrit en
    Mars 2012
    Messages
    1 970
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeur
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Mars 2012
    Messages : 1 970
    Points : 3 375
    Points
    3 375
    Par défaut
    Grunt >> "Parmi les progrès que j'ai vu, il y en a un qui passe inaperçu et qui va nous soulager pourtant : le passage en UTF-8 des fichiers de propriétés.
    Beaucoup méconnaissaient l'utilitaire native2ascii et s'échinaient à entrer des \u0241 dans ces fichiers, s'épuisant, tout en les rendant illisibles."

    Tu sais s'il y a moyen de tester si un emoji est installé sur un device?
    Comme les emoji ont un encoding utf8...

  5. #5
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    736
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 736
    Points : 2 799
    Points
    2 799
    Par défaut
    Citation Envoyé par Mickael Baron Voir le message
    Le format du fichier JAR évolue. Celui-ci permet de gérer plusieurs implémentations d'une même classe au sein d'une archive unique. Avant Java 9, il était donc impossible de gérer plusieurs versions d’une même bibliothèque au sein d’une même archive.
    Dommage que ça ne s'applique qu'à la version de Java, pas des modules ou d'autres bibliothèques (un comble quand on sait que la nouveauté principale est la modularité): je cherchais justement un moyen d'avoir dans le même JAR le même plugin adapté à deux versions d'une application principale. Bon, tant pis.

    Citation Envoyé par grunt2000 Voir le message
    REPL permet à Java de se mettre à la hauteur de Python en termes d'accessibilité sur la ligne de commande.
    Les enseignants vont bien l'apprécier : pour faire des démonstrations rapides de quel effet à telle instruction par rapport à telle autre, c'est très bien.
    C'est vrai, encore que depuis pas mal de temps je faisais ça avec jjs. Bon d'accord ça oblige à faire du javascript et pas du java. Mais d'un autre côté, si Java conserve toutes ses contraintes en mode REPL (comme l'obligation de typer toutes les variables) ça en diminue quand même un peu l'intérêt.

    Citation Envoyé par grunt2000 Voir le message
    Parmi les progrès que j'ai vu, il y en a un qui passe inaperçu et qui va nous soulager pourtant : le passage en UTF-8 des fichiers de propriétés.
    Beaucoup méconnaissaient l'utilitaire native2ascii et s'échinaient à entrer des \u0241 dans ces fichiers, s'épuisant, tout en les rendant illisibles.
    C'en est fini de cela.
    Intéressant mais un peu tardif. Tant qu'à faire, pourquoi ne pas remplacer le vieux format plat des fichiers properties par un format hiérarchique, genre JSON ou YAML?
    Et puis contrairement à ce qu'écrit Oracle ici, je connais pas mal de gens qui sous prétexte de travailler seulement en français+anglais laissent les fichiers Properties en ISO-8859-1 dans les jar, ce qui entraînera fatalement des erreurs au moment de basculer à Java 9.

    Citation Envoyé par hotcryx Voir le message
    Tu sais s'il y a moyen de tester si un emoji est installé sur un device?
    A priori c'est plutôt au niveau des polices de caractères : si les emoji sont des caractères, alors chacun doit être présent dans toutes les polices de caractère, sauf si l'outil génère des changements de police à la volée.

    Citation Envoyé par hotcryx Voir le message
    Comme les emoji ont un encoding utf8...
    oui mais ils ne sont pas dans le BMP, donc en UTF-8 ils prendront 4 positions! On passe donc à UTF-8 précisément au moment où il est susceptible de devenir obsolète même dans les pays où on n'utilise que le latin sans accent...

  6. #6
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par esperanto Voir le message
    je connais pas mal de gens qui sous prétexte de travailler seulement en français+anglais laissent les fichiers Properties en ISO-8859-1 dans les jar, ce qui entraînera fatalement des erreurs au moment de basculer à Java 9.
    Apparemment le chargement d'un fichier Properties repasse en ISO-8859-1 si la lecture en UTF-8 échoue, donc çà ne devrait pas poser trop de problèmes.
    https://docs.oracle.com/javase/9/int...2-82006A7A14C7

  7. #7
    Membre émérite
    Inscrit en
    Janvier 2006
    Messages
    736
    Détails du profil
    Informations forums :
    Inscription : Janvier 2006
    Messages : 736
    Points : 2 799
    Points
    2 799
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Apparemment le chargement d'un fichier Properties repasse en ISO-8859-1 si la lecture en UTF-8 échoue, donc çà ne devrait pas poser trop de problèmes.
    https://docs.oracle.com/javase/9/int...2-82006A7A14C7
    Oui j'avais lu puisque c'était précisément ce lien que je citais.
    Mais un basculement automatique ce n'est pas sans danger: tant que les gens pourront éditer le fichier à la main, il se produira toujours des cas où, en l'ouvrant avec un éditeur mauvais ou mal paramétré, on se retrouvera au milieu du document avec un mauvais caractère entraînant le basculement de l'encodage pour l'ensemble du document.

  8. #8
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 130
    Points
    9 130
    Par défaut
    Une des questions récurent auxquelles j'ai droit est la remise en cause de la modularité de OSGi face à jigsaw.

    à mon avis la modularité dans java9 est résolue à la compilation.
    tu définis des modules et leurs dépendances. Puis tu compile et tu lie les modules ensemble pour obtenir une JVM ad-hoc.
    Avec OSGi (karaf, felix, equinoxe...) la résolution est dynamique elle se fait à l'exécution. soit lorsque le module est déployé (import) soit lorsqu'il est exécuté (dynamic-import).

    l'un et l'autre ne sont pas contradictoire mais complémentaires.
    On peut très bien imaginer une karaf écrite sous forme de modules java9 pour obtenir un noyau minimal. les ajouts dynamiques de OSGi étant relégués à l'exécutions.

    Je pense qu'une évolution de OSGi devra décidé de l'interprétation à faire lors du déploiement de modules java9 dans un conteneur.
    l'entête du module contient les informations import/export, mais pas de notion de version. tout comme aujourd'hui lorsqu'un bundle importe un package sans spécifier de version, c'est la version la plus récente disponible qui est lié.

    J'ajoute que l'alliance OSGi s'étonne de l'absence de version dans les import/export et de la dissymétrie des import/export. l'expérience de l'alliance dans le domaine à montré qu'un système symétrique était beaucoup plus facile à implémenter et à gérer. importer des modules et exporter des packages n'est pas pour l'alliance une bonne chose. un autre problème noté est l'impossibilité des faire évoluer la classe module-info.java. le fichier meta-info des jar laissait la possibilité d'ajouter des clefs qui n'était interprétées que par ceux qui s'y intéressait et était ignorées par la JVM standard. Les infos du module sont compilé dans une classe module-info qui n'est pas extensible qui ne peut être dérivée et qui ne supporte pas les annotations.
    A+JYT

  9. #9
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par esperanto Voir le message
    tant que les gens pourront éditer le fichier à la main, il se produira toujours des cas où, en l'ouvrant avec un éditeur mauvais ou mal paramétré, on se retrouvera au milieu du document avec un mauvais caractère entraînant le basculement de l'encodage pour l'ensemble du document.
    En même temps un fichier mal encodé peut déjà poser des problèmes, même sous Java 8.
    Je ne vois pas trop le problème avec çà.

  10. #10
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Points : 672
    Points
    672
    Par défaut
    Bon... je vais faire Braillou-Braz, je ne pas content de cette arrivée d'un Java 9, peu exploitable.

    maven-enforcer-plugin:1.4.1 bloque toute compilation par Maven des projets Spring boot (la dépendance Apache commons-lang2 est responsable de cet incident, d'après ce que j'ai compris, traquez-là au plus tôt),
    Ailleurs, des tests unitaires s'arrêtent en disant : "On ne veut plus continuer, JAXB n'existe plus !". Sans doute, il me faudra bidouiller le paramétrage des plugins surefire et failsafe. Et vous aussi. Et lui aussi, et eux aussi, et ...
    Merci pour le boulot additionnel !

    Je ne comprends pas la démarche,

    Il n'auraient pas pu faire un fonctionnement de Java 9 normal d'abord
    et génial ensuite, seulement sur demande ?

    Parce que le mode génial empêche de lui faire faire fonctionner quoi que ce soit à cet instant.

    Absolument rien ne démarre avec Java 9.
    Je suis passé du Java 1.2 à mes débuts à Java 9 aujourd'hui. Et j'ai jamais vu ça. On est pas à 99% - 100% de bon fonctionnement comme on l'a souvent eu,
    on est à quoi ? 10, 20% des trucs qui tournent avec sans manipulation ? Et 40% avec ? Tous les éditeurs cavalent pour essayer de trouver comment répondre aux plantages induits par Java 9.
    S'ils ont de la chance, une communication sur un forum suffira. Sinon : repackaging et relivraison pour tout le monde.

    Tout le monde logiciel, version +1 de tous les artefacts du monde... et de leurs dépendances... et sous dépendances.
    Merci Java ! Y avait vraiment besoin de ça !

    Des génies.

  11. #11
    Membre régulier
    Profil pro
    Inscrit en
    Juillet 2004
    Messages
    112
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2004
    Messages : 112
    Points : 111
    Points
    111
    Par défaut
    Sur un petit programme je suis passé de 60/75Mo d'occupation mémoire par la JVM en Java8, à 14Mo en Java9; mais je n'ai pas vu de différences sur le temps de lancement.
    Quand on passe son code en modules ça permet de mieux appréhender sa structure globale j'ai trouvé, notamment à cause des dépendances circulaires.
    Sinon REPL et les fabriques de collections me parlent bien.

  12. #12
    Expert confirmé Avatar de yildiz-online
    Homme Profil pro
    Architecte de domaine
    Inscrit en
    Octobre 2011
    Messages
    1 447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte de domaine

    Informations forums :
    Inscription : Octobre 2011
    Messages : 1 447
    Points : 4 570
    Points
    4 570
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    Bon... je vais faire Braillou-Braz, je ne pas content de cette arrivée d'un Java 9, peu exploitable.

    ...

    Des génies.
    Les problèmes que tu as cité sont tous issus de l'écosystème maven, pourquoi blâmer java 9?

    Il y a d'ailleurs une page de status https://cwiki.apache.org/confluence/...ava+9+-+Jigsaw avec la liste des issues ouverts et des versions minimum requises.

    Ce qui est génial c'est de migrer day one sans vérifier l'état des systèmes dépendant (vu les plugins maven en M1, c'est tout de même clair que ce n'est pas mature si on prend la peine de vérifier) et ensuite rejeter la faute
    Une migration, ça se planifie: migration JRE, test, migration JDK test, migration bytecode, test, tout ça en un jour avec des dépendances même pas en RC, en esperant que ça passe crème, vraiment?...

  13. #13
    Membre éclairé

    Profil pro
    Inscrit en
    Janvier 2007
    Messages
    608
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2007
    Messages : 608
    Points : 672
    Points
    672
    Par défaut
    Là je blâme parce que les conséquences elles sont déjà prévisibles.
    Vu l'impact qu'il a, tout va devoir être refait.

    Déjà : Maven, Eclipse, Tomcat, qui dysfonctionnent, et ce sont seulement les trois premiers que j'ai essayé.
    Et c'est par transitivité que Maven est en cause : là, ce sont des artefacts populaires (apache commons-lang 2.x) qui cassent.

    il ne suffit pas que les artefacts soient mis à disposition corrigés ni seulement Maven, il faut aussi que les éditeurs recompilent, re-packagent et relivrent tout à tout le monde. Ce n'est pas rien !
    Tout en faisant des scripts de lancement qui disent :

    Quelle est la version de Java que je trrouve sur le système ?
    Si c'est la 8 ou la 7, je lance avec java maClasseMain
    Si c'est la 9, je lance avec java maClasseMain --chargeça

    Et ça pour la totalité du parc logiciel Java installé dans le monde. Tout ce qui a des annotations, de l'XML – et au bas mot 60% des applications du monde – plante d'autorité.

    C'est loin d'être indolore à faire :
    parce que si une application a été créée en 2013 avec un artefact-tierce-partie version 1.6 et ne fonctionne plus, c'est peut-être seulement l'artefact.tierce.partie version 3.7, bientôt disponible, qui sera compatible. Et voici 2 versions majeures de l'artefact à prendre en compte. Est-ce seulement possible ?

    L'impact de Java 9, à mes yeux, il est très très lourd.
    Que ce soit maintenant ou dans un an, ce travail restera à faire. Et il est pesant.

    La preuve : Maven n'a pas été pris au dépourvu par Java 9 et sur le lien que tu indiques tu lis que ne fonctionnent pas à cet instant les plugins :
    maven-ear-plugin, maven-ejb-plugin, maven-enforcer-plugin, maven-javadoc-plugin, maven-war-plugin
    Le jour J, malgré toutes les milestones qu'ils ont certainement exoérimenté pour éprouver Maven face à Java 9, ils ne sont pas prêts.
    Accordes-moi qu'au moins eux, ils l'auraient dû. Dans les dernières RC, Maven aurait du pouvoir être éprouvé, ses plugins majeurs rapidement rectifiés et redistribués, et ça n'a pas pu être le cas.
    Maven n'a pas été pris au dépourvu par Java 9, donc, mais il a été et est encore dans l'incapacité de le suivre à cet instant.
    C'est un présage sombre.

    Ça donne l'étendue du chantier.
    Alors qu'il aurait suffit de laisser Java continuer à fonctionner comme il le faisait, en chargeant toujours tout, et seulement sur un JAVA_OPTS paramétré par l'administrateur qui l'aurait vraiment voulu, dire : je me mets en mode "Je ne charge que le minimum."
    Là on impose à toutes les applications de vivre sans oxygène. On l'impose. Et elles ne fonctionnent effectivement pas.
    Qui a réussi à lancer quoi avec Java 9, aujourd'hui ? Il y a t-il seulement une application compilée avant Juillet 2017 qui fonctionne sans intervention ? Je me le demande.

    C'est pour favoriser Python et C# cette belle démonstration ? Ce n'est pas parce que c'est Java nouvelle version que c'est bien et bien fait. Là, c'est cuisant.
    C'est un mélange d'autoritarisme et de bêtise. Je l'écris, et je pense que je ne serai pas le seul dans les prochaines semaines à avoir cet avis.

    C'est un mauvais choix qui ne tardera pas à être marquant dans le monde logiciel, et qui restera dans les annales.

  14. #14
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut JDK 9 que pour 64 bits
    JDK 9 n'est pas disponible pour 32 bits, non mais allo quoi!

  15. #15
    Membre expérimenté
    Profil pro
    Inscrit en
    Juin 2006
    Messages
    1 354
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : Juin 2006
    Messages : 1 354
    Points : 1 419
    Points
    1 419
    Par défaut
    non mais sérieux, il n'y aura pas de version 32 bits ? pffffffffffffff ca devient lourd

  16. #16
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 130
    Points
    9 130
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    Là je blâme parce que les conséquences elles sont déjà prévisibles.
    Vu l'impact qu'il a, tout va devoir être refait.

    Déjà : Maven, Eclipse, Tomcat, qui dysfonctionnent, et ce sont seulement les trois premiers que j'ai essayé.
    Et c'est par transitivité que Maven est en cause : là, ce sont des artefacts populaires (apache commons-lang 2.x) qui cassent.
    ....

    il faut modérer un peut tout ça
    Karaf avec commons-lang2 jaxb etc. fonctionne sous java9

    tout n'est pas encore testé mais ça fonctionne. ok il a fallu travailler un peu pour y arriver (pas sans adaptation) mais ça fonctionne.

    en entreprise lorsqu'un soft à été développé pour une version de JAVA on évite de la faire fonctionner avec une autre.
    ou alors on passe par une phase de validation.

    l'arrivé de java9 ne change pas la donne.
    A+JYT

  17. #17
    Expert confirmé Avatar de yildiz-online
    Homme Profil pro
    Architecte de domaine
    Inscrit en
    Octobre 2011
    Messages
    1 447
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Architecte de domaine

    Informations forums :
    Inscription : Octobre 2011
    Messages : 1 447
    Points : 4 570
    Points
    4 570
    Par défaut
    Citation Envoyé par grunt2000 Voir le message
    ... Déjà : Maven, Eclipse, Tomcat, qui dysfonctionnent, et ce sont seulement les trois premiers que j'ai essayé. ...
    Et?..., c'est le premier jour pour tout le monde, que ce soit maven, eclipse (intellij n'a pas ce problème soit dit en passant) ou tomcat ne change rien, ils ont besoin de temps pour arriver à maturité, tes remarques auraient été justifiées pour une mineur, mais certainement pas pour une majeur.

    C'est tout simplement irresponsable de tenter de migrer quoi que ce soit le jour de sortie d'une major, que ce soit java, .net, un middleware ou même un OS, d'autant plus si les composants de l'écosystème ne sont pas encore stables (on ne va quand même pas mettre du .M1 dans une chaîne de production tout de même...)

  18. #18
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    501
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 501
    Points : 1 160
    Points
    1 160
    Par défaut
    Apres tous les commentaires, sa ye, je peux dire que java a fait un churn .

  19. #19
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2011
    Messages
    501
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2011
    Messages : 501
    Points : 1 160
    Points
    1 160
    Par défaut
    A chaque fois, je vois une nouvelle version d'un language sortir. A chaue fois, c'est la meme histoire, vous etes pas au courant, on vous a pris par la gorge.
    Come on guys, la construction de Java 9 etait la, avant la release de Java 8.

  20. #20
    Expert éminent
    Avatar de sekaijin
    Homme Profil pro
    Urbaniste
    Inscrit en
    Juillet 2004
    Messages
    4 205
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Urbaniste
    Secteur : Santé

    Informations forums :
    Inscription : Juillet 2004
    Messages : 4 205
    Points : 9 130
    Points
    9 130
    Par défaut
    Citation Envoyé par epsilon68 Voir le message
    JDK 9 n'est pas disponible pour 32 bits, non mais allo quoi!
    openjdk pour aarch32 est toujours d'actualité.
    A+JYT

Discussions similaires

  1. Java 8 est disponible, la plate-forme se met aux expressions lambdas
    Par Hinault Romaric dans le forum Général Java
    Réponses: 32
    Dernier message: 24/12/2014, 15h26
  2. Quelle API Java pour un jeu de plate forme 2D ?
    Par dawadam dans le forum API graphiques
    Réponses: 0
    Dernier message: 16/06/2011, 23h25
  3. [java] Moteur de jeu de plate-forme
    Par luckyvae dans le forum Projets
    Réponses: 12
    Dernier message: 15/08/2007, 23h06
  4. Message: 'ce symbole est propre à une plate-forme'
    Par neho88 dans le forum Delphi
    Réponses: 4
    Dernier message: 18/10/2006, 16h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo