LinuxFr.org : les dépêches de Java

Sortie de Datafari 6.2, moteur de recherche open source pour entreprise avec de l'IA

2025-06-15T09:19:21+02:00

Nous (NdM: France Labs qui porte datafari.com) sommes fiers de vous annoncer la mise à disposition de Datafari 6.2

Pour faire court, la grosse nouveauté vient de l’intégration simplifiée des outils tiers d’IA générative. Ces travaux ont été en partis financés par le projet Européen NGI Search Neural Datafari, qui a permi du coup également d'ajouter la recherche vectorielle bout en bout au projet Apache Solr.

Pour rappel, Datafari est une solution de recherche pour entreprise. Où que les connaissances se trouvent et sous quelque format que ce soit, elle permet aux employés de retrouver les données utiles.

Et désormais grâce à l’IA, de « discuter » avec ses connaissances. Plus concrètement, il s’agit de récupérer et d’indexer les données et documents depuis de nombreuses sources différentes et plusieurs formats de fichiers, et de permettre aussi de chercher des documents mais aussi d’utiliser une IA générative pour les questionner.

Pour cette dépêche, on se concentre sur la version libre et open source (mais il y a aussi d’autres nouveautés sur la version entreprise propriétaire).

lien nᵒ 1 : Page de téléchargement
lien nᵒ 2 : Accéder au code source
lien nᵒ 3 : Le forum de discussion
lien nᵒ 4 : La documentation
lien nᵒ 5 : Le site officiel
lien nᵒ 6 : Image Docker
lien nᵒ 7 : La précédente dépêche sur Datafari

Notre dernière dépêche datant de… Datafari 5.3, voici Les nouveautés et changements principaux par rapport à cette dernière:

Ajout d’un module RAG (Retrieval Augmented Generation)
Passage à Solr 9.8 avec recherche vectorielle
Ajout d’un module d’appel de LLM à l’indexation
Gestion automatique du chunking des documents indexés
Création d’un module autonome d’analytics au lieu de Zeppelin pour optimiser les ressources
Création d’un regex connector à l’indexation
Refonte technique de l’interface graphique, en React
Passage à la V2 des API REST de Datafari
Prototype d’agent autonome pour héberger en local un modèle d’IA
Du bugfix de partout

Comment démarrer ?

Pour voir à quoi ça ressemble, nous avons téléversé une courte vidéo de démonstration. Pour démarrer tout de suite, le mieux est d’aller lire le quick start guide. Nous mettons gratuitement à disposition notre documentation Datafari sur Confluence, qui couvre les usages, l’administration et le développement. Attention, les modules d’IA que nous avons développés, nécessitent la disponibilité d’un serveur exposant un modèle d’IA compatible. De base, Datafari n’héberge pas localement une IA. Le plus simple pour débuter est de le connecter par exemple à openAI pour se faire la main, et ensuite de passer à des modèles locaux hébergés par vos soins ou par des partenaires.

Pour rappel, voici les principales fonctionnalités de Datafari en tant que moteur de recherche :

Que peut‐on faire avec Datafari ?

Datafari est un moteur de recherche pour entreprise enrichi à l’IA : membres de la famille des outils de gestion des connaissances, les solutions de recherche fédèrent les connaissances en analysant et indexant tous les documents d’une organisation, aussi bien leur contenu que leurs métadonnées. Pour cela, le moteur de recherche doit être multi‐sources, multi‐formats, et gérer la sécurité. En outre, il faut permettre l’administration de l’outil.

Dans la version libre, on peut, côté admin :

Administrer les connecteurs aux sources de données vers de nombreuses sources (nous utilisons Apache ManifoldCF avec tous ses connecteurs) dont Sharepoint, Confluence, Alfresco et les partages de fichiers ;
Gérer l’algorithme de pertinence qui classe les documents pour leur affichage suite à une requête ;
Activer les modules de recherche vectorielle et de RAG
Mettre en avant des documents pour des requêtes identifiées ;
Créer des utilisateurs et leur assigner des rôles ;
Voir des statistiques d’usage de l’outil ;
Créer l’équivalent de Google AdWords (appelés promoliens) ;
Gérer des synonymes ;
Plein d’autres choses accessibles depuis la documentation Confluence.

Côté utilisateur, on peut :

Chercher de façon simple ou avancée ;
Prévisualiser les résultats ;
« Discuter » avec ses documents via le module RAG
Bénéficier de la correction orthographique et de l’auto‐complétion ;
Choisir et utiliser des facettes pour filtrer les résultats ;
Mettre des résultats dans un panier de favoris ;
Créer des alertes par courriel quand des documents modifiés ou nouveaux correspondent à une requête.

Et ensuite ?

Pour le reste de 2025, nous allons continuer à ajouter des fonctionnalités se basant sur les IA génératives pour multiplier les possibilités.

Des commentaires ?

Nous sommes en permanence à l’écoute des commentaires et suggestions pour faire avancer le produit, alors profitez-en, que ce soit d’un point de vue technique ou fonctionnel, ça nous intéresse. Ha et si vous êtes déjà un utilisateur, n’hésitez pas à en parler sur le web !

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Cassandre 6.0.0, un cadriciel pour développer votre propre « trading bot »

2022-06-01T10:03:28+02:00

Un automate ou robot de trading est un programme qui va automatiquement placer des ordres d’achats et de ventes sur des marchés de crypto-monnaies sans qu’un humain n’ait à intervenir.

Cassandre, développé en Java et proposé sous licence GPLv3, se présente comme un starter Spring Boot. Après l’avoir ajouté à votre projet et avoir créé une classe annotée, Cassandre se chargera de fournir automatiquement à votre classe les données du marché, les données sur vos comptes et vos ordres. Il vous permettra aussi de passer de nouveaux ordres et de créer des positions.

Cassandre propose aussi un mode qui permet de simuler le fonctionnement du bot avec des données historiques afin de valider vos stratégies.

Avec cette version 6, voici les principaux changements :

- Un site web en français ;
- Passage à Java 17 ;
- Migration de la base de données pour gérer correctement les UID/ID ;
- Nouvelle API GraphQL.

lien nᵒ 1 : Site web & documentation
lien nᵒ 2 : Sources
lien nᵒ 3 : Version 6.0.0

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Cassandre 4.0.0, un cadriciel pour développer votre propre « trading bot »

2021-02-27T10:13:19+01:00

Un automate ou robot (bot) de trading est un programme qui va automatiquement placer des ordres d’achats et de ventes sur des marchés de cryptomonnaie (ou des exchanges, dans notre cas) sans qu’un humain n’ait à intervenir.

Cassandre se présente comme un starter Spring Boot. Après l’avoir ajouté à votre projet et avoir créé une classe annotée, Cassandre va se charger de fournir automatiquement à votre classe les données du marché, les données sur vos comptes et vos ordres. Il vous permettra aussi de passer de nouveaux ordres et de créer des positions.

À partir de là, vous pourrez développer votre propre stratégie en utilisant les outils et méthodes de vos choix (analyse technique, apprentissage automatique, apprentissage profond…).

lien nᵒ 1 : Sources
lien nᵒ 2 : Documentation

Grâce à l’utilisation de XChange, nous prenons en charge de nombreux exchanges.

Dans cette version 4.0.0, nous avons ajouté :

utilisation de Liquidbase pour garantir une migration facile des prochaines versions ;
refactoring de la base de données pour y stocker l’ensemble des données (orders, trades, positions, strategies) et utiliser la base plutôt que la mémoire ;
ajout de Lomboz pour réduire le code ;
on peut désormais appeler les créations d’ordres et de positions depuis la stratégie sans passer par les services ;
documentation via Qase de tous les tests unitaires ;
ajout d’un objet CurrencyAmount pour gérer plus facilement (comparaison, ajout…) les montants en cryptomonnaies ;
réduction de la taille mémoire (tourne sans problème avec 512Mo de mémoire vive).

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Silverpeas 6.2 est sortie malgré le contexte pandémique

2021-02-01T22:21:18+01:00

L'année 2020 marque le début d'une période historique dont on se serait bien passée, celle d'une pandémie mondiale qui a ralenti voir paralysé les activités économiques, sociales et culturelle de nos sociétés dîtes modernes. L'épidémie a aussi forcé des entreprises à outrepasser leur frilosité, voire même certains de leurs a priori, et elles ont fini par mettre leurs équipes en télétravail. Ceci s'est particulièrement ressenti par un gain d'intérêt à Silverpeas qui est une plate-forme collaborative open-source qui facilite justement le travail collaboratif à distance entre les personnes et les équipes.

Pour rappel et pour faire simple, une plate-forme collaborative est un portail d'applications ou de composants qui propose des fonctionnalités de partage et de structuration de l'information, de la connaissance et des compétences, et de mises en relation des individus et des équipes. Bien sur, Silverpeas, comme pour tout autre outil collaboratif, ne fera pas que d'un coup les personnes ou les organisations collaborent parce que ceci est avant tout un état d'esprit et une façon de travailler. Mais il facilitera à chacun d'entre nous et à nos organisations la collaboration déjà existante et donnera les outils pour l'améliorer et l'étendre ; mais ceci restera toujours à la discrétion des individus.

lien nᵒ 1 : Site Web du projet
lien nᵒ 2 : Notes de version
lien nᵒ 3 : Image Docker
lien nᵒ 4 : Page d'installation de Silverpeas 6

Silverpeas est une plate-forme open-source (Affero GPL) écrite en Java au sein de laquelle un ou plusieurs espaces et sous-espaces de collaboration peuvent être définis. Ce sont dans ceux-ci que des composants fonctionnels (appelés applications dans Silverpeas) peuvent être activés (en une ou plusieurs instances). Chacun de ces composants évoluent plus ou moins indépendamment les uns des autres mais reposent tous sur un socle commun (appelé Silverpeas Core). La particularité de Silverpeas est d'être clé en main, c'est à dire d'être facilement installable (pour une application de cette envergure) et que tous les composants fonctionnels soient disponibles et facilement activables. Nous pouvons démarrer avec un jeu réduit de fonctionnalités qui répondent aux besoins et, au fur et à mesure de l'évolution de ceux-ci, en activer d'autres.

Silverpeas 6.0 est sortie fin janvier 2018, la version 6.1 en juin 2020, et la nouvelle version 6.2 fin janvier 2020.

Silverpeas 6.2 apporte son lot de corrections de bogues mais aussi des nouvelles fonctionnalités dont :

L'édition en ligne dans le navigateur et en simultanée (paramétrable par les éditeurs) de documents via une instance de LibreOffice Online (à mettre en place à côté). Jusqu'à présent l'édition en ligne se faisait par WebDAV via sa suite de bureautique préférée (MS-Office, LibreOffice, …). Cette dernière est bien sur toujours présent.
Restriction de la messagerie instantanée à un ou plusieurs groupes d'utilisateurs : en effet, selon leur topologie, il peut ne pas être pertinent d'activer la messagerie instantanée. Pour rappel, la messagerie instantanée repose sur JSXC et nécessite derrière un serveur XMPP eJabberd.
Désormais il est possible d'affiner les utilisateurs à afficher dans l'annuaire général mais aussi d'y inclure des contacts d'Annuaire de Contacts,
Possibilité d'avoir plusieurs agendas au sein d'une seule instance de l'application Calendrier et dont des agendas distants (synchronisation en lecture seule toutefois).
Dans une application Calendrier, les utilisateurs peuvent s'abonner à un agenda particulier pour y être informé de nouveaux événements ou des changements sur ceux-ci.
Amélioration du workflow de suivi des demandes dans l'application Formulaire en Ligne avec support de la mise en brouillon, de la validation successive, etc.

Les notes de version (cf lien) à destination des utilisateurs permettront une exhaustivité d'informations sur les nouveautés et fonctions de cette version 6.2

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Java 15 est sorti

2020-09-15T14:47:42+02:00

Ce 15 septembre 2020 sort Java 15. C’est l’occasion pour cette dépêche de revenir sur les nouveautés entre les blocs de texte et autres ramasse‑miettes. On en profite pour parler de quelques informations autour de Java (les vingt‑cinq ans de la plate‑forme, les nouveaux champions, etc).

lien nᵒ 1 : OpenJDK 15
lien nᵒ 2 : Quarkus 1.5

Sommaire

Java 15

Abandons

Avec ce nouveau rythme, Java s’autorise à supprimer des parties de la plate‑forme. Pour cette version :

le système d’exploitation Solaris et l’architecture SPARC, rendus obsolètes par la dernière version, ne sont plus pris en charge (JEP 381) — cocasse quand on connaît les débuts du langage ;
Nashorn, le moteur JavaScript inclus dans le JDK, a lui aussi été retiré (JEP 372), il était considéré comme obsolète depuis la version 11 sortie en septembre 2018 ;
ce n’est pas encore une suppression, mais RMI activation (et seulement RMI activation pas tout RMI) est rendu obsolète (JEP 385) ;
biased locking n’est plus activé par défaut (il faut ajouter l’option -XX:+UseBiasedLocking), elle est du même coup considérée obsolète (JEP 374).

Conséquences des retraits

Cas de la prise en charge SPARC/SOLARIS

Le JDK étant plutôt vaste, le retrait de la prise en charge d’une architecture a des conséquences à de très nombreux endroits allant des systèmes de construction, la sécurité, la génération du bytecode ou encore la génération d’IHM. La personne en charge de la JEP a donc fait le tour du propriétaire pour retirer tout ce qui devait l’être, comme on peut le voir sur la liste de diffusion. Les plus curieux pourront suivre les différents liens pour voir le mode de développement du JDK et les spécificités de chaque domaine. Au final, ce sont plus de 127 000 lignes qui ont été supprimées, ce qui ne représente que moins d’un pourcent du nombre total de lignes de code.

Cas de la gestion du JSON

Suite à la suppression du Nashorn JavaScript Engine, il est apparu que le JDK utilisait le JavaScript et par conséquent le JSON pour certaines fonctionnalités. Se pose alors la question d’une gestion native du JSON ou de laisser cette compétence à des bibliothèques tierces. Actuellement, rien n’est décidé et il y a deux directions possibles :

oui, mais sous quelle forme et quand ?
non pas pour éviter d’avoir quelque chose de mal foutu comme pour le XML ou encore le journalisation et se concentrer sur ce qui fait réellement la plus‑value du JDK.

Nouveautés

Ramasse‑miettes

Deux nouveaux ramasse‑miettes (garbage collectors — gc) sont disponibles en stable avec cette version :

Shenandoah

Shenandoah est un ramasse‑miettes qui vise à réduire les temps de pause. Pour atteindre cet objectif, il déplace les objets sans avoir à mettre en pause l’application. Il est aussi capable de mieux paralléliser le déplacement d’objet. Cela ne supprime pas totalement les pauses : elles sont encore nécessaires pour libérer la mémoire. Avec Shenandoah, la vérification des objets en vie et leur déplacement se fait sans pause, mais le nettoyage de la mémoire en réclame une. Comme il fait moins de choses pendant les pauses, elles sont plus courtes. L’activation se fait via l’option -XX:+UseShenandoahGC. Ce changement est décrit dans la JEP 379.

ZGC

ZGC se donne pour objectif d’avoir des temps de pause faibles, y compris sur de grands tas (heap) de l’ordre du téraoctet. Pour cela, il est capable de décharger les classes sans arrêter l’exécution. Tous les ramasse‑miettes actuels de Java effectuent du déchargement de classes, mais ils sont obligés de le faire uniquement durant le stop the world. ZGC a travaillé pour pouvoir faire cela en concurrence de l’application. Il semble que cela a eu des effets de bord positifs, notamment le temps de pause n’est dépendant que du nombre de fils d’exécution de l’application. Il s’agit de l’amélioration majeure, mais il y a eu bien d’autres travaux comme le fait de pouvoir rendre de la mémoire au système d’exploitation, la gestion de tas de 8 Mio jusqu’à 16 Tio. Actuellement, seuls Windows, macOS et GNU/Linux sur les architectures x86-64 et AArch64 sont pris en charge. Pour l’activer, c’est l’option -XX:+UseZGC. Ce changement est décrit dans la JEP 377.

C’est très bien mais, du coup, comment choisir entre Shenandoah, ZGC ou rester sur G1 ?

C’est une question bien complexe qui est évidemment très dépendante de l’application cible. Premièrement, G1, malgré le fait qu’il continue d’être amélioré, est très loin derrière ZGC et Shenandoah. Les objectifs de ces derniers sont assez similaires et ils sont tellement efficaces qu’on ne peut pas voir de différence entre eux quand ils sont comparés à G1… De mon avis personnel et de ce que j’en ai lu :

ZGC est fait pour être simple, il est moins configurable ;
Shenandoah est plus configurable et il offre des temps de pause plus prédictibles que ZGC.

Néanmoins, tout cela peut encore changer d’ici la sortie de Java 17 (en septembre 2021).

Blocs de texte

Les blocs de texte arrivent enfin en version définitive (JEP 378). Cette fonctionnalité a fait beaucoup parler d’elle depuis son introduction en Java 13. Il est donc maintenant possible de définir des chaînes de caractères multilignes comme ça :

String query = """
               SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"
               WHERE "CITY" = 'INDIANAPOLIS'
               ORDER BY "EMP_ID", "LAST_NAME";
               """;

Classes cachées

Cette nouveauté offre la possibilité aux cadriciels de générer des classes pour son propre usage qui ne seront pas accessibles de l’extérieur et ainsi de gérer la tambouille interne sans risque de fuite, notamment en utilisant la réflexion.

Java possède des classes internes, qui ne sont pas directement exposées au niveau de l’API, mais qui restent accessibles par réflexion. Ce n’est pas leur nom peu alléchant Unsafe qui empêche qu’elles soient largement utilisées par tout un tas de logiciels. Un des objectifs des développeurs du JDK est de faire en sorte que cette pratique cesse. Un article de Java Magazine en parle et il y a, bien sûr, la JEP 371 qui décrit cette évolution.

C’est donc une étape de plus sur la route de la suppression des classes de sun.misc.Unsafe.

Sous le capot

cette version inclut la prise en charge des signatures EdDSA (JEP 339) ;
l’API DatagramSocket bénéficie d’une réimplémentation (JEP 373).

En vrac

nouvelles méthodes pour obtenir une valeur absolue : JDK‑8241374 ;
ajout de Unicode 13 : JDK‑8239383 ;
mise à jour à la version 37 de la base Unicode CLDR pour améliorer l’internationalisation de vos logiciels ;
l’AppCDS gère désormais les lambdas, ce qui permet d’accélérer encore un peu le démarrage de la JVM ;
Les énumérations peuvent désormais contenir 4 103 constantes JDK‑8241798 !

Avant‑premières

Les fonctionnalités ci‑dessous sont considérées comme en avant‑première (preview), elles sont sujettes à changement d’une version à l’autre.

Filtrage par motif avec instanceof

La filtrage par motif (pattern matching) sur instanceof (JEP 383) permet de discriminer un objet selon sa classe et de récupérer une référence correctement typée. Un exemple possible serait :

Object myVar = foo();
if (myVar instanceof String s) {
    System.out.println(s);
}

Cela n’est pas encore disponible avec l’instruction switch.

Sealed classes

Les sealed classes sont des classes dont on contrôle l’héritage. Cela permet d’avoir une connaissance à la compilation de toutes les classes filles de cette dernière. Le premier gain est de pouvoir s’assurer qu’on a géré tous les cas dans un switch qui vérifie le type par instanceof. C’est décrit dans la JEP 360.

L’écriture est assez différente de ce que l’on trouve en Scala. Ce dernier oblige à ce que toutes les classes filles soient décrites dans le même fichier. Java garde la volonté d’avoir (en principe) une seule classe par fichier. Cela s’écrit donc ainsi :

package org.linuxfr;

public abstract sealed class Contenu
    permits org.linuxfr.Depeche,
            org.linuxfr.Journal,
            org.linuxfr.Lien {
  // ...
}

Il faut voir que cela remet en cause les possibilités d’étendre le code. Ça sert quasi uniquement quand on a besoin de l’exhaustive checking au sein du pattern matching. Pour bien décrire l’intérêt, cela permet d’écrire :

String foo(Contenu c) {
  return switch(c) {
    case Depeche d -> "plouf";
    case Journal j -> "plif";
    case Lien l -> "plof";
  };
}

Sans avoir besoin d’avoir un cas default.

Records

Les records (apparus dans la précédente version de Java) sont des classes immuables qui bénéficient d’une syntaxe succincte. Cette mise à jour assure le bon fonctionnement avec les sealed classes et sur l’usage d’annotations, mais la JEP 384 est très complète pour décrire tout leur fonctionnement.

Pour ce qui est du code un Point en deux dimensions se déclarera comme ça :

record Point(int x, int y) {}

Et elle s’utilise comme n’importe quelle classe. Comme pour le constructeur vide créé par défaut, pour vous ici le langage définit le equals()/hashCode(), les getter (avec un style « builder », dans l’exemple on a x() et y()), le constructeur avec le profil que vous avez défini et une méthode toString(). Comme pour le constructeur par défaut, il est possible de surcharger les implémentations fournies. Cela devrait réduire l’intérêt de lombok ou immutables.

Cette nouvelle itération apporte diverses évolutions plus ou moins discrète :

il y a l’interdiction d’utiliser this dans le constructeur canonique, c’est la solution trouvée pour éviter aux développeurs peu attentionnés de faire n’importe quoi ;
une modification tardive fait que les attributs des records deviennent réellement finals et ne peuvent pas être modifiés par réflexion JDK‑8247444 ;
la possibilité de créer des records locaux de la même manière que les classes ;
les mécanismes de sérialisation et de désérialisation propre et qui, donc, diffèrent des classes :
- la sérialisation est basée seulement sur l’état de l’objet,
- la « désérialisation » utilise uniquement le constructeur canonique.

La version finale sera certainement livrée en version 16.

Écosystème

fast‑jar

Le projet Quarkus est un cadriciel Java alternatif à Spring visant l’extrême performance et à être developer friendly. Sa version 1.5 propose un nouvel empaquetage pour les applications Java nommé fast‑jar.

Un fichier au format JAR est une archive ZIP des applications Java contenant les classes compilées ainsi que quelques fichiers de description et des fichiers de configuration de l’application. Il est possible d’y inclure les bibliothèques utilisées par l’application : c’est ce que l’on appelle un fat‑jar ou un uber‑jar. C’est un peu comme une compilation statique, cela permet de distribuer l’application avec un unique fichier (il faut « juste » avoir un JDK installé).

La simplicité de ces uber‑jar leur a fait rencontrer un vif succès, mais l’arrivée de Docker a un peu changé la donne. Le système de couches de Docker (une image Docker dépend d’une précédente image dont on a modifié le contenu) pousse à organiser ses images comme suit :

l’image de base contenant le JDK ;
on ajoute les dépendances de l’application dans une couche dédiée ;
on ajoute l’application dans une autre couche ;
si applicable, on ajoute les fichiers de configuration dans une dernière couche.

L’idée sous‑jacente est de découper les couches en fonction de la fréquence de mise à jour :

on modifie plus fréquemment sa configuration que l’application ;
on met à jour plus fréquemment l’application que ses dépendances ;
on met à jour plus fréquemment les dépendances que le JDK.

Cela permet de ne télécharger que les dernières couches lors des mises à jour.

Lors de leurs tests de performance, les développeurs de Quarkus se sont rendu compte que le temps de démarrage d’une application uber‑jar est bien plus court qu’avec les dépendances séparées (voir ici). Pour pouvoir à la fois avoir un empaquetage Java efficace et continuer de suivre les bonnes pratiques Docker, ils ont créé fast‑jar. Il s’agit simplement d’un JAR éclaté, mais qui possède un index dans le JAR principal qui indique où trouver chaque classe. Le chargeur de classes n’a donc plus à aller chercher dans chaque JAR si la classe qu’il cherche s’y trouve ou non.

Développement du JDK

La version 16 du JDK donnera quelques modifications importantes dans son développement :

passage à C++14 (JEP 347) ; actuellement cantonné à C++98, les nouveaux développements seront effectués avec la norme C++14, la JEP décrit ce qui est autorisé ou non d’utiliser ;
devnewton en avait parlé dans les liens : passage de Mercurial à Git (JEP 357), cette décision est motivée par la taille de l’historique, l’outillage autour de Git et les hébergements disponibles pour Git — justement, dans la foulée, il a été décidé de partir chez GitHub (JEP 369) ; vous trouverez les raisons de ce changement dans la JEP associée : Why GitHub?

Java champions

Les Java Champions sont un groupe de promoteurs de Java indépendants d’Oracle (ou de Sun à l’époque). Les membres sont élus par leurs pairs (et sont aussi proposés à l’élection de cette façon).

Le 5 mai dernier, Audrey Neveu était élue Java Champion. Elle travaille chez Pivotal comme développeuse Java, Kotlinv et JS, et est surtout connue en tant que membre des Cast Codeurs où elle sensibilise aux enjeux sociétaux que les technologies peuvent poser (les risques liés aux libertés, les problèmes que les GAFAM peuvent induire…).

Vingt‑cinq ans de Java

Le 25 mai dernier Java a soufflé ses vingt‑cinq bougies. Ça a été l’occasion de créer différents évènements : par exemple, Oracle a mis en ligne Moved by Java, et ParisJUG a organisé une soirée rétrospective avec plusieurs champions Java francophones c’est visible sur YouTube. On y retrouve pêle‑mêle :

Audrey Neveu, nouvelle championne ;
Antonio Gonçalves, cofondateur du ParisJUG, de Devoxx France, il travaille pas mal autour de Java EE ;
Emmanuel Bernard, développeur Red Hat sur les projets Hibernate et maintenant Quarkus ;
Jean‑Michel Doudoux il a produit énormément de documentations autour de Java, entre autres sur Developpez.com, il en publie aussi sur son propre site ;
Rémi Forax, enseignant à l’université, il est contributeur OpenJDK depuis très longtemps.

Il y a aussi un article sympa listant 25 super‑applications.

AdoptOpenJDK devient Adoptium

AdoptOpenJDK est une distribution de Java très populaire. Elle a rejoint en juin dernier la fondation Eclipse. Il peut être compliqué d’un point de vue légal d’utiliser le nom « OpenJDK », il a donc été choisi de renommer le projet Eclipse Adoptium. Cela va permettre au projet de bénéficier de toute l’infrastructure proposée par Eclipse d’un point de vue technique (hébergement par exemple) et organisationnel (la gouvernance n’est pas attachée à une éventuelle entreprise).

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Cassandre, un cadriciel pour développer votre propre « trading bot »

2020-04-09T10:57:57+02:00

Un automate ou robot (bot) de trading est un programme qui va automatiquement placer des ordres d’achats et de ventes sur des marchés de cryptomonnaie (ou des Exchanges, dans notre cas) sans qu’un humain n’ait à intervenir. L’avantage est, bien sûr, qu’ils travaillent 24 h / 24 et qu’ils sont toujours concentrés !

Cassandre se présente comme un starter Spring Boot. Après l’avoir ajouté à votre projet et avoir créé une classe annotée, Cassandre va se charger de fournir automatiquement à votre classe les données du marché, les données sur vos comptes et vos ordres. Il vous permettra aussi de passer de nouveaux ordres.

À partir de là, vous pourrez développer votre propre stratégie en utilisant les outils et méthodes de vos choix (analyse technique, apprentissage automatique, apprentissage profond…).

Avec ce projet, notre but est de démystifier ce domaine et de partager ce que nous apprenons, vous pourrez donc aussi trouver un guide complet sur le développement du bot et un début de cours sur le développement de stratégie (on a déjà pas mal avancé sur l’analyse technique).

Grâce à l’utilisation de XChange, nous prenons potentiellement en charge de nombreux Exchanges.

lien nᵒ 1 : Sources (GitHub)
lien nᵒ 2 : Guide
lien nᵒ 3 : XChange
lien nᵒ 4 : Spring Boot

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Java 14 tombe le masque

2020-03-18T14:50:21+01:00

À quelques jours du printemps, une nouvelle version de Java arrive avec son lot de corrections, améliorations, nouveautés et retraits. Voilà six mois que Java 13 a apporté ses quelques nouveautés. Cette nouvelle itération est bien plus riche aussi bien sur les fonctionnalités définitives que sur celles en cours de maturation. Au programme pas moins de 16 JEP intègrent le langage. Seulement une partie sera détaillée dans la suite de dépêche.

lien nᵒ 1 : Les JEPs OpenJDK 14
lien nᵒ 2 : L’ensemble des améliorations et des corrections

Les nouveautés définitives

Avec la nouvelle cadence de versionnage, les nouveautés arrivent plus tôt mais dans un état non définitif et profitent des retours d’expérience des utilisateurs.

Temps de démarrage et empreinte mémoire

Depuis plusieurs versions, les temps de démarrage et l’empreinte mémoire diminuent. Il est possible d’espérer un gain d’une dizaine de pourcents sur le temps de démarrage, c’est toujours ça de pris ! Côté empreinte mémoire, en revanche, la baisse est plus conséquente, de l’ordre de 30 % à 40 %. Ces améliorations sont natives, il n’est pas nécessaire d’ajouter des options. Pour plus de détails, une présentation et un article.

Du côté des ramasse‑miettes

G1

G1 est le ramasse‑miettes par défaut depuis Java 8 et il progresse de version en version à tous les niveaux (temps de réponse, gestion de la mémoire). Je vous laisse regarder cette présentation ou le support. Cette progression est une bonne raison pour ne plus rester sur Java 8, car aucune amélioration n’est portée sur les versions antérieures.

Les ramasse‑miettes expérimentaux

ZGC (disponible depuis Java 11) fonctionne sur les trois principaux systèmes d’exploitation et il devrait bientôt ne plus être expérimental si l’on en croit cette JEP. L’idée derrière ZGC est de proposer un ramasse‑miettes à faible latence et qui peut aussi bien gérer des petites ou des grosses quantités de mémoire.
Shenandoah est un autre ramasse‑miettes à faible latence intégré depuis Java 12, son objectif est d’avoir des temps de pause identiques quelle que soit la quantité de mémoire à libérer. Si vous voulez savoir comment ça fonctionne et avoir un état d’avancement du projet, je vous laisse regarder cette présentation et pour les explications plus détaillées c’est ici (partie 1), puis là (partie 2).

Switch statement et switch expression

Les switch expression et switch statement sont arrivées dans la version 12, ont été revues dans la version 13 et sont définitives dans cette version 14 (voir la JEP 361).

Avant, on devait écrire :

public enum Event {
    PLAY, PAUSE, STOP
}

String log;
switch (event) {
  case PLAY:
    log = "User has triggered the play button";
    break;
  case STOP:
  case PAUSE:
    log = "User needs a break";
    break;
  default:
    String message = event.toString();
    LocalDateTime now = LocalDateTime.now();
    log = "Unknown event " + message + 
          " logged on " + now;
    break;
}

Et maintenant, cette syntaxe est possible :

var log = switch (event) {
    case PLAY -> "User has triggered the play button";
    case STOP, PAUSE -> "User needs a break";
    default -> {
        String message = event.toString();
        LocalDateTime now = LocalDateTime.now();
        yield "Unknown event " + message + 
              " logged on " + now;
    }
};

Avec cette nouvelle forme :

il n’y a plus de risque d’oublier un break en cours de chemin ;
il n’est plus nécessaire d’instancier une variable à vide ;
c’est plus court !

Autre fait notable, le cas par défaut n’est plus obligatoire lorsque toutes les possibilités d’un enum sont traitées. Par précaution, en rajouter un peut protéger s’il y a un ajout dans l’énumération.

Le mélange des syntaxes est aussi possible avec des risques d’erreurs comme le montre l’exemple suivant :

int i = switch (day) {
    case MONDAY -> {
        System.out.println("Monday"); 
        // ERROR! Block doesn't contain a yield statement
    }
    default -> 1;
};
i = switch (day) {
    case MONDAY, TUESDAY, WEDNESDAY: 
        yield 0;
    default: 
        System.out.println("Second half of the week");
        // ERROR! Group doesn't contain a yield statement
};

Chacun se fera son avis sur ces nouvelles formes, car autant un switch case à l’ancienne est pénible à écrire, autant avec les nouvelles possibilités il va falloir s’accorder sur le style à suivre sur un projet.

JDK Flight Recorder Event Streaming

Dans Java 11, Oracle a libéré Flight Recorder (FR) qui permet de suivre l’activité d’une application du sol au plafond, c’est‑à‑dire des appels processeur aux méthodes utilisées pour faire de l’affichage, en passant par le ramasse‑miettes et par le compilateur à la volée. Pour diverses explications, du code et des démos, allez voir cette conférence ou encore cet article. Toutefois, pour découvrir l’outil rapidement, il faut lancer votre application avec java -XX:StartFlightRecording:filename=/tmp/monAppli.jfr -jar monAppli.jar, interagir avec durant quelques instants et l’arrêter. Il est aussi possible de démarrer les enregistrements sur une application déjà en fonctionnement avec jcmd MainClass JFR.start. Ensuite, vous pouvez profiter d’un résumé des évènements enregistrés avec $JAVA_HOME/bin/jfr summary /tmp/monAppli.jfr | less ; pour une analyse plus poussée, Java Mission Control est bien plus adapté.
Le JDK Flight Recorder Event Streaming apporte la possibilité de profiter directement de ces mesures sans passer par la case écriture dans un fichier et lecture à partir de ce dernier. Ça peut sembler basique, mais ça ouvre de nombreuses possibilités pour monitorer de façon déportée différents services (un exemple avec du Grafana et du Quarkus).

Des NullPointerException plus explicites

Dorénavant, les développeurs Java auront moins d’excuses pour passer de longs moments à décortiquer les NPE, car elles indiqueront quel objet est null. Cette fonctionnalité existe depuis 2006 dans le JDK de SAP, et la plus grande ouverture des contributions à Java a permis de la rendre disponible au plus grand nombre. Pour Java 14, il faudra activer l’option -XX:+ShowCodeDetailsInExceptionMessages afin d’en profiter et, à partir de Java 15, l’option sera activée par défaut.

Nouveautés en prévisualisation

Records

La verbosité du langage n’est plus à démontrer et, pour alléger la charge, des efforts sont faits, notamment avec de l’inférence de type avec le mot clé var au moment de déclarer une variable. Les records vont dans ce sens‑là, mais en plus ils permettent de transporter de la donnée de manière immutable. Voici un petit exemple de code :

public record Bouchot(String nom){}

C’est tout, une seule ligne pour créer un record ! Derrière, le langage se débrouille pour générer les méthodes equals(), toString() et hashCode(). Pour accéder au nom d’un bouchot (que l’on aura déclaré comme ceci : var monBouchot = new Bouchot("DLFP"), il suffit de faire monBouchot.nom(). Un record reste une classe Java, avec quelques limitations toutefois, il est donc possible de rajouter des contraintes sur le constructeur, par exemple refuser les null ou écrire votre propre méthode toString(), si la version générée ne vous convient pas.

public record Bouchot(String nom){
  public Bouchot {
    if(null == nom){
      throw new IllegalArgumentException("Crois‑tu qu’une moule puisse s’accrocher à null ?");
    }
  }
}

Une chose intéressante à savoir est que les records ont été définis en prenant en compte le futur du langage aussi bien du côté développeur (types scellés, pattern matching et déconstruction) que de la machinerie interne (inline type). Pour aller plus loin, je vous laisse lire cet article.

Pattern Matching instanceof

Java est le dernier des principaux langages fonctionnant sur la JVM à ne pas implémenter le pattern matching. Pour cette première, il commence modestement en apportant un peu plus de légèreté syntaxique.

// Avant avec le cast
if (obj instanceof Bouchot) {
    Bouchot b = (Bouchot) obj;
    var nom = b.nom();
}

//Après
if (obj instanceof Bouchot b) {
    var nom = b.nom();
}

L’étape suivante est de combiner le pattern matching avec les switch expressions et de pouvoir déconstruire les records. Tout le programme est détaillé dans la JEP 375 et en voici un avant‑goût :

record Point(int x, int y) {}

if (obj instanceof Point(var a, var b)) {
    System.out.println(a+b);
}

Outils d’empaquetage

L’idéal de Java qui était, si je ne me trompe pas, compile ton application une seule fois et elle fonctionnera partout, semble ne plus trop être à l’ordre du jour. La démarche est plus, livre ton application avec les modules Java strictement nécessaires et, optionnellement, le JRE qui va avec. Le but étant la diminution de la taille des applications mais aussi l’amélioration de la réactivité et de la sécurité, car moins de code sera chargé et donc exposé. Comme d’habitude, les détails sont à lire dans la JEP 343.

Les blocs de texte, seconde itération

Après une première implémentation dans la version précédente de Java, en voici une nouvelle (JEP 368). Le principe est d’avoir une solution élégante pour se débarrasser des concaténations sur plusieurs lignes, de se battre avec les échappements divers et variés et surtout améliorer la lisibilité.

String query = """
               SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
               WHERE `CITY` = 'INDIANAPOLIS'
               ORDER BY `EMP_ID`, `LAST_NAME`;
               """;

C’est aussi utilisable en combinaison avec d’autres bibliothèques, voici un exemple d’utilisation avec JOOQ.

Avec cette seconde version, viennent des caractères d’échappement des lignes pour jongler avec les lignes trop longues ou gérer plus finement les retours à la ligne.

Dans l’exemple suivant toutes les lignes feront six caractères :

String colors = """
    red  \s
    green\s
    blue \s
    """;

Les mises au placard et les départs

Ironie de l’histoire, l’architecture créée par la même société que le langage est dépréciée et ne sera rapidement plus supportée. Pour les rares qui ont encore du Solaris et du SPARC, c’est bientôt la fin pour faire tourner des machines virtuelles Java (JVM) modernes. Les détails sont présents dans la JEP 362. Même processus pour le ramasse‑miettes Concurrent Mark Sweep dans le but de laisser plus de temps au développement des autres ramasse‑miettes, les détails dans la JEP 291.

Suppression des outils Pack200, suite à leur placardisation dans Java 11, ils sont remplacés par les outils jlink, plus d’informations dans la JEP 367.

Dans les prochaines versions

La seconde version du pattern matching de instanceof, les types scellés, la version définitive des blocs de texte. Je vous laisse regarder cette diapo de Rémi Forax (un contributeur d’OpenJDK). Pour une vision plus « sous le capot », Brian Goetz (un architecte du langage) a rédigé deux articles sur les évolutions de Java.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Communiquer avec D-Bus en Java avec JNIDBus

2019-09-24T13:24:02+02:00

Avec mes collègues chez Viveris, on s’est dit qu’on aimerait bien faire plus de logiciel libre. On a donc monté un « groupe opensource » dont le but est d’identifier les projets pour lesquels on peut publier tout ou une partie du code sous licence libre, et aussi de contribuer aux outils et bibliothèques qu’on utilise le plus.

Il y a quelques mois je vous présentais QTestFramework, depuis on a également pu contribuer au dissecteur 0MQ pour Wireshark et un outil pour le boundary scan JTAG.

On vient de publier il y a quelques jours une bibliothèque Java pour communiquer en D-Bus.

lien nᵒ 1 : Projets opensource chez Viveris
lien nᵒ 2 : JNIDBus sur GitHub
lien nᵒ 3 : D-Bus sur Wikipédia

Sommaire

Contexte
JNIDBus
- Historique
- Utilisation

Contexte

D-Bus

D-Bus est un système de communication inter-processus utilisé sous GNU/Linux. Le projet a été lancé par des développeurs de Red Hat au sein de Freedesktop. Il a été intégré dans GNOME 2 et KDE 4, et aujourd’hui il est utilisé par de très nombreux composants d’un système GNU/Linux : systemd, NetworkManager et PulseAudio, par exemple. Il y a même une implémentation dans le noyau Linux lui‑même.

JNI

JNI (Java Native Interface) est une API qui permet d’interfacer du code tournant dans une machine virtuelle Java avec du code natif. Cela nécessite d’écrire (en C ou C++) des wrappers qui vont manipuler la pile de la JVM pour récupérer les arguments et pousser les valeurs de retour, et éventuellement accéder aux objets Java manipulés. Les méthodes ainsi implémentées peuvent ensuite être appelées depuis le code Java de façon transparente.

Solutions existantes et leurs limitations

Freedesktop propose DBus-Java, mais il n’y a pas eu de version publiée depuis 2009. La dernière version a besoin de Java 7 pour fonctionner. De plus, cette bibliothèque implémente le protocole D-Bus en Java, ce qui risque de poser des problèmes d’interopérabilité avec l’implémentation en C.

Il existe bien une version mise à jour de la bibliothèque qui corrige au moins le premier problème, cependant l’API n’utilise pas les nouvelles fonctionnalités de Java et c’est bien dommage.

JNIDBus

Historique

Dans le cadre d’une migration d’un de nos logiciels depuis Java 7, nous avons découvert que DBus-Java ne prenait pas en charge les versions plus récentes. Nous aurions pu nous contenter d’une mise à jour de cette implémentation, mais il y avait beaucoup de code à reprendre dedans et de toute façon, l’API ne nous convenait pas.

En effet, dbus-java représente les messages D-Bus par des « tuples » génériques, ce qui est assez peu pratique à utiliser et rend le code illisible. De plus, les API sont bloquantes et cela nous contraignait à utiliser une réserve (pool) de fils d’exécution qui complexifiait encore le logiciel.

L’ensemble des ces défauts et l’absence d’alternative viable nous ont poussé à développer notre propre alternative, en essayant de répondre a toutes les problématiques.

Afin de ne pas réimplémenter le protocole D-Bus nous voulions utiliser la bibliothèque libdbus-1. L’écosystème Java possède deux manières d’appeler du code natif : JNI et JNA, ce dernier étant écarté pour des raisons de performances et de complexité des bibliothèques de liaison (bindings) à écrire.

Enfin, la dernière contrainte était de réduire le code natif au strict minimum, afin de limiter la complexité de ce dernier qui est très difficile à tester unitairement.

Utilisation

La base de JNIDBus est la sérialisation d’objet Java. La signature du message est décrite dans une annotation.

Exemple pour un message contenant une chaîne de caractères et un entier :

@DBusType(
    /* Pour plus d’info sur le format de la signature, référez vous
     * à la documentation D-Bus
     */
    signature = "si",

    /* Donne le nom des propriétés contenant les données du message,
     * dans notre cas la chaîne de caractères est contenue dans la
     * propriété nommée « string » et l’entier dans le champs « integer »
     */
    fields = {"string","integer"}
)
public class StringMessage extends Message {
    /* Les champs seront accédés au travers de ses setters et
     * getters qui devront respecter la convention "setXxx"/"getXxx"
     */
    private String string;
    private int integer

    public String getString() { ... }
    public void setString(String string) { ... }

    public int getInteger() { ... }
    public void setInteger(int string) { ... }

}

L’appel de méthodes distantes est transparent grâce a l’utilisation de proxy Java, il suffit de décrire l’interface de l’objet et de donner le nom de son bus pour pouvoir l’appeler. Toute méthode distante retourne un PendingCall auquel on doit attacher un listener pour être notifié de l’arrivée du résultat.

JNIDBus permet également d’exposer des méthodes distante par le biais de handlers. Un handler est simplement une classe annotée décrivant et implémentant les méthodes distantes, les signatures sont inférées grâce aux types d’entrées et de sorties. Les handlers seront exécutés dans la boucle d’évènements, il est donc primordial d’éviter tout appel bloquant ou toute tâche lourde. Afin de tout de même pouvoir effectuer ces tâches lourdes, les handlers gèrent un type de retour asynchrone (Promise).

Exemple d’un handler pour un signal et un appel :

@Handler(
    /* pour plus d’information référez vous à la documentation D-Bus
     */
    path = "/some/object/path",
    interfaceName = "some.dbus.interface"
)
public class SomeHandler extends GenericHandler {
    @HandlerMethod(
        //le nom exposé a D-Bus peut être différent du nom de la méthode Java
        member = "someSignal",
        type = HandlerType.SIGNAL
    )
    //Ici notre signal n’a aucun paramètre, on utilise donc le singleton EmptyMessage
    public void someSignal(Message.EmptyMessage emptyMessage) { ... }

    @HandlerMethod(
        member = "stringSignal",
        type = HandlerType.METHOD
    )
    public SomeOutput someCall(SomeInput input) { ... }
}

Comment enregistrer le handler auprès de D-Bus :

//connection au bus
Dbus receiver = new Dbus(BusType.SESSION,"my.bus.name");
//instanciation
SomeHandler handler = new SomeHandler();
//ajout, JNIDBus lancera une exception si le handler n’est pas valide
this.receiver.addHandler(handler);

Le langage Kotlin est pris en charge par le biais d’un artefact Gradle supplémentaire définissant des extensions qui suspendent l’appel de fonction et offrant la possibilité d’avoir des handlers qui facilitent la mise en place de cette suspension :

//il faut enregistrer la classe qui se chargera d’invoquer les méthodes qui suspendent
KotlinMethodInvocator.registerKotlinInvocator()

@Handler(path = "...", interfaceName = "...")
class CallHandler : KotlinGenericHandler() {

    @HandlerMethod(member = "suspendingCall", type = MemberType.METHOD)
    suspend fun suspendingCall(emptyMessage: Message.EmptyMessage): SingleStringMessage {
        //coroutines are awesome
        delay(2000)
        return SingleStringMessage().apply { string = "test" }
    }
}

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie d’OpenJDK 13

2019-09-24T09:51:26+02:00

Le 17 septembre 2019 est sortie cette nouvelle version d’OpenJDK. Elle comporte son lot de nouveautés, de fonctionnalités en préversion et des retraits. C’est aussi l’occasion de réécriture de certains composants, notamment l’API Socket pour l’inclusion des fils d’exécution — threads — locaux (aka Fibers). Les notes de version vous permettront d’avoir plus de détails.

lien nᵒ 1 : Notes de version
lien nᵒ 2 : AdoptOpenJDK
lien nᵒ 3 : Vidéo sur les dernières nouveautés et celles à venir

Sommaire

Dynamique de développement
- Contributions
- Rythme de publication et durée de maintenance
Dans les épisodes précédents
- Quelques nouveautés apparues
  - Mot clef « var »
  - Nouvelle méthode pour les collecteurs « Collectors::teeing »
Nouveautés
Nouveautés en préversion
- Expressions switch
- Text Block
Futur

Dynamique de développement

Contributions

Bien qu’Oracle reste le principal contributeur au projet, depuis les dernières versions, Red Hat et d’autres sociétés prennent en charge une part significative du travail, aux environs de 30 % des tickets pour la version 13. Plus de détails dans les billets du blog d’Oracle concernant la sortie des versions 12 et 13.

Rythme de publication et durée de maintenance

Depuis la sortie d’OpenJDK 9, le rythme de publication est passé à une version tous les six mois avec une maintenance raccourcie pour les versions sans support étendu (actuellement 9, 10, 12 et 13). À l’heure actuelle, les versions 8 et 11 ont un support de longue durée. Selon les distributions du JDK (Red Hat, IBM, Azul, Amazon, etc.) c’est encore différent.

Dans les épisodes précédents

Quelques nouveautés apparues

Mot clef « var »

La version 10 a vu l’apparition du mot clef var qui permet l’inférence de type et dont l’usage a été étendu aux expressions lambda dans la version 11. Cela permet de ne pas avoir à déclarer le type s’il est évident ou d’avoir à écrire un type trop verbeux. Il existe une liste de bonnes pratiques (ici ou là) pour éviter de rendre le code illisible.

Nouvelle méthode pour les collecteurs « Collectors::teeing »

Depuis la version 12, la méthode statique Collectors::teeing permet de récupérer dans un flux deux informations différentes et ensuite d’appeler une méthode pour exploiter les données obtenues. Cet article en anglais apporte plus de détails.

Nouveautés

Dans cette version les évolutions définitives sont principalement des mises à jour côté sécurité, des correctifs divers et variés ainsi que des améliorations de la machine virtuelle Java (JVM).

Dynamic CDS Archive JEP 350

C’est une extension d’un module libéré par Oracle dans le JDK 10 (Application Class‑Data Sharing JEP 310). Ce module permet des temps de chargement raccourcis et une empreinte mémoire plus faible en partageant certaines classes entre les processus Java. Cette extension simplifie l’usage du module grâce à quelques options :

archivage à l’arrêt ;
chargement d’une archive au démarrage.

ZGC : uncommit unused memory

ZGC est un ramasse‑miettes expérimental à faible latence. Il est présent depuis le JDK 11. Désormais, la mémoire peut être rendue au système d’exploitation en configurant les options. C’est bien pratique puisque désormais la taille maximale du tas (heap) est passée de 4 à 16 Tio.

Divers

Intégration d’Unicode 12.1, vous pourrez désormais avoir un émoji gilet jaune. Pour les personnes plus versées dans les aspects sécurité, la lecture du blog de Sean Mullan est une bonne chose.

Nouveautés en préversion

Il s’agit de fonctionnalités à découvrir et qui nécessitent une activation à la compilation. Elles sont d’ailleurs amenées à ne pas rester en l’état. Par exemple, les switch expressions en sont à leur seconde itération.

Expressions switch

Cette fonctionnalité est définie par la JEP 325. Il s’agit d’une des solutions pour rendre le code Java moins verbeux, et donc limiter le risque d’erreurs. Ainsi, le code :

switch (day) {
    case MONDAY:
    case FRIDAY:
    case SUNDAY:
        System.out.println(6);
        break;
    case TUESDAY:
        System.out.println(7);
        break;
    case THURSDAY:
    case SATURDAY:
        System.out.println(8);
        break;
    case WEDNESDAY:
        System.out.println(9);
        break;
}

Peut désormais s’écrire de la manière suivante :

switch (day) {
    case MONDAY, FRIDAY, SUNDAY -> System.out.println(6);
    case TUESDAY                -> System.out.println(7);
    case THURSDAY, SATURDAY     -> System.out.println(8);
    case WEDNESDAY              -> System.out.println(9);
}

Ou encore si l’on veut affecter un résultat à une variable :

int numberOfLetters = switch (dayOfWeek) {
  case MONDAY:
  case FRIDAY:
  case SUNDAY:
   yield 6;
  case TUESDAY
   yield 7;
  case THURSDAY
  case SATURDAY
   yield 8;
  case WEDNESDAY
   yield 9;
  default:
   throw new IllegalStateException("Huh?: " + day);
};

Text Block

Cette fonctionnalité est définie par la JEP 355. Les blocs de texte étaient initialement prévus pour la version 12 du JDK, mais au dernier moment ils ont été retirés faute de consensus sur le délimiteur et le comportement. L’idée est d’avoir du texte dont il est préférable de conserver le formatage pour des raisons de facilité d’écriture.
Par exemple, au lieu d’écrire :

String html = "<html>\n" +
              "    <body>\n" +
              "        <p>Hello, world</p>\n" +
              "    </body>\n" +
              "</html>\n";

String query = "SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`\n" +
               "WHERE `CITY` = 'INDIANAPOLIS'\n" +
               "ORDER BY `EMP_ID`, `LAST_NAME`;\n";

Il est possible d’écrire :

String html = """
              <html>
                  <body>
                      <p>Hello, world</p>
                  </body>
              </html>
              """;

String query = """
               SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
               WHERE `CITY` = 'INDIANAPOLIS'
               ORDER BY `EMP_ID`, `LAST_NAME`;
               """;

Ce guide exhaustif en anglais à destination des développeurs décrit les cas d’usage avec les bonnes et les mauvaises pratiques.

Futur

Avec le nouveau rythme de publication des JDK, les nouveautés arrivent de manière plus progressive. Ainsi, dans les prochaines versions, voici les améliorations qui devraient rendre le langage meilleur :

les Records, qui seront une sorte de data class telle que présente dans d’autres langages ;
les Sealed type, qui seront des types algébriques permettant de restreindre les possibilités ;
des NullPointerException plus explicites.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

confusable-homoglyphs : une bibliothèque pour gérer les caractères qui se ressemblent

2019-03-14T11:36:17+01:00

Bonjour tout le monde,

J’ai l’honneur de vous présenter une nouvelle bibliothèque Java (en fait compatible avec n’importe quel langage qui utilise la machine virtuelle Java, normalement) : confusable-homoglyphs. « Nouvelle » dans sa version Java, car c’est en réalité un portage d’une bibliothèque Python. Notez qu’il en existe aussi une version PHP.

C’est un outil sous licence Apache 2.0 qui permet de gérer directement au sein d’une application les caractères Unicode qui se ressemblent, et donc qui sont source de confusion.

lien nᵒ 1 : Dépôt Git de confusables-homoglyphs (Java)
lien nᵒ 2 : Version Python (originale) de confusables_homoglyphs
lien nᵒ 3 : Portage en PHP de confusable-homoglyphs
lien nᵒ 4 : Retour d’expérience sur le portage Python → Java

Quel est donc le but de cette bibliothèque ?

Les humains utilisent divers systèmes d’écriture, et ce qui devait arriver, arriva : il y a des caractères qui se ressemblent (voire qui sont graphiquement identiques, selon la police d’écriture), mais qui sont différents. Or, de telles confusions peuvent avoir des conséquences fâcheuses, par exemple :

l’utilisateur « ΑlaskaJazz » (le premier Α est un alpha majuscule grec) peut se faire passer pour l’utilisateur « AlaskaJazz » (uniquement des lettres latines) ;
on peut vous inciter à vous connecter sur www.microsоft.com ou www.faϲebook.com au lieu de www.microsoft.com ou www.facebook.com ;
etc., on pourrait multiplier les exemples désagréables à l’infini.

Si Unicode fournit des listes des caractères qui peuvent prêter à confusion, elles sont difficiles à utiliser en l’état : ce sont des fichiers textes avec un formatage particulier, qui plus est hébergés sur des serveurs instables et fréquemment hors ligne.

confusable-homoglyphs permet de gérer ces confusions en détectant et donnant des informations sur les caractères potentiellement problématiques.

D’accord, mais comment ça s’utilise ?

La bibliothèque est disponible sur Maven Central et donc s’importe comme n’importe quelle autre bibliothèque Java, ici avec Maven ou Gradle :

<dependency>
    <groupId>fr.spacefox</groupId>
    <artifactId>confusable-homoglyphs</artifactId>
    <version>1.0.1</version>
</dependency>

compile group: 'fr.spacefox', name: 'confusable-homoglyphs', version: '1.0.1'

Puis on initialise l’une des deux classes utilitaires, selon ce qu’on veut faire :

Categories categories = Categories.fromInternal();
Confusables confusables = Confusables.fromInternal();
// ou si on préfère fournir un jeu de données spécifique :
Categories categories = Categories.fromJson("/full/path/to/categories.json");
Confusables confusables = fromJsons("/full/path/to/categories.json", "/full/path/to/confusables.json");
// (Confusables utilise Categories en interne).

Et on utilise les objets créés. Il y a un résumé de l’API publique ici. La création est relativement longue par rapport à l’utilisation, il vaut mieux garder ces objets vivants entre deux appels.

Les intentions et contraintes du projet

En réalité, je n’ai pas besoin de cette bibliothèque, au‐delà du fait que je trouve qu’elle manque à Java. Je voulais aussi et surtout :

connaître la difficulté à porter une bibliothèque de Python à Java ;
voir ce que c’est de créer un projet, seul, de A à Z et complet (avec documentation et tout) ;
essayer de déployer quelque chose sur Maven (en tant que fournisseur).

Les contraintes que je me suis choisies pour ce projet étaient donc :

licence libre (Apache 2.0) ;
Java 8, pour garder une bonne compatibilité avec les projets actuels et les différents langages qui utilisent la machine virtuelle Java ;
une API aussi proche de possible que l’originale (il y aura une version 2 avec des modifications dans cette API, un jour) ;
disponible sur Maven Central, pour être utilisable comme n’importe quelle bibliothèque Java ;
avec une doc complète ;
avec une couverture de tests correcte ;
avec de l’intégration continue via GitHub (j’ai toujours utilisé GitLab et GitLab CI pour mes autres projets Java).

Et comme j’aime bien partager mon expérience, j’ai écrit un billet sur ce que j’ai tiré de celle‐ci.

Je n’ai jamais eu l’occasion de vérifier que tout fonctionne bien sous Android. Si quelqu’un s’en sert dans cet environnement, que cette personne n’hésite pas à me faire signe. J’espère que ce petit utilitaire – ou les versions Python ou PHP – pourront vous servir un jour ! N’hésitez pas à créer tickets et demandes d’intégration (pull requests) si le cœur vous en dit !

Cette dépêche est publiée sous licence CC BY 4.0.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de JDK 10

2018-11-09T08:05:21+01:00

Cette dépêche aura mis du temps à venir au monde, et depuis le JDK 11 — la version avec support étendu (LTS) — est sorti, mais il est encore temps de ~~troller~~^W discuter de façon constructive de l’évolution d’un langage qui reste aujourd’hui au cœur des entreprises.

C’est l’occasion de (re)voir les ajouts côté langage, les changements et retraits côté API, les évolutions de la machine virtuelle Java (JVM), la gestion du code source ; le tout documenté au travers des JEP à la base des spécifications de Java.

lien nᵒ 1 : Notes de version
lien nᵒ 2 : Liste des nouveautés

Sommaire

Côté langage
- Un ajout : l’inférence de type pour les variables locales (JEP 286)
Côté API
- Changements
  - JEP 314
- Suppressions (API obsolètes)
Côté JVM
- JEP 304
- JEP 307
- JEP 310
- JEP 312
- JEP 316
- JEP 317
Côté code
- JEP 296
- JEP 313
- JEP 322
- JEP 319

Côté langage

Un ajout : l’inférence de type pour les variables locales (JEP 286)

Il est désormais possible de déclarer des variables locales en remplaçant le type par le mot var afin de laisser le compilateur deviner le type :

// ici, le compilo comprend que edt est de type Map<String, String>
var edt = Map.of("lundi", "piscine", "mardi", "pétanque");

Ainsi, Java s’aligne sur de nombreux autres langages (sur la JVM, notamment Scala et Kotlin). Ce changement devrait inciter à éviter d’écrire des lignes à rallonge dont le seul but est d’éviter d’écrire les types des résultats intermédiaires. En effet, certains types peuvent être soit inconnus du programmeur (qui a la flemme d’ouvrir la Javadoc), soit très longs à écrire (types génériques), voire impossibles à écrire comme les types non dénotables, par exemple pour une classe anonyme :

var x = new Object() { int a; }; x.a = 42;

Remarque : var n’est pas un mot-clé, mais un identifiant de type réservé. Ainsi, il est toujours possible de déclarer une variable ou une méthode de nom var… mais pas une classe !

Côté API

Changements

JEP 314

On parle ici d’une amélioration sensible de l’internationalisation en s’appuyant sur des extensions d’Unicode. Voici la liste des nouvelles venues :

cu (type de devise, « currency type») ;
fw (premier jour de la semaine, « first day of week ») ;
rg (region override) ;
tz (time zone).

Tout ça va permettre aux classes de formatage (java.text.DateFormat, java.text.NumberFormat…) de récupérer directement les informations Unicode disponibles.

Suppressions (API obsolètes)

Suppression de l’attribut java.lang.SecurityManager.inCheck.
Suppression des méthodes suivantes :

java.lang.Runtime.getLocalizedInputStream(java.io.InputStream) ;
java.lang.Runtime.getLocalizedOutputStream(java.io.OutputStream) ;
java.lang.SecurityManager.classDepth(java.lang.String) ;
java.lang.SecurityManager.classLoaderDepth() ;
java.lang.SecurityManager.currentClassLoader() ;
java.lang.SecurityManager.currentLoadedClass() ;
java.lang.SecurityManager.getInCheck() ;
java.lang.SecurityManager.inClass(java.lang.String) ;
java.lang.SecurityManager.inClassLoader().

Côté JVM

JEP 304

Le ramasse‐miettes (garbage collector) est désormais défini par une interface plus propre, permettant dans le futur d’ajouter ou retirer plus facilement des implémentations de ramasse‐miettes. À noter que, dans cette version, les auteurs se sont contentés de faciliter ce travail, sans le mettre en œuvre.

JEP 307

Le ramasse‐miettes par défaut (nommé « G1 » et promu à ce poste dans le JDK 9) est amélioré pour limiter les cas de latence, et ainsi limiter les impacts de la version précédente pour les utilisateurs.

JEP 310

La mémoire consommée par des processus java est réduite en améliorant le partage de méta‐données. Cela a également un effet positif sur la vitesse de démarrage, avec des objectifs ambitieux : des lancements jusqu’à 20 à 30 % plus rapides, et une économie de 340 Mio sur des processus consommant 13 Gio. À noter que ce dernier chiffre concerne un cas de serveur d’applications faisant tourner six JVM.

JEP 312

Pas mal d’actions émises par la JVM imposent aujourd’hui un arrêt de tous les fils d’exécution (threads) en cours. Cette JEP permet à la JVM d’arrêter un ou plusieurs fils d’exécution spécifiques, sans tout stopper.

Pour se figurer l’impact, il faut se dire qu’aujourd’hui la capture d’une pile d’appel complète — lors de l’interception d’une exception — imposait ce type de blocage complet. Désormais, seul un fil d’exécution sera interrompu, permettant au reste de l’application de continuer joyeusement sa route.

On va donc vers une réduction générale de la latence.

JEP 316

L’idée ici est d’utiliser les nouvelles mémoires économiques de type NV-DIMM en permettant à l’utilisateur de spécifier son choix. Cela se fait, bien sûr non pas dans le code, mais dans les arguments de la JVM, sous la forme : -XX:AllocateHeapAt=<path>.

En effet, ces mémoires sont typiquement accessibles via le système de fichiers, que ce soit sous Windows ou GNU/Linux.

JEP 317

Graal, un nouveau compilateur à la volée (JIT — Just In Time — en anglais) introduit dans le JDK 9 est désormais activable via des options de la ligne de commande, que voici :

-XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler

Rien de réellement nouveau, mais cela va permettre d’avoir plus de testeurs (et donc d’améliorer la qualité).

Côté code

JEP 296

Le code source de Java, jusqu’ici réparti dans huit dépôts Mercurial séparés, est regroupé au sein d’un dépôt unique. Pour les évolutions ou corrections qui touchent plusieurs composants (par exemple « jdk » et « langtools »), cela permettra d’avoir un seul commit atomique. Cela est cohérent, sachant que tous les composants suivaient le même cycle de vie de toute façon.

JEP 313

Un peu de nettoyage avec le retrait de l’outil javah, qui n’était de toute façon plus utilisé depuis le JDK 9 et affichait des avertissements lorsqu’on l’invoquait. En charge de la génération de fichiers natifs d’en‐tête, cette fonction avait déjà été réimplémentée directement dans javac depuis le JDK 8.

JEP 322

La numérotation des versions Java change ! On passe donc de :

openjdk version "1.8.0_161"
OpenJDK Runtime Environment (build 1.8.0_161-b14)
OpenJDK 64-Bit Server VM (build 25.161-b14, mixed mode)

À ceci (pour l’exemple, on imagine un build 42 d’un JDK 11 LTS) :

openjdk 11 2018-09-20 LTS
OpenJDK Runtime Environment (build 11+42-LTS)
OpenJDK 64-Bit Server VM (build 11+42-LTS, mixed mode)

Changement a priori cosmétique, mais qui pourrait avoir de lourdes conséquences… L’avenir répondra à cette question. En effet, beaucoup d’éditeurs de logiciels, font des tests assez fins sur les versions pour s’assurer que tel ou tel bogue ne risque pas de les affecter.

Pour les lecteurs de la Javadoc du JRE, l’étiquette @since reste alignée avec la propriété système java.specification.version. Et pour l’occasion, deux nouvelles propriétés sont ajoutées :

java.version.date, qui fournit la date de disponibilité de cette version ;
java.vendor.version, optionnelle, pour la version spécifique d’un correctif de distribution GNU/Linux par exemple.

JEP 319

Jusqu’ici, le jeu de certificats déclaré dans le JDK était par défaut vide, obligeant un développeur à les rajouter. Désormais, un certain nombre d’autorités sont intégrées, dont notamment :

Let’s encrypt ;
Digicert ;
Comodo ;
et quelques autres.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de Pollen 3

2018-02-13T08:12:57+01:00

Après plus de 20 000 sondages créés, Pollen fait peau neuve !

Pollen est une plate‐forme de sondages libre (AGPL) développée en Java/JavaScript. Cette nouvelle mouture repense principalement l’ergonomie et le design de l’application et propose une API permettant d’interagir avec vos sondages depuis votre site Web.

Cette nouvelle version a fait l’objet d’une refonte importante de l’application. En ce sens, l’équipe de développement est à l’affût de tous vos retours ou commentaires.
Un sondage Condorcet a été créé si vous souhaitez y jeter un œil : Quelle est votre distribution préférée ?

lien nᵒ 1 : Site officiel
lien nᵒ 2 : LinuxFr.org : Pollen, un nouveau gestionnaire de sondages libre

Historiquement, ce logiciel est né de la recherche de mise en œuvre d’un fonctionnement démocratique au sein de notre société. Nous souhaitions que chaque membre dispose du même droit à prendre part à chaque décision de la vie de l’entreprise (1 homme = 1 voix). Lorsqu’il n’y a pas unanimité dans une prise de décision, il nous fallait trouver un système efficace afin que chacun puisse exprimer rapidement son souhait. En ce sens, un système de vote binaire (oui/non) ou à choix unique ne pouvait pas convenir. Nous avions besoin de pouvoir exprimer des préférences.

Par exemple, voici une étude de l’augmentation de congés annuels, quatre choix sont possibles (il s’agit d’un exemple fictif) :

pas d’augmentation ;
une journée supplémentaire ;
deux jours supplémentaires ;
une semaine supplémentaire.

Dans cet exemple, l’un d’entre nous pourrait souhaiter en première intention que l’augmentation soit d’une semaine. En second choix, il souhaiterait que ce soit de deux jours, puis d’un jour et finalement pas d’augmentation en dernière alternative. Un second salarié pourrait souhaiter que l’augmentation des congés soit d’un ou deux jours sans réelle préférence. En revanche, ce salarié préférerait qu’il n’y ait pas d’augmentation plutôt que l’adoption d’une semaine supplémentaire, car il estime que ce serait trop pénalisant pour la société. Enfin, un dernier pourrait estimer qu’il ne souhaite pas d’augmentation des congés. Toutefois, si le consensus allait vers une augmentation, il préférerait que ce soit d’une ou deux journées. Seulement en dernier lieu, il souhaiterait que ce soit d’une semaine supplémentaire.

Par le vote Condorcet, Pollen nous permet d’exprimer facilement ce type de choix et de déterminer l’option la plus consensuelle. Par ailleurs, Pollen cherche également à répondre aux autres formes de sondages dont nous pourrions avoir besoin dans la vie de notre entreprise (élection d’un président avec un ou plusieurs tours, créer des collèges de votants, choix d’une date pour un rendez‐vous…). Bref, vous l’aurez compris, la diversité des modes de scrutins proposés (Condorcet, Borda, Coombs, vote alternatif, jugement majoritaire…) est toujours partie intégrante de l’ADN de Pollen.

Une instance en ligne de Pollen est disponible et permet à tout un chacun d’y créer des sondages. Toutefois, l’application reste évidemment téléchargeable et installable sur un serveur privé.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Silverpeas 6.0 est (enfin) sorti !

2018-02-06T16:29:15+01:00

Après deux ans de travail acharné, tout en maintenant la 5.15, Silverpeas 6.0 est enfin sorti !

Silverpeas est un portail collaboratif et social pour faciliter la collaboration et l’échange d’informations entre les personnes à l’aide d’applications intégrées. Chaque application est construite sur cette idée de collaboration, de partage.

Cette version majeure de Silverpeas contient des changements ergonomique, fonctionnels et surtout techniques. La version 6 repose désormais sur le serveur d’application Wildfly (la 6.0 tourne sur la version 10.1.0 de celui‐ci), s’appuie sur JEE 7 et Java 8.

lien nᵒ 1 : Silverpeas
lien nᵒ 2 : Les notes de version de la version 6.0
lien nᵒ 3 : La page d’installation de Silverpeas 6
lien nᵒ 4 : Pour juste tester Silverpeas 6
lien nᵒ 5 : Le dépôt Docker officiel de Silverpeas 6

Silverpeas est un portail collaboratif et social. Son objectif est de faciliter la collaboration et l’échange d’informations et de connaissances entre les personnes et les équipes en leur offrant des applications intégrées diverses et variées comme des GED (Gestion électronique des documents), des forums, des agendas, des blogs et ainsi de suite. Chaque application est construite sur cette idée de collaboration, de partage. Ce n’est donc pas un pur système de gestion de contenu, ni une pure GED, ni un pur truc‐muche.

Cette nouvelle version majeure de Silverpeas s’accompagne d’un changement non seulement ergonomique et fonctionnel, mais aussi et surtout technique. Désormais, la nouvelle lignée de versions 6 repose sur le serveur d’application Wildfly (la 6.0 tourne sur la version 10.1.0 de celui‐ci), s’appuie sur JEE 7 et Java 8. Le bus collaboratif a été revu et repose pleinement sur CDI (Context and Dependency Injection) et ses possibilités. Le modèle métier de Silverpeas a aussi été amélioré. De nouveaux moteurs et API ou des grosses évolutions ont fait leur apparition, dont notamment :

la gestion d’événements calendaires qui désormais motorise les applications Almanach (agenda collaboratif) et Agenda Personnel ;
la gestion des rappels ;
les notifications aux utilisateurs (qui utilisent le Server Send Event) ;
le rendu des pages dynamique par JavaScript ;
la prise en charge des vidéos ;
un moteur de Workflow modernisé.

Une refonte ergonomique a aussi été faite :

les frameset ont été supprimés et désormais le rendu des différentes parties des pages Web se fait dynamiquement avec un nouveau moteur de rendu ; ce dernier est en constante évolution et toutes les pages ne sont pas encore gérées pleinement par celui‐ci ; toutefois, on peut constater et profiter d’un affichage et d’une interactivité plus fluide ;
l’utilisation des possibilités de HTML 5 avec notamment la lecture de vidéos ;
Un peaufinage de l’éditeur [WYSIWYG] avec justement la prise en charge des vidéos, de nouveaux thèmes ou encore de la sauvegarde en brouillon du contenu en rédaction afin de pouvoir le retrouver en cas de coupure de session ;
l’apparition d’indicateurs dynamiques (nombre d’utilisateurs connectés, de notifications non lues, d’affichage de notifications, etc.) ;
un nouveau look plus séduisant, Aurora ; celui‐ci ne fait pas partie de la distribution de base, mais il peut être installé facilement (reste la partie paramétrage à faire, plus fastidieuse) ;
les applications Almanach et Agenda Personnel reposent désormais sur le nouveau moteur de gestion d’événements calendaires avec son jeu de composants graphiques (widgets) prêts à emploi ;
une pagination bien plus performante (et surtout plus fluide).

De nouveaux ajouts fonctionnels accompagnent aussi Silverpeas 6.0 :

l’enrichissement des profils et des annuaires des utilisateurs à l’aide de formulaires (les champs fichier, image et vidéo ne sont pas encore pris en charge par cet enrichissement) ;
une uniformité entre l’agenda personnel et ceux collaboratifs, avec des liens pour passer de l’un à l’autre et la possibilité de retrouver dans son agenda personnel des événements des agendas collaboratifs auxquels on participe ;
Pouvoir importer ou synchroniser un agenda distant avec son agenda personnel. Le support aussi multi-agendas dans l’agenda personnel ;
la notification aux parties prenantes d’une modification de contenu, avec la possibilité de préciser la nature de celle‐ci et de rajouter cette précision en tant que commentaire à la contribution modifiée ;
la possibilité d’avoir une apparence différente par domaine d’utilisateurs ;
une messagerie instantanée basée sur JSXC et le protocole XMPP (actuellement elle utilise le serveur ejabberd, qui nécessite d’être installé et configuré à part).
etc.

Avec la version 6.0 de Silverpeas, un nouvel installateur et lanceur, basé sur Gradle, fait son apparition. Avec celui‐ci, il suffit de saisir la commande suivante pour installer Silverpeas (après avoir récupéré sa distribution) :

$ ./silverpeas install

Pour le mettre à jour vers une nouvelle version (après avoir mis à jour celle‐ci dans le fichier silverpeas.gradle) :

$ ./silverpeas clean install

(la commande clean est pour nettoyer l’installation précédente)

Pour lancer Silverpeas :

$ ./silverpeas start

Pour l’arrêter :

$ ./silverpeas stop

Toujours avec la version 6.0, si vous ne désirez pas récupérer la distribution de Silverpeas pour l’installer vous‐même à la main, une image Docker vous est proposée parmi les dépôts officiels Docker sur le Docker Hub.

De même, vous trouverez aussi, pour essayer Silverpeas, son installateur IzPack, mais aussi une image Docker dédiée à ça sur le dépôt Docker de Silverpeas.

Bref, que d’évolutions majeures pour commencer cette nouvelle lignée de Silverpeas. Un grand merci à sa communauté qui a aidé, testé et surtout supporté le développement de cette nouvelle version.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Silverpeas 5.15 est sortie ... et la 6.0 est en préparation

2015-12-01T16:00:44+01:00

Champagne ! Après plus d'un an de développement, Silverpeas 5.15 est enfin sortie ! Jamais une version évolutive n'aura apporté autant de nouveautés. 75 pour être exact. Sans parler des nombreuses corrections de bogues (environ 76) Silverpeas est un portail collaboratif (gestion des connaissances, espaces collaboratifs métiers, publication et gestion de contenu web, …) fonctionnant sous J2EE, sous licence AGPL.

La version 5.15 devrait être la dernière de Silverpeas 5. En effet, en parallèle à sa réalisation, l'équipe derrière Silverpeas a aussi travaillé et continue à travailler sur la future version 6.0 qui débutera Silverpeas 6. C'est ce qui explique ce temps long. En fait, la majeure partie des nouvelles fonctionnalités de la 5.15 vient d'un report dans Silverpeas 5 de celles prévues pour la 6.0 afin que les utilisateurs existants puissent profiter aussi des nouveautés sans avoir à attendre et à installer la version 6.0.

lien nᵒ 1 : Silverpeas
lien nᵒ 2 : La release note de la 5.15
lien nᵒ 3 : Les paquets deb et rpm
lien nᵒ 4 : Installation en production

Silverpeas 5.15 améliore l'expérience des utilisateurs qu'ils soient administrateurs fonctionnels ou techniques, contributeurs ou simples lecteurs :

de nouvelles applications au catalogue : Boite à idées, Membres de l'espace,
des applications complètement remaniées : Actualités, Formulaires en ligne,
ou encore enrichies : la Galerie d'Images qui devient une Médiathèque,
des fonctionnalités transverses grandement améliorées : le glisser/déposer, l'édition en ligne, les abonnements, les notifications utilisateurs, …
enfin, un travail conséquent a été réalisé afin d'offrir une interface encore plus homogène et ergonomique.

Depuis la première version, Silverpeas 5 n'a cessé de s'enrichir aussi bien du point de vue fonctionnel, ergonomique que technique. À tel point d'ailleurs que la version 5.15 aurait pu être à elle seule une version majeure. Il est temps désormais de passer à un nouveau jalon avec Silverpeas 6. Pour cette version, son socle technique sera rajeuni et modernisé ; il sera désormais basé, en partie, sur Wildfly et sur Java 8. Avec cette mouture, l'accent sera mis sur l'enrichissement conséquent de son interface de services Web de type REST et sur l'amélioration de l'interactivité entre applications. Mais ce qui va surtout changer c'est la direction, avant tout architectural, que prendra Silverpeas 6. Il est prévu en effet à terme de pouvoir découpler l'interface graphique Web du moteur de façon à ce que chacun puisse évoluer de son côté. À partir de là, il sera plus facile de refondre l'IHM en une application de type Single-Page, en partant sur une approche SOFEA (Service Oriented Front End Architecture).

Un grand merci à sa communauté sans qui cette version n'aurait pu être aussi riche.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Développer des applications mobiles multiplateformes avec Java… avec le framework Codename One

2015-07-26T07:40:17+02:00

Codename One est un framework permettant de développer en natif pour iOS, Android, BlackBerry et Windows Phone à partir d'un unique code Java.

Il est open-source (licence GPL avec exception Classpath) et se présente sous la forme d'un plug-in disponible pour les trois environnements de développement majeurs en Java (NetBeans, Eclipse, IntelliJ IDEA (NdM: les deux premiers sont sous licence libre, le dernier existe en version "Community" libre et en version propriétaire). Il a pour particularité d’utiliser le cloud pour la compilation, ce qui évite aux développeurs d'avoir à installer divers SDK ou de posséder un système d’exploitation spécifique indispensable à la programmation des applications pour certaines plateformes mobiles.

Il a été créé par deux anciens ingénieurs d'Oracle, Chen Fishbein et Shai Almog, ceux-là mêmes qui mirent au point la bibliothèque d'interface graphique LWUIT, qui eut son âge d'or à l'heure où le J2ME régnait encore dans le monde de la téléphonie avant d'être détrôné par l'iPhone.

lien nᵒ 1 : Site officiel de Codename One
lien nᵒ 2 : Site d'entraide francophone sur le framework Codename One
lien nᵒ 3 : Présentation de Codename One sur D-BookeR
lien nᵒ 4 : Le livre "Codename One - Développer en Java pour iOS, Android, Blackberry et Windows Phone"

Codename One produit du code natif optimisé, assurant à ses applications de meilleures performances. (NdM: l'accès au code source natif produit n'est pas fourni dans l'offre gratuite de Codename One).

Le plug-in est composé d'une API contenant toutes les classes nécessaires à la conception d'une application mobile, d'un designer, d'un simulateur pour tester les applications sur son ordinateur et du serveur de compilation dans le cloud.

L’une des grandes particularités de Codename One est son architecture dite « lightweight » qui apporte une meilleure solution aux problèmes de fragmentation des plateformes mobiles. Un composant lightweight dans ce cas-ci est un composant écrit entièrement en Java qui dessine sa propre interface tout en gérant ses propres événements et états. Cette manière de faire apporte un énorme avantage en termes de portabilité puisque le même code est exécuté sur toutes les plateformes en plus d’autres avantages. Les composants graphiques de Codename One sont personnalisables.

L’API de Codename One couvre de nombreuses fonctionnalités. On peut y trouver ce qu’il faut pour faire, par exemple, les tâches suivantes :

l'interface graphique ;
la manipulation de la vidéo et de l’audio (enregistrement comme affichage) ;
le stockage ;
l'accès à la caméra ;
la manipulation d'une base de données SQLite ;
la manipulation des services web ;
le réseau ;
l'accès au cloud ;
la lecture des codes barres et QR codes ;
l’internationalisation et la localisation ;
les notifications ;
la manipulation des contacts ;
l'accès aux pages web ;
la monétisation ;
l’accès aux réseaux sociaux ;
la géolocalisation ;
les tests unitaires ;
la création de thèmes personnalisés ;
etc.

Codename One est orienté exclusivement vers la conception d’applications métiers et n’a pas du tout été pensé pour créer des jeux. Quelques efforts sont en train d’être faits dans ce sens, mais rien de concret n’est encore disponible de ce côté.

Pour s'y former, vous disposez de la documentation officielle, complétée par de nombreux articles et tutoriels vidéo, ainsi qu'un forum très actif (en anglais). En outre, un livre vient de paraître en français aux éditions D-BookeR.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Modernisez votre code Java en un clic avec AutoRefactor v1.0.0 !

2015-06-05T08:31:37+02:00

Le 22 mars 2015 est sortie la version 1.0.0 du projet AutoRefactor. Ce logiciel est publié sous Eclipse Public License v1.0 et GNU General Public License v3+.

AutoRefactor restructure automatiquement le code source d'un programme Java afin de :

Faciliter la maintenance en améliorant la lisibilité
- exemple : lorsque toutes les branches d'un if ont les mêmes instructions à la fin des blocs, celles-ci sont déplacées après le if, …
Moderniser le code
- exemple : passer des APIs de java.util.Vector vers celle de java.util.List, …
Appliquer les bonnes pratiques
- exemple : utilisation d’accolades après un if, javadoc bien formés, bonne utilisation des APIs de BigDecimal, TestNG, …
Réduire la taille du code
- exemple : un if imbriqué dans un autre if devient un if unique, suppression des variables locales déclarées juste avant un return, …
Améliorer les performances
- exemple : utiliser Integer.valueOf(int) au lieu de new Integer(int), …

lien nᵒ 1 : Site officiel
lien nᵒ 2 : AutoRefactor sur Github
lien nᵒ 3 : Soirée Autorefactor à l'AlpesJUG 24/02/2015 – Le support
lien nᵒ 4 : Exemples de restructuration de code effectuées par AutoRefactor (tirés de la suite de tests)

Sommaire

Historique
Utilisation
Principe de fonctionnement
- Système de passes successives
  - Attention ! Il faut toujours relire le code modifié automatiquement avant de committer les changements !
  - De la difficulté d’écrire des outils automatiques dans un monde subjectif
- Futur
Appel à contributions

Historique

J'ai commencé ce projet car j'en avais assez de faire les mêmes changements manuellement (ou semi-manuellement avec les refactorings proposés par Eclipse) dans tous les fichiers sur lesquels je travaille. J'ai commencé par utiliser des expressions rationnelles pour retravailler toute la base de code, mais les faux positifs étaient bien trop nombreux, et puisque les expressions rationnelles ne travaillent que sur du texte, toute analyse s'appuyant sur la sémantique du langage (types, variables, etc.) est impossible.
J'ai donc fait diverses expérimentations pour pouvoir faire des analyses « comprenant » le langage. Hélas toutes ces expérimentations ont raté.
Toutes, jusqu’à ce que je crée un greffon Eclipse s'appuyant sur l'API des Java Development Tools (Eclipse JDT). Cette dernière fournit un parser, mais surtout une API pour faire des refactorings. En fait, c'est l'API que l'IDE Eclipse utilise pour ses propres refactorings.

Utilisation

Depuis l'interface d'Eclipse, le développeur sélectionne les fichiers, packages ou projets Java à restructurer, et lance la réorganisation automatique du code. Pour cela, il choisit l’entrée AutoRefactor dans le menu contextuel accessible par un clic doit, ou bien il tape le raccourci clavier Alt+Shift+Y.
Le greffon AutoRefactor restructure alors le code en appliquant automatiquement les refactorings choisis par le développeur.

Principe de fonctionnement

Les restructurations de code sont implémentées par des refactorings successifs, c'est-à-dire des petits changements incrémentaux qui modifient le code sans changer son comportement à l'exécution. Ceci est vrai pour la plupart des refactorings, ceci dit, certains peuvent avoir des effets de bord (voir ci-après), mais un programme sensible à ces changements s'expose à des comportements indéfinis lors de l’exécution.

Système de passes successives

Le greffon travaille avec un système de passes successives. Lorsque le développeur a choisi les règles de refactoring à appliquer, le greffon prend la liste des refactorings et (algorithme simplifié) :

le fichier Java à analyser est parsé et produit un arbre syntaxique abstrait (AST en anglais)
pour chaque refactoring :
1. cherche des opportunités de refactoring en visitant l'arbre syntaxique abstrait
2. génère les réécritures de code lorsqu'une opportunité de refactoring a été identifiée
lorsque tout l'arbre syntaxique abstrait a été visité, si des réécritures de code ont été générées :
1. alors, toutes les réécritures de code générées sont appliquées sur le fichier
2. le fichier est sauvegardé
3. boucle vers 1.
4. sinon, fin : il n'y a plus de refactorings possibles sur ce fichier Java

Actuellement, tous les refactorings implémentés font du filtrage par motif (pattern matching) et travaillent fichiers par fichiers.

Du coup, il est extrêmement facile de paralléliser le code : le greffon lance autant de fils d’exécution en arrière-plan qu'il y a de processeurs disponibles et utilise une simple liste de tâches pour leur fournir du travail. Chaque tâche consiste à analyser et restructurer un fichier Java.

Bien sûr, le greffon dispose d'une suite de tests composée de paires de fichiers exemples Java : un fichier avant restructuration, un autre fichier contenant le résultat que l'on souhaite obtenir après restructuration. La suite de tests unitaires exécute chaque règle de refactoring indépendamment sur sa paire de fichiers et compare la sortie attendue avec la sortie obtenue. Les deux doivent correspondre. La compilation et les tests unitaires sont exécutés sur un serveur d’intégration continue.
Je vous encourage très vivement à regarder les exemples tirés de la suite de tests.

Par ailleurs, je teste plus avant les refactorings sur la base de code mature d'OpenDJ. Cela me permet de trouver pas mal de bugs avant qu'ils n'atteignent une version stable et donc de rajouter des cas de tests. Le code mature est bien plus sournois que les cas de tests auxquels on peut penser ! :)

Attention ! Il faut toujours relire le code modifié automatiquement avant de committer les changements !

En effet, voici un exemple de code pour lequel les changements ont modifié le comportement :

Integer i1 = 0;
Integer i2 = new Integer(0);
if (i1 == i2) { // compare des références d'objets !
    System.out.println("OK");
}

Ici, "OK" n'est pas affiché sur le terminal car i1 et i2 sont deux objets différents en mémoire.
Maintenant si AutoRefactor modifie le code comme ceci :

Integer i1 = 0;
Integer i2 = Integer.valueOf(0);
if (i1 == i2) { // compare des références d'objets !
    System.out.println("OK");
}

"OK" sera affiché sur le terminal car i1 et i2 référencent le même objet en mémoire.
Comment est-ce possible ? Et bien la ligne Integer i1 = 0; est en fait générée comme ceci par le compilateur java : Integer i1 = Integer.valueOf(0);. De plus il existe un cache pour les objets Integer entre -128 et 127 (inclus), ce qui fait que i1 et i2 référencent le même objet en mémoire.
Ce code aurait probablement du être écrit comme ceci :

int i1 = 0;
int i2 = 0;
if (i1 == i2) { // compare la valeur des entiers !
    System.out.println("OK");
}

Et le code aurait correctement affiché "OK" sur le terminal.
AutoRefactor ne sait pas encore le faire, mais j’espère y arriver un jour.

Cet exemple démontre que certains refactorings ne préservent pas totalement le comportement lorsque le code s'appuie sur des comportements « limites » de Java.
Cependant il est possible que ce soit bien le comportement désiré par le programmeur.

C'est pourquoi il est recommandé de toujours relire les refactorings automatiques avant des les committer dans le gestionnaire de sources. Vous utilisez bien un gestionnaire de source, n'est-ce pas ?

De la difficulté d’écrire des outils automatiques dans un monde subjectif

Après avoir mis ce gros bémol, je tiens à signaler que j'essaie d’avoir un résultat final propre et logique. Je suis pragmatique : soit j'essaie absolument de préserver le comportement du programme, et dans ce cas, je ne fais presque rien ; soit je prends des risques « mesurés » en ignorant les cas « bêtes » comme celui-ci dessus, et alors j'autorise beaucoup plus de possibilités de refactorings.
C'est un équilibre dur à trouver dans certains cas tel qu'illustré par la méthode isHardToRead(). Bien sûr, c'est éminemment subjectif, mais puisque c'est moi qui code, j'impose mes idées. :) Plus sérieusement, si vous pensez que j'ai tort, je suis ouvert à discussion.

J'avais d'ailleurs pensé rajouter une préférence pour forcer à préserver le comportement, mais j'ai renoncé lorsque je me suis rendu compte du nombre de refactorings que cela interdirait. Par exemple, un code aussi simple que celui-ci :

System.out.println("this is " + obj.toString());

ne pourrait plus être réécrit comme ceci :

System.out.println("this is " + obj);

En effet, on perdrait la vérification sur référence nulle. Si obj est null, la première écriture lève une NullPointerException, alors que la deuxième écriture imprime "this is null". Bien sur, il serait peut-être possible de détecter qu'obj n'est pas null en faisant une analyse du flot de contrôle (j'ai bien dit peut-être), mais cela nécessite des outils dont je ne dispose pas encore. Par pragmatisme, j'ai simplement considéré que s’appuyer sur un appel à toString() pour détecter une référence nulle était une mauvaise pratique dans ce cas, et j'ai quand même écrit la règle qui fait cette réécriture :)

Futur

Même si tous les refactorings actuellement implémentés font du filtrage par motif, j’espère bien parvenir un jour à faire de l'analyse de flot de contrôle en construisant un graphe de flot de contrôle (CFG an anglais). Ceci permettrait d’écrire des refactorings comprenant les chemins d’exécution du code, comme le ferait un développeur qui lirait du code. En particulier, il deviendrait possible de réduire la portée des variables, comprendre quels chemins d’exécution du code sont morts (impossibles à atteindre)

J'aimerai aussi développer une autre fonctionnalité : l'extraction (semi-?)automatique de méthodes.
Voici un exemple de code que je vois trop souvent :

    // ... quelques dizaines / centaines de lignes de code
    boolean found = false;
    for (String s : strings) {
        if (toFind.equalsIgnoreCase(s2)) {
            found = true;
            break;
        }
    }
    if (found) {
        // faire quelque chose
    }
    // ... quelques dizaines / centaines de lignes de code

Comment simplifier cette longue méthode ?
En extrayant une nouvelle méthode, comme ceci :

    // ... quelques dizaines / centaines de lignes de code
    if (containsIgnoreCase(strings, toFind)) {
        // faire quelque chose
    }
    // ... quelques dizaines / centaines de lignes de code
}

private boolean containsIgnoreCase(Collection<String> strings, String toFind) {
    for (String s : strings) {
        if (toFind.equalsIgnoreCase(s2)) {
            return true;
        }
    }
    return false;
}

La plus grosse difficulté, c'est de savoir comment nommer la nouvelle méthode, et un humain doit intervenir, d’où le coté semi-automatique.

Le support de Java 7 arrive doucement avec le support de refactorings générant l'opérateur diamant '<>' (pas de besoin de répéter les types génériques), et le multi-catch (pas besoin de copier-coller le même bout de code dans deux blocs catch différents).
Par exemple, le code suivant :

List<String> strings = new ArrayList<String>();

try {
    // plus de code
} catch (IllegalArgumentException e) {
    e.printStackTrace();
} catch (NullPointerException e) {
    e.printStackTrace();
}

Peut être réécrit comme ceci en Java 7 :

List<String> strings = new ArrayList<>();

try {
    // plus de code
} catch (IllegalArgumentException | NullPointerException e) {
    e.printStackTrace();
}

La version 1.1.0 à venir a beaucoup de bonnes et nouvelles choses disponibles. Je vous conseille de l'installer depuis les nightlies.

Appel à contributions

J’espère que la présentation de ce greffon vous aura intéressé.

Si vous êtes un développeur Java, je vous encourage à l'installer :

Depuis l'update site http://autorefactor.org/releases/
Depuis l'Eclipse marketplace:
Pour les aventureux, installez une nightly depuis l'update site http://autorefactor.org/nightly/

Si vous êtes vraiment enthousiasmés et que vous voudriez l’améliorer ou l'adapter à vos besoins, n’hésitez surtout pas ! Envoyez des rapports de bugs, des pull-requests, interagissez sur gitter, etc.

Si vous voulez aider, mais que vous êtes à court d’idées, voici une petite liste :

Testez le logiciels sur de grosses bases de code anciennes. C'est là où se cachent les surprises. :)
Je suis aussi intéressé par des retours d’expériences, blog posts ou autres… Faites connaître ce greffon auprès de vos collègues !
J'ai plein d’idées dans le bug tracker, mais pas assez de temps pour les implémenter. Si jamais le cœur vous en dit…
Le site web est moche, et a besoin d'amour
Le greffon n'a pas encore de logo malgré mes misérables tentatives.

Je m'amuse bien à réécrire le code automatiquement. Franchement, ce n'est pas trop difficile ou trop long d'ajouter de nouvelles règles, alors n’hésitez pas à vous lancer ! Je vous aiderai.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Sortie de LDAP Synchronization Connector 2.1.0

2014-05-21T16:42:35+02:00

Le logiciel LDAP Synchronization Connector est un moteur de synchronisation entre annuaires LDAP, bases de données, fichiers, et autres sources (API REST, etc.). Il est particulièrement efficace pour diffuser les données d'utilisateurs et de groupes entre son annuaire d'entreprise, un serveur Active Directory, une base de données d'application. On peut le classer dans la catégorie des logiciels de Méta-annuaire ou de gestionnaire d'identités (IDM en anglais).

La version 2.1.0 vient d'être publiée, avec son lot de nouveautés et de correctifs, décrits dans la suite de la dépêche.

Ndm : LSC est livré sous licence BSD.

lien nᵒ 1 : Annonce de la sortie sur la forge du projet
lien nᵒ 2 : Téléchargement
lien nᵒ 3 : Site web
lien nᵒ 4 : Dépêche sur la sortie de LSC 1.0
lien nᵒ 5 : Conférence LSC à la LDAPCon 2013

Scripts Javascript et Groovy

Pour configurer les règles d'association d'attributs entre source et destination, ou les conditions de création/modification/suppression/renommage d'entrées, LSC permet d'utiliser des langages de script comme Javascript et Groovy.

La version 2.1.0 améliore ce support de plusieurs manières :

le debugger Rhino peut être activé grâce au préfixe rdjs:
des fichiers externes peuvent être utilisés pour simplifier le code écrit dans la configuration XML.

Paquets

LSC est désormais livré sous forme de paquets Rpm et Debian en plus de la distribution traditionnelle. Des dépôts Yum et Apt ont été mis en place, il n'y a donc plus d'excuse pour ne pas l'installer.

Correctifs

De nombreux bogues ont été corrigés dans cette nouvelle version, en particulier sur la gestion des attributs binaires, sur l'encodage des DN et le mode dry-run. La liste complète des changements est visible sur la forge du projet

Greffons

LSC possède un système de greffons encore peu exploité jusqu'ici. Ces greffons permettent d'ajouter des sources et/ou des destinations possibles pour les connecteurs. Les greffons disponibles pour la version 2.1 sont :

Exécutable: lance des scripts pour chaque action de synchronisation
NIS: interroge un annuaire NIS (Yellow Pages)
OBM: met à jour les utilisateurs et les groupes dans OBM

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

OpenJDK JEP 180: HashMap, collisions & attaques par la complexité

2014-05-06T08:58:52+02:00

Cette dépêche parle de la JEP 180 d'OpenJDK 8 qui propose une solution intéressante aux problèmes d'attaques sur la complexité que rencontrent les tables de hachage.

On a déjà parlé de ce sujet ici même à plusieurs reprises. Je vais cependant rapidement représenter le problème et l'évolution des discussions. Le lecteur averti sur le sujet ira directement au dernier paragraphe pour voir la proposition de la JEP 180.

NdM : merci à ckyl pour son journal.

lien nᵒ 1 : Journal à l'origine de la dépêche
lien nᵒ 2 : Dépêche précédente sur la JEP 142

Sommaire

Présentation des tables de hachage
Attaques par la complexité
Java 7u6 & « alternative string-hashing »
Attaques par la complexité (bis)
JEP 180: Une solution intéressante
- Conclusion

Présentation des tables de hachage

Une table de hachage est une implémentation du type abstrait tableau associatif. Un tableau associatif permet d'associer une clé à une ou plusieurs valeurs, on le nomme aussi parfois dictionnaire. Il fait partie des types abstraits les plus utilisés avec les listes.

Une table de hachage est une implémentation particulière d'un tableau associatif. Elle est aussi la plus courante. Basiquement il s'agit d'un tableau dont les cases contiennent un pointeur vers nil, un élément ou une liste d'élément. On détermine la case à utiliser en appliquant une fonction de hachage à la clé. Idéalement, chaque case ne pointera que vers un unique élément. Dans ce cas les opérations d'insertion, de consultation et de suppression se font en temps constant, noté , c'est à dire qui ne dépend pas du nombre d'éléments présents dans la table de hachage. Cependant si la fonction de hachage retourne deux fois la même valeur pour deux clés différentes, ce que l'on nomme collision, alors les deux valeurs sont généralement stockées comme une liste. C'est à dire que maintenant il va falloir parcourir toute cette liste. Dans le pire cas, la fonction de hachage retourne toujours la même valeur, toutes les valeurs vont donc être stockées dans la même case et l'on va devoir parcourir la liste pour chaque opération. La complexité est alors linéaire par rapport au nombre d'éléments dans la structure, noté , ce qui est très peu performant. Une table de hachage a donc une complexité moyenne d' mais un pire cas en . Il est donc crucial d'avoir une fonction de hachage performante. Les personnes n'étant pas à l'aise avec l'implémentation d'une table de hachage ou les concepts précédant auront tout intérêt à consulter la page Wikipédia qui est assez complète.

Cet article s'accompagne d'un benchmark écrit avec JMH qui va nous permettre d'observer comment se comporte la classe HashMap de Java dans différentes circonstances. Le code de ce benchmark est extrêmement simple:

  @GenerateMicroBenchmark
  public int put() {
    HashMap<String, Object> map = new HashMap<String, Object>();

    for (String s: strings) {
      map.put(s, s);
    }

    return map.size();
  }

Nous insérons une collection de chaîne de caractère dans une HashMap et nous mesurons le temps moyen de cette opération. Mesurer l'insertion est une métrique correcte pour ce que nous souhaitons mesurer car lors d'une insertion, dans le cas où la clé existe déjà il faut remplacer la valeur existante. Il faut donc rechercher parmi toutes les clés déjà existantes dans cette case. Les comportements en consultation et en suppressions seront similaires à celui que nous observons. Dans tous les cas, en cas de collision, il faudra traverser toutes les valeurs de cette case. Exemple du code de la méthode put():

    public V put(K key, V value) {
        if (key == null)
            return putForNullKey(value);
        int hash = hash(key.hashCode());
        int i = indexFor(hash, table.length);
        for (Entry<K,V> e = table[i]; e != null; e = e.next) {
            Object k;
            if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                V oldValue = e.value;
                e.value = value;
                e.recordAccess(this);
                return oldValue;
            }
        }

        modCount++;
        addEntry(hash, key, value, i);
        return null;
    }

On peut clairement y voir les étapes suivantes:

On calcule le hash de la clé, qui va déterminer la case i
On itère sur toutes les clés présentes dans la case i pour regarder si une correspond à key
- Si oui, alors on remplace la valeur existante par value
- Sinon, on ajoute un nouvel élément pour cette clé à la fin de la liste

Comme on le voit avec la ligne suivante int hash = hash(key.hashCode());, en Java la case est calculée à partir de la valeur retournée par hashCode(). On applique en plus la fonction hash() afin d'améliorer un peu la distribution des clés. En effet, i est calculé modulo la taille de la table qui est une puissance de deux, et il est facile d'avoir des effets néfastes:

   /**
     * Applies a supplemental hash function to a given hashCode, which
     * defends against poor quality hash functions.  This is critical
     * because HashMap uses power-of-two length hash tables, that
     * otherwise encounter collisions for hashCodes that do not differ
     * in lower bits. Note: Null keys always map to hash 0, thus index 0.
     */
    static int hash(int h) {
        // This function ensures that hashCodes that differ only by
        // constant multiples at each bit position have a bounded
        // number of collisions (approximately 8 at default load factor).
        h ^= (h >>> 20) ^ (h >>> 12);
        return h ^ (h >>> 7) ^ (h >>> 4);
    }

Enfin le cas qui va nous intéresser particulièrement ici est celui des chaines de caractères comme clé car c'est une utilisation extrêmement courante et exposée aux attaques. Souvent les données fournies par l'utilisateur sont des chaînes de caractères plutôt que des objets complexes. Par exemple les en-tête HTTP sont souvent stockés dans un tableau associatif.

Regardons donc comment est implémenté le hashCode de la classe String:

   /**
     * Returns a hash code for this string. The hash code for a
     * <code>String</code> object is computed as
     * <blockquote><pre>
     * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
     * </pre></blockquote>
     * using <code>int</code> arithmetic, where <code>s[i]</code> is the
     * <i>i</i>th character of the string, <code>n</code> is the length of
     * the string, and <code>^</code> indicates exponentiation.
     * (The hash value of the empty string is zero.)
     *
     * @return  a hash code value for this object.
     */
    public int hashCode() {
        int h = hash;
        int len = count;
        if (h == 0 && len > 0) {
            int off = offset;
            char val[] = value;

            for (int i = 0; i < len; i++) {
                h = 31*h + val[off++];
            }
            hash = h;
        }
        return h;
    }

Cela correspond à une fonction de hachage non cryptographique très courante pour les chaînes de caractères. C'est une variante du Bernstein hash, aussi appelé djb2. Elle a ceci d'intéressant qu'elle est utilisée par beaucoup de plateformes et qu'expliquer pourquoi elle marche et comment et pourquoi ont été choisies les valeurs est assez difficile. Les gens intéressés pourront découvrir d'autres fonctions ainsi que passer beaucoup de temps à chercher les réponses à la question précédente.

Dans tous les cas nous appellerons cette variante de dbj2 sous le doux nom de DJBX31A.

Maintenant exécutons notre benchmark en utilisant Java 6u45 avec des chaines aléatoires de taille constante, 15 caractères, pour des collections allant de 10 à 30.000 éléments. Le résultat est le suivant:

Dans ce cas nous avons le comportement normal attendu. Il y a peu de collisions. En moyenne le temps d'insertion est constant et ne dépend pas de la taille de la collection, . Nous voyons donc que la courbe est linéaire puisque nous répétons fois une opération prenant un temps donné. Nous voyons aussi que nous arrivons à insérer environ 20 000 éléments par milliseconde.

Attaques par la complexité

Si vous avez bien suivi la première partie, vous savez que la performance d'une table de hachage dépend du nombre de collisions et donc de la qualité de sa fonction de hachage. Par nature une table de hachage ne permet pas de garantir que les opérations seront en , il s'agit seulement du cas moyen quand tout se passe bien. La performance au pire cas est .

Ce fait est connu de tout étudiant ayant suivi une introduction à l'algorithmique. Seulement il y a quelques années certains ont eu l'idée d'utiliser ce pire cas pour faire des dénis de service. C'est une attaque par la complexité. L'idée est simple, beaucoup d'applications stockent en mémoire des chaînes de caractères fournies par un utilisateur dans une table de hachage. S'il arrive à fournir des chaînes qui vont systématiquement créer des collisions, alors il va pouvoir ralentir très fortement le système.

L'idée n'est pas nouvelle, elle a été parfaitement documentée en 2003 par Scott A. Crosby et Dan S. Wallach lors de l'Usenix-Sec. Ils avaient alors étudié Perl, qui avait réagi et fourni un correctif. Tout le monde a alors oublié cette histoire pendant quelques années.

En 2011, Alexander Klink et Julian Wälde se souviennent de cette histoire et partent alors explorer ce qu'il est possible de faire avec presque 10 ans après. Les slides du 28C3 décrivent très bien ce qu'ils trouvent. En gros presque toutes les plateformes majeures sont vulnérables de PHP à Java en passant par Python puisque tout le monde ou presque utilise une variante de djb2, pour lequel il est très facile de générer des collisions. Le résultat c'est qu'on peut faire un déni de service sur à peu près n'importe quoi avec très peu de données. Avec 2 MB de données ils arrivent à occuper un processeur pendant plus d'une demi-heure.

Le benchmark suivant compare la courbe précédente avec une où toutes les clés se retrouvent dans la même case car on génère spécialement les clés pour que DJBX31A retourne toujours la même valeur bien que les chaînes soient différentes.

Comme on peut le voir l'effet est plutôt dramatique. Chaque insertion dépend donc maintenant du nombre d'éléments dans la table de hachage. Si vous vous rappelez du code de la méthode put(), nous avons à parcourir tous les éléments à chaque fois. Puisque nous allons insérer un nouvel élément, il faut vérifier tous les autres. La courbe devient donc quadratique. Pour 20 000 éléments on peut voir que l'on est déjà 1000 fois plus lent. Vous pouvez facilement extrapoler pour 50 000 ou 100 000.

Java 7u6 & « alternative string-hashing »

Comme la plupart des plateformes impactées par cette découverte, Java cherche une solution. Et beaucoup vont choisir une solution similaire. L'idée est qu'il faut empêcher un utilisateur de pouvoir générer des collisions. Une solution est d'utiliser des fonctions de hachage cryptographiques qui sont conçues pour cela. En pratique ce n'est pas possible car elles sont beaucoup trop lentes (grossièrement il y a au minimum un ordre de grandeur d'écart). Le consensus est alors de migrer vers une autre fonction de hachage: Murmur 2 ou 3. Murmur est une bonne fonction de hachage non cryptographique, elle est rapide et fournit de bons résultats. En plus on peut l'initialiser avec une graine qui va conditionner la valeur de sortie. L'idée est donc de générer la graine à l'exécution. Il devient alors compliqué pour l'utilisateur de générer des collisions car il a besoin de la graine et qu'il n'y a pas accès.

Python utilise cette solution et décide de changer sa fonction de hachage pour Murmur.

Java veut faire de même mais a un problème supplémentaire. La Javadoc de la méthode hashCode de String documente l'implémentation sous-jacente:

 /**
     * Returns a hash code for this string. The hash code for a
     * <code>String</code> object is computed as
     * <blockquote><pre>
     * s[0]*31^(n-1) + s[1]*31^(n-2) + ... + s[n-1]
     * </pre></blockquote>
     * using <code>int</code> arithmetic, where <code>s[i]</code> is the
     * <i>i</i>th character of the string, <code>n</code> is the length of
     * the string, and <code>^</code> indicates exponentiation.
     * (The hash value of the empty string is zero.)
     *
     * @return  a hash code value for this object.
     */

DJBX31A fait donc partie du contrat de la classe, et on ne peut pas le changer sans risque de casser la compatibilité et le comportement des applications. C'est une règle stricte du côté de Java.

Pour cette raison on imagine donc ce qui est pour moi l'un des patchs les plus dégueulasses de l'histoire du JDK qui a été livré en Java 7u6. En gros on ne touche à rien de ce qui existe. On rajoute une nouvelle méthode hash32 à la classe String qui repose sur Murmur.

   int hash32() {
        int h = hash32;
        if (0 == h) {
           // harmless data race on hash32 here.
           h = sun.misc.Hashing.murmur3_32(HASHING_SEED, value, 0,
value.length);

           // ensure result is not zero to avoid recalcing
           h = (0 != h) ? h : 1;

           hash32 = h;
        }

        return h;
    }

Maintenant on patche les collections utilisant des fonctions de hachage pour faire la chose suivante : on regarde le type de l'élément, si c'est String alors on invoque hash32 par une introspection dédiée car la méthode n'est pas publique, sinon on invoque hashCode. Seulement les String sont immutables, et la valeur de hashCode était cachée pour éviter de la recalculer à chaque fois. On doit donc faire de même avec hash32 qui impose donc 4 octets supplémentaire à chaque instance de String. Pour finir on initialise HASHING_SEED dynamiquement à l'initialisation pour empêcher les collisions.

C'est cool on n'a pas touché à hashCode ! Seulement voilà le comportement des applications peut toujours changer même en remplaçant la fonction de hachage uniquement dans les collections. Alors on rajoute un flag pour décider si on veut oui ou non utiliser le alternative string-hash dans les collections.

Voir le courriel sur la liste de discussion d'OpenJDK ainsi que le patch.

Voilà ça pique les yeux mais ça fait le job ! Refaisons tourner le même benchmark avec Java 7u55:

Ah oui j'ai dit qu'il y avait une option pour l'alternative string-hashing mais j'ai pas dit qu'elle était activée par défaut… Recommençons avec -Djdk.map.althashing.threshold=1

C'est mieux non ? Bon OK par défaut on est toujours vulnérable trois ans après…

Attaques par la complexité (bis)

Seulement voilà, entre temps quelques-uns ont commencé à creuser le problème. Ils ont attaqué Murmur3 avec graine qui n'a pas tenu très longtemps. Ca a d'ailleurs été présenté au 29c3. Dans les speakers on notera DJB, oui c'est le même.

Rebelote, tous ceux qui sont passés à Murmur sont impactés ainsi que quelques copains dont les fonctions ont aussi été cassées. C'est un peu moins trivial de générer des collisions avec Murmur mais le travail difficile a été fait pour nous. On n'a qu'à écrire le code…

Essayons de refaire tourner notre benchmark en générant des collisions contre Murmur:

Cette fois nous comparons le comportement usuel avec:

Des collisions contre DJBX31A sans l'alternative string-hashing
Des collisions contre Murmur3 avec l'alternative string-hashing

(Je n'ai pas investigué les deux points à 15k et 25k qui sont très étranges. Le générateur passe les tests unitaires et les résultats eux sont stables…)

C'est grosso modo la même chose. On a donc fait un patch moche qui ne sert plus à rien puisque dans les deux cas on est vulnérable…

JEP 180: Une solution intéressante

Maintenant qu'est-ce qu'on fait ?

En même temps qu'ils ont cassé Murmur avec graine, DJB et ses potes ont proposé une nouvelle fonction de hachage: SipHash. Elle est vendue comme étant aussi rapide que les précédentes mais résistante aux attaques par collisions.

La plupart des plateformes ont migré vers SipHash, Python par exemple. Et comme on s'est déjà fait avoir une fois on en profite pour faire la PEP 456 qui permet d'avoir des fonctions de hash interchangeable pour les chaîne de caractères et tableaux d'octets. On bascule à SipHash mais comme on sait que ça risque de recommencer, on prévoit le coup…

Du côté de Java on a toujours le même problème avec hashCode, rechanger hash32 fait prendre quelques risques aussi et le patch initial étant "crado" on aimerait bien s'en débarrasser. On choisit donc une approche radicalement différente. Plutôt que de chercher une fonction de hachage parfaite, on rebascule sur DJBX31A. On s'applique plutôt à résoudre le problème du au pire cas. Le vient du fait que les collisions sont gérées avec une liste chaînée. Si on utilise un arbre balancé plutôt qu'une liste on passe en ce qui réduit drastiquement le problème.

C'est ce que propose la JEP 180 et qui a été implémenté dans OpenJDK 8.

Refaisons tourner notre benchmark sur OpenJDK 8:

Cette fois ci nous comparons le comportement normal d'OpenJDK 8 et Java 7u55 ainsi que le comportement d'OpenJDK8 avec des collisions.

Tout d'abord nous constatons que les performances dans le cas normal n'ont pas régressé. Ensuite nous voyons que contrairement à une solution qui vise a prévenir entièrement les collisions, l'utilisation d'arbre balancé a tout de même un coût. Les opérations passent de à . Cependant si on regarde les chiffres ce n'est pas dramatique. À 20 000 éléments nous sommes maintenant à ~10ms plutôt que ~1ms loin de la seconde initiale.

Nous avons regardé le point de vue performance, cependant utiliser des arbres balancés a aussi un impact non négligeable sur la consommation mémoire. En effet au lieu d'avoir à stocker un bête pointeur sur l'élément suivant, on se retrouve avec quatre pointeurs et un booléen. Ce qui pourrait faire exploser la consommation mémoire. Cependant par défaut on utilise toujours une liste chaînée. Quand le nombre de collisions augmente dans une case et dépasse un seuil on convertit tout ou une partie de la liste en arbre balancé pour optimiser le ratio consommation mémoire/performance. Cette technique est appliquée à chaque feuille de l'arbre. On démarre avec une liste, puis on convertit la feuille en arbre quand elle devient trop grande. Quand on supprime des éléments on peut rebasculer vers une liste chaînée. Les seuils de conversion étant respectivement à 8 et 6 éléments.

Si l'on observe la consommation mémoire avec Jol on peut voir que ça marche très bien:

Ici on a fait attention à ce que les chaînes aient toujours la même taille dans les deux cas.

En pratique dans une utilisation courante avec une fonction de hachage correcte, les collisions seront rares et les arbres balancés ne seront jamais utilisés. Par contre quand ils rentrent en action cela permet d'éviter les DOS ou simplement d'avoir de bonnes performances quand la fonction hashCode de l'utilisateur est biaisée.

J'invite le lecteur intéressé à aller regarder le code. Le commentaire initial explique extrêmement clairement comment ça fonctionne et c'est plutôt rigolo à lire.

Conclusion

L'approche d'OpenJDK 8 est intéressante et différente des autres plateformes puisqu'elle ne cherche pas à résoudre le problème des collisions mais à améliorer le pire cas. Changer de fonction de hachage pour les String étant compliqué on peut comprendre ce choix. Ils ont fait le pari que les performances offertes par les arbres balancés suffiront à se protéger et à offrir une bonne robustesse aux mauvaises fonctions de hachage. En pratique, au pire cas on observe un ralentissement constant de ~10x quelle que soit la taille de la collection.

De l'autre côté beaucoup de plateformes ont changé de fonction de hachage pour éviter le pire cas mais n'ont pas cherché à l'améliorer et sont restés aux listes chainées. Ils se protègent donc des dénis de service selon les connaissances actuelles mais ne cherchent pas à se protéger pour le futur ni à offrir une réponse performante aux fonctions de hachage qui pourraient être légèrement biaisées pour certains autres types de données car implémentées par l'utilisateur.

Dans l'idéal les deux techniques devraient être appliquées mais je ne connais pas de plateforme qui le fasse. Et vous les outils que vous utilisez ils ont fait quoi ?

Voilà c'est un problème pas nouveau mais on en entendra certainement à nouveau parler. Dès qu'on lit une valeur du monde extérieur, celui-ci va s'arranger pour trouver un moyen de faire des choses "sympas". Les attaques algorithmiques permettent de varier un peu les plaisirs et forcent à s'interroger longuement à chaque fois qu'on stock une valeur que l'on ne contrôle pas.

Note: Tout le matériel créé pour écrire l'article est en ligne.

NdM : Pour ceux qui se demandent comment sont fait les graphiques, ils s'agit du mode xkcd de matplotlib comme expliqué par l'auteur dans les commentaires du journal à l'origine de la dépêche.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

OpenJDK 8, JEP 142 & False Sharing

2014-04-02T20:48:58+02:00

Java 8 est sorti ce mois‐ci et vous avez même eu droit à une dépêche, ici‐même, qui parle des lambdas, de l’API flux (stream API), etc.

Cependant, derrière ces gros changements qui impactent le monde hétérogène des développeurs Java, il y a des petits changements qui eux servent plutôt aux développeurs qui font des briques de base, de l’infrastructure ou du code qui va vite. Je vous propose donc d’explorer quelques JDK Enhancement Proposals d’OpenJDK.

Pour cette première dépêche, on commence avec la JEP 142 : Reduce Cache Contention on Specified Fields soit l’annotation @Contended qui vise à proposer une solution aux problèmes de false sharing.

NdM : merci à ckyl pour son journal.

lien nᵒ 1 : Journal à l’origine de la dépêche
lien nᵒ 2 : LinuxFr.org : Java 8 et NetBeans 8 sont disponibles
lien nᵒ 3 : Nouveautés du JDK 8
lien nᵒ 4 : JEP 142: Reduce Cache Contention on Specified Fields

Sommaire

Le false sharing est un problème de performance en environnement parallèle qui est causé par une « leaky abstraction » du matériel. La présentation suivante est extrêmement grossière et ne vise qu’à faire comprendre le problème aux gens ne connaissant pas du tout le domaine.

En tant que développeur, on aime se représenter la mémoire comme un espace d’adressage continu. Plus on travaille dans un langage de haut niveau, plus cela est vrai. Par exemple, les problèmes d’alignement sont une notion totalement inconnue pour beaucoup. Cependant, dans ce monde idéal, la réalité du matériel refait surface périodiquement.

Un processeur étant beaucoup plus rapide que la mémoire vive et le principe de localité ayant été découvert, il dispose de caches mémoire. Ce sont des petits morceaux de mémoire tampon travaillant à une vitesse beaucoup plus proche de celle du processeur. Le pari étant qu’une fois l’accès coûteux à la mémoire centrale effectué, cette valeur va être réutilisée et on ira alors la chercher dans ce cache en gagnant énormément de temps.

Le problème du false sharing vient de deux choses :

L’architecture des caches. Un cache est composé d’un certain nombre de lignes de taille fixe (64 octets, par exemple). Lorsqu’une modification est faite, elle affecte la ligne entière.
Le processeur doit gérer la cohérence entre ces caches à l’aide d’un protocole de cohérence. Il s’agit de s’assurer que lorsqu’un processeur ou un cœur fait une modification, elle sera visible par les autres. Chaque architecture a son propre modèle de cohérence, le x86 étant, par exemple, particulièrement fort. Ce modèle est exposé dans les langages de bas niveau, mais les langages de haut niveau décrivent souvent leur propre modèle mémoire. Charge au compilateur de traduire celui du langage vers celui de la plate‐forme.

Si l’on met ces deux choses ensemble, on arrive au false sharing : deux variables théoriquement indépendantes se retrouvent sur la même ligne de cache. Chacune est lue ou modifiée par un processeur distinct, cependant les processeurs doivent passer leur temps à se synchroniser, et les performances s’écroulent.

Bref, notre bel espace mémoire uniforme vient d’en prendre un coup. Coller ou espacer deux variables peut faire varier d’un à plusieurs ordres de grandeur la performance de notre structure de données.

Exemple

Commençons avec un banc d’essai très simple : une classe avec un seul membre et quatre fils d’exécution (threads). Le premier lit en permanence la valeur de ce membre, les trois autres ne font rien. Le banc d’essai est écrit avec JMH :

  @State(Scope.Benchmark)
  public static class StateNoFalseSharing {
    public int readOnly;
  }

  @GenerateMicroBenchmark
  @Group("noFalseSharing")
  public int reader(StateNoFalseSharing s) { return s.readOnly; }

  @GenerateMicroBenchmark
  @Group("noFalseSharing")
  public void noOp(StateNoFalseSharing s) { }

Ce qui nous donne le résultat suivant :

Benchmark                                        Mode   Samples         Mean   Mean error    Units
g.c.Benchmarks.noFalseSharing:noOp               avgt        18        0.297        0.002    ns/op
g.c.Benchmarks.noFalseSharing:reader             avgt        18        0.743        0.003    ns/op

Comme on pouvait s’y attendre, c’est très rapide, et on aura du mal à mesurer quelque chose de plus petit.

Maintenant, faisons évoluer notre banc d’essai. Nous ajoutons un deuxième membre qui va être accédé par les trois fils d’exécution qui ne faisaient rien. Le premier fil ne change absolument pas et, si les caches n’étaient pas organisés en ligne, il n’y aurait aucune raison que sa performance soit affectée.

  @State(Scope.Group)
  public static class StateFalseSharing {
    int readOnly;
    volatile int writeOnly;
  }

  @GenerateMicroBenchmark
  @Group("falseSharing")
  public int reader(StateFalseSharing s) {
    return s.readOnly;
  }

  @GenerateMicroBenchmark
  @Group("falseSharing")
  public int writer(StateFalseSharing s) {
    return s.writeOnly++;
  }

Regardons les résultats :

Benchmark                                        Mode   Samples         Mean   Mean error    Units
g.c.Benchmarks.falseSharing:reader               avgt        18        5.038        0.617    ns/op
g.c.Benchmarks.falseSharing:writer               avgt        18       78.530        3.598    ns/op

On vient presque de gagner un facteur 10.

Nous pouvons vérifier l’agencement mémoire de notre objet StateBaseline avec jol, pour voir que nos deux variables ont bien été juxtaposées par le compilateur :

gist.contended.Benchmarks.StateFalseSharing object internals:
 OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
      0    12       (object header)                N/A
     12     4   int StateFalseSharing.readOnly     N/A
     16     4   int StateFalseSharing.writeOnly    N/A
     20     4       (loss due to the next object alignment)
Instance size: 24 bytes (estimated, the sample instance is not available)
Space losses: 0 bytes internal + 4 bytes external = 4 bytes total

Sans rentrer dans les détails, statistiquement, il y a de fortes chances qu’elles se retrouvent dans la même ligne de cache.

@Contended

La solution à notre problème est donc simplement d’espacer ces deux variables, quitte à perdre de l’espace. Ça paraît simple, mais, avant OpenJDK 8, cela demandait de très sérieusement connaître la machine virtuelle Java (ou lutter contre elle).

Fort du principe de localité, le comportement logique de la machine virtuelle Java est d’essayer d’entasser autant que possible les différents membres comme bon lui semble. La disposition (layout) d’un objet peut changer selon beaucoup de critères. Et l’utilisation d’un ramasse‐miettes n’aide pas, puisque ce dernier peut décider de déplacer un peu tout et n’importe quoi (notamment les tableaux utilisés pour les aligner). Bref, trouver une stratégie qui marche, est une source d’amusement inépuisable. Aleksey Shipilёv en a documenté quelques‐unes dans un banc d’essai JMH, de même que Martin Thompson.

La JEP 142 propose d’ajouter une annotation @Contended pour identifier les variables, ou classes, qui doivent se retrouver seules sur une ligne de cache pour éviter le false sharing.

Essayons de l’utiliser :

  @State(Scope.Group)
  public static class StateContended {
    int readOnly;
    @Contended volatile int writeOnly;
  }

  @GenerateMicroBenchmark
  @Group("contented")
  public int reader(StateContended s) {
    return s.readOnly;
  }

  @GenerateMicroBenchmark
  @Group("contented")
  public int writer(StateContended s) {
    return s.writeOnly++;
  }

Vérifions avec jol puis avec JMH :

gist.contended.Benchmarks.StateContended object internals:
 OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
      0    12       (object header)                N/A
     12     4   int StateContended.readOnly        N/A
     16   128       (alignment/padding gap)        N/A
    144     4   int StateContended.writeOnly       N/A
    148     4       (loss due to the next object alignment)
Instance size: 152 bytes (estimated, the sample instance is not available)
Space losses: 128 bytes internal + 4 bytes external = 132 bytes total


Benchmark                                        Mode   Samples         Mean   Mean error    Units
g.c.Benchmarks.contented:reader                  avgt        18        0.742        0.006    ns/op
g.c.Benchmarks.contented:writer                  avgt        18       70.811        3.572    ns/op

On observe que la variable a bien été décalée, et l’on retrouve les performances initiales.

Limitations

@Contended est une JEP d’OpenJDK, c’est‐à‐dire qu’il ne s’agit pas d’une spécification de Java ou de la machine virtuelle Java (JVM). L’annotation se trouve dans un paquet privé d’Oracle, et elle n’est disponible que pour les classes du kit de développement Java (JDK) par défaut (comme beaucoup de choses que le JDK se réserve précieusement). Si l’on veut l’utiliser, et donc se lier à OpenJDK, il faut passer l’option -XX:-RestrictContended.

Bien entendu, vu l’impact sur la consommation mémoire et la possibilité de réduire l’efficacité du cache, il faut bien savoir ce qu’on fait et l’utiliser avec parcimonie.

Notre exemple était très simple et nous connaissions le problème. Malheureusement, dans la vraie vie, ce n’est pas aussi évident, et il n’existe pas à ma connaissance d’outil simple permettant de détecter le false sharing, quel que soit le langage. On peut suivre les conseils d’Intel et les appliquer avec l’outil qu’ils fournissent ou avec perf, mais ça reste assez empirique.

Si l’on garde le principe du false sharing en tête, cela permet de surveiller les mauvaises pratiques dans les bouts d’infrastructure qui peuvent être affectés. En général, il faut que ça commence à aller sérieusement vite, donc avec des structures de données dédiées, pour que ça commence à devenir un problème.

Cas courants

Identiquement à notre exemple, un même objet possède deux membres qui sont utilisés par deux fils d’exécution différents. ~~Ça arrive, par exemple, quand un objet tient des statistiques.~~ Dans ce cas, on va annoter le membre avec @Contended.

On peut avoir aussi le cas de plusieurs instances d’une même classe qui préféreraient chacune être dans leur propre ligne de cache. Dans ce cas, on va annoter la classe. Cela fonctionne aussi si l’on met les instances dans un tableau ; cas courant, lorsque l’on fait travailler plusieurs fils d’exécution en parallèle.

Le dernier cas est le calcul de type matriciel avec plusieurs fils d’exécution. Dans ce cas, l’annotation ne peut rien et il faut concevoir son algorithme pour en tenir compte (tout comme on itère dans le bon sens). Dr doobs fournit un tel exemple.

J’ai essayé de fournir quelques exemples dans le banc d’essai.

Conclusion

@Contended ne devrait pas changer la vie de grand monde, hormis celle des gens qui pondent l’infrastructure de service à haute performance. Mais, elle ouvre la porte à une revendication de longue date : marier les bénéfices de la machine virtuelle Java avec les besoins des applications haute performance, en ouvrant l’accès au matériel et à des techniques contre l’esprit initial de Java, mais nécessaires.

Cette annotation ne répond absolument pas au besoin de pouvoir contrôler l’agencement d’un objet ou de choisir quels membres d’un objet doivent être regroupés. Elle ne résout pas non plus les problèmes d’indirection dus aux références pour les objets. Mais la pression monte doucement avec le nombre d’applications qui passent en off‐the‐heap ou en mmap lorsque nécessaire.

Enfin, le false sharing n’est pas le seul problème lié aux caches, il y a d’autres exemples.
Et, bien entendu, exploiter les caches correctement a un impact certain sur les performances d’une application.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Java 8 et NetBeans 8 sont disponibles

2014-03-28T14:19:56+01:00

Oracle a annoncé la mise à disposition de la nouvelle version standard de Java, huitième du nom. Deux ans et sept mois après Java 7, la publication de cette nouvelle version a été retardée afin d’améliorer la sécurité.

Et pour permettre d’exploiter au mieux ce nouveau JDK, une nouvelle version de l’environnement de développement NetBeans est également disponible et porte le même numéro. Côté Eclipse, un correctif est proposé et concernant IntelliJ, Java 8 est pris en charge dans la version 13.1 sortie la semaine dernière.

Ces deux sorties marquent la volonté d’Oracle de convaincre les développeurs.

lien nᵒ 1 : Notes de version : What’s New in JDK 8
lien nᵒ 2 : NetBeans 8
lien nᵒ 3 : Téléchargement
lien nᵒ 4 : JDK 8 features
lien nᵒ 5 : [LinuxFr.org] Naissance d’un géant : Java

Sommaire

Nouveautés Java 8

Nouveautés Java 8

Les lambdas

C’est une technique pour écrire des fonctions qui ne sont pas nommées et directement définies là où elles sont appelées. Cela permet une écriture plus simple pour les fonctions qui ne sont appelées qu’à un seul endroit du code. L’exemple classique est pour définir une fonction de tri :

public class Users {
    public String username;
    public int    karma;

    /**
     * Sort users by karma
     */
    public static void sortUser(Users[] users) {
        Arrays.sort(users, (Users u1, Users u2) -> { return u1.karma - u2.karma; });
    }
}

Avant l’introduction des lambdas, dans cet exemple, il fallait définir une implémentation pour Comparator, ce qui était un peu plus verbeux :

public class Users
{
    public String username;
    public int    karma;

    /**
     * Sort users by karma
     */
    public static void sortUser(Users[] users) {
        Arrays.sort(users, new Comparator<Users>() {
            @Override
            public int compare(Users u1, Users u2) {
               return u1.karma - u2.karma;
            }
         });
    }
}

Interfaces fonctionnelles (FunctionalInterface)

Pour implémenter les lambdas, le langage s’appuie sur les interfaces fonctionnelles, c’est‐à‐dire des interfaces possédant une seule méthode abstraite. Toutes les interfaces respectant cette condition sont, de fait, des interfaces fonctionnelles. Toutefois, il est possible d’utiliser l’annotation @FunctionalInterface pour qu’une erreur soit levée si une interface ne respecte plus cette condition.

API Stream

L’interface de programmation (API) Stream a été ajoutée, permettant de représenter des données sous forme de flux et de les manipuler de manière efficace. Cette API s’appuie largement sur les fonctions lambdas décrites plus haut.

Les habitués des tubes (pipes) du Shell (il y en a par ici ? :)), des langages fonctionnels et de certains autres comme Perl ne devraient pas être trop dépaysés par cette manière de programmer.

Voici un exemple sorti de la documentation officielle :

int sum = widgets.stream()
                 .filter(b -> b.getColor() == RED)
                 .mapToInt(b -> b.getWeight())
                 .sum();

Ici, widgets est une Collection<Widget>, mais cette API peut être utilisée avec toute sorte de flux de données, comme des fichiers ou des sockets. Il est aussi possible de créer ses propres types de flux stream.

Enfin, il est possible de paralléliser les traitements sur ces flux de manière simple (plus simple que gérer des Threads).

Nashorn, JavaScript dans Java

Java inclut désormais un nouveau moteur JavaScript qui remplace le vieillissant Rhino. Il permet donc d’invoquer du code JavaScript directement dans le code Java. Il est évidemment possible d’interagir avec le code Java en appelant du code Java en JavaScript, ou même en étendant des classes Java.

Il est aussi possible de l’utiliser directement en ligne de commande comme un script classique et d’éviter d’écrire un wrapper Java. La commande s’appelle jjs.

Implémentation par défaut dans les interfaces (Defender Methods)

Jusqu’à la version précédente, les interfaces Java ne pouvaient contenir de code, uniquement des déclarations de méthodes. À partir de cette version, les implémentations de méthodes statiques et les implémentations par défaut de méthodes sont possibles. Ces dernières sont des implémentations des méthodes qui seront utilisées si la méthode n’est pas redéfinie dans une autre implémentation qui étend celle‐ci ou une classe qui implémente l’interface sans implémentation pour la méthode.

Cela fait resurgir le problème de l’héritage en diamant qui était évité par l’absence d’héritage multiple de classe et que les interfaces permettaient d’éviter par rapport aux classes abstraites. Que faire lorsqu’une méthode est définie dans plusieurs interfaces implémentées dans une classe ? Prenons l’exemple suivant :

interface A {
    void m() default {}        
}
interface B extends A {}
interface C extends A {}
class D implements B, C {}

Ce cas est assez simple, D héritera de l’implémentation dans A. Si B ou C implémentent la méthode, ce sera cette implémentation qui sera utilisée (l’implémentation la plus spécifique est utilisée). Si B et C implémentent la méthode, il faudrait spécifier explicitement quelle méthode sera utilisée.

Méthodes statiques dans les interfaces

En plus des méthodes par défaut, il est possible de définir des méthodes statiques dans les interfaces. Il n’y a pas de différence avec les méthodes statiques dans une classe.

API Date

Beaucoup de monde attendait une évolution (une révolution ?) de l’interface de programmation (API) Date et utilisait JodaTime à la place de l’API standard.

Java 8 apporte une nouvelle API pour gérer les dates, qui est divisée en deux parties :

le temps humain, principalement porté par LocalDate et LocalTime gère une date prenant en compte le fuseau horaire et possédant distinctement différents champs (pour l’heure, le jour, etc.) ;
le temps machine, qui est un horodatage (timestamp) et qui s’appuie sur les classes Instant et Duration.

Grande nouvelle : cette nouvelle API est thread-safe ! Je vous laisse découvrir plus en détail cette API au travers du tutoriel de Yohan Beschi, Tutoriel sur les nouveautés du langage 8 : la nouvelle API Date et Time.

Disparition du Permgen

C’est une évolution spécifique à l’implémentation de référence, mais ça fera plaisir à beaucoup de monde en évitant des erreurs du type java.lang.OutOfMemoryError: PermGen space. Le permgen stockait les définitions de classes définies dans le programme en cours, et sa taille pouvait poser un problème pour les grosses applications utilisant beaucoup de classes ou les générant en cours de fonctionnement. C’est donc un point en moins à surveiller pour les mises en production.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

JQM, un serveur de batchs asynchrones en Java

2013-12-24T00:30:13+01:00

JQM (Job Queue Management) est un gestionnaire de batch sous licence Apache qui permet de traiter sur des noeuds de traitement répartis toutes les tâches potentiellement longues qui ne sont pas désirables dans un serveur d'application à travers un système de files d'attente. Ce logiciel s'adresse à toute application qui souhaite gérer l'exécution de ses tâches hors du serveur d'application.

Une tâche peut être déclenchée depuis un appel Web Service ou une API par une application web, un ordonnanceur ou un flux d'interface.

L'outil propose de nombreuses fonctionnalités comme l’arrêt d’une tâche, la récupération de fichiers générés, la priorisation d’une tâche et bien d’autres. JQM a été développé en Java SE 1.6, utilise Hibernate/JPA 2.0 comme ORM, et une base de donnée comme référentiel de configuration et file d'attente des traitements. JQM est compatible avec les bases HSQL, MySQL et Oracle, les serveurs d’application WebSphere et Glassfish (prochainement Tomcat) pour l'API cliente et gère les ressources JNDI pour les bases de données et les brokers de messages.

L'outil est compatible avec les projets Maven et tout particulièrement la gestion des dépendances et des projets parents.

lien nᵒ 1 : Code source sur GitHub

Architecture

JQM est composé de trois grandes parties :

les moteurs de traitements (des JVM standalone) qui exécutent les tâches. Il est possible de déployer plusieurs moteurs (ou noeuds) de traitements pour des raisons de performance ou de haute disponibilité
une base de données qui joue le rôle de file de traitement et de référentiel de configuration
les clients (une application Web dans un serveur d'application, une ligne de commande, un ordonnanceur, une autre tâche (job) JQM etc.) qui soumettent des tâches à JQM

Les noeuds de traitement sont reliés à des files de traitement en base de données et ont chacun un intervalle de polling et un nombre défini de tâches pouvant tourner simultanément.

Par exemple:

VIPqueue = 10 tâches en simultané + intervalle de polling de 1 seconde
SLOWqueue = 3 tâches en simultané + intervalle de polling de 15 min

Cycle de vie d'une tâche

Le cycle de vie d'une tâche passe par quatre états différents.

Après avoir été ajoutée à la file d'attente, la tâche prend le status SUBMITTED. Une fois que la tâche est "attrapée" par un noeud, son statut passe à l'état ATTRIBUTED suivi de RUNNING une fois que l'exécution de celle-ci a commencé.

La tâche à la fin de son exécution a deux états possibles, CRASHED si la tâche n'a pas fonctionné correctement ou ENDED si tout le processus s'est déroulé correctement.

Fonctionnalités

Pour les développeurs

Pour les développeurs de traitement :
une tâche est définie comme telle une fois qu'elle étend (extends) la classe JobBase de l'API jqm-api.
Au sein d'une tâche, il est possible de récupérer des ressources via JNDI (base de données, broker de message, répertoire de traitement…), d'envoyer une progression, un message de log ou de mettre en file une autre tâche.
Pour les clients des traitements :
Il existe plusieurs moyens d'utiliser
JQM.
- Par le biais de l'API jqm-clientapi qui permet d'avoir toutes les fonctionnalités existantes, à savoir la possibilité de mettre une tâche en file, de regarder son état, de l'annuler, de le changer de file et bien d'autres ;
- Par le biais d'un web service ;
- Par une interface en ligne de commande ;
- Par une IHM web (très frustre à l'heure actuelle).

Pour les administrateurs

Un administrateur a la possibilité de consulter les logs, de gérer les connexions JNDI, de paramétrer les associations entre les tâches et les files.

Exemple de tâche

public class Caller extends JobBase
{
    @Override
    public void start()
    {
        Map<String, String> params = new HashMap<String, String>();
        p.put("myParam1", "Pouet");
        p.put("myParam2", "tut tut");
        // enQueue is a JobBase method.
        // It is used to enqueue a Job, here “Called”.
        enQueue("CalledJob", "Bob", null, null, null, null, null,          
                        null, null, null, null, params);
        }
}

Exemple d'intégration de JQM dans un SI

Dans cet exemple, JQM est utilisé pour gérer une intégration au fil de l'eau de message dans un ERP qui ne possède qu'une interface d'entrée de type table / prodédure stockée.

JQM joue un rôle de « joint de dilatation » entre un système événementiel qui gère des pics à 200 000 messages par heure et une interface de type procédure stockée qui traite des données en masse mais ne se prête pas à de nombreuses exécutions simultanées.

Chaque message est traité par un thread d'un conteneur MDB (Message Driven Bean) et déclenche une tâche JQM. La file de tâches JQM est paramétrée pour n'exécuter qu'une seule tâche à la fois et annuler les lancements surnuméraires. La tâche lance la procédure stockée de l'ERP qui traite toutes les données en attente dans la table d'interface.

En pic, plusieurs centaines de messages n'occasionneront qu'un ou deux lancement de la procédure stockée qui traitera en masse les données. Le système permet ainsi de rester très réactif en période creuse (au contraire des systèmes de type batch cyclique) tout en permettant la montée en charge lors des pics.

Origine du projet

Le projet a été développé par la société Enioka dans le cadre d'un projet pour l'un de ses clients pour l'intégration d'un ERP.

Suite à la réalisation de ce projet, il a été convenu que JQM deviendrait open source afin de combler le manque actuel de ce type d'outils libres dans un contexte java SE/EE 6.

Le code source et la documentation sont disponibles sur Github.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Ametys, le CMS java open source français qui monte

2013-07-04T23:07:54+02:00

La nouvelle version 3.5 du CMS libre Ametys vient d'être livrée. Toujours téléchargeable gratuitement sur le site ametys.org, cette nouvelle version ajoute des améliorations notables sur la gestion multi-site et s'enrichit de nouveaux plugins et services tout en améliorant le rendu back office et l'expérience utilisateur.

Visitez le site démo d'Ametys et connectez-vous au backoffice : demo.ametys.org

Tous les détais sur Ametys dans la seconde partie de la dépêche !

lien nᵒ 1 : Ametys CMS
lien nᵒ 2 : Site de démo
lien nᵒ 3 : Téléchargement gratuit
lien nᵒ 4 : Forum Ametys
lien nᵒ 5 : Téléchargement via Sourceforge

Créé dans les années 2000 et particulièrement adapté dans un contexte de partage et de publication de contenus fédéré entre plusieurs sites, Ametys se différencie avant tout par son interface de contribution ergonomique et conviviale très proche des outils de bureautiques (Microsoft Word).

Un rapide aperçu des fonctionnalités clés du CMS :

ergonomie & simplicité (Glisser-déposer, éditeur Wysiwyg, …) ;
plate-forme multi-sites ;
facilite le partage de contenus ;
fonctionnalités Web 2.0 : Moteur de blogs, Connexion réseaux sociaux, Widgets personnalisables ;
dernières normes d’accessibilité ;
gestion de workflow facilement personnalisables ;
atelier charte graphique ;
plugin cartographie ;
plugin enquêtes en ligne avec statistiques.

Smile, 1er intégrateur européen de solutions open source, livre son expertise sur la solution : "Ametys répond parfaitement aux besoins des entreprises et administrations publiques à la recherche d’une solution de gestion de contenus modulable et fiable."

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

CapeDwarf, Google App Engine pour JBoss

2013-07-01T21:45:45+02:00

Google App Engine est un service de Platform as a Service (PaaS). C'est-à-dire qu'au lieu de fournir une infrastructure pour y installer ce qu'on veut, Google fournit des API pour y déployer les applications que l'on souhaite. CapeDwarf est la réimplémentation par Red Hat de ces API pour JBoss, un serveur d'application Java EE libre (un serveur d'application, c'est aussi un ensemble d'API pour déployer facilement des applications).

Red Hat et Google travaillent ensemble sur un système de test open source permettant de valider des implémentations alternatives de Google App Engine (telles que CapeDwarf). L'intérêt est d'avoir des API plus orientées cloud que JEE sur des infrastructures privées ou de pouvoir migrer de l'une à l'autre plus facilement.

lien nᵒ 1 : CapeDwarf
lien nᵒ 2 : L'annonce sur le blog de Google Cloud Platform

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

L’environnement de développement Eclipse 4.3 est disponible

2013-06-30T09:54:37+02:00

La Fondation Eclipse vient d’annoncer la disponibilité d’une nouvelle version de l’environnement de développement libre Eclipse numéroté 4.3, nom de code Kepler, pour Linux, Mac OS X et Windows.

Eclipse Kepler se compose de 71 projets, ce qui représente 58 millions de lignes de code. Cette nouvelle version prend en charge Java EE 7 (sorti le 12 juin dernier) et apporte de nouvelles améliorations concernant l’interface et les performances.

Kepler apporte de nouvelles améliorations concernant l’interface et les performances. Les nouvelles fonctionnalités sont nombreuses, bien détaillées et illustrées de captures d’écran - cliquez sur les liens ci dessous. Voir la liste en français en seconde partie.

lien nᵒ 1 : Eclipse.org
lien nᵒ 2 : Annonce de la disponibilité d'Eclipse 4.3
lien nᵒ 3 : Nouvelles fonctionnalités de l'interface
lien nᵒ 4 : Nouvelles fonctionnalités pour les développeurs Java
lien nᵒ 5 : Nouvelles API
lien nᵒ 6 : Nouvelles fonctionnalités pour les développeurs de plug-in
lien nᵒ 7 : Téléchargement

D'après l'annonce de presse

Comme chaque année, la communauté Eclipse coordonne une sortie majeure de ses projets Open Source fin juin.
Cette sortie simultanée est une bonne illustration de l'efficacité des processus de développement en logiciel libre : appliqués ici au développement distribué à grande échelle (Eclipse Kepler réunit 71 projets, 420 développeurs et plus de 58 millions de lignes de code), elle permet aux utilisateurs de mettre à jour, en une fois, les nouvelles versions de leurs projets, en s'appuyant sur un agenda prévisible de sortie.

Eclipse est une plateforme de développement ouverte composée de frameworks extensibles, outils et runtimes pour construire, déployer, et gérer le cycle de vie logiciel.

Voici quelques-unes des principales nouveautés pour Kepler :

Support de Java EE7

– La version 3.5 du projet Eclipse Web Tools (WTP) apporte le support de Java EE 7, lui-même récemment publié, incluant le support pour JPA 2.1, JSF 2.2, JAX-RS 2.0, Servlet 3.1, EJB 3.2, Connector 1.7, App Client 7.0 et EAR 7.0.
Les assistants de création, les aides au contenu et de validation ont été mis à jour.

Nouvelle suite pour la gestion des processus métier

– Eclipse Stardust 1.0 apporte un moteur et des outils de gestion de processus métier. Eclipse Stardust inclut un environnement de modélisation qui permet de créer et de débugger les modèles de workflow, un moteur de processus pour exécuter des applications BPM, un portail web pour les exécutions basées sur un navigateur et la surveillance des processus métier et un composant de reporting basé sur BIRT pour la surveillance d’exécution et le reporting des applications BPM.

Extensibilité et utilisation d’un IDE basé sur le web

– Orion 3.0 apporte des améliorations sur l’utilisation et l’extension de l’IDE web Orion. Il peut maintenant être facilement installé comme un fichier WAR dans un serveur d’applications Java, permettant de déployer vers des services cloud plus facilement. L’utilisation d’Orion a également été améliorée pour inclure la navigation de fichiers directement dans l’éditeur, de nouveaux raccourcis (vi et Emacs), sauvegarde automatique / chargement automatique et un nouveau style visuel.

Nouveau support pour le Big Data

– Eclipse BIRT 4.3 introduit le support des bases de données MongoDB et Cassandra et permet une intégration simplifiée pour les capacités de visualisation BIRT dans des applications Big Data. C’est un ajout au support existant d’Hadoop fourni par BIRT.

Meilleure intégration pour la revue de code

– Grâce à Mylyn 3.9, il est désormais beaucoup plus facile de réaliser des revues de code dans Eclipse. La nouvelle vue navigateur intégrée avec Gerrit démontre la vue structurée de tous les fichiers et commentaires d’une revue.

Amélioration de l’intégration avec Maven pour les développeurs JavaEE

– Nouveau support pour l’intégration Maven avec le projet Eclipse Web Tools (WTP) fournissant un ensemble de connecteurs qui ajoute le support Maven pour les projets Eclipse Java EE, incluant les projets war, ejb, et rar.

Nouveautés de l'interface

Changements ergonomiques

Les fenêtres peuvent être détachées sur plusieurs moniteurs tout en restant à jour ;
Assistant de migration pour les installations partagées d'Eclipse ;
Correction d'installation ;
Les barres d'outils peuvent être repositionnées ;
Raccourcis dans le dialogue d'ouverture de ressources ;
Les recherches peuvent se faire sur des mots entiers ;
La fenêtre de dialogue s'ouvre avec le dernier mot recherché ;
Une option de lancement permet maintenant d'arrêter un plugin bogué sans arrêter Eclipse.

Développement

SWT pour GTK3
Améliorations de performances.

Outils

Importation projets imbriqués ;
Les warnings peuvent être affichés au lancement d'une fenêtre de configuration ;
Une option permet de ne pas utliser -XstartOnFirstThread ;
Prise en charge de augment task pour Ant.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

Qi4j SDK 2.0 - Framework de Programmation Orientée Composite

2013-05-01T10:50:39+02:00

Après deux ans de dur labeur, la Communauté Qi4j lance aujourd'hui la deuxième génération de son framework de Programmation Orientée Composite, disponible sous la très libérale licence Apache 2.0.

La Programmation Orientée Composite (COP en anglais) pousse les concepts de la Programmation Orientée Aspects (POA ou en anglais AOP) dans ses retranchements en permettant de créer des objets Composites à partir de Fragments. Avec un framework de Programmation Composite il est possible d'implémenter chaque aspect comme un objet séparé puis de les traiter comme des Mixins/SideEffects/Concerns que l'on assemble en un Composite cohérent. Les principaux bénéfices d'une telle approche sont un fort découplage et une réutilisation aisée.

lien nᵒ 1 : Qi4j.org
lien nᵒ 2 : Téléchargements
lien nᵒ 3 : Documentation

Qi4j reste un bon citoyen de l'écosystème Java car il est implémenté sans avoir recours à des pré-processeurs ou autre générateurs de code. Il permet d'utiliser tout ce que vous savez déjà ainsi que les outils auxquels vous êtes habitués, la liste des bibliothèques et extensions disponibles venant étayer cette affirmation.

Qi4j apporte donc la Programmation Orientée Composite à la plateforme Java et vous permet de rester concentrés sur le domaine métier tout en évitant la plupart des désadaptations rencontrées dans le développement logiciel comme par exemple le mapping relationel/objet, le chevauchement de différents aspects, la testabilité.

Les principaux points d'excellence de Qi4j sont le découpage explicite des applications en couches et modules, une approche AOP fortement typée et souple, un système d'injection basé sur les affinités, la gestion cloisonnée de la persistance, de l'indexation, de la construction de requêtes et bien d'autres choses encore.

D'après le co-fondateur, Niclas Hedhman, la version 2.0 est une réécriture complète du runtime. "Bien que nous ayons cassé la compatibilité en de nombreux points soigneusement sélectionnés, la plupart des applications basées sur la version 1.4 peuvent être portées avec relativement peu de changements.". Il continue en disant : "Ces changements sont nécessaires pour les prochaines fonctionnalités comme une forte intégration de Scala, du futur JDK8 et d'EventSourcing dans le modèle de persistance."

"La route fût longue jusqu'à la publication de cette version,", dit Paul Merlin le Release Manager pour la 2.0, "mais nous sommes convaincus que Qi4j représente la meilleure plateforme basée sur Java pour créer des applications métier."

Non seulement la communauté a remodelé une base de code déjà remarquable, mais elle a également produit un nouveau site web, fortement intégré avec le système de construction du framework basé sur Gradle. "Ce nouveau système permet de publier la documentation lors du processus de release." a ajouté Paul. "Tout le code présent dans la documentation est directement inclus depuis notre suite de tests. Je suis très fier du travail effectué sur le nouveau site."

La communauté estampille la version 2.0 "Reductionism". Qu'est-ce que cela signifie ? "Nous voulions faire tous les changements rompant la compatibilité aussi vite que possible et sortir un Qi4j le plus léger possible. Beaucoup de fonctionnalités prévues ont du attendre. Nous voulions avant tout sortir la base de la plateforme.", dit Niclas.

Qu'y a-t-il de vraiment nouveau ?

"Tout", dit Niclas. Pour Qi4j Core le plus important est l'introduction du paradigme fonctionnel qui permet un code plus clair. De plus, nous pourrons le porter sur le JDK8 très facilement. Le second grand changement a été de réduire la taille de Qi4j Core pour mettre plus de choses dans les Extensions comme la sérialisation et les métriques. Le nombre d'extensions pour la persistance et l'indexation a grandement augmenté.

Qu'est-ce qui est prévu pour la suite ?

"Nous nous concentrerons sur la productivité des développeurs. Pour les prochaines versions, nous avons à l'esprit des choses comme le support des TimeSeries et EventSourcing dans Qi4j Core, l'assemblage plus facile des Stacks d'Applications. Nous visons également à constamment enrichir le SDK (librairies, extensions, exemples et outils) ainsi que la documentation. Un autre objectif est d'agrandir la communauté en rendant plus accessible le développement du coeur de Qi4j." dit Paul. "Nous avons devant nous des chantiers importants et intéressants." ajoute Niclas.

La Communauté Qi4j est formée de développeurs indépendants venant d'horizons différents qui travaillent dur pour créer le framework d'applications métier le plus intéressant pour la plateforme Java.

Télécharger ce contenu au format EPUB

Commentaires : voir le flux Atom ouvrir dans le navigateur

LinuxFr.org : les dépêches de Java

Sortie de Datafari 6.2, moteur de recherche open source pour entreprise avec de l'IA

Comment démarrer ?

Que peut‐on faire avec Datafari ?

Dans la version libre, on peut, côté admin :

Côté utilisateur, on peut :

Et ensuite ?

Des commentaires ?

Sortie de Cassandre 6.0.0, un cadriciel pour développer votre propre « trading bot »

Sortie de Cassandre 4.0.0, un cadriciel pour développer votre propre « trading bot »

Silverpeas 6.2 est sortie malgré le contexte pandémique

Java 15 est sorti

Sommaire

Java 15

Abandons

Conséquences des retraits

Cas de la prise en charge SPARC/SOLARIS

Cas de la gestion du JSON

Nouveautés

Ramasse‑miettes

Shenandoah

ZGC

Blocs de texte

Classes cachées

Sous le capot

En vrac

Avant‑premières

Filtrage par motif avec instanceof

Sealed classes

Records

Écosystème

fast‑jar

Développement du JDK

Java champions

Vingt‑cinq ans de Java

AdoptOpenJDK devient Adoptium

Sortie de Cassandre, un cadriciel pour développer votre propre « trading bot »

Java 14 tombe le masque

Sommaire

Les nouveautés définitives

Temps de démarrage et empreinte mémoire

Du côté des ramasse‑miettes

G1

Les ramasse‑miettes expérimentaux

Switch statement et switch expression

JDK Flight Recorder Event Streaming

Des NullPointerException plus explicites

Nouveautés en prévisualisation

Records

Pattern Matching instanceof

Outils d’empaquetage

Les blocs de texte, seconde itération

Les mises au placard et les départs

Dans les prochaines versions

Communiquer avec D-Bus en Java avec JNIDBus

Sommaire

Contexte

D-Bus

JNI

Solutions existantes et leurs limitations

JNIDBus

Historique

Utilisation

Sortie d’OpenJDK 13

Sommaire

Dynamique de développement

Contributions

Rythme de publication et durée de maintenance

Dans les épisodes précédents

Quelques nouveautés apparues

Mot clef « var »

Nouvelle méthode pour les collecteurs « Collectors::teeing »

Nouveautés

Dynamic CDS Archive JEP 350

ZGC : uncommit unused memory

Divers

Nouveautés en préversion

Expressions switch

Text Block

Futur

Que peut‐on faire avec Datafari ?

Quel est donc le but de cette bibliothèque ?

D’accord, mais comment ça s’utilise ?

Silverpeas 6.0 est (enfin) sorti !

Modernisez votre code Java en un clic avec AutoRefactor v1.0.0 !

C’est quoi le false sharing ?