Discussion :

[adiGuba]

Salut,


Java 8 est désormais au stade de "Developer Preview", téléchargeable à cette adresse : http://jdk8.java.net/download.html

Je pense qu'il pourrait être intéressant de partager nos avis et nos découvertes vis à vis des nouveautés de cette version, que ce soit les grosses fonctionnalités ou les petites "trucs" anodin mais qui pourrait s'avérer utile...


a++

[adiGuba]

Je commence par jdeps et les profils !


La JEP 161 apporte une notion de profil au JDK.
L'API standard a été retravaillé afin de pouvoir être découpé en 3 profils plus réduit :

• Le profil "compact1" comporte les packages de base (java.lang, java.io, java.net, java.nio, java.security, etc.).
• Le profil "compact2" y rajoute les packages lié à RMI, SQL et XML (java.rmi, java.sql, javax.xml, etc.).
• Le profil "compact3" y rajoute les packages plus spécifiques (java.lang.instrument, java.util.prefs, javax.annotation.processing, javax.lang.model, javax.management, javax.naming, etc.)
• Enfin le profil "Full JRE" y rajoute tous les autres packages de l'API standard (bref c'est le Java SE que l'on connait).

Certaines JVMs pourrait donc implémenter uniquement un de ces profils afin de réduire leurs tailles et mieux s'adapter au matériels sur lequel elles tournent (inutile d'incorporer AWT/Swing sur une machine sans écran par exemple).

L'objectif étant de pouvoir développer des applications ne neccessitant pas forcément l'API complète du JRE, afin de les faire tourner sur du matériel avec des ressources "limités".

Et avec Java 9 ces profils seront intégrés dans la modularisation de Java tant attendu...





Dans le même temps, le JDK s'enrichi d'un nouvel outil : jdeps
jdeps permet de définir les dépendances d'une classe ou d'un jar.
Il peut lister soit les packages utilisés, soit les profils correspondant.


Par exemple pour un simple "Hello World", on pourrait avoir ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
jdeps Main.class
 
Main.class -> C:\dev\bin\jdk-1.8.0\jre\lib\rt.jar
   <unnamed> (Main.class)
      -> java.io
      -> java.lang

Ou bien en affichant les profils :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
jdeps --profile Main.class
 
Main.class -> C:\dev\bin\jdk-1.8.0\jre\lib\rt.jar
   <unnamed> (Main.class)
      -> java.io                                            compact1
      -> java.lang                                          compact1

Pour les classes/jars plus imposant, on peut se contenter d'afficher un résumé, qui affichera soit les jars utilisés, soit les profils correspondant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
jdeps --summary Main.class
 
Main.class                     -> C:\dev\bin\jdk-1.8.0\jre\lib\rt.jar

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
jdeps --summary --profile Main.class
 
Main.class                     -> compact1

En modifiant notre "Hello World" pour qu'il utilise un JOptionPane, on voit que l'utilisation de Swing implique l'utilisation d'un JRE complet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
jdeps --summary --profile Main.class
 
Main.class                     -> Full JRE
Main.class                     -> compact1

Mieux : jdeps peut également indiqué les librairies externes (à condition que le classpath soit correctement défini).
Cela peut permettre de détecter l'utilisation de librairies inutilisés...


a++

[LGnord]

Finalement, les expressions lambas (+- les fonctions) sont-elles dans Java 8?

[JoeChip]

Apparemment oui ; pour moi ce serait un des grands progrès... En tout cas un qui me concernerait, opérationnellement.

[adiGuba]

Finalement, les expressions lambas (+- les fonctions) sont-elles dans Java 8?

Oui !


Au niveau du langage, les principales nouveautées sont :

• La notion d'interface fonctionnelle (interface avec une seule méthode abstraite), avec un package java.util.function qui en définit un certain nombre...
  
• Les expressions lambda qui peuvent être affectées à une interface fonctionnelle :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  1
  2
  3
  4
  Comparator<String> comparator = (String s1, String s2) -> { return s1.compareToIgnoreCase(s2); };
   
  // Ou en plus succinct le (type des paramètres est déduit par le compilateur)
  Comparator<String> comparator = (s1, s2) -> s1.compareToIgnoreCase(s2);

• Les références de méthode, qui peuvent remplacer les expressions lambda lorsqu'on veut appeler une méthode dont la signature correspond à la lambda :
  

  Code :

  Sélectionner tout - Visualiser dans une fenêtre à part

  Comparator<String> comparator = String::compareToIgnoreCase;

• Les méthodes par défaut dans les interfaces, qui permettent d'associer du code à une méthode définie dans une interface.
  Cela permettra enfin de faire évoluer les interfaces sans tout casser (et l'API de Collections va bien en profiter).
  
• La possibilité de définir des méthodes static dans une interface.
  
• Une meilleure gestion de l'inférence des types avec les méthodes paramétrées par les Generics.

a++

[thelvin]

Les méthodes par défaut dans les interfaces, qui permettent d'associer du code à une méthode définie dans une interface.
Cela permettra enfin de faire évoluer les interfaces sans tout casser (et l'API de Collections va bien en profiter).

Si je comprends bien, la différence avec une simple classe abstraite, c'est qu'il n'y a pas de variables membres et donc ces méthodes sont implémentées uniquement en s'adressant aux méthodes, qui sont polymorphes ?

[adiGuba]

Si je comprends bien, la différence avec une simple classe abstraite, c'est qu'il n'y a pas de variables membres et donc ces méthodes sont implémentées uniquement en s'adressant aux méthodes, qui sont polymorphes ?

Oui il n'y a pas de variables membres et donc pas d'état.

Et ces méthodes par défauts sont bien polymorphes. Si la classe qui implémenté l'interface "redéfini" la méthode, alors c'est cette dernière version qui est utilisé lors de l'appel.

Cela permet de faire évoluer les interfaces sans tout casser :

• Jusqu'à présent l'ajout d'une méthode dans une interface impliquait obligatoirement des incompatibilités du binaire et des sources, car toutes les classes implémentant la-dite interface devaient alors implémenter la nouvelle méthode. Du coup il était quasi-impossible de modifier une interface de l'API standard...
  
• Désormais on peut ajouter autant d'interface que l'on souhaite sans trop de problème à partir du moment où on lui associe un code par défaut.
  Le seul risque étant qu'une classe implémentant l'interface puisse déjà posséder une méthode "identique" (même nom + même type de paramètres) mais avec un type de retour ou des exceptions différentes et incompatibles (ce qui reste assez minime comme risque).

Pour moi c'est LA plus grosse nouveauté, avant même les Lambdas.
En effet cela permet de faire évoluer les APIs existantes en douceur... par exemple pour leurs faire utiliser les lambdas !


a++