Nous vous proposons aujourd’hui la troisième d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulerons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.

Cette vidéo traite des numéros :

• 06 : Utilisation impropre des caches
• 05 : Utilisation excessive de la mémoire

Nous vous proposons aujourd’hui la deuxième d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulerons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.

Cette vidéo traite des numéros :

• 08 : Usage incorrect de Java EE
• 07 : Utilisation abusive du XML

Nous vous proposons aujourd’hui la première d’une série de cinq vidéos consacrées aux problèmes de performances des applications java / J2EE.
Nous y déroulerons le top 10 des problèmes de performances en environnement java / J2EE en les illustrant par des cas concrets et en proposant pour chacun des mesures permettant de s’en prémunir.

Cette vidéo traite des numéros :

• 10 : Logging excessif
• 09 : Mauvaise configuration du serveur d’application

Le débat autour de l’introduction des closures dans le langage Java fait rage – avec toute la mesure et l’absence de pédanterie dont sait faire preuve notre profession sur ce type de sujet. Selon toute vraisemblance, les closures seront l’une des fonctionnalités phare de Java 7. Reste à savoir sous quelle forme.
Deux écoles ont émergé sur le sujet : la première, désignée BGGA (du nom de ses auteurs et promoteurs, Gilad Bracha, Neal Gafter, James Gosling et Peter von der Ahe), propose une extension syntaxique relativement complexe mais permettant d’introduire dans le langage tous les idiomes nécessaires à un support des closures similaire à celui disponible dans Ruby ou Smalltalk : function types, free variables, blocks, etc. ; la seconde désignée par l’acronyme CICE (pour Concise Inner Class Expressions) et soutenue par Joshua Bloch, Doug Lea et « Crazy Bob » Lee, propose plus modestement une simplification de la syntaxe java dans le but de désinhiber l’usage des Inner Class en lieu et place des closures.
L’occasion de faire ici un point sur ces deux approches et d’apporter, sinon une pierre à l’ouvrage, du moins des éclaircissements sur les termes du débat.
Lire la suite de cet article »

Vous avez sûrement déjà , au moins une fois, en parcourant les sources d’un logiciel open source été impressionné par la qualité formelle du code : nommage efficace et pertinent, choix judicieux des paquets et de leur hiérarchie, émergence des concepts au travers de la structure, javadoc riche et dénuée de fautes d’orthographe… même si j’embellis un peu le tableau pour les besoins du propos, on oublierait pour un peu qu’il s’agit du même language que celui utilisé pour développer ce logiciel de gestion aux sources cryptiques dont vous avez hérité la maintenance. En fait, le code source de certains projets open source évoque fortement les fiches bristol que les filles confectionnaient au lycée pour simplifier leurs révisions, vous vous souvenez ? Ces précieuses fiches dont, pour tout dire, vous vous moquiez un peu, mais qui rendaient limpides les cours du semestre précédent quand vous même n’arriviez plus à relire vos propres notes. Jamais vu un garçon faire des fiches bristol bariolées. C’est un truc génétique, je crois, une séquence codante dans la branche manquante du chromosome Y, qui interdit aux mâles l’usage de l’encre turquoise et celle de la règle pour souligner les titres.
Lire la suite de cet article »

Ce billet est le premier d’une série décrivant les principes et composants du « Java Operations Toolkit ». JOT est un projet encore embryonnaire (je le publierai bientôt sous license Open Source, et sous un autre nom, JOT étant déjà pris… Si certains parmi vous ont une idée…). Son objectif est d’offrir aux applications java un ensemble d’utilitaires, d’API et de bonne pratiques visant à en faciliter l’exploitation.

Comme son titre le suggère, ce premier billet concerne la journalisation, connue également sous son sobriquet anglo-saxon de « log ».
Depuis plusieurs années maintenant, l’utilisation d’un framework dédié pour gérer les logs s’est généralisée. Log4j a ouvert la voie, suivi par framework java.util.logging à partir du JDK 1.4, qui adopte une architecture très similaire à celle de log4j, tout en proposant une nomenclature moins intuitive (du moins pour ceux qui pensent que « DEBUG » désigne un niveau de journalisation plus évident que « FINEST »). Citons également les meta-frameworks Commons Logging et SLF4J, qui offrent une couche d’adaptation au dessus des différents frameworks pour en unifier l’usage.

L’objet ici n’est pas de comparer ces différentes solutions : elles sont toutes très proches et offrent toutes les fonctionnalités attendues d’un utilitaire de logging:

• une API simple et intuitive, style log.debug(message) ou log.info(message)
• une configuration externalisée permettant d’activer ou de désactiver certaines traces sans intervention sur les sources ou les binaires
• la possibilité de configurer des flux de sortie divers pour les messages (console, fichiers avec rotation, sockets, base de données, JMS, syslog, NTEventLog, etc.), avec une granularité très fine
• la possibilité de configurer le format des messages

On ne peut que se féliciter de l’adoption massive de ces frameworks, en particulier du plus illustre d’entre eux, log4j. Cette adoption a pourtant bien souvent un revers: disposer de ces fonctionnalités a exempté les architectes et développeurs d’une réflexion réelle sur l’usage des logs. La politique de journalisation se réduit fréquemment à cette simple directive : « Utiliser log4j », et le code est en conséquence saupoudré plus ou moins densément (selon l’humeur ou la sensibilité du développeur) d’instructions du style

Lire la suite de cet article »