Dans le premier article de cette série, nous avons vu comment la JVM optimise notre code. Ici, intéressons nous à la manière dont la mémoire est gérée et aux différents Garbage Collectors.

L’hypothèse générationnelle

Toute la gestion de la mémoire opérée par la JVM se base sur une hypothèse générationnelle, résumée par la phrase "la plupart des objets meurent jeunes" ou encore "La plupart des objets créés deviennent très rapidement inaccessibles".

L’idée derrière cette hypothèse est que les applications créent de nombreux objets pour leur fonctionnement, mais que seule une faible partie d’entre eux a une longue durée de vie. Ainsi, les différentes étapes d’un traitement génèrent beaucoup d’objets transitoires mais une seule donnée finale.

Le graphique suivant résume la quantité d’objets créés par une application en fonction de leur âge.

Note : un objet est considéré comme toujours en vie s’il existe un autre objet vivant qui le référence.

Lire la suite de cet article »

Origines

Depuis 1996, Java et la JVM ont envahi nos équipements pour devenir des éléments incontournables de notre quotidien. Avant de s’intéresser aux détails et aux forces de la JVM, il est important de comprendre la relation entre le langage Java et cette dernière.

Au démarrage, Java se voulait un langage multi-plateformes, principalement guidé par le principe WORA : "Write Once, Run Anywhere". La JVM ne comportait qu’un nombre limité d’optimisations par rapport à aujourd’hui, et Java était critiqué à raison pour sa lenteur. C’est en 2000 que le langage a bénéficié d’un second souffle avec l’intégration de Hotspot dans la JVM 1.3.

La technologie Hotspot, quant à elle, est motivée par une toute autre problématique : concevoir une technologie qui maintienne l’aspect multi-plateformes de Java tout en profitant des optimisations de chaque machine (type de CPU, architecture matérielle).

Java est le langage dans lequel nous développons nos applications, Hotspot est le support par lequel nos applications sont de plus en plus optimisées à chaque nouvelle version de la JVM.

Lire la suite de cet article »

De la touche "F5" aux frameworks de tests

Les tests unitaires sont aujourd’hui une norme dans le développement des applications Java. L’amplification des techniques Agiles et du mouvement Software Craftsmanship ont poussé à mettre les tests unitaires comme prérequis au développement d’applications.
 
Concernant le développement d’applications front en javascript, les tests se limitent souvent à une vérification manuelle du comportement attendu sur le navigateur. La touche “F5” et les “alert” en sont les principaux outils. Qui n’a pas passé des heures à rafraîchir sa page et à regarder les messages d’alertes pour comprendre le changement de comportement d’un module lors d’une modification du code ?
 
Ceci entraîne une perte de temps énorme, la confiance envers son code lorgnant vers 0 ainsi qu’une maintenance qui devient quasiment impossible.
 
Heureusement, au fil du temps les navigateurs ont sorti des outils permettant de faciliter les tests du code tels que Firebug pour Firefox ou le puissant outil de développement présent dans Chrome (je n’ai malheureusement pas encore utilisé les outils IE).  Ces outils sont d’une aide inestimable mais les tests sont toujours fait manuellement.
Des frameworks de tests unitaires pour Javascript existent pourtant depuis plus de 10 ans. L’apparition de Node.js et de frameworks de développement front en javascript (Angular, Backbone, Ember…) ont fait passer le javascript dans une dimension supérieure et permettent aujourd’hui le développement partiel ou total d’applications dans ce langage. Ce développement impose de facto l’utilisation de tests (unitaires, d’intégration…).
 
Nous allons voir dans cet article la logique des tests unitaires en javascript pur afin de mieux appréhender le fonctionnement des frameworks de tests automatisés tel que Jasmine, mocha ou QUnit. Nous montrerons d’ailleurs une version de ces tests avec QUnit afin de commencer à voir les possibilités que peuvent nous offrir ces frameworks.

Lire la suite de cet article »

Parmi les bonnes résolutions pour l’année 2013, le site web de Xebia s’est refait une beauté. Ce nouveau site reflète l’image de Xebia : épuré, décalé mais surtout… no bullshit.

Le plus simple est d’y jeter un oeil et de laisser vos commentaires. Ça se passe ici.

La plateforme Java EE conserve de nos jours encore une mauvaise réputation. Les fameux EJB 2 et conteneurs lourds démarrant en plusieurs minutes vous rappelleront quelques bons souvenirs. L’arrivée de Spring a ouvert la voie aux conteneurs légers, à l’inversion de contrôle, ou encore à l’injection de dépendances; et est devenue la solution de référence. Cependant, la plateforme Java EE a beaucoup évolué entre temps.

Nous allons voir que Java EE 6 n’a maintenant rien à envier à Spring. Cette plateforme est devenue légère et simple à prendre en main. Toutes les spécifications ne seront pas abordées en détails.  Nous parlerons plutôt de conteneurs légers et testables, de managed beans, d’EJB Lite, ainsi que des nombreux services et patterns offert par la plateforme.  Nous terminerons par la spécification CDI et ses extensions portables, qui offrent de belles perspectives à la plateforme Java EE 6.

Lire la suite de cet article »

Pour cette avant-dernière session de la conférence, l’incontournable Joshua Bloch remplit comme à son habitude la grande salle de Devoxx. Il nous présente aujourd’hui une rétrospective des meilleures et des pires fonctionnalités ajoutées au fil des versions de Java. Sa critique est objective et sans détours, d’autant qu’il a participé de près ou de loin à bon nombre des sujets abordés.

Lire la suite de cet article »

En Java EE, on parle souvent de clustering de serveurs d’application pour évoquer la mise en relation d’un certain nombre de serveurs.

On parle également de failover pour parler de la capacité à rendre l’indisponibilité d’un ou de plusieurs serveurs du cluster complètement transparente vis à vis du client; cela se traduit par le fait de garantir au client la reprise du même contexte d’exécution qui existait en amont de l’apparition de la panne du serveur incriminé.

Glassfish V3, l’implémentation de référence de JEE6 (JSR 316), inclut à partir de sa version 3.1 des nouvelles fonctionnalités de clustering (synchronisation lors du démarrage d’une nouvelle instance, réplication des changements dynamiques de configuration,…), et offre également un mécanisme de réplication de la session http et des EJB statefull.

Au cours de cet article nous aborderons la mise en place d’un cluster glassfish, la configuration Apache avec le plugin Glassfish Load Balancer et le test du failover à travers une application web.

Il faut noter que toutes les étapes d’installation et de configuration peuvent être réalisées en mode console ou en mode GUI (à travers la console d’administration Glassfish). L’approche console (ligne de commande) a été adoptée.

Lire la suite de cet article »

Voilà 11 ans que Roy Fielding a introduit REST, le style d’architecture original du web appliqué aux échanges inter-applications. Reposant sur HTTP, il promet économie, simplicité et profit des structures réseau en place. Voyons comment l’implémenter via un client JavaScript — présenté dans un article connexe — communiquant avec un serveur Java — présenté ici –. Le code clé-en-main est disponible sur GitHub.

Une fois déployée, la servlet Jersey mappe l’url /resource/* ; la partie cliente est disponible sur /index.html. Le web.xml définit deux filtres Jersey afin de loguer les trames HTTP des échanges client-serveur.

Lire la suite de cet article »

Dans un précédant article, nous avons vu les lambda expressions et comment elles allaient apparaître dans Java 8 — l’idée étant d’orienter Java vers un style plus fonctionnel. Mais pour parfaire l’intégration de ce style de programmation dans Java, Brian Goetz indique qu’il faudra modifier l’API Collection pour y ajouter des fonctions telles que filter, map ou fold. Afin de faciliter la mise en place de telles fonctions au sein de l’API Collection, Brian Goetz propose d’intégrer les méthodes virtuelles d’extension (virtual extension method) dans le langage.

Dans cet article, nous allons voir ce que sont les méthodes virtuelles d’extension, comment est-ce que Java résout le lien entre ces méthodes et leur implémentation, et comment est traité le cas du diamant (un problème classique en programmation objet). Puis nous comparerons les méthodes virtuelles d’extension avec une autre approche plus ou moins similaire utilisée dans d’autres langages : les mixins.

Lire la suite de cet article »

Durant cet été, l’actuel architecte de Java auprès d’Oracle, Brian Goetz, a fourni des informations intéressantes sur l’implémentation des lambda expressions dans le futur Java 8 et de ses conséquences sur le langage. Par lambda expression comprenez ici closure ou fonction anonyme, qu’il est possible de stocker dans une variable ou de retourner depuis une méthode ou depuis une autre fonction, et bien sûr d’appeler. L’intégration des lambda expressions se fait dans le cadre de la JSR 335 (JSR 335: Lambda Expressions for the JavaTM Programming Language), aussi appelé Lambda Project.

Du point vue d’Oracle, la stratégie donnée à Brian est celle-ci :

Oracle’s position is that Java must evolve – carefully, of course – in order to remain competitive. (« La position d’Oracle est que Java doit évoluer – prudemment, bien sûr – afin de rester compétitif. »)

À partir de quoi, Brian propose :

It is my belief that the best direction for evolving Java is to encourage a more functional style of programming. (« Je suis convaincu que la meilleure orientation pour l’évolution de Java est d’encourager un style de programmation plus fonctionnel. »)

Nous allons voir dans cet article, l’état des actuelles propositions faites pour étendre le langage Java vers un style fonctionnel.

Lire la suite de cet article »