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++

[thelvin]

Bien sûr mais je cherchais à voir plus loin.

Ça permet d'étendre les interfaces existantes sans casser les implémentations existantes (qui ne compileraient plus si on ajoutait juste une nouvelle méthode dans l'interface.)
Problème qui ne se posait pas avec les classes abstraites (ou les classes tout court d'ailleurs.)

On peut donc y voir l'aveu que les collections auraient dû être des classes abstraites depuis le début,
ou on peut se demander la différence entre une implémentation par défaut dans une interface, et une implémentation définie dans une classe abstraite.

Au début je penchais vers le premier, mais en y réfléchissant, associer aux interfaces du code utilisant le contrat de cette interface, ça a du sens, c'est ce que font plein de classes utilitaires. Ça ne casse donc pas le principe de n'imposer aucune implémentation, et c'est garanti par le compilateur.

[adiGuba]

Oui la grosse différence c'est qu'une classe abstraite peut avoir un état via des variables, et donc une implémentation plus concrète, là où une interface ne pourra se baser que sur de l'abstrait.

Donc malgré cela les 3 couches restent toujours utile (interfaces avec méthodes par défaut, classe abstraites avec implémentation de base, puis classe concrète avec implémentation finale).




Tu parles de classes utilitaires et cela semble bien être l'objectif premier des méthodes par défaut et des méthodes static dans les interfaces, tout en permettant de mieux les référencer (puisqu'elle sont directement visible dans l'interface en question sans avoir à chercher la classe utilitaire associé).

Par exemple l'interface Comparator s'est bien étoffé !

Jusqu'à présent si on voulait créer un Comparator selon plusieurs critères, il fallait tout coder soit-même :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
		Comparator<User> c = new Comparator<User>() {
			@Override
			public int compare(User u1, User u2) {
				int diff = u1.getFirstName().compareTo(u2.getFirstName());
				if (diff==0) {
					diff = u1.getLastName().compareTo(u2.getLastName());
					if (diff==0) {
						diff = Integer.compare(u1.getAge(), u2.getAge());
					}
				}
				return diff;
			}
		};

Désormais l'interface Comparator possède des méthodes static comparing() permettant de créer des Comparators à partir d'un fonction retournant une valeur.

Par exemple pour comparer des User selon la valeur retournée par getFirstName() :

Code :

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

Comparator<User> c = Comparator.comparing( (User u) -> u.getFirstName() );

On peut même remplacer la lambda par une référence de méthode, ce qui rend le tout encore plus lisible :

Code :

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

Comparator<User> c = Comparator.comparing( User::getFirstName );

S'ajoute à cela des méthodes par défaut thenComparing() permettant d'ajouter une règle supplémentaire à un Comparator existant, selon le même principe.
On obtient alors notre Comparator selon les 3 critères assez facilement :

Code :

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

1
2
3
Comparator<User> c = Comparator.comparing(User::getLastName)
			.thenComparing(User::getFirstName)
			.thenComparingInt(User::getAge);

a++

[LGnord]

Une autre utilisation: l'interface iterator pourra être étendue avec une implémentation par défaut remove() qui lance une UnsupportedOperationException.

Je n'arrive pas à décider si c'est bien ou pas.

[adiGuba]

Au niveau des nouveaux concepts, il faudra désormais faire avec la boucle d'itération interne.


Jusqu'à présent on avait affaire à des boucles d'itérations externe, soit en utilisant directement un Iterator, soit en utilisant le for-étendus :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
List<String> list = ...
 
// Itération externe utilisant un Iterator :
Iterator<String> iter = list.iterator();
while (iter.hasNext()) {
	String value = iter.next();
	// traitement sur value
}
 
 
// Itération externe utilisant un for-étendu :
for (String value : list) {
	// traitement sur value
}

Par "externe" il est sous-entendu que l'implémentation de la liste n'a aucun moyen de contrôler le déroulement de cette dernière.



Désormais, l'interface Iterable est doté d'une nouvelle méthode forEach() permettant de parcourir les éléments de manière "interne", ce qui nous donne :

Code :

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

1
2
3
list.forEach( (value) -> {
	// traitement sur value
});

La principale différence vient du fait que l'on n'effectue pas directement la boucle. On se contente d'appeler la méthode forEach() en lui passant une expression lambda contenant notre traitement.

Bien sûr l'implémentation par défaut se contente d'utiliser le for-étendu pour parcourir tous les éléments :

Code :

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

1
2
3
4
5
6
    default void forEach(Consumer<? super T> action) {
        Objects.requireNonNull(action);
        for (T t : this) {
            action.accept(t);
        }
    }

Mais les implémentations pourront à loisir proposer une autre implémentation plus adapté.
Par exemple ArrayList parcourt directement son tableau interne sans passer par l'Iterator, tandis que les collections synchronisés (Collections.synchronizedXXX()) gèrent la synchronisation de toute la boucle...



Et bonus supplémentaire, on dispose du même genre de facilité sur les Map :

Code :

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

1
2
3
4
5
	Map<String,String> map = ...;
 
	map.forEach( (k, v) -> {
		System.out.println("k=" + k + ", v=" + v);
	});

Une autre utilisation: l'interface iterator pourra être étendue avec une implémentation par défaut remove() qui lance une UnsupportedOperationException.

Je n'arrive pas à décider si c'est bien ou pas.

C'est "bien" dans le sens où c'est ce qui a toujours été conseillé dans la documentation de la méthode : http://docs.oracle.com/javase/7/docs...l#remove%28%29

L'API de Collections possède comme cela un bon nombre de méthode "optionnelle", qui doivent remonter une UnsupportedOperationException lorsqu'elles ne sont pas gérés.




a++

[bouye]

Concernant les lambdas, posté par Richard Bair (le chef architecte de l’équipe JavaFX sur son Twitter) :

Lambda just rocks:

Code :

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

mcBtn.setOnAction(event -> handleMemCleanButtonClicked());

Suivit de :

More lambda goodness:

Code :

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

splitter.setOnMouseDragged(this::onSplitterDragged);

(reference to local method)

Sinon comme je le disais recement sur mon blog, bonjour pour comprendre le code de certaines boucles desormais : Can use functionnal operations…

[adiGuba]

Sinon comme je le disais recement sur mon blog, bonjour pour comprendre le code de certaines boucles desormais : Can use functionnal operations…

Je pense quand même qu'il y a certains soucis avec NetBeans.

Je ne suis pas habitué à l'API Chart, mais il y a eu un gros travail pour améliorer le "type inference" dans Java 8.
Et du coup je pense vraiment que tous ces casts sont vraiment inutile (il faudrait essayer de compiler en ligne de commande pour vérifier).


De même, le code généré ne me semble pas forcément adapté : les générateurs des EDIs ne produisent pas forcément un code très joli...

Par exemple il te produit deux map() alors que la première est un peu inutile (et c'est sûrement lié au mauvais cast).

Perso si j'avais à écrire une boucle de la sorte :

Code :

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

1
2
3
4
5
for (Object d : sourceSeries.getData()) {
	final LineChart.Data sourceData = (LineChart.Data) d;
	final LineChart.Data data = copyData(sourceData);
	dataList.add(data);
}

Je pense que cela pourrait s'écrirait plutôt comme ceci :

Code :

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

1
2
3
List<LineCharData> dataList = sourceSeries.getData().stream()
	.map((d)-> copyData(d))
	.collect(Collectors.toList());

Voir même comme ceci (si copyData est une méthode static) :

Code :

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

1
2
3
List<LineCharData> dataList = sourceSeries.getData().stream()
	.map(NomDeLaClasse::copyData)
	.collect(Collectors.toList());

Maintenant cela reste clairement un mauvais exemple : la boucle est si simple que son équivalent en "stream" n'apporte pas grand chose...



a++

[adiGuba]

Tutoriel sur la nouvelle API de Dates, qui semble vraiment très complète : http://docs.oracle.com/javase/tutori...iso/index.html


a++

[adiGuba]

Les documents "State of the Lambda" ont été mis à jour :

• State of the Lambda décrit les évolutions apportés par les lambdas, les références de méthode et les méthodes par défaut.
• State of the Lambda: Libraries Edition présente quelques unes des nouvelles APIs qui les utilisent.

a++

[Uther]

Les lambdas sont vraiment une bonne avancé, je suis juste toujours choqué par la syntaxe variables -> code.

J'ai beau la voir depuis un bon moment, je la trouve toujours aussi peu claire. A vouloir gagner 2 caractères, je trouve qu'elle a vraiment perdu en lisibilité par rapport au #(variables){code} du début du projet.

[adiGuba]

Les lambdas sont vraiment une bonne avancé, je suis juste choqué par la sytaxe variables -> code.

La syntaxe exacte c'est (variables) -> code ou (variables) -> {code}

J'ai beau la voir depuis un bon moment je la trouve toujours aussi peu claire. A vouloir gagner 2 caractères, je trouve qu'elle a vraiment perdu en lisibilité par rapport au #(variables){code} du début du projet.

Je préférais également ce genre de syntaxe, simplement car le début de la lambda est plus visible grâce au diese...


a++

[adiGuba]

La nouvelle API de Date me semble vraiment bien complète !

• Déjà on a plein de type de date/heure qui pourront s'adapter à nos besoin (heure seule, date seule, date+heure, avec ou sans fuseaux horaires) : Instant, LocalDate, LocalDateTime, LocalTime, OffsetTime, OffsetDateTime, ZonedDateTime.
  
• La notion de durée est désormais représentée, via les classes Duration et Period qui représentent respectivement un nombre de millisecondes et un intervalle de jour (et/ou mois/année)...
  
• Tous ces objets s'instancient via des méthodes static, et peuvent être "modifié" via des méthodes d'instance :
  

  Code :

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

  1
  2
  3
  4
  5
  6
  7
  8
  	LocalDate today = LocalDate.now();
  	LocalDate yesterday = today.minusDays(1);
  	LocalDate lastMonth = today.minusMonths(1);
  	LocalDate nextWeek = today.plusWeeks(1);
  	LocalDate firstDayOfMonth = today.withDayOfMonth(1);
   
  	LocalDate d1 = LocalDate.of(2013, 9, 24);
  	LocalDate d2 = LocalDate.of(2013, Month.SEPTEMBER, 24);

• Tous ces objets sont immutables : les méthodes de modifications retournent donc une nouvelle instance.
  Plus besoin de protéger ces objets lorsqu'on les partage entre plusieurs classes.
  
• Le mois "0" n'existe plus !!! Et le mois "1" correspond à JANVIER (Hourra !!!)
  
• L'API n'utilisent que des exceptions "unchecked" qui ne nous forceront pas à les traiter à tout prix.

[edit] Bon par contre à première vue c'est nettement plus complexe à appréhender !


a++

[Tommy31]

C'est donc la fin de JodaTime ?

[bouye]

En tout cas, a la JavaOne de l'an dernier le créateur de Joda (puisque c'est la même personne qui s'occupe des deux) disait qu'il n'avait plus trop le temps de s'en occuper vu qu'il était totalement focalise sur cette nouvelle API.