DES REX ET DEVOXX — 1er épisode

Il s’agit de vous évoquer, dans cette première partie, les retours d’expérience de notre Dream Team Carbon IT présente dans ce lieu de Devoxxion de la technique avec gourous d’un autre temps, prêcheurs du futur et magiciens du code.

Voici donc un petit état des lieux des retours d’expérience au sujet de l’écosystème Java

Hibernate et Elasticsearch

Hibernate et Elasticsearch sont sur un bateau, par Emmanuel Bernard @emmanuelbernard & David Pilato @dadoonet

David & Emmanuel, coiffés de leur plus beau couvre-chef, nous rejouent leur plus belle scène du « dis donc, c’est compliqué de faire marcher Elasticsearch avec Hibernate ». Bon, c’est vrai qu’ils sont meilleurs développeurs qu’acteurs ces deux là, on va pas se mentir !

Mais quiconque a du un jour utiliser Hibernate et ES ensemble comprend où les speakers veulent en venir : entité vers JSON, gestion des transactions et/ des rollbacks, schéma et analyzer, JSON vers entité…

Heureusement, Hibernate Search va nous sauver ! En se pluggant sur les events de l’ORM, et grâce à quelques lignes de conf et annotations, il apporte la solution aux problèmes précédemment cités. On pourra en outre utiliser la QueryDSL d’ES, ou une DSL spécifique Hibernate

Cela dit, comme c’est encore en version alpha, on va encore attendre quelques mois.

High-Performance Hibernate (ou benchmark empirique) @vlad_mihalcea

Intro

⇒ Constat : 50 % des problèmes de performance sont dus à la base de données

T = tacq + tdal + treq + texec + tres + tidle

Acq : acquisition

Dal : Data Access Logique

Req : Requète

Exec : Execution

Res : Resultat (fetching)

Idle : Release

Bonne pratique pour la conf :

⇒ Configuration de ReleaseMode

After Transaction meilleur que After Statement

⇒ ID Generator et Seq Generator

Équivalent niveau performance mais meilleurs que TableRow

⇒ Ne pas mettre un Batch_insert à 1 (ça semblait logique).

Il conseille de mettre 10 sachant qu’au dessus de ce nombre, les performances affichées sont équivalentes.

⇒ En terme de cascading et batching, utiliser la configuration

order_insert=true

order_update=true

⇒ Si possible, ne mettre que les champs utiles dans la requête.

Par exemple

select nom, prénom from personne

plutôt que

select * from personne

⇒ DTO vs Entities

Préférer les Entities quand il y a besoin de sauvegarder les éléments.

Préférer les DTO pour la lecture.

Autre sujet Java :

Performance: Java vous déclare sa flamme : Présentation de l’outil FlameGraph, permettant le profilage d’application sous Linux, MacOS, Windows, etc. Il existe un script dédié pour le profilage d’application Java.

OutOfMemoryException :

Quel est le coût des objets en Java ?, par Jean-Philippe Bempel @jpbempel

Dans ce talk, Jean-Philippe nous fait un tour initiatique des impacts du code sur la mémoire de notre bonne vieille JVM, nous montre comment traquer les potentielles fuites mémoire et nous donne quelques pistes/solutions pour éviter le fatidique OutOfMemoryException.

Un objet, au sens java, est avant tout de la mémoire allouée. Que cela soit un simple char ou un objet complexe, il y a de la mémoire qui est prise dès que l’objet est instancié.

Pour un objet, la JVM attribue de la mémoire pour :

• L’entête (contenant des métadatas de l’instance de cet objet)
• Les champs
• L’alignement (lié à l’adressage sur 8-bit)

Quelques chiffres nous sont ensuite présentés :

• ArrayList prendra 440 bytes
• LinkedList : 2432 bytes
• ConcurrentHashMap : 4047 bytes

Il conseille ainsi d’utiliser des objets adaptés aux besoins et de toujours mesurer l’impact de leurs utilisations : “La mesure et non la démesure”.

Par la suite, le speaker nous présente des outils pour traquer les fuites mémoire sans entrer trop dans le détail, simplement quelques retours de ses différentes expériences.

Enfin, Jean-Philippe termine le talk avec quelques tips pour lutter contre le surcoût en mémoire dont :

• Flyweight pattern & Initializer Pattern
• ArrayList plutôt que LinkedList

Jhipster

JHipster en 2016 par Julien Dubois @juliendubois

Après avoir fait un rapide tour de l’activité Open Source de JHipster, il nous a monté une architecture en microservice d’une boutique e-commerce. La démonstration est clairement impressionnante car JHipster permet de bootstrapper l’ensemble extrêmement rapidement et facilement.

JOOQ

Lukas Eder @lukaseder est venu nous présenter JOOQ, un framework qui se démarque du classique JDBC (trop verbeux et surtout offrant trop de possibilité d’introduire des bugs voire des failles de sécurité) et d’Hibernate/JPA (utilisant massivement les annotations et donc un grand niveau d’indirection par rapport à SQL). JOOQ est un DSL qui permet d’écrire en SQL directement en Java (ou Scala). Cela permet d’accéder directement à toute la puissance du langage SQL et de la base de données associée. Le fait que cela soit intégré directement au langage offre l’auto-complétion, la sécurité du typage mais surtout vous aide à écrire du SQL.

Autres sujets :

Guillaume Laforge @glaforge nous a fait une large revue des bonnes pratiques dans le design d’API REST : format des URL, gestion des relations, codes retour adaptés, ou encore approche HAL.

Dans le prochain article, nous vous évoquerons les retours d’expérience en ce qui concerne les langages alternatifs

Big KISS à tous !