Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Oracle présente de nouvelles fonctionnalités de Java 9
Et fixe les bases pour implémenter la modularité

Le , par Hinault Romaric

62PARTAGES

1  0 
Oracle a dévoilé de nouvelles fonctionnalités qui seront intégrées à Java 9, la prochaine version majeure de la plateforme de développement, qui sera disponible en 2016.

Java 9 introduira via la JEP 158 (Unified JVM Logging), un système d’enregistrement commun pour tous les composants de la JVM. Cela permettra une refonte complète de la façon dont Java signale les événements dans les sous-systèmes.

Plus de contrôle au niveau de la compilation sera offert par cette version (JEP 165 - More compiler controls). Cette amélioration permettra aux développeurs de changer les options de compilation du compilateur JIT Hotspot afin de pouvoir effectuer des optimisations spécifiques.

Avec la JEP 214 (Remove GC Combinations Deprecated in JDK 8), trois fonctionnalités du garbage collection (ramasse-miettes) seront supprimées. Il s’agit de DefNew + CMS, ParNew + SerialOld et Incremental CMS. Ces fonctionnalités étaient déjà obsolètes dans Java 8.

Quelques petits changements seront apportés au projet Coin (JEP 213), qui avait été introduit dans Java 7. Pour rappel, le projet Coin apporte quelques changements linguistiques à Java.

En plus de ces fonctionnalités, Oracle a l’intention de finaliser avec le projet « Resolve Lint and Doclint Warnings » pour le nettoyage des avertissements, qui avait débuté il y a plusieurs années. Java 9 offrira également un support de Datagram Transport Layer Security, et des sorties HTML5 pour Javadoc. De nombreuses corrections seront également apportées pour améliorer la gestion des importations, et les classes dépréciées ne vont plus générer des alertes.

À ces spécifications, s’ajoutent d’autres JEP qui ont été présentées en aout dernier, qui permettent de doter le langage de programmation d’une nouvelle « API lightweight JSON » pour la production et la consommation de documents JSON, de « HTTP2 Client » pour le support du HTTP 2.0 et des web sockets et de « Process API Updates » qui permet d’améliorer le contrôle, la gestion et l’interaction avec les processus non Java.

Bien que le projet Jigsaw ne soit pas encore intégré au projet, Oracle a réaffirmé son engagement d’offrir la modularité dans Java 9. Les ingénieurs d’Oracle ont fixé les bases pour une mise en œuvre structurée du projet Jigsaw à travers la JEP 152, JEP 201 et JEP 220. Jigsaw représente une nouveauté très attendue. Mais, son développement fait face à plusieurs défis qui doivent être relevés avant son intégration.

Jigsaw apportera des gros changements au JDK. Il permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Ainsi, une machine virtuelle Java (JVM) pourra fonctionner sans le support de certains packages de base.

Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, a fait savoir qu’avec Jigsaw, le format JAR n’avait plus sa place dans le système d’exécution de Java. « Le format JAR a fait son temps, c'est le moment de passer à autre chose », avait affirmé celui-ci.

Une annonce qui n’a pas manqué de créer une certaine frayeur chez les développeurs. Mais, Oracle rassure. Bien que le système d’exécution de Java reposera sur les modules et non les fichiers jar, la plateforme continuera à prendre en charge et à exécuter les applications empaquetées dans les fichiers Jar. Avec le temps, les développeurs devront, cependant, migrer vers les nouveaux formats modulaires.

Le passage à un système de module aura également un impact important sur les outils de développement et les Framework.

À titre de rappel, les JEP sont les nouveaux processus permettant le développement et le test de fonctionnalités relatives au langage Java ou à sa machine virtuelle, sans recourir au processus complet de spécification (JSR). Par la suite, toute JEP qui a été implémentée avec succès sera intégrée à Java sous la forme de mise à jour ou de nouvelle version.

Source : Oracle

Et vous ?

Quelle fonctionnalité attendez-vous le plus dans Java 9 ?

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de akecoocoo
Membre habitué https://www.developpez.com
Le 20/11/2014 à 16:04
Euh, les apps sous Android, c'est pas en Java ?!?
5  0 
Avatar de Nico02
Membre expérimenté https://www.developpez.com
Le 20/11/2014 à 15:01
Citation Envoyé par Traroth2 Voir le message
Java au niveau des clients lourds comme mobiles étant en voie de disparition rapide, je ne suis pas sûr que Jigsaw soit toujours aussi attendu, en fait. Parce qu'au niveau serveur, les bénéfices concrets sont quand même minces. Démarrage plus rapide du serveur et occupation mémoire plus réduite, en gros. Au prix de la barrette de RAM...
Mouai m'enfin bon il faut pas non plus oublier tout ce qui est système embarqué qui eux seront ravis de ne pas avoir à charger toutes ces bibliothèques inutiles.

Et puis dire que Java est en voie de disparition des clients lourds/mobile

Autant les projets Web on effectivement le vent en poupe par rapport au client lourd (et pas que pour Java) autant le mobile je suis pas du tout convaincu..
3  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 20/11/2014 à 22:52
Citation Envoyé par 23JFK Voir le message
C'est la partie proclamant la "fin" du format JAR qui me fait tiquer. D'ailleurs, depuis sa primodéclaration, il semble avoir un peu fait machine arrière.

Puis, tous les projets n'ont pas besoin de pousser à l'extrême le concept de modularité. Côté serveur, cela permettra sans doute d'optimiser le fonctionnement, mais pour des déploiements d'applications, une requête sur un fichier JAR sera toujours plus performante que 20 requêtes sur des fichiers JMOD.
Pourquoi il y aurait 1 seule requête pour un JAR, mais 20 pour un JMOD ?

C'est juste un nouveau format va juste permettre de gérer les lacunes des jars, comme la gestion des dépendances et des versions...
Une fois la transition faite il y aura peut d'intérêt à revenir au JAR, sauf à vouloir conserver une rétrocompatibilité avec une ancienne version de Java...

a++
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 21/11/2014 à 17:22
Citation Envoyé par Traroth2 Voir le message
Oui, oui, je ne dis pas que ça ne sert à rien. Mais c'est sur le client que la différence aurait été vraiment déterminante, et là, les jeux sont faits. Jigsaw vient avec 10 ans de retard...
Bah les technos tournent. Rien ne dit que Java ne reviendra pas sur le devant de la scène coté desktop et/ou navigateur.
A la fin des années 90 c'était le DHTML qui était à la mode, avant d'être petit à petit remplacé par des langages cote-serveur... avant de revenir à la mode sous un autre nom (AJAX) un peu plus élaboré.

Et de nos jours on parle de plus en plus du JavaScript coté desktop !

Le gros problème de Java dans le navigateur, outre le plugin bien lourd, c'était surtout la guerre qu'il y a eu avec Microsoft et son "Java" non-standard qui a complètement cassé le "write-one run-everywhere".

Le JavaScript c'est certe bien mais cela a un paquet de défaut, surtout lorsqu'on gère des applications complexes.
Je ne serais pas étonné de voir des tentatives pour intégrer un nouveau langage en standard dans les navigateurs, et un langage comme Java (ou C#) pourrait très bien remplacer avantageusement le JavaScript.

Le gros problème c'est que ces langages sont étroitement liés à des API énormes contenant plein de chose pas forcément adapté (que faire de CORBA, AWT, Swing, JDBC ou encore javax.management), et qu'il devient difficile et "lourd" de les incorporer dans un navigateur.

Mais demain avec le projet Jigsaw on pourrait très bien imaginer un Java "light" : le même langage, mais associé à une API minimum.
Le module de base devrait contenir les principaux package (java.lang / java.util), et pourra être enrichi d'autres modules selon les besoins.

Il serait donc possible de voir des navigateurs inclurent un Java "minimum", le tout couplé à un module "browser" permettant une communication simple avec le browser, et des modules optionnelles représentant les fonctionnalités "html5"...
Et on pourrait se retrouver à codé des applications Java qui tourneraient directement dans le navigateur.

a++
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 11/05/2015 à 11:51
Citation Envoyé par yahiko  Voir le message
Le principal souci des applets Java, en plus de mettre trois plombes à se charger, c'est que d'abord c'est ultra moche au sein d'une page Web.

Je ne parlais pas d’insérer des applets, mais de pourvoir utiliser du Java à la place du JavaScript.

Le problème de lancement des applets disparait si la JVM est inséré dans le navigateur (comme la machine virtuelle JavaScript).
Quand aux différentes couches UI il n'en serait même pas question puisque je parle d'un Java "minimum".
Grosso-modo on aurait accès uniquement aux packages de base (java.lang, java.util), et à un package "java.browser" permettant de communiquer avec le navigateur.

Toute la partie UI passerait pas une manipulation du DOM comme on le fait actuellement en JavaScript.
Grosso-modo au lieu de faire :
Code HTML : Sélectionner tout
<script type="text/javascript" src="/script.js"></script>
Code JavaScript : Sélectionner tout
1
2
3
4
5
  
document.getElementByID("title").innerText = "Titre de mon application"; 
document.getElementByID("button").addEventListener("click", function(e) { 
    window.alert("click on button"); 
}


On pourrait faire la même application en Java :
Code HTML : Sélectionner tout
<script type="application/java" src="/archive.jar"></script>
Code Java : Sélectionner tout
1
2
3
4
5
6
  
Document document = Browser.getDocument(); 
document.getElementByID("title").setInnerText("Titre de mon application"); 
document.getElementByID("button").addEventListener("click", (e) -> { 
    Window.alert("click on button"); 
}


Citation Envoyé par yahiko  Voir le message
Quand au potentiel énorme, avec l'amélioration de JavaScript tant côté serveur que côté client, j'ai du mal à voir l'énormité du potentiel des applets.

Avoir du code typesafe et un vrai langage bien pensé.

Citation Envoyé par yahiko  Voir le message
Oui, en fait tu veux que la verbosité et la rigidité contre-productive de Java soit transposée côté navigateur...

JavaScript c'est bien pour foutre une ou deux animations sur une page...
Mais quand tu développes une application un tant soit peu consistant c'est agréable d'avoir un langage qui ne vas pas te pêter à la gueule pour un oui ou pour un non.
Je revis depuis que je fais du GWT et que mon JavaScript se limite à une ligne par-ci par-là...

a++
2  0 
Avatar de adiGuba
Expert éminent sénior https://www.developpez.com
Le 20/11/2014 à 18:15
Citation Envoyé par akecoocoo Voir le message
Euh, les apps sous Android, c'est pas en Java ?!?
Le code source est écrit en Java, mais ce n'est pas compilé en bytecode Java ni exécuté par un JVM.

Google a créé son propre bytecode et sa propre machine virtuelle (Dalvik).

Citation Envoyé par 23JFK Voir le message
Avec des affirmations comme celle-ci, il ne va pas rester architecte en chef bien longtemps celui-là.
Pourquoi ?

a++
1  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 20/11/2014 à 20:13
Citation Envoyé par Traroth2 Voir le message
Parce qu'au niveau serveur, les bénéfices concrets sont quand même minces. Démarrage plus rapide du serveur et occupation mémoire plus réduite, en gros. Au prix de la barrette de RAM...
Démarrage plus rapide des serveurs => Extrèmement intéressant si tu travail avec des noeuds à la demande. Quand ta charge augmente, entre attendre 30 secondes le démarrage de la jvm et attendre 15 secondes, c'est la différence entre un engorgement temporaire et un effet de cascade qui va tuer tes clients.

Modulariser java pour réduire son emprunte mémoire est important aussi sur un serveur lancant beaucoup de jvm. Ca permettra, en ce qui me concerne, d'utiliser plus souvent java pour du scripting là où pour le moment on lance du python ou du php parce qu'on ne peut pas se permette de de lancer simultanément 20 ou 40 jvm qui consomment chacune 64Mb ou d'attendre 5 secondes d'initialisation pour calculer 2 secondes. Et réduire le nombre de langages à maitriser dans une équipe, c'est aussi augmenter son expertise...

La barette de RAM est pas chère, c'est vrai. Mais sur un serveur, la différence entre 8 16 ou 32 slots pour mettre ta mémoire, c'est très coûteux.
1  0 
Avatar de Traroth2
Membre chevronné https://www.developpez.com
Le 21/11/2014 à 11:58
Citation Envoyé par tchize_ Voir le message
Démarrage plus rapide des serveurs => Extrèmement intéressant si tu travail avec des noeuds à la demande. Quand ta charge augmente, entre attendre 30 secondes le démarrage de la jvm et attendre 15 secondes, c'est la différence entre un engorgement temporaire et un effet de cascade qui va tuer tes clients.

Modulariser java pour réduire son emprunte mémoire est important aussi sur un serveur lancant beaucoup de jvm. Ca permettra, en ce qui me concerne, d'utiliser plus souvent java pour du scripting là où pour le moment on lance du python ou du php parce qu'on ne peut pas se permette de de lancer simultanément 20 ou 40 jvm qui consomment chacune 64Mb ou d'attendre 5 secondes d'initialisation pour calculer 2 secondes. Et réduire le nombre de langages à maitriser dans une équipe, c'est aussi augmenter son expertise...

La barette de RAM est pas chère, c'est vrai. Mais sur un serveur, la différence entre 8 16 ou 32 slots pour mettre ta mémoire, c'est très coûteux.
Oui, oui, je ne dis pas que ça ne sert à rien. Mais c'est sur le client que la différence aurait été vraiment déterminante, et là, les jeux sont faits. Jigsaw vient avec 10 ans de retard...
1  0 
Avatar de tchize_
Expert éminent sénior https://www.developpez.com
Le 11/12/2014 à 15:09
Jusqu'à présent, la compatibilité a toujours été assurée en java, je ne vois pas ce qui te fait penser que ce ne serait plus le cas.
1  0 
Avatar de Washmid
Membre averti https://www.developpez.com
Le 07/05/2015 à 17:53
Citation Envoyé par MikeRowSoft Voir le message
Je me demande bien comment fonctionne cette machine virtuelle.
La machine virtuelle : http://jmdoudoux.developpez.com/cour...eloppons/java/

Citation Envoyé par MikeRowSoft Voir le message
Je crois qu'il y a des fichiers exécutables pour l'intégration avec les systèmes d'exploitations, mais pas de scripts pour une interaction direct comme pour JavaScript ou Visual Basic Script ou Script Shell ou autres.
On peut créer des exécutables par plateforme (.exe) mais aussi exécuter des scripts (javascript, groovy, python etc.) pas de soucis à ce niveau là. La JVM ne fait pas tourner qu'un langage ! http://en.wikipedia.org/wiki/List_of_JVM_languages

Citation Envoyé par MikeRowSoft Voir le message
Ils ont une priorité défini, même si ils peuvent la changé à leurs guises dans certains cas.
Le Java Community Process a son mot à dire : http://fr.wikipedia.org/wiki/Java_Community_Process

En espérant t'avoir éclairé
1  0