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.

[vbrabant]

-Java Modularity/Java Kernel : j'en pense pas grand chose et je trouve l'idée ridicule (cf discussion sur la distribution du JDK par le passe). En quoi les gens trouvent difficile de télécharger 7~15Mo de nos jours quand on peut trouver des téléchargements de démos de jeu ou de logiciels de DAO/bureautique qui dépassent les 500Mo~1Go... De plus dans le pays ou Internet est moins développer, mieux vaut tout télécharger en une seule fois sur un poste et distribuer l'intégralité de la distrib sur CD sur les autres plutôt que de devoir télécharger/streamer à chaque fois sur chacun des postes.

De mon points de vie, la notion de modularité est uniquement interressante pour la mise a jour du JRE, et encore à nouveau uniquement dans un environnement connecté 100% du temps au Net (et via un débit rapide).

Je crois que tu es passé à coté de certaines choses. La raison d'être de Java Modularity/Java Kernel est surtout de réduire le temps de lancement de l'application en ne chargeant que le strict nécessaire. Tous les PC n'ont pas Java installé.

Exemple (réel) que tu peux rencontrer aujourd'hui: tu as la JVM installée en locale. Et tu va sur le site de la sncb pour regarder les trajets entre Bruxelles et Paris. Tu choisis d'avoir le calendrier pour choisir la date d'aller. Et là, tout se bloque, car c'est une applette Java, et qu'il faut lancer la JVM, et télécharger le petit jar pour le calendrier. Si Java était modulaire, il ne faudrait charger que 2mo en mémoire, et pas 15Mo ou 30Mo.
Mais ca, c'est dans le cas où tu as déjà la JVM installée en local.
Maintenant, imagine que tu n'as pas la JVM installée en local. Tu vas sur le même site, et l'applet se met en route. Comme il n'y a pas de JVM installée, il va commencer à l'installer pour toi. 2Mo, au lieu de 15Mo. Soit 2 secondes au lieux de 15 secondes si tu as une connection rapide à 8Mbits/sec. Et la prochaine fois que tu reviens sur ce site, c'est instantané. Plus de téléchargement.
Puis, tu découvres Glossitope, http://glossitope.org/site/. Pour le coeur de Glossitope, il te faut quasi rien. Peut-être 2Mo, peut-être 4Mo. Pas plus.
Et puis, tu commences à installer différents widgets pour glossitope. Et plus ces widgets sont complexes, plus tu télécharges avec des modules du JRE.
Jusqu'au jour où finalement tu auras, sans t'en rendre compte, un JRE installé complètement sur ton pc.
Mais, tu continueras à n'avoir en mémoire, selon l'application lancée, que le strict nécessaire.
Et ca, c'est super avantageux. non ?
Cette histoire de Java Kernel/JavaModularité va, je pense, redonner vie aux applets, et peut-être même aux applications de style JavaWebStart pour le consommateur final. Et puis, cette histoire de Java Kernel/Modularité, c'est la clé du succès pour JavaFX. JavaFX sans le Kernel/Modularité, est, à mon sens , voué à l'échec.

Un autre avantage, est que tu pourrais également distribuer ton application avec Java. En ne mettant que le stricte nécessaire de Java pour ton application, et pas tout ce qui serait superflu, réduisant la taille de ton application au niveau du Disque, mais aussi au niveau mémoire.

Vincent

[bouye]

Attention le message suivant contient du Flash

Je crois que tu es passé à coté de certaines choses. La raison d'être de Java Modularity/Java Kernel est surtout de réduire le temps de lancement de l'application en ne chargeant que le strict nécessaire. Tous les PC n'ont pas Java installé.

[...]

Ah oui c'est le cote attrayant de la chose. Et si au final on a qq chose qui se charge plus vite (suivez mon regard... Flash) tout en permettant a l'utilisateur de trouver Java "cool" (...Flash) alors ca redorera son blason cote client (...Flash), surtout pour ce qui est de l'utilisation web (...Flash). Quoique dans l’application de la chose, c’est tout bon pour le JSE (Flash, Flash, Flash), je doute franchement qu’un administrateur JEE se laisse aller à activer une telle fonctionnalité de mise à jour sur laquelle il n’a aucun contrôle et côté JME… hum, faut pas rêver... ca reste trop limité aux possibilités de la platforme physique - je ne crois pas que mon téléphone supporterait une mise à jour constante de sa VM indéfiniment et il manquera de place assez rapidement pour installer des tonnes et des tonnes de libs supplémentaires. Non, la cible visée semble bien plus être le desktop web qu'autre chose. Pas même le desktop bureautique.

Mais je crains qu'au contraire tu n'ais pas saisi le contexte d'utilisation que je mentionne c'est à dire le monde "réel/actuel" hors des zones hyper-connectées que sont l'Amérique du Nord, l'Europe, le Japon, la Corée et les grandes-villes de part la planète ; bref, le reste du monde. Mais il est vrai que je faisais référence à des discussions/réflexions passées où j’expliquais peut-être mieux ce contexte.

Bref dans le monde "réel", aussi surnommé "trier-monde informatique" on n’a pas de gros débits, on n’est pas connecté 24h/24, on n’a pas de larges zones couvertes par des bornes Wifi en accès libre via les transports ou les gares et parfois on n’a même pas l'électricité ni le téléphone 24h/24. Hors on se propose de modulariser la distribution du JRE à un point tel qu'il faudra être connecté pour pouvoir utiliser du Java. S'il existe quelques part des distribution complètes tout reste Ok, et il me semble qu'adiGuba (ou Gfx je ne sais plus) avait bien indiqué dans une discussion passée qu'il était question de mettre en place des repository des extensions les plus utilisées, voir des grosse distributions comme cela se fait pour Linux (cf c'était une discussion ou je me plaignais de la volonté de retirer Java Sound du JRE, le premier effet direct de la modularisation du JRE, et de la difficulté de trouver les Java extensions sur le site officiel, sans compter du manque d'uniformité de leur format et de leur procédure d'installation).

Mais dans le cas ou le streaming devient le chemin obligatoire pour utiliser Java, ca va faire grincer pas mal de dents, dans ma zone par exemple, le Pacifique (mais ca marche aussi pour l'Afrique, l'Asie, etc...). Jusqu'à présent Java était une technologie intéressante/sexy pour tout pays en voie de développement de par son faible coût (cout minimal = paye du développeur, outils de devel gratuit, redistribution gratuite), la richesse de l’API (qui n’est pas liée a un OS particulier contrairement à .NET (oui je sais que Mono existe)), sa facilite de déploiement (on télécharge un JRE contenant tout ce qu'il faut, parfois une ou deux extensions et c'est bon, on le met sur un CD et on peut le redistribuer/dupliquer, etc...). Or là d’un coup on change la donne et il faudra que l’ordinateur client ait accès à Internet, etc…

Bon bref ca c’est le scénario exagéré/vue du côté négatif bien sur, j’attends de voir la mise en œuvre et bien sur même dans nos pays des progrès en connectique et dans les infrastructures de communication ont lieu régulièrement (quoiqu’à leur propre rythme) et donc sur le (très) long terme c’est probablement la voie à suivre.

[lunatix]

je pense que tu n'as pas saisi. Le jre va continuer a etre distribué en entier. par contre, si en passant sur le net, tu tombes sur une applet, et que tu n'as pas encore installé java, le consumer jre entre en jeu, 2mo de download rapidos, et paf ca demarre.

[bouye]

J'avais pourtant pense avoir mis suffisement de "si" et de "dans le cas ou" pour que ca indique bien les suppositions .

Par contre attendons un peu la mise en oeuvre avant d'etre aussi categorique.

[gifffftane]

Java a dès le départ été conçu pour le web, particulièrement pour les applets, et cela n'a jamais marché, (du moins pour les applets).

À mon avis, c'est parce que Sun a toujours voulu parier sur les gros débits. Pourquoi se mettrait-il à parier aujourd'hui sur les bas débits - ou même seulement sur la config de tout le monde ?

Je ne vois rien dans les évolutions de java qui montre concrètement un tel engagement ; seul, peut être, le fait que Java Web Start soit devenu, bien tard, une techno utilisable par CD.

Pour l'instant au niveau de ces configs légères nous en sommes seulement aux effets d'annonce.

Il y a Java Me, qui pourrait indiquer que Sun veut gagner dans les configs pauvres. Mais dans ce domaine il est difficile de dire que le "write once, run partout" a été respecté. L'enjeu de Java Me est surtout de mettre en valeur les portables haut de gamme, à mon opinion.

J'admets qu'il me semble que Java - et Sun en général - commence à réussir sur le Desktop, et que cela peut entraîner des changement philosophiques de fond. On verra.

[Killing Joke]

Les property sont une bonne chose, mais la syntaxe choisie laisse à désirer.
J'aurais aimé une syntaxe aussi souple que celle disponible ... en Pascal Objet !

Ex. avec Getter / Setter implicite (qu'on n'a pas à écrire) :

Code :

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

public property int maPropriété read maPropriétéInterne write maPropriétéInterne;

Ex. de propriété externe en lecture seule :

Code :

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

1
2
 
public property int maPropriété read maPropriétéInterne;

Ex. où l'on surcharge le setter :

Code :

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

1
2
 
public property int MaPropriété read maPropriétéInterne write setMaPropriétéInterne;

avec bien sûr plus loin alors :

Code :

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

1
2
3
4
5
6
 
private int maPropriétéInterne;
public void setMaPropriétéInterne(int propriete) {
    log.debug("Ca y est on assigne maPropriete avec <" + propriete + ">");
    this.maPaPropriétéInterne = propriete;
}