Espace de discussion autour de la disponibilité de Mustang (Java SE 6) [Nouveauté]

**Ricky81** · 11/12/2006, 22h02

Bonsoir,

comme annoncé par adiGuba, la plateforme Java SE 6 (alias Mustang) est désormais disponible en version finale !

Vous pouvez profiter de ce sujet pour échanger sur le contenu de cette release et discuter des nouveautés et tendances, partagez des liens, ...

Un premier article résumant les principales nouveautés de Mustang : http://adiguba.developpez.com/tutoriels/java/6/

Le site officiel : http://java.sun.com/javase/6/

**adiGuba** · 12/12/2006, 10h03

Salut,

Un petit article qui met en évidence les performances "Out of the Box", c'est à dire les performances sans aucun tuning ou configuration spécifique : Java 6 Leads Out of the Box Server Performance.

Selon les tests, on obtient des gains de performance de 20 à 40% par rapport au JDK 5.0...

a++

**themei** · 12/12/2006, 11h01

A ce rythme là, bientot Java sera aussi perfs que du C++.

**adiGuba** · 12/12/2006, 11h24

Envoyé par themei

A ce rythme là, bientot Java sera aussi perfs que du C++.

C'est déjà le cas depuis longtemps, par exemple : Java vs C++ "Shootout" Revisited

Bien sûr cela peut varier selon les tests, mais globalement on peut dire que les performances de Java sont au moins aussi bonne que du C++. Et la JVM server permet des optimisations impossibles en C++ (optimisation à la volée à l'exécution, selon le contexte de l'application).

Toutefois, les différences sont imperceptibles dans une application standard, mais seulement sur de gros traitements répétitifs...

Java se traine une mauvaise réputation qui date de ses origines (avant Java 1.2 et les JVM HotSpot).

Toutefois, il est vrai qu'elle souffre de 2 défaut (a mon avis) :

Le temps de démarrage de la JVM, qui est généralement plus lent qu'une application natif, en particulier pour de petites applications (mais que l'on peut désormais combler par un SplashScreen avec Java 6 ).
Swing, qui est vraiment une API merveilleuse, mais qui est trop souvent mal-employé, en particulier ce qui concerne la gestion de l'affichage dans l'EDT. Bien souvent il est utilisé pour des traitements "lourds" qui empêchent la mise à jour de l'affichage (et le fameux bugs du "rectangle-gris").
Ceci est en partie corrigé par Java 6 car le double-buffering de Swing empêche désormais les "rectangles-gris", et la classe SwingWorker permet de mieux gérer les traitements dans une UI Swing...
Ce n'est corrigé qu'en partie car l'origine du problème est bien le développeur et non pas l'API ou le langage (lire Threads et performance avec Swing pour plus de détail).

Or il y a souvent amalgames entre les deux et ce type de bugs (malheureusement courant) est souvent imputé au langage et non pas au développeur...

a++

**mavina** · 12/12/2006, 13h13

Salut,

Très interressant tout ça, je m'en vais de ce pas faire mumuse avec

Fred

**Babaôrom** · 12/12/2006, 13h31

D'ailleurs, quelqu'un saurait-il comment s'utilisera la classe SwingWorker qui (si je ne dis pas de bêtises) est sensée résoudre le problème des traitements longs vis à vis de l'interface graphique?

**adiGuba** · 12/12/2006, 13h59

Envoyé par Babaôrom

D'ailleurs, quelqu'un saurait-il comment s'utilisera la classe SwingWorker qui (si je ne dis pas de bêtises) est sensée résoudre le problème des traitements longs vis à vis de l'interface graphique?

Très simplement, et de manière assez proche d'un Thread (mais tout en permettant plus de chose).

Il suffit d'en hériter et de redéfinir la méthode doInBackground() qui devra contenir le code a exécuter en arrière plan (et seulement lui : donc aucun code qui ne modifie l'affichage).
Il est également possible de redéfinir done() qui sera appelé dans l'EDT à la fin du traitement (par exemple pour mettre à jour l'affichage).
Enfin, il est également possible de redéfinir la méthode process() qui permet de mettre à jours l'affichage en cours de traitement. (dans doInBackground() on effectue le traitement et on passe le résultat à la méthode publish() qui se chargera d'appeler process() dans l'EDT).

Je ne sais pas si je suis bien clair... mais il n'y a rien de très difficile...

A noter qu'une version identique pour Java 5.0 existe déjà ( https://swingworker.dev.java.net/ ), et qu'une vielle version quelque peu différente est disponible dans les tutoriels de Sun depuis l'origine de Swing (ou presque).

a++

**lunatix** · 12/12/2006, 14h27

le tutoriel de Sun sur java a été mis a jour... et on y trouve une partie sur swingworker

**knoum** · 12/12/2006, 18h44

Je viens juste de l'installer et même si cela est trop tôt pour donner un avis je ne peux m'empêcher de dire que je suis épaté par la réactivité au niveau de l'IDE (NB) et des petites applications que j'ai développé sous Eclipse et sous NetBeans 5.5 (mon préféré).

EDIT: (à mon niveau d'utilisation primaire

) une petite bombe.

**adiGuba** · 15/12/2006, 15h51

Java SE 6 est-il vraiment plus rapide ? Réponse

Is Java SE 1.6.0 Faster?

a++

**Baptiste Wicht** · 15/12/2006, 16h34

Envoyé par adiGuba

Java SE 6 est-il vraiment plus rapide ? Réponse

Is Java SE 1.6.0 Faster?

a++

Très intéressant ton lien, merci

**narmataru** · 15/12/2006, 18h13

Je viens juste de l'essayer et bien je ne sais pas si c'est le double buffering ou autre chose, mais l'interface graphique parrait beaucoup plus réactive ! Coté gain de performance j'ai fais un test très vite fait (qui a dit mal fait ?) et je n'ai pas détecté de différence notable avec la versin 5 :
10000 insertion dans derby :
java 5 : 10855ms
java 6 : 10655ms

Et j'ai cette erreur au démarrage de mon appli :

ATTENTION: Prefs file removed in background /usr/local/lib/java/jdk1.6.0/jre/.systemPrefs/rie/riesystemcheck/modules/maj/prefs.xml
MESSAGE - Premier lancement de RIESystemCheck version 20061205
ERROR - Erreur lors de l'enregistrement de la nouvelle version dans les préférences (erreur de mon appli).
SYSTEM::java.lang.IllegalArgumentException: Non pris en charge : indent-number
java.util.prefs.BackingStoreException: java.lang.IllegalArgumentException: Non pris en charge : indent-number
at java.util.prefs.FileSystemPreferences$8.run(FileSystemPreferences.java:615)
at java.security.AccessController.doPrivileged(Native Method)
at java.util.prefs.FileSystemPreferences.writeBackCache(FileSystemPreferences.java:600)

Ca doit pas être bien méchant, mais c'est bizarre car je n'utilise pas du code extraordinaire :

Code :

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

1
2
3
4
5
6
7
8
9
10
private void saveLastVersion(BigInteger b){
		Preferences pref = Preferences.systemNodeForPackage(this.getClass());
		pref.put(prefKeyVers, b.toString());
		try{
			pref.flush();
		}
		catch(Exception e){
			EasyLog.getInstance().error("Erreur lors de l'enregistrement de la nouvelle version dans les préférences.", e);
		}
	}

**ptr83** · 20/12/2006, 16h36

Je risque de dire quelque chose de vraimment idiot mais bon je tente tout de même...

Y a t il moyen de passer à Java SE 6 en utilisant Websphere 6.0.1 d'IBM? En fait je pense que j'en suis toujours au J2SE 1.4.2

...

**Ulhume** · 22/12/2006, 10h38

Envoyé par themei

A ce rythme là, bientot Java sera aussi perfs que du C++.

Assez d'accord avec adiGuba. Ceci dit je nuancerais en disant que les performances de Java sont aujourd'hui quasi équivalentes à du Natif. "non-optimisé" Si l'on prends l'exemple de Java vs GCC, un même code obtient peu ou prou les mêmes performances depuis le mêmes performances qu'un Java v5 et est surpassé par Java v6. Ce qui tend à prouver que la natif ne gagne pas si facilement aujourd'hui sur du Java. Une autre "preuve" (mais là je suis peut-être incompétent... ) c'est que GCJ, censé compiler du Java en Natif, ne dépasse pas lui non plus la moindre version de d'un VM standard.

En revanche, si l'on applique une optimisation (type -O3), les performances d'un code natif se font bien meilleur mais est-ce parce que les développeurs de GCC sont meilleurs en optimisation que ceux de javac ?

Je me suis fait un petit benchmark maison (en grande partie repiqué ceci dit ;-) pour tester les différentes version de JDK mais aussi Java vs Mono et vs GCC pour ceux que cela intéressent : http://artisan.karma-lab.net/node/1112 (c'est d'ailleurs en faisant des recherches sur d'autres benchmarks que je suis tombé ici ;-)

Ceci dit, ces benchs ne sont pas encore assez complet à mon goût, j'aurais besoin d'y rajouter une performance de threads, et surtout l'occupation CPU car s'il s'avère que du natif est aussi rapide que du Java mais avec 50% de charge en moins, cela remet pas mal de choses en cause.

Un autre aspect est effectivement le temps de chargement. Les tests de mon bench les ignore car les timings sont pris dans le code lui même (après chargement donc). Il faudrait que je rajoute des tests pour évaluer les différences de temps de chargement mais je me heurte au cache disque qu'il faudrait désactiver pour avoir un peu de justesse (quelqu'un sait t-il faire cela sous Linux ? )

Voilà, si vous avez des remarques sur mes tests où si vous constatez d'énormes boulettes, je suis preneur bien évidemment :-)

**narmataru** · 22/12/2006, 10h49

Lorsque je clique surton lien j'ai cette erreur :

Firefox ne peut trouver le serveur à l'adresse antinea.artisan.karma-lab.intra.

**jlassiramzy** · 22/12/2006, 10h50

dois je donc laisser tomber le jdk1.5.0_06 et opter pour jdk 1.6 pour ma prochaine application un peu complexe qui se base entierement sur swing ?

**mavina** · 22/12/2006, 13h14

Je me suis ammusé à faire des tests sommaires, sur un exemple tout simple :
une double boucle de 1000 itérations et une création de String dedans. Rien de plus bête

J'ai pu constater que Java 6 gagnait entre 20 et 40% de vitesse d'execution par rapport à Java 5.
Faut voire sur d'autres tests moins "primaires" mais ça fait déjà plaisir

Fred

**Ulhume** · 22/12/2006, 14h44

Envoyé par narmataru

Lorsque je clique surton lien j'ai cette erreur :

Quel gros malin je fait, c'était l'adresse locale... J'ai édité le post avec la bonne url :
http://artisan.karma-lab.net/node/1112

Sinon, j'ai aussi rajouté les fameux temps de chargement vu que j'ai trouvé (enfin !) le moyen de vider le cache en lecture fs de Linux. Et bien pour être honnête c'est pas très brillant. Sur la machine de test, aucune différence de Java 4 à Java 6, inlassablement à 1 seconde, contre 0.5 avec Mono...

Sinon, pour mon idée de l'occupation CPU variable d'un test à l'autre, c'est faux, 100% à chaque fois.

**Ulhume** · 22/12/2006, 16h59

Envoyé par mavina

Je me suis ammusé à faire des tests sommaires, sur un exemple tout simple :
une double boucle de 1000 itérations et une création de String dedans. Rien de plus bête

J'ai pu constater que Java 6 gagnait entre 20 et 40% de vitesse d'execution par rapport à Java 5.
Faut voire sur d'autres tests moins "primaires" mais ça fait déjà plaisir

Fred

Logique, y'a un facteur 2 rien que sur les StringBuffer

**joho** · 22/12/2006, 17h47

Envoyé par jlassiramzy

dois je donc laisser tomber le jdk1.5.0_06 et opter pour jdk 1.6 pour ma prochaine application un peu complexe qui se base entierement sur swing ?

Tout dépend pourquoi, pour qui etc...
A moins d'utiliser Java web start/JNLP ton programme peut ne pas fonctionner, (peu de gens on déja installé la jre6 [peu de gens ont déja installé la jre1.4 .... beaucoup n'ont jamains installé de jre])
Si les fonctionalités de la jre6 (ou les performances) te sont a ce point importantes pour ton programme, (ou si tu en as super envie parce que c'est cool

)alors oui fais des programmes en java6.

Espace de discussion autour de la disponibilité de Mustang (Java SE 6) [Nouveauté]

Langage Java

Discussions similaires

Partager

Partager