Discussion :

[bouye]

C'est a nouveau Java One (la grande conf anuelle de Sun a San Francisco pour ceux qui ignorent ce que c'est), et l'on donne quelques nouvelles infos sur les orientations du devellopement de Java 7.

http://tech.puredanger.com/2007/05/09/java7-roundup-14/
http://puredanger.com/techfiles/java7.pdf
http://puredanger.com/techfiles/Java7WhatsNext.ppt

Ce que je retiendrai surtout :

-Java Modularity/Java Kernel : j'en pense pas grand chose et je trouve l'idee ridicule (cf discussion sur la distribution du JDK par le passe). En quoi les gens trouvent difficile de telecharger 7~15Mo de nos jours quand on peut trouver des telechargement de demos de jeu ou de logiciels de DAO/bureautique qui depassent les 500Mo~1Go... De plus dans le pays ou Internet est moins develloper, mieux vaut tout telecharger en une seule fois sur un poste et distribuer l'integralite de la distrib sur CD sur les autres plutot que de devoir telecharger/streamer a chaque fois sur chacun des postes.

De mon points de vie, la notion de modularite est uniquement interressante pour la mise a jour du JRE, et encore a nouveau uniquement dans un envirronement connecte 100% du temps au Net (et via un debit rapide).

- Swing : l'application framework que j'attends depuis ... 1999~2000 se precise enfin. Le beans binding aussi ca permettra d'ecrire plus rapidement les actions d'un programme.
Aucune nouvelle de nouveaux composants helas...

-Reified generics : top si ca rapprochera plus le concept des generics de celui des templates. Si on peut en plus faire de la reflection dessus ca sera bien aussi mais alors il y aura probablement quelques problemes de compatibilite ascendente. L'exemple present dans la presentation PowerPoint n'est guere parlant.

- Short instance creation : si j'ai bien compris l'histoire on va dans la bonne direction. En effet, depuis que j'ai commence a faire des Generics j'ai toujours trouve assez ridicule de devoir faire ca :

Code :

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

Map<String, Integer> map = new HashMap<String, Integer>();

alors que ceci suffirai largement (oui on peut le faire en desactivant des warnings dans l'IDE, je sais) :

Code :

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

Map<String, Integer> map = new HashMap();

Cependant d'apres l'exemple on aura plutot ca :

Code :

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

map := new HashMap<String, Integer>();

Ce que je trouve TRES TRES etrange

- le support des proprietes : mis a part la notation pointeur qui portera encore plus a confusion les utilisateurs de C++ migrant vers Java , dans le principe c'est interressant mais pour le noment je n'ai vu nulle part si la generation automatique des getters/setters supporte :
1) la surchage manuelle de ces meme getters/setters (y compris quand il y a de la covariance) directement dans la classe ou dans les classes filles. Ben oui parfois il faut verifier les valeurs passees ou retournees.
2) la leve automatique d'un PropertyChangeEvent quand on modifie la propriete... c'est quand meme bien ca le coeur du probleme : notifier les observateurs que la propriete a change sans devoir a chaque fois manuellement reecrire les mecanismes permettant d'enregister/desenregistrer les listeners ainsi que le parcourt de la liste pour la notification de l'evenement...

- les petits plus :
Les string dans des switch
Utiliser directement les operateurs numeriques sur les BigDecimal
Les operateurs < et > sur les enums.

pour le reste c'est pas trop ma tasse de the donc je ne peux pas donner mon avis. Et surtout je n'ai toujours rien compris aux closure mis a part que ca me donne mal au crane.

[®om]

Code :

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

Map<String, Integer> map = new HashMap<String, Integer>();

alors que ceci suffirai largement (oui on peut le faire en desactivant des warnings dans l'IDE, je sais) :

Code :

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

Map<String, Integer> map = new HashMap();

Ta ligne de code est équivalente à :

Code :

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

1
2
3
4
HashMap hmap = new HashMap();
Map<String, Integer> map = hmap;
// tu peux donc rajouter
hmap.put(new Object(), new Object());

d'où le warning...

Et les paramètres génériques à gauche et à droite ne sont pas forcément les mêmes.

Code :

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

List<? extends Number> list = new ArrayList<Integer>();

Sinon un mot clé property pourrait être une bonne idée (j'y pensais justement quand on avait un projet EJB3).

Les closures ça peut être bien, mais ça perturbe au début lorsqu'on lit un code (selon les syntaxes proposées) de démo d'une closure...

[bouye]

Ta ligne de code est équivalente à :

Code :

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

1
2
3
4
HashMap hmap = new HashMap();
Map<String, Integer> map = hmap;
// tu peux donc rajouter
hmap.put(new Object(), new Object());

d'où le warning...

Non car il suffirait de restreindre cette ellipse a l'usage de l'operateur new ce qui changerait au final peu de chose puisque grosso modo les Generics actuels ne sont que du sucre syntaxique pre-compilation destine a eviter les erreurs de programmation courants. Bref il me semble que c'est plutot une limitation (volontaire certes) de la grammaire du langage ou du compilateur qu'autre chose (bien plus que le fait que les types ne soient pas conserves en runtime).

Et les paramètres génériques à gauche et à droite ne sont pas forcément les mêmes.

Code :

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

List<? extends Number> list = new ArrayList<Integer>();

D'ou la possibilite de laisser la specification du type a doite de l'affectation en optionnel (s'il y a rien on garde le type a gauche de l'affectation, sinon on prend le type a droite s'il est compatible avec le type de gauche - ce qui est fait actuellement dans ce dernier cas de figure).

Mais bon, pas la peine de grands debats, ce n'est guere la direction (ou la syntaxe) qu'ils ont pris.

Les closures ça peut être bien, mais ça perturbe au début lorsqu'on lit un code (selon les syntaxes proposées) de démo d'une closure...

D'ou le mal de crane en effet .

[adiGuba]

Salut,

- Swing : l'application framework que j'attends depuis ... 1999~2000 se precise enfin. Le beans binding aussi ca permettra d'ecrire plus rapidement les actions d'un programme.

J'ai testé l'Application Framework et c'est vrai que c'était un gros manque pour Swing... Le beans binding à l'air prometteur, mais un peu trop basé sur les noms des attributs (ce qui implique qu'il n'y a pas de vérification à la compilation, et que cela peut géner la refactorisation...)

-Reified generics : top si ca rapprochera plus le concept des generics de celui des templates.

Je n'ai pas trop suivi cela et je ne vois pas trop ce que cela apporterais... à voir donc...

Cependant d'apres l'exemple on aura plutot ca :

Code :

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

map := new HashMap<String, Integer>();

Ce que je trouve TRES TRES etrange

Je n'aime pas trop cette syntaxe non plus
Je n'ai pas lu la présentation que tu donnes en lien (les fichiers PPT sont bloqué par le firewall ), mais il me semble qu'il y a eu un grand nombre de proposition pour cela (dont la tienne ).

Et surtout je n'ai toujours rien compris aux closure mis a part que ca me donne mal au crane.

Il faut le voir comme une autre façon d'écrire des inner-classes, tout en permettant plus d'intéraction avec la méthode appellante (utilisation de variable locale non-final, gestions des exceptions et des interruptions (break/return)).

Un exemple tout simple avec invokeLater().
Ceci :

Code :

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

1
2
3
4
5
	SwingUtilities.invokeLater(new Runnable() {
		public void run() {
			// CODE ICI
		}
	});

Pourrait s'ecrire de la manière suivante :

Code :

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

1
2
3
	SwingUtilities.invokeLater() {
		// CODE ICI
	}

Et cela permettra de se débarrasser de certaine construction un peu trop "lourde", comme par exemple l'utilisation des locks :

Code :

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

1
2
3
4
5
6
	lock.lock();
	try {
		// CODE ICI
	} finally {
		lock.unlock();
	}

Par quelque chose du style :

Code :

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

1
2
3
	Tools.withLock(lock) {
		// CODE ICI
	}

Rien que ca c'est une infime possibilité des closures, mais cela apporterait vraiment beaucoup je pense !


Perso je suis à fond pour, même s'il est vrai que cela peut devenir assez complexe lorsqu'on rentre dans les détails...

a++

[Baptiste Wicht]

Il faut le voir comme une autre façon d'écrire des inner-classes, tout en permettant plus d'intéraction avec la méthode appellante (utilisation de variable locale non-final, gestions des exceptions et des interruptions (break/return)).

Un exemple tout simple avec invokeLater().
Ceci :

Code :

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

1
2
3
4
5
	SwingUtilities.invokeLater(new Runnable() {
		public void run() {
			// CODE ICI
		}
	});

Pourrait s'ecrire de la manière suivante :

Code :

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

1
2
3
	SwingUtilities.invokeLater() {
		// CODE ICI
	}

Personnnellement, j'espère vraiment qu'une telle syntaxe ne va pas être mise en oeuvre... Je ne trouve vraiment pas propre d'insérer du code directement dans une méthode...

Je préfèrerais plutôt une nouveau type d'objet dans lequel qu'on pourrait initialiser directement avec du code :

Code :

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

1
2
3
4
SwingUtilities.invokeLater(new JeSaisPasQuoi(){
	// CODE ICI
	}
)

Mais j'aurais quand même un peu de peine... Ca va quand même à l'encontre de ce qui est fait actuellement.

[adiGuba]

Personnnellement, j'espère vraiment qu'une telle syntaxe ne va pas être mise en oeuvre... Je ne trouve vraiment pas propre d'insérer du code directement dans une méthode...

Personnellement cela ne me choque pas... cela se rapproche de ce qui est fait pour les instructions tel que for, while, synchronized...

Je préfèrerais plutôt une nouveau type d'objet dans lequel qu'on pourrait initialiser directement avec du code :

Code :

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

1
2
3
4
SwingUtilities.invokeLater(new JeSaisPasQuoi(){
	// CODE ICI
	}
)

Il me semble que c'est la proposition de CICE : du sucre syntaxique pour la création de classes anonymes...

Mais j'aurais quand même un peu de peine... Ca va quand même à l'encontre de ce qui est fait actuellement.

Perso je pense que les classes anonymes sont quand même énormément verbeuse et assez limité !


a++

[Baptiste Wicht]

Personnellement cela ne me choque pas... cela se rapproche de ce qui est fait pour les instructions tel que for, while, synchronized...

C'est vrai que c'est déja ce qu'on fait en quelque sorte... Mais personnellement l'histoire du Runnable ne me dérange pas et me suffit tout à fait.

Mais je n'aime pas vraiment l'idée de mettre directement les {} et insérer du code dedans... Je préférerais les voir représenté par un objet ou un type primitif....

[christopheJ]

Il faut vraiment que je me penche sur les closures (la session de Neal Gafter à JavaOne ne m'a pas convaincu...)
A priori on perd l'obligation des attributs en final, il y aurait quelques apports par rapport aux possibilités de return et gestion d'exception, mais je n'ai pas tout compris...

Si après l'argument est de taper moins de code, je ne suis pas d'accord. Les éditeurs, entre la complétion et les templates de code, font beaucoup pour nous.
Les nouvelles syntaxes ont un aspect "cryptographie" qui ne facilite pas la lecture du code.

[bouye]

Moi plus je regarde les deux exemples du short instance creation donnes dans la presentation, plus je me dis que ca va etre imbitable pour ceux qui ne passent pas par des IDE pour programmer :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
map := new HashMap<String, Integer>();
for (word : args) {
  freq := map.get(word);
  ...
}
 
final map := new HashMap<String, Integer>();
for (final word : args) {
  final freq := map.get(word);
  ...
}

La c'est bon car l'exemple est tout petit mais j'imagine mal dans une bonne grosse classe utilitaire contenant des methodes tres longues, un debutant arriver a trouver les types corrects de word et freq ; il faut quand meme remonter a la declaration map pour les en deduire... (une prochaine question piege pour les entretiens d'embauche et les examens de DEUG/license d'informatique ?).

Passe encore si cette syntaxe n'etait utilisee que pour les operateurs new et foreach mais, l'appel a :

Code :

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

freq := map.get(word);

suggere qu'on aurai plus besoin d'indiquer le type des valeurs retournees par une methode. C'est vrai que d'un cote ca fait (un peu mais pas beaucoup) moins de code a taper, mais deja qu'on a des gens pas f$%#$ de lire la documentation des methodes et classes qu'ils utilisent... ca promet en nouvelles questions absurdes en tout genre... et en prises de tetes (des deux parties) pour arriver a comprendre les codes fournis ou ceux qu'on donnera en solution...

[sinok]

Passe encore si cette syntaxe n'etait utilisee que pour les operateurs new et foreach mais, l'appel a :

Code :

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

freq := map.get(word);

suggere qu'on aurai plus besoin d'indiquer le type des valeurs retournees par une methode. C'est vrai que d'un cote ca fait (un peu mais pas beaucoup) moins de code a taper, mais deja qu'on a des gens pas f$%#$ de lire la documentation des methodes et classes qu'ils utilisent... ca promet en nouvelles questions absurdes en tout genre... et en prises de tetes (des deux parties) pour arriver a comprendre les codes fournis ou ceux qu'on donnera en solution...

Mouaip, mais le temps qu'ils comprennent qu'il faut utiliser les dernières versions de java on est tranquile pour un moment (sans parler du jour où ce sera enseigné dans les écoles ^^)

Enfin coté javaOne ce qui m'intéresse le plus au final pour le moment, c'est la promesse d'un temps de hargement de la JVM éventuellement réduit en passant par la Consumer JRE.

Bon ensuite j'ai pas eu le temps de tout suivre, mais l'appli semi web créée par l'équipe de Swingx avait l'air sympa (bon ensuite à utiliser les applets c'est toujours aussi lourd, vivement que çà change).

Enfin ce que j'attends avant tout ce sont les slides et vidéos des différentes sessions, c'est là qu'il y a le plus à apprendre, découvrir et ainsi de suite...
De ce point de vue là javaOne est une des principales mines d'infos, et à mon sens c'en est le plus intéressant (plutôt que les déclaration clinquantes à la javaFX, les closures et ainsi de suite).


Donc les slides, les slides, les slides

[adiGuba]

Autant je ne suis pas d'accord avec vous sur les closures (c'est un "must-have" à mon avis ), autant je dois dire que ces "short instance creation" ne me branche guère...

En fait je me contenterais largement de la proposition de bouye (supprimer les Generics lorsqu'ils sont identique) :

Code :

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

Map<String, Integer> map = new HashMap();

a++

[deltree]

mon passé sur des technologies concurrentes me pousse à proposer une instantiation-déclaration tout en un:

Code :

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

1
2
 
new HashMap<String, Integer>() map ;

Certes on ne type pas en Map, mais on n'écrit qu'une seule fois HashMap, et on évite la création d'un nouveau keyword ":=" au langage Java.

Quand à l'appel de freq := map.get(word);
je ne le trouve pas nécessaire non plus, étant donnée que les IDE sont capable des déclarer la variable du bon type tout seul.

[christopheJ]

Donc les slides, les slides, les slides

Voir sur mon blog pour les liens

Autant je ne suis pas d'accord avec vous sur les closures (c'est un "must-have" à mon avis ),

La présentation de Neal Gafter sur les closures commence avec un truc du genre :

Dans 30 ans on rigolera des gens voulant faire une langage sans closures, comme on rigole maintenant des gens voulant faire un langage sans récursivité

[sinok]

Voir sur mon blog pour les liens

M'suis déjà fait plaisir, j'ai attaqué par la partie desktop cet aprem (bon au taf ça va pas franchement vite pour lire des slides, donc pas franchement sympa) et ce soir

[gifffftane]

Je signale qu'au niveau des génériques, le problème d'avoir à répéter 50 fois le paramètre n'est qu'un problème d'API ; on peut parfaitement l'éviter (je veux dire le résoudre), du moins dans les classes génériques que l'on crée soit même ; le HashMap est donc mal fait, c'est tout.

Ainsi, pour une classe générique Gener<T> donnée, on peut parfaitement écrire :

Code :

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

1
2
3
4
5
6
7
8
9
 
  public void toto()
  {
    Gener<String> gen1;
    Gener<Integer> gen2;
 
    gen1 = Gener.nouvelle();
    gen2 = Gener.nouvelle();
  }

... vous voyez que je ne donne qu'une fois le type paramètre.

Et voici la méthode nouvelle dans la classe Gener<T> :

Code :

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

1
2
3
4
5
 
  public static <P> Gener<P> nouvelle()
  {
    return new Gener<P>();
  }

... vous voyez qu'elle reste parfaitement... générique.

Bon, certes, on peut chipoter de ce que je re-écris trois fois le terme <P>...

[Baptiste Wicht]

Voir sur mon blog pour les liens

Erf... Ils ont enlevé les slides pendant la nuit

[remika]

En attendant : http://www.mediafire.com/?bn4mbzksdgt

[adiGuba]

En attendant : http://www.mediafire.com/?bn4mbzksdgt

Il ne s'agit pas d'une présentation de JavaOne, mais de St Louis Code Camp (mais cela n'enlève rien à sont intérêt )

Au passage l'auteur maintient une page recensant les propositions de Java 7 : http://tech.puredanger.com/java7

a++

[remika]

Effectivement

Pas très réveillé moi ce matin...

[Baptiste Wicht]

En attendant : http://www.mediafire.com/?bn4mbzksdgt

Bien que n'ayant rien à voir avec JavaOne, ca reste très intéressant

Très intéressant aussi ton site Adiguba