MilamberSpace » Java

JMeter : Pourquoi exécuter son test de charges en mode non-gui (sans interface graphique) ?

Milamber — Sun, 01 Feb 2009 09:55:32 +0000

JMeter dispose de deux modes de fonctionnement, un mode GUI et un non-GUI, « GUI » signifiant Graphical User Interface, c’est-à-dire un mode de fonctionnement avec une interface graphique utilisateur qui permet de créer, éditer un script et lancer un test de charges et autres choses. Le mode non-GUI ne permet pas de manipuler un script, mais simplement de lancer le script de test de charges.

Pourquoi ce mode non-GUI ? Parce qu’en mode GUI, JMeter peut être gêné par la gestion du ‘graphisme‘ pendant qu’il est en train d’exécuter un test de charges. Et cela peut avoir un impact sur la qualité des résultats du tir.

En effet, sur le poste JMeter, la gestion du mode graphique impacte :

Le processeur. JMeter doit traiter deux choses : le test de charges (envoi des requêtes, réception des réponses, éventuellement écriture dans un fichier, etc.) et l’affichage des résultats dans les récepteurs (listeners) ainsi que d’éventuels calculs statistiques (total, moyenne, etc.). La puissance du processeur est donc découpée en deux tâches principales : la gestion du tir et la gestion de l’affichage.
La mémoire. Certains récepteurs comme celui de l’arbre de résultats ou celui de tableau de résultats, sont extrêmement gourmands en mémoire, en effet, pour chaque test d’échantillon, il faut ajouter un petit ‘chouia‘ dans la mémoire. Or quand son test de charge génère de très nombreuses requêtes, le petit chouia devient énorme, ce qui peut même faire des OutOfMemoryError du côté JMeter si on ne prends pas soin d’augmenter la taille de mémoire maximale de la JVM de JMeter (au niveau du script de lancement).

Et pour couronner le tout, la machine virtuelle Java (qui je le rappelle, exécute JMeter), aura parfois besoin de faire passer le garbage collector (GC) pour la gestion de la mémoire, ce qui a un impact sur le traitement des résultats, le GC gelant les threads (donc le tir et le traitement des résultat) lors de l’identification des objets à supprimer de la mémoire.

Ces points montrent que le mode GUI est plutôt à proscrire lors d’un test de charge aussi simple soit-il, car on risque d’avoir des résultats erronés en termes de calcul de temps de réponses, par JMeter lui-même, ce dernier est perturbé par la gestion de l’affichage des résultats de manière graphique, et par le fonctionnement de la JVM au niveau la gestion de la mémoire si le nombre de requêtes/réponses devient très important.

Donc pour résumé, le mode GUI est plutôt à utiliser pour créer et maintenir ses scripts JMeter et lancer des tir de charges « blancs » permettant de vérifier la bonne exécution d’un scénario. Le mode non-GUI est à utiliser pour l’exécution du test de charge « officiel ».

Un petit conseil pour finir : si vous avez une machine JMeter avec un processeur multi-core (dual core), il est préférable d’utiliser une machine virtuelle Java dernière version (6), car la gestion des processeurs (core) y est bien plus optimale que la version 5 (sans parler de la 1.4). Avec une JVM 6, JMeter et tous ses petits threads vont utiliser l’ensemble des CPU disponibles sur le poste de test JMeter.

Utilisation de NDC de Apache Log4J pour tracer et suivre l’exécution d’une application Java

Milamber — Tue, 15 Jan 2008 20:46:38 +0000

Un fonctionnalité pratique du framework de logging Apache Log4J est le NDC (pour Nested Diagnostic Contexts). Ce dernier permet de tracer et suivre plusieurs instances d’un même traitement dans un seul fichier de log. Une utilisation typique est le fichier de log d’une application web s’exécutant sur un serveur d’applications, car plusieurs instances d’une même servlet (et de plusieurs servlets) s’exécutent en même temps pour servir les utilisateurs.

La fonctionnalité permet donc de mieux comprendre le déroulement d’un traitement, en particulier lors qu’un problème survient lors d’un tir de charges ou sur un environnement en production. Et imaginons que ce problème ‘ne se reproduit pas’ en environnement de recette / développement, et donc l’origine pourrait être ces accès multiples en même temps…

Un développeur seul sur sa machine génère que un seul log séquentiel, mais avec de multiples utilisateurs, le log devient un enchevêtrement de plusieurs traitements séquentiels.

Voici un exemple de log applicatif pendant un tir de charges :

[2008-01-15 20:31:50,750][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,755][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@1ba287e
[2008-01-15 20:31:50,757][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,758][DEBUG] (JndiJdbcTableView.java:62) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,758][DEBUG] (JndiJdbcTableView.java:64) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,759][DEBUG] (JndiJdbcTableView.java:78) - doGet() - end
[2008-01-15 20:31:50,768][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet() - start
[2008-01-15 20:31:50,769][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet() - Ok connexion
[2008-01-15 20:31:50,769][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,770][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,775][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@1d2f8be
[2008-01-15 20:31:50,776][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,777][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,777][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,775][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,778][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,778][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,780][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,780][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,780][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,783][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet() - end
[2008-01-15 20:31:50,784][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => com.mysql.jdbc.ResultSet@10de02d
[2008-01-15 20:31:50,786][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,786][DEBUG] (DirectJdbcTableView.java:66) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,787][DEBUG] (DirectJdbcTableView.java:68) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,788][DEBUG] (DirectJdbcTableView.java:85) - doGet() - end
[2008-01-15 20:31:50,789][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => com.mysql.jdbc.ResultSet@172c403
[2008-01-15 20:31:50,786][INFO ] (DirectJdbcTableView.java:60) - doGet() - Ok connexion
[2008-01-15 20:31:50,791][DEBUG] (DirectJdbcTableView.java:64) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,791][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,792][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet() - start
[2008-01-15 20:31:50,792][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet() - Ok connexion
[2008-01-15 20:31:50,793][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet() - Appel Boxers => bdSelectAll
[2008-01-15 20:31:50,793][DEBUG] (DaoBoxers.java:24) - bdSelectAll() - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:31:50,794][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list
[2008-01-15 20:31:50,794][DEBUG] (DirectJdbcTableView.java:66) - doGet() - Mise en attribut resultat
[2008-01-15 20:31:50,795][DEBUG] (DirectJdbcTableView.java:68) - doGet() - Renvoi vers JSP
[2008-01-15 20:31:50,796][DEBUG] (DirectJdbcTableView.java:85) - doGet() - end
[2008-01-15 20:31:50,798][DEBUG] (DaoBoxers.java:27) - bdSelectAll() - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@695586
[2008-01-15 20:31:50,799][DEBUG] (DaoBoxers.java:36) - bdSelectAll() - Retour list

La fonctionnalité NDC ajoute la possibilité d’avoir un « identifiant » de traitement, par exemple le nombre de secondes depuis le 1er janvier 1970. Ainsi le log devient un enchevêtrement de traitements séquentiels identifiés.
Et voici un exemple de log applicatif avec NDC :

[2008-01-15 20:07:55,920][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675911) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@19e907
[2008-01-15 20:07:55,921][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675911) - Retour list
[2008-01-15 20:07:55,922][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675911) - Mise en attribut resultat
[2008-01-15 20:07:55,922][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675911) - Renvoi vers JSP
[2008-01-15 20:07:55,924][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675917) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@93a96c
[2008-01-15 20:07:55,925][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675917) - Retour list
[2008-01-15 20:07:55,926][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675917) - Mise en attribut resultat
[2008-01-15 20:07:55,926][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675917) - Renvoi vers JSP
[2008-01-15 20:07:55,927][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675911) - end
[2008-01-15 20:07:55,929][DEBUG] (DirectJdbcTableView.java:49) - doGet(1200427675929) - start
[2008-01-15 20:07:55,931][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675917) - end
[2008-01-15 20:07:55,934][DEBUG] (DirectJdbcInInitTableView.java:49) - doGet(1200427675934) - start
[2008-01-15 20:07:55,938][DEBUG] (JndiJdbcWithValidationTableView.java:48) - doGet(1200427675938) - start
[2008-01-15 20:07:55,938][INFO ] (JndiJdbcWithValidationTableView.java:56) - doGet(1200427675938) - Ok connexion
[2008-01-15 20:07:55,939][DEBUG] (JndiJdbcWithValidationTableView.java:60) - doGet(1200427675938) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,941][DEBUG] (net.milamberspace.dao.DaoBoxers.java:24) - bdSelectAll(1200427675938) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,941][INFO ] (DirectJdbcTableView.java:60) - doGet(1200427675929) - Ok connexion
[2008-01-15 20:07:55,942][DEBUG] (DirectJdbcTableView.java:64) - doGet(1200427675929) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,942][DEBUG] (DaoBoxers.java:24) - bdSelectAll(1200427675929) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,947][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675938) - ResultSet ok => org.apache.tomcat.dbcp.dbcp.DelegatingResultSet@17dde01
[2008-01-15 20:07:55,948][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675938) - Retour list
[2008-01-15 20:07:55,949][DEBUG] (JndiJdbcWithValidationTableView.java:62) - doGet(1200427675938) - Mise en attribut resultat
[2008-01-15 20:07:55,949][DEBUG] (JndiJdbcWithValidationTableView.java:64) - doGet(1200427675938) - Renvoi vers JSP
[2008-01-15 20:07:55,950][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675929) - ResultSet ok => com.mysql.jdbc.ResultSet@7a3c6c
[2008-01-15 20:07:55,952][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675929) - Retour list
[2008-01-15 20:07:55,952][DEBUG] (DirectJdbcTableView.java:66) - doGet(1200427675929) - Mise en attribut resultat
[2008-01-15 20:07:55,952][DEBUG] (DirectJdbcTableView.java:68) - doGet(1200427675929) - Renvoi vers JSP
[2008-01-15 20:07:55,954][DEBUG] (DirectJdbcTableView.java:85) - doGet(1200427675929) - end
[2008-01-15 20:07:55,956][INFO ] (DirectJdbcInInitTableView.java:57) - doGet(1200427675934) - Ok connexion
[2008-01-15 20:07:55,956][DEBUG] (DirectJdbcInInitTableView.java:61) - doGet(1200427675934) - Appel Boxers => bdSelectAll
[2008-01-15 20:07:55,957][DEBUG] (DaoBoxers.java:24) - bdSelectAll(1200427675934) - SQL => SELECT ID, PRENOM, NOM FROM BOXERS
[2008-01-15 20:07:55,958][DEBUG] (JndiJdbcWithValidationTableView.java:78) - doGet(1200427675938) - end
[2008-01-15 20:07:55,961][DEBUG] (DaoBoxers.java:27) - bdSelectAll(1200427675934) - ResultSet ok => com.mysql.jdbc.ResultSet@283198
[2008-01-15 20:07:55,963][DEBUG] (DaoBoxers.java:36) - bdSelectAll(1200427675934) - Retour list

Cela permet une lecture plus facile des logs (la couleur n’est pas incluse ), dès lors que l’on sait utiliser la commande grep sous Unix en faisant quelques petits grep sur l’identifiant. (par exemple : grep 1200426850018 mon_log.txt)

Comme faire pour utiliser NDC ? Et bien tout d’abord dans le fichier de configuration de Log4J, le fameux log4j.properties. Il faut ajouter la balise « %x » dans le ConversionPattern, celle-ci sera remplacée par l’identifiant unique défini lors de l’utilisation de NDC.

Exemple de fichier log4j.properties

log4j.rootLogger=DEBUG, LOG1
log4j.appender.LOG1=org.apache.log4j.ConsoleAppender
log4j.appender.LOG1.layout=org.apache.log4j.PatternLayout
log4j.appender.LOG1.layout.ConversionPattern=[%d][%-5p] (%C.java:%L) - %M(%x) - %m%n

Au niveau du code source Java, on utilisera deux méthodes de la classe statique NDC.

NDC.push(String ID) qui permet de poser un identifiant
NDC.pop() qui permet de dépiler le dernier identifiant posé

Voici un exemple simple d’utilisation pour une servlet, avec ici, l’utilisation de « new Date().getTime() » comme identifiant :

protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
 NDC.push(String.valueOf(new Date().getTime()));
 logger.debug("start");
 Connection connection = null;
 try {
 	connection = getDataSource().getConnection();
 	logger.info("Ok connexion");
	DaoBoxers dao = new DaoBoxers();
 	dao.setConnection(connection);
 	ArrayList list = dao.bdSelectAll();
 	request.setAttribute("beanListeBoxer", list);
 	this.getServletContext().getRequestDispatcher("/tableview.jsp").forward(request, response);
 } catch (Exception e) {
 	logger.error(e);
 	throw new ServletException(e.getMessage());
 } finally {
 	try {
 		connection.close();
 	} catch (SQLException sqle) {
 		logger.error(sqle);
 	}
 	logger.debug("end");
 	NDC.pop();
 }
}

Bien entendu, les appels à logger.xxxx() dans les méthodes du DAO vont également bénéficier de l’identifiant NDC.

Espérons que ce billet vous sera utile.

La page de manuel de Log4J.

SAP Memory Analyzer : voilà un vrai outil pour analyser des Heap Dump Java !

Milamber — Sun, 14 Oct 2007 16:51:38 +0000

Vous avez développé une application JEE, et depuis son passage en production au moins une fois par jour il y a une erreur Java « OutOfMemoryError ». La première réaction a été de dire : mauvaise configuration de la taille maximale de la JVM… vous avez préconisé 1Go de Max Heap Size, cela n’a pas fonctionné, l’erreur OOME arrive encore… Alors on est passé à 2Go… Toujours l’erreur d’OOME… Aie, et que faire…

Quand vous êtes à ce point, vous pouvez être certain que vous avez une fuite de mémoire (memory leaks) quelque part. Oh, ce n’est pas que vous êtes un mauvais développeur et que vous ne savez pas bien gerer la mémoire, en effet, parfois un problème de fuite de mémoire peut survenir à cause d’une fonctionnalité activée du serveur d’applications de production et qui rentre en « conflit » avec une brique de l’application. (Je citerai un exemple vécu : le cache (activé) JDBC de la source de données WebSphere 5.1 et un framework maison de mapping O/R)

Quand on a un problème d’OutOfMemory, on commence souvent par activer le mode verbeux du Garbage Collector (GC), c’est une très bonne idée, cela permet d’avoir une petite idée sur le déroulement du problème de mémoire (on peut utiliser l’outil Extensible Verbose Toolkit d’IBM pour ce travail, cf références). Cependant c’est insuffisant pour trouver la cause du problème. Quelques recherches sur Internet vous apprennent qu’il est possible d’avoir une image de la mémoire Java avec la génération d’un « heap dump », ensuite il suffit de l’analyser pour trouver la cause de la fuite de mémoire. Facile à écrire, mais dur à faire…

Commençons par la génération du heap dump. La bonne nouvelle, c’est que depuis les versions Java 1.4.2 update 12, Java 5 update 07 et Java 6, la génération de heap dump est « devenu » facile. Pour avoir un heap dump automatique dès que vous avez une erreur OOME, il faut simplement ajouter ce paramètre -XX:+HeapDumpOnOutOfMemoryError dans les arguments de la JVM. La mauvaise nouvelle, c’est que pour les versions antérieures, c’est plus difficile d’obtenir un heap dump. Cela dépend de l’éditeur de la JVM que vous utilisez (IBM, BEA, Sun, HP, etc), il faut se reporter sur le site de l’éditeur pour trouvez la bonne recette…

Une fois que l’on a trouvé le bon paramètre pour générer son heap dump, il ne reste plus qu’à le mettre en production et attendre l’erreur fatal d’OOME. Quand celle-ci arrive, on attend la génération du fichier qui peut prendre plusieurs minutes car le fichier aura la taille de la JVM au moment de l’erreur. Donc si la taille maximum est à 1Go, le fichier va faire 1Go.

Maintenant que l’on a son fichier heap dump, il faut l’analyser…et là aussi c’est pas simple. Il existe différents moyens, allant du mode texte (via Hprof) vers des outils tels que Heap Analyzer de IBM ou bien HAT (ou JHAT maintenant) de Sun. Le gros problème de ses outils, c’est que c’est quasiment impossible d’ouvrir un heap dump d’1Go avec. Vous avez un OutOfMemoryError de l’outil

La bonne nouvelle c’est que l’éditeur SAP a pensé à nous, à travers son outil d’analyse Memory Analyzer. Ce dernier est basé sur l’environnement RCP d’Eclipse. Il ouvre sans difficulté un heap dump de 1Go, car il analyse le fichier heap dump petit à petit et en créant ses propres fichiers d’index. (Il faut compter environ 1h30 pour ouvrir un fichier 1,2Go sur un portable Vista avec 2Go de RAM, Core 2 Duo 2GHz)

Memory Analyzer dispose de nombreuses fonctionnalités, dont l’une qui va nous intéresser particulièrement : la détection de fuite de mémoire (find memory leaks). De plus il dispose de tutoriaux pour aider à l’analyse de fichier heap dump.

Voici quelques captures d’écran qui en diront plus que mes longs discours :

Détails d’un heap dump.

Histogramme, détails par classe : nombre d’objets, taille la plus petite de l’objet, taille des objets

Inspector pour avoir le détail et le contenu d’un objet

La détection de fuite de mémoire, ici un objet détient à lui tout seul 657 Mo sur 1024 Mo ! Cela sent le memory leaks…

Analyse de la fuite mémoire, la cause ici semble être une liste HashMap de + de 490000 objets.

[Quelques pointeurs]

Sortie de Eclipse Europa

Milamber — Mon, 09 Jul 2007 09:12:12 +0000

La Fondation Eclipse vient de sortir Eclipse Europa. Il s’agit de la mise à jour synchronisée de 21 projets permettant ainsi d’assurer une compatibilité entre les sous-projets d’Eclipse et le socle. Europa désigne donc plus qu’Eclipse et plusieurs déclinaisons d’Europa sont proposées :

Chaque déclinaison est composée d’outils adaptés à l’environnement ciblé. Il reste bien sûr possible de faire sa propre déclinaison en téléchargeant individuellement les modules via le mécanisme de mise à jour livré dans Eclipse (socle).

Pour la version qui nous concerne « le plus », la version pour les développeurs JEE, on trouvera Eclipse 3.3 et le projet Web Tools (WTP) 2.0. Incluant notamment un éditeur graphique HTML / JSP / JSF, le support de Java EE version 5, le module Mylyn qui permet de faire du travail collaboratif au niveau de l’équipe de développement, etc.

Au niveau des Web Tools, quelques captures d’écran en disent plus qu’un long discours. Pour les nouveautés sur les JSP cliquer ici, le HTML ici et plus généralement sur l’éditeur syntaxique ici. Concernant le support des environnements d’exécution des applications JEE (autrement dit les « serveurs d’applications ») voir ici. Pour compléter les Web Tools, on trouvera le module des WebServices ici, et l’ajout d’un module Dali JPA pour Java Persistence API qui simplifie le mapping objet/relationnel pour les EJB 3.0.

Parmi les autres projets on remarquera : BIRT qui permet de faire du décisionnel avec la création de rapport / tableau de bord / graphiques à la manière de Crystal Report. TPTP pour le profiling de code Java, et les tests de performances d’une application Java.

Eclipse Europa ne révolutionne pas bien entendu, la plus part des modules évoqués ci-dessus se trouvaient déjà dans Callisto (le nom de la dernière livraison synchronisée). Mais Europa apporte son lot d’améliorations de l’environnement de développement (cf. les captures d’écrans) et important, le support de Vista.

Pas de risques donc à migrer vers cette nouvelle version de cet outil devenu le socle d’un très grand nombre d’environnements de développement.

[Quelques pointeurs]

Dossier Eclipse

Milamber — Mon, 16 Apr 2007 19:14:44 +0000

Eclipse devient incontournable, personne ne dira le contraire. Même Microsoft ! en effet, la revue ‘Redmond Developer news’, destinée aux utilisateurs des produits Microsoft, a publié cet éditorial qui met en avant le fait que l’utilisation d’Eclipse dépasse largement le monde Java et donc que des outils basés sur Eclipse pourraient être de plus en plus utilisés dans le cadre de développements en technologies Microsoft.

L’éditorial: ‘Pay Attention to Eclipse’
Et en réponse, 01net nous propose un dossier Eclipse :
Eclipse, la plate-forme à tout faire

Introduction
- Développer en Java rime souvent avec plate-forme Eclipse. Mais la fondation open source initiée par IBM, sert à créer toutes sortes de logiciels.
Un moyen de fédérer la communauté Java
- La plate-forme open source Eclipse est devenue, dans la communauté Java, quasi incontournable. Notamment en matière de développement logiciel. Même si la couverture fonctionnelle de son concurrent, Netbeans, reste à la hauteur.
De l’environnement de développement à la plate-forme
- En quelques années, IBM a transformé Eclipse IDE en une plate-forme de développement et d’intégration de logiciels ouverte à plus de 150 partenaires. L’émergence d’une vraie alternative à Microsoft ?
Une usine à logiciels bâtie sur la méritocratie
- Fondé en fin 2001 pour créer une alternative à Visual Studio de Microsoft, le consortium Eclipse a su se muer en véritable plate-forme de mutualisation, sous l’aspect d’une fondation à but non lucratif.

Sortie de Java 6

Milamber — Mon, 25 Dec 2006 09:18:19 +0000

Et hop, quelques jours après l’annonce du passage en licence open source de Java, une nouvelle version voit le jour. Contrairement à ce l’on pourrait penser, il ne s’agit de la version 5 de Java + la licence open source = version 6. Cette dernière est le fruit de deux années de travail des membres du JCP.

Pour un petit rappel historique : la version 1.0 est sortie en 1996, la 1.1 en 1997, la 1.2 en 1998, la 1.3 en 2000, la 1.4 en 2002 et la version 1.5 (renommé 5.0) en 2004. Donc deux ans après on trouve la version 1.6 (6.0).

Qu’apporte cette nouvelle version ? De meilleures performances (de 5 à 24% selon le contexte, plus performante que la version 5 de Java), une meilleure supervision de la JVM grâce à l’utilisation de l’API JMX (Java Management Extension), le support de langages tiers comme le JavaScript, l’intégration de Java DB et le support des Web Services (déjà intégré dans le J2EE seulement).

[Quelques pointeurs]