All posts in Java

Quelles perspectives pour Java et le développement Mobile ?

Quelles perspectives pour Java et le développement Mobile ?

C’est la question posée aux intervenants et participants de notre dernier ApéroTech du 14 novembre dernier à Toulouse.

A la découverte de Flutter 

Pour lancer l’ApéroTech sur le sujet du futur du développement Mobile, Thibaud a présenté une alternative à React Native : Flutter, lancé par Google. Les participants ont ensuite pu bénéficier d’une démo en live de l’API Spatioport pour découvrir les capacités du framework.

Retour d’experiences croisées sur Oracle Code One 2019

L’ApéroTech s’est poursuivi avec l’intervention d’Olivier et Bertrand, heureux participants du dernier Oracle Code One à San Francisco qui ont fait le point sur l’avenir de l’écosystème Java.
JVM, GraalVM, JakartaEE, Microprofile et Kubernetes : de multiples bouleversements accompagnent les mutations des environnements d’exécution.
Les impressions à chaud de Bertrand sont à retrouver sur son article ici.

Merci aux intervenants et participants pour leurs échanges et leur belle énergie !

Nous avons hâte de vous retrouver en mars 2020 pour une nouvelle édition.

Informations et inscriptions sur la page Meetup Les Z’ApéroTech.

Les Feature Toggles* : Activer / Désactiver dynamiquement une fonctionnalité d’un logiciel

* La désignation ne fait pas consensus et la liste des termes synonymes est très longue : Feature Flag, Feature Switch, Conditional Feature, Feature flipper, Feature Bits, Gatekeepers….

Le principe

À la livraison d’une nouvelle version d’un logiciel sur un environnement, toutes les nouvelles fonctionnalités sont rendues disponibles immédiatement. Au contraire, le modèle de design Feature Toggle* a pour but de fournir un interrupteur de fonctionnalités qui active ou désactive une partie du code sans nécessiter ni redéploiement ni redémarrage de l’application.

Les usages possibles

Cette fonctionnalité peut avoir de nombreux usages. Les cas suivants en sont un exemple et ne représentent pas l’exhaustivité des situations.

CAS 1 – Différents besoins sur différents environnements

Pratiquer des livraisons régulières, fréquentes et de petite taille est une des conditions à garantir pour l’agilité d’un projet (Continuous Delivery). L’enjeu est le maintien d’un cycle de développement court pour limiter les risques du rythme élevé de changements. Or si cette stratégie s’avère un atout en environnement de recette, où la validation de petites briques logicielles réduit la durée de la phase de tests, elle peut être difficile à réaliser en environnement de production. En effet, une fonctionnalité peut représenter plusieurs itérations de développements et il serait incongru de la mettre à disposition de l’utilisateur de façon incomplète. Le système de feature toggles rend possible la livraison de parties de fonctionnalités en mode désactivé sans que cela n’affecte la stabilité du code. L’activation pourra être réalisée au bout de quelques semaines, une fois que l’ensemble du code nécessaire aura été livré.

CAS 2 – Incident suite à une livraison

Lorsqu’un dysfonctionnement est rencontré en production par un utilisateur suite à une récente livraison, il sera possible de désactiver la fonctionnalité pour réduire l’instabilité du logiciel en attendant une résolution.

CAS 3 – Dépendances entre équipes

Il n’est pas rare que plusieurs équipes travaillent en parallèle sur des besoins différents et dans des délais qui leur sont propres tout en ayant en commun une ou plusieurs applications. Par exemple, l’interface peut être la même pour toutes les équipes. Lorsque le moment est venu pour une équipe de livrer son travail, elle se trouve gênée par les développements encore en cours ou en validation des autres équipes sur l’application partagée. Si chaque équipe a mis en place des toggles,  la livraison sera envisageable à la condition que chaque fonctionnalité non encore terminée soit désactivée.

CAS 4 – Tests comparatifs

Il existe une catégorie de Feature toggles dont l’activation se fait par utilisateur. La condition d’activation peut être déterminée par un profil de permissions ou encore l’appartenance à un échantillon. Au lieu de plusieurs environnements, un seul est nécessaire pour comparer des résultats entre différents groupe d’utilisateurs et valider une approche.

AUTRES CAS – L’activation de fonctionnalités peut aussi…

  • concerner la configuration d’un système opérationnel déjà en service afin de déterminer les meilleurs paramètres (court terme) ou bien de maintenir un service stratégique au détriment d’un autre en dégradant les performances à son profit (long terme)
  • être amenée à rester sur le long terme dans le cas du besoin de customisation de fonctionnalités par utilisateur (par exemple un mode « utilisateur premium»)

Selon Martin Fowler 1 – son blog, il existe deux axes de qualification pour un feature toggle, son dynamisme (changements au déploiement / à chaud / par requête) et sa longévité (nombre de jours / mois / années). Cette classification doit orienter vers le choix d’une implémentation.

Un rapide aperçu avec FF4J

FF4J  (Feature Flipping for Java) est un framework en licence libre apache 2.

Une fois les dépendances nécessaires ajoutées (ff4j-core, junit, ff4j-web) et la configuration paramétrée, il faudra créer un service fournissant une instance de la classe FF4J.

Étape 1. Créer un feature toggle

Cela consiste à insérer une nouvelle entrée dans un feature store (le système de stockage) précisant l’identifiant du toggle, sa description, son statut d’activation, son groupe d’appartenance, les rôles d’utilisateurs ou les stratégies associés. L’offre de système de stockage des données est large : mémoire, bases relationnelles ou no-sql.

CREATE TABLE FF4J_FEATURES (
  "FEAT_UID"            VARCHAR(100),
  "ENABLE"              INTEGER NOT NULL,
  "DESCRIPTION"         VARCHAR(1000),
  "STRATEGY"            VARCHAR(1000),
  "EXPRESSION"      VARCHAR(255),
  "GROUPNAME"           VARCHAR(100),
  PRIMARY KEY("FEAT_UID")
);

ci-dessus : Table prévue pour le stockage en base relationnelle, le champ « enable » stocke 1 pour le statut « activé » 0 pour « désactivé ».

Étape 2. Utiliser le feature toggle dans le code

L’identifiant choisi à l’étape 1 permettra de vérifier l’état d’activation.

If (ff4j.check("id.du.toggle")) {
	doBehiavorA()
}  else {
	doBehiavorB()
}

ci-dessus : si le toggle est activé alors le comportement A est joué sinon le comportement B fonctionne.

Étape 3 . Déployer le code sur un environnement

Étape 4 . Contrôler l’activation via la console d’administration

ci -dessus : Une interface graphique permet de réaliser l’opération sans nécessiter de compétences techniques.

Limites

     Ce mécanisme complexifie le code : deux cas de comportements sont implémentés en même temps donc deux fois plus de code. Il est donc conseillé de réfléchir aux bons emplacements stratégiques dans le code et de limiter le nombre de recours. Dans le même ordre d’idée, le nombre total de fonctionnalités couvertes se doit de rester faible pour rester maintenable.
     Heureusement, ce risque est diminué dans la plupart des usages puisqu’ils répondent à un besoin temporaire. Néanmoins, cette situation temporaire va induire une opération supplémentaire de nettoyage du code, une fois que la fonctionnalité est activée de manière définitive.
     Il existe également quelques cas où la sécurisation avec un toggle n’est pas envisageable. J’ai notamment déjà rencontré le cas lors d’un changement structurel important au niveau du modèle en projet .
     Il existe une controverse. En effet, les outils de gestion de versions (tel que Git) apportent une aide précieuse dans la résolution de certaines problématiques (ex. CAS 3). Si la pratique très courante du Feature Branching (séparation des fonctionnalités en branches) est jugée inadaptée face au défi de l’intégration et de la livraison continues pour les uns 1 – martin fowler blog, elle reste une réponse possible lorsque bien exécutée pour d’autres 2 – james mckay blog. Ces approches peuvent aussi être utilisées côte à côte.

     Enfin, cette approche va de pair et prendra tout son sens dans un contexte où l’automatisation des tests et des déploiements est déjà en place.

Quelques implémentations

Flaggr (Android), angular-feature-flags (Angular), rollout.io (javascript), Togglz (Java), au sein du framework Spring (Java)…

 

Retour sur EclipseCon France 2018

En septembre 2017, Oracle annonçait sa décision, en accord avec les autres grands acteurs du marché que sont IBM et RedHat, de transférer les technologies JavaEE à la fondation Eclipse pour «rendre le processus d’évolution de ces standards plus agile» [4].
Cette annonce a provoqué un séisme au sein de la communauté Java et a levé de grandes interrogations sur l’avenir de la plateforme, sur le positionnement du projet Eclipse MicroProfile et sur l’état d’avancement de cette transition.
Comme chaque année DocDoku1 était présent à l’EclipseCon France 2018, rendez-vous annuel de la communauté Eclipse à Toulouse.
Comme à chaque fois un thème est à l’honneur. Cette année il était légitime que ce soit le tour de la plateforme «entreprise» pour Java d’être sous le feu des projecteurs.
Étant moi même à l’affût d’information sur l’avenir de cette plateforme, j’ai profité de l’unique journée à laquelle j’ai pu venir, pour me concentrer sur JakartaEE et MicroProfile.

JakartaEE

JakartaEE


Au début de cette année, la communauté a choisi le nom JakartaEE pour désigner ce qu’Oracle appelait JavaEE. En effet Oracle a souhaité conserver ses droits sur la marque Java, il fallait donc trouver un autre nom.
Pourtant à la fin de l’année 2017 la fondation Eclipse avait annoncé la création du projet Eclipse Enterprise for Java (EE4J).

EE4J ou JakartaEE ?

Eclipse Enterprise for Java [5] est le projet «chapeau» pour tout ce qui concerne les technologies JavaEE, c’est à dire les API mais aussi les implémentations de référence transférées aussi par Oracle.
Eclipse JakartaEE Platform [6] est donc un sous-projet de EE4J qui reprend ce qu’était la spécifiaction de la plate-forme JavaEE : la définition d’un environnement d’exécution résultant de l’agrégation d’un ensemble spécifications d’API.
On trouve naturellement par ailleurs un sous-projet pour chaque API (Servlet, EJB, …) mais aussi les implémentations de références développées au sein de la fondation Eclipse ou par Oracle comme Yasson, EclipseLink, Glassfish, Grizzly, Jersey, …

Où en est la transition ?

Tout d’abord la procédure de transfert est longue car Oracle doit faire des vérifications (propriété intellectuelle, licence, …) pour chaque élément transféré.
En outre, les CTS2/TCK3 d’Oracle ne sont pas libres.
Nous apprenons que la transition se fera en plusieurs étapes :

  • Rendre JakartaEE 8 officiellement compatible avec JavaEE 8.C’est à dire obtenir une implémentation de référence JakartaEE qui passe les CTS/TCK actuels d’Oracle.
  • Fournir des CTS/TCK libres pour JakartaEE et s’assurer que l’implémentation de référence JakartaEE passe avec succès ces tests.
  • Une fois ces deux objectifs atteints JakartaEE pourra évoluer selon le processus normal de la fondation Eclipse.

En regardant l’état d’avancement on peut voir que la migration d’une bonne partie des projets est déjà bien avancée.

Un point sur les licences

Le système actuel de licence d’Oracle (CDDL4 et GPL5v2 des spécifications, API et RI ; TLDA6 pour l’usage des TCK et de la marque JavaEE) vont également changer en Eclipse Public License (EPLv2)

Comment la plateforme évoluera-t-elle ?

Les API sortent du giron de JCP7 et des JSR8 pour rejoindre le système des Working Group d’Eclipse et du processus de spécification de la fondation.
Grâce à ce changement, l’Eclipse Foundation espère une plus grande agilité et flexibilité.$
On nous indique que la stratégie d’évolution sera la standardisation a posteriori des bonnes idées qui ont fait leurs preuves à l’instar des exemples célèbres comme Hibernate, Weld, Jersey qui ont donné JPA, CDI et JAX-RS.
Notons que le JCP ne disparaît pas, il continue de fonctionner pour ce qui concerne JavaSE.

JakartaEE vs. MicroProfile

JavaEE 6 a vu l’arrivée de la notion de profil (Web Profile, Full Profile) au sein de la plateforme JavaEE. Le constat de l’époque étant que toutes les applications n’avaient pas besoin de l’ensemble des technologies de la plateforme.
Avec l’arrivée du Cloud Computing et succès des architectures micro-service (comprendre à base de VM), Eclipse MicroProfile propose une spécification de profil encore plus minimal, concurrent direct de Spring Boot [7], basé essentiellement sur les API standard CDI, JAX-RS et JSON-P auxquelles s’ajoutent quelques API nouvelles (Config, Health, Metrics, …).

MicroProfile

Eclipse MicroProfile [8] est donc une spécification alternative d’un ensemble d’API adaptées à la mise en œuvre d’applications architecturées sous forme de micro-service.
D’abord basé sur un nombre très limités d’API, la plateforme évolue comme le montre le tableau [Table:1]

Évolution de Microprofile
API/MicroProfile 1.0 1.1 1.2 1.3 1.4 2.0
CDI 1.2 2.0
JSON-P 1.0 1.1
JAX-RS 2.0 2.1
Config 1.0 1.1 1.2 1.3
Health Check 1.0
Metrics 1.0 1.1
Fault Tolerance 1.0 1.1
JWT Propagation 1.0 1.1
Open Tracing 1.0 1.1
Open API 1.0
Rest Client 1.0 1.1
JSON-B 1.0

Une des forces des spécifications ouvertes, comme pour JEE, est de permettre de fédérer divers éditeurs. Grâce à cela il existe plusieurs implémentations de MicroProfile (voir le tableau ci-dessous).

Implémentations de MicroProfile
Éditeur Implémentation
IBM Open Liberty [9]
RedHat WildFly Swarm [10]
Payara Payara Micro [11]
Apache Tomee [12]
Hammock Hammock [13]
Kumuluz KumuluzEE [14]

Avec les implémentations de MicroProfile, il est possible de déployer une application de plusieurs façons :

  • l’application, les dépendances et le runtime sont packagés dans un seul et même JAR exécutable.Format popularisé par Maven et Spring Boot, la taille de l’archive peut devenir si importante que cela peut poser des problèmes lors de déploiements fréquents (déploiement continu)
  • L’archive JAR contient l’environnement d’exécution, l’archive WAR les ressources métier et les éventuelles dépendances tierces.Avantage, Le WAR est plus léger à déployer car il ne contient que ce qui est spécifique au métier. Cela rappelle le mode de déploiement dans un serveur JavaEE.

12-Factor Application

Pour rappel, «Application à 12 facteurs» est une méthodologie pour construire des applications SAAS9.
Les 12 facteurs en question sont:

  1. Une seule base de code, versionnée (Codebase)
  2. Déclarer explicitement et isoler les dépendances (Dependencies)
  3. Ne pas stocker la configuration dans le code (Config)
  4. Tous les services sont vus comme des ressources «tierces» (Backing services)
  5. Stricte séparation entre la construction, la livraison et l’exécution d’une application (Build, release,run
  6. Les processus d’une application sont sans-étatProcesses
  7. Les services (Web) sont exposés via un port réseau (Port Binding)
  8. L’application se décompose en processus parallèles (Concurrency)
  9. L’application doit pouvoir être démarrée et arrêtée à la demande (Disposability)
  10. Garder les environnements (développement ,recette, production) aussi similaires que possible(Dev/Prod parity)
  11. Les logs sont un flux d’événements indépendant de la manière dont ils sont stockés (Logs)
  12. Les processus d’administration doivent s’exécuter dans le même environnement que l’application (Admin Process)

La présentation d’Emily Jiang [2] nous montre comment l’association de la plateforme MicroProfile et Kubernetes permettent de mettre en œuvre une application selon ces principes.

Codebase
Le code source de l’application est géré par Git (sur GitHub).
Dependencies
La construction et la gestion des dépendances est gérée par Maven.
Config
Les configmaps Kubernetes et l’API Config servent à injecter les propriétés de configuration dans l’application.
Build-Release-Run
Une plateforme d’intégration continue prend en charge le packaging pour chaque environnement.
Processes
L’API REST permet de mettre en œuvre les processus sans-état
Port Binding
Kubernetes et l’API Config sont responsable de l’affection des ports
Concurrency
Le découpage en micro-services et Kubernetes permettent de gérer la mise à l’échelle
Disposable
L’API Fault Tolerance permet de rendre l’application résiliente aux arrêts des processus.
Dev/Prod Parity
Kubernetes Helm permet de s’assurer que les différents environnements sont similaires
Logs
ELK10 permet d’indexer et de gérer les journaux.
Admin Process
L’outillage standard de Kubernetes (kubectl exec) permet des déclencher les processus d’administration.

Sécurité sans-état avec JWT

La sécurité est un aspect fondamental pour les applications d’entreprise, celui-ci est d’ailleurs pris en compte dans JavaEE (avec plus ou moins de souplesse) depuis les tous débuts de la plateforme.
Les architectures micro-service («SOA avec un nom sexy» dit Jean-Louis Monteiro [3]) ne font pas exception, mais l’aspect sans-état nécessaire pour faciliter la gestion de la charge change la donne.
Jean-Louis discute des inconvénients des différentes options d’authentification et de propagation des identités:

Basic Auth
présente plusieurs risques car :
– le couple login/motdepasse est envoyé à chaque requête,
– risque d’attaque DOS du référentiel de sécurité.
OAuth 2.0
basé sur une paire de jetons (access/refresh) recrée au final une session HTTP côté serveur pour garder une trace des jetons générés (et confiés au client) : cela consomme de la mémoire et du temps de calcul car chaque micro-service activé doit vérifier les tokens
JWT
est un format de jeton similaire à SAML mais codé en JSON. Ils contiennent des informations signées et potentiellement chiffrées. Dans ce cas de figure les informations signées, donc non altérables, sont stockées côté client.

L’association JWT + OAuth 2.0 permet de réduire considérablement les ressources nécessaires côté serveur : seules des références de jeton sont conservées (pour la révocation) et chaque service peut vérifier la signature du jeton de manière autonome.
Une présentation de la mise en œuvre de se mécanisme avec l’API JWT propagation de la plateforme MicroProfile vient enfin compléter la brillante démonstration.

JakartaEE + IOT

Une démonstration concrète de la mise en œuvre de technologies JavaEE et de l’Internet des Objets.
Payara Micro [11] est une déclinaison du serveur d’application Payara Server (basé sur Glassfish), pensée pour les micro-services «conteneurisés».
Ce micro-serveur d’application est compatible MicroProfile, mais malgré sa taille (moins de 70Mo),il supporte la mise en cluster, les connecteurs JCA, le Clustering, JCache, les EJB Timer, les événements CDI distribués.
Comment obtenir un serveur d’application si léger ? En faisant l’impasse sur les API historiques les moins pertinentes pour ce genre d’application m’a-t-on indiqué.
Grâce à sa légèreté, sans trop de compromis quant aux fonctionnalités, nous assistons à la démonstration d’une application capable d’agréger des données en provenance de capteurs (d’humidité dans le cas présent) à travers des applications JavaEE déployées sur des nano-ordinateur de type RaspberryPi.
Événements CDI distribués, connecteur JCA pour des échanges de messages asynchrone (MQTT), services REST sont au rendez-vous pour démontrer que les technologies JavaEE ont aussi leur place dans le monde des ressources contraintes de l’IOT.

Kubernetes : retour d’expérience

La fondation Eclipse est en cours de migration de sa plateforme d’intégration continue depuis Cloodbees Jenkins Enterprise vers une solution basée sur un cluster Kubernetes (OpenShift).
À partir de sa propre expérience de migration, Mikaël Barbero nous présente une excellente introduction à Kubernetes [1]
Kubernetes [15] est un système Open Source d’orchestration de conteneurs (VM) permettant d’automatiser le déploiement, la configuration, la gestion et la montée en charge d’applications ou de micro-service «conteneurisés».
Contrairement à la plateforme JavaEE où le conteneur – la machine virtuelle Java – est limitée à l’exécution de bytecode, les conteneurs (machines virtuelles) gérés par Kubernetes sont plus génériques car indépendants d’un OS, d’un langage et d’une plateforme pré-définis.
Là ou les serveurs d’application JavaEE permettaient d’orchestrer des machines virtuelles Java au sein d’un cluster, des outils comme Kubernetes réalisent sensiblement le même travail avec des conteneurs Docker dans le cas présent.
On perçoit comment ont évolués les usages ces dernières années: plutôt que de dépendre des capacités d’un serveur d’application JavaEE, limitées plus ou moins au monde Java, on préfère utiliser un outillage tiers pour gérer un cluster de machines virtuelles plus générales

Conclusion

Que ne lit-on pas ici et là sur la nature «monolithique» de la plateforme JavaEE, que l’on oppose à une architecture fragmentaire des micro-services.
Pourtant JavaEE/JakartaEE ne décrit pas comment doit être implémenté l’environnement d’exécution mais défini seulement un ensemble d’API qui doit être disponible et un format de packaging. Chaque type de composant est d’ores et déjà distribuable, alors pourquoi ne pourrait-on pas voir JEE comme la définition d’une PAAS11 tout à fait capable de construire des applications à base de micro-services ?
Est-ce la difficulté de morceler la plateforme comme ce qui a été réalisé lors des premiers profils (Web et Full) ? Est-ce la nécessité de conserver une compatibilité ascendante ?
Le succès des solutions MicroProfile (ou dans une certaine mesure Springboot ou Dropwizard) nous apprend que:

  • On doit pouvoir choisir les technologies strictement nécessaires à la mise en œuvre d’une application ou d’un composant applicatif.L’intégration de systèmes de modules dynamiques comme OSGI dans les implémentations des serveurs d’applications permet d’ores et déjà de ne charger en mémoire que les composants nécessaires, reste la configuration parfois complexe d’un domaine que l’on voudrait déléguer à des systèmes moins spécifiques.
  • Micro-service ou pas, le contexte des applications d’entreprise nécessite de disposer de solutions pour simplifier la mise en œuvre des aspects transverses (sécurité, transaction, distribution, tolérance aux pannes, métrologie, surveillance, journalisation, …).Il suffit, pour s’en convaincre, de regarder l’évolution des API de MicroProfile. Si les nouvelles API répondent à de nouveaux usages, elles peuvent également profiter à JakartaEE, mais à ce rythme MicroProfile restera-t-il «micro» ?
  • Le choix de la standardisation adoptée par Sun/Oracle ou la fondation Eclipse permet de fédérer les efforts des différents éditeurs et de favoriser la portabilité et l’interopérabilité.

Maintenant que JavaEE est en passe d’être libéré de la tutelle – soit-elle symbolique – d’Oracle, l’enthousiasme des participants à la conférence était au rendez-vous.
Grâce à la disponibilité de systèmes de virtualisation par conteneurs capables d’exécuter des composants (Java ou non); d’outils permettant la gestion d’infrastructures complexes de type Cluster ou Cloud; la modularité sera à mon avis le défi auquel devra répondre la plateforme JakartaEE, soit en intégrant ou définissant de nouveaux profils comme MicroProfile, soit plutôt en proposant une plateforme totalement modularisé pouvant être composée à la carte, à l’instar du travail réalisé sur JavaSE.
Demain, déployer une application JakartaEE consistera-t-il à découvrir à partir d’un paquetage les API utilisées, de provisionner un conteneur contenant le strict nécessaire et d’exécuter le tout ?
Merci enfin à toute l’équipe de la fondation Eclipse qui ont encore une fois réussi à organiser un événement fantastique.
Bravo à tous les conférenciers pour la variété et la qualité des présentations.

Références

1. Mikaël Barbero. 2018. Kubernetes 101. Retrieved from https://www.slideshare.net/mikaelbarbero/kubernetes-101-a-cluster-operating-system/
2. Emily Jiang. 2018. Build a 12-Factor Microservice in Half an Hour. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/Build12FactorAppUsingMP.pptx
3. Jean-Louis Monteiro. 2018. Stateless Microservice Security via JWT, TomEE and MicroProfile. Retrieved from https://www.eclipsecon.org/france2018/sites/default/files/slides/2018_EclipseConEU_StatelessRESTSecurityWithMP-JWT.pdf
4. 2017. Opening Up Java EE – An Update. Retrieved from https://blogs.oracle.com/theaquarium/opening-up-ee-update
5. Eclipse Enterprise for Java. Retrieved from https://projects.eclipse.org/projects/ee4j
6. JakartaEE. Retrieved from http://microprofile.io/
7. Spring Boot. Retrieved from https://spring.io/projects/spring-boot
8. Eclipse MicroProfile. Retrieved from http://microprofile.io/
9. Open Liberty. Retrieved from https://openliberty.io/
10. WildFly Swarm. Retrieved from http://wildfly-swarm.io/
11. Payara. Retrieved from https://www.payara.fish/
12. Apache TomEE. Retrieved from http://tomee.apache.org/
13. Hammock. Retrieved from https://hammock-project.github.io/
14. KumuluzEE. Retrieved from https://ee.kumuluz.com/
15. Kubernetes. Retrieved from https://kubernetes.io/

  1. DocDoku est membre solution de la fondation Eclipse
  2. Compatibility Test Suite
  3. Tehnology Compatibility Kit
  4. Common Development and Distribution License
  5. Gnu Public License
  6. Technology License and Distribution Agreement
  7. Java Community Process
  8. Java Specification Request
  9. Software As A Service
  10. Elasticsearch, Logstash, Kibana
  11. Platform As A Service

Retrouvez DocDoku sur l’EclipseCon 2018

Les 13 et 14 juin prochains, DocDoku vous donne rendez-vous dans la ville rose pour l’EclipseCon France 2018, le grand rassemblement annuel français de la communauté Eclipse.

Comme lors de la précédente édition, DocDoku reste fidèle à son engagement en tant que sponsor de l’événement et vous accueillera sur son stand pour parler solutions et technologies, mais également présenter ses derniers cas clients.
Le programme de la conférence 2018 couvrira cette année des sujets en lien avec la modélisation, les systèmes embarqués, le Cloud, la Data Analytics, le DevOps et plus encore, le tout agrémenté de sessions de démonstration des outils basés sur Eclipse.

Cette année nous serons particulièrement attentifs aux conférences sur l’arrivée dans la fondation du groupe de travail JakartaEE, auquel DocDoku appartient désormais.
En effet, ce projet ambitieux prend la suite de la renommée plateforme de développement d’applications d’entreprise Java Enterprise Edition, maintenue par Oracle précédemment.

Nous resterons également captivés par les conférences du groupe de travail Polarsys, auquel DocDoku participe également au travers de la plateforme PLM d’Eclipse EPLMP.

13 et 14 juin 2018
Centre de Congrès Pierre Baudis
11 esplanade Compans Caffarelli
31000 Toulouse

Lien direct vers le formulaire d’inscription : ici

Retour sur EclipseCon France 2017


Comme les années précédentes, DocDoku était présent à l’EclipseCon France et j’ai pu assister à quelques présentations.
Faut-il encore présenter le projet Eclipse ? Pour ceux qui auraient vécu dans une grotte durant les 16 dernière années (ou ceux qui n’étaient pas nés), Eclipse est un projet proposant une plateforme extensible, basée sur OSGi, qui permet de construire des applications par agrégation de greffons (plugin) en se basant sur une bibliothèque de composants sur l’étagère.
À une époque éloignée Eclipse était considéré comme un environnement de développement intégré – c’était la première application il est vrai – pourtant force est de constater qu’année après années le projet va bien au delà de cela et que ce n’est pas près de s’arrêter, l’étagère ne cesse de s’agrandir.
Hier c’était une plateforme, puis une fondation, puis un ensemble de projets basés sur les technologies de la plateforme, aujourd’hui l’écosystème ne cesse d’évoluer et s’immisce dans une quantité impressionnante de domaines : bien sûr les outils de développement, mais aussi la modélisation, le cloud, ou encore une multitude de domaines (IoT, robotique, science, big data, …).

Au début il y avait l’outil

Du côté des outils de développement, toujours plus d’améliorations pour déboguer, pour tester, pour suivre les évolutions des langages. Java reste le langage privilégié mais ne règne plus en maître, certains veulent pouvoir développer dans la plateforme avec d’autres langages.

Java 9

L’intégration de Java 9 arrive avec son lot de nouveautés, lié en particulier au nouveau système de module tant attendu de la dernière version de la plateforme d’Oracle :

  • Support des images (jimage);
  • Support des modules (JMOD);
  • Nouveau fichier module-info.java.

De gros changements en perspective avec la disparition programmée (progressivement) des fichiers JAR.

Déboguer

Les outils de débogage s’améliorent aussi Barbero [2017].

  • triggerpoint pour activer un certain nombre de breakpoints
  • conditional watchpoint
  • tracepoint pour écrire dans la console et éviter les System.out.println() dans le code.
  • Show Logical Structure permet d’obtenir une représentation simplifiée de la structure de certains types (Listes, Maps, …)

Couverture de code

À l’occasion de l’intégration d’EclEmma, un outil de couverture de code Java, à la distribution Eclipse Oxygen, SonarSource nous rappelle quelques bonnes pratiques pour éviter les bogues Mandrikov [2017]. Un outil intégré, non intrusif, pourquoi s’en passer?

EASE

EASE (Eclipse Advance Scripting Environment) propose le moyen d’intégrer du code développé avec des langages de script dans la plateforme Eclipse.
Airbus présente un retour d’expérience : Constatant que le développement d’un plugin Eclipse nécessite certaines contraintes, l’idée est de proposer un pont pour le langage Python offrant une API simplifiée aux composants Eclipse. Les avantages d’un langage de script avec la puissance de la plateforme en somme Bernard [2017].

Abstraire par les modèles

Au devant de la scène cette année, l’ingénierie dirigée par les modèles était particulièrement
bien représentée. Par modèle j’entends une représentation abstraite de concepts mis en jeu dans un domaine particulier.

D’une part, la première journée accueillait le Xtext Summit – série de conférences sur Xtext, technologie liée aux langages dédiés (Domain-specific Language) : définition d’un langage et génération des outils. D’autre part, de nombreuses conférences gravitaient autour des modèles.

Je n’ai pas pu assister à toutes les conférences, mais le peu que j’en ai vu a affûté ma curiosité.

Eclipse EMF Parsley

Eclipse EMF Parlsey fournit un ensemble de composants d’interface utilisateurs basés sur EMF.
L’équipe de RCP Vision illustre la mise en œuvre d’une démarche MDA: Un modèle EMF, une transformation décrite par un DSL Xtext. C’est-à-dire comment un modèle EMF peut être transformé, enrichit, grâce à un DSL Guidieri et al. [2017a].

Après M2Doc : Doc2M

Ou comment l’approche Model to Document (M2Doc) n’est pas toujours suffisante.

Après une présentation intéressante de l’utilisation de la technologie M2Doc pour générer des PDF à partir de données structurées – conformément à un modèle et des gabarits (au format xdoc) – on nous montre que cela n’est pas toujours satisfaisant et un cas où il faut aussi synchroniser les documents avec les instances du modèle Michot [2017].

Big EMF models

Générer des applications à partir d’un modèle c’est bien, mais comment stocker, partager et gérer l’évolution d’un modèle, surtout quand celui-ci devient important ? Un tour d’horizon des solutions disponibles nous donne un aperçu des outils à disposition et de leurs limites, en particulier lorsque les modèles deviennent très gros, et quelques pistes pour y remédier Viaud and Lasalle [2017].

S’envoler vers les nuages

Quel que soit le domaine, la plate-forme Eclipse et ses applications font
face à un nouvel enjeu : la (re-)localisation croissante des applications dans
le cloud.

La plateforme Eclipse est historiquement plutôt tournée vers le Desktop, du moins en ce qui concerne l’interface utilisateur. Les nouveaux usages de l’informatique, réclament ce qui aurait paru un peu utopique quelques années en arrière: pouvoir utiliser n’importe quelle application, y compris un environnement de développement depuis n’importe quel appareil (pourvu que ses capacités soient adaptées) et depuis n’importe où (pourvu que l’on ait du réseau).

Eclipse RAP

Avec SWT comme base pour les composants graphiques, bon nombre d’applications construites sur la plateforme Eclipse aimeraient exposer leur interface utilisateur à travers les technologies du Web.

Eclipse RAP vise à remplacer les composants SWT natifs par un équivalent Web, avec à la clé l’espoir de pouvoir exposer n’importe quelle application RCP sur le Web.

Au fil du temps cela ne fonctionne pas trop mal mais SWT ayant été conçu pour fonctionner en local, sa transposition à travers un réseau reste verbeuse (beaucoup d’interaction entre le client et le serveur). Cela semble tout de même rester acceptable pour RCP Vision qui nous fait un retour d’expérience sur la mise en œuvre d’une applications Desktop et Web à partir d’un modèle EMF Guidieri et al. [2017b].

Eclipse Che

Eclipse Che vise, rappelons le, à offrir un environnement de développement en mode Web. Cela nécessite des changements assez importants par rapport à un IDE traditionnel:

  • Interface utilisateur déportée (ici le choix s’est tourné vers la réécriture de l’interface utilisateur avec GWT)
  • Serveur de compilation et de traitement
  • Espace de travail partagé ou multiples

On retrouve les gros changement de modèle d’architecture induis par le Cloud (approvisionnement, distribution serveur et client Web).

La présentation nous montre comment cela peut être mis en œuvre et laisse entrevoir les avantages que l’on peut en tirer Benoit [2017].

Theia

Après Eclipse Che dont je viens de parler, développé en Java; Eclipse Orion – un autre IDE en ligne, dédié aux technologies du Web, développé en JavaScript ; voici un autre projet d’IDE, Theia-ide, développé en TypeScript. Il n’est ni sous licence Eclipse, ni basé sur la plateforme et ses technologies, mais il ambitionne d’être l’« Eclipse du futur », aussi bien sur le PC que sur le cloud (https://github.com/theia-ide/theia).

Approvisionner une application Eclipse

Une application Eclipse est un agrégat de greffons. Plus le nombre de greffon augmente, plus construire une application devient complexe (récupérer, agréger, configurer, …).

Nombre d’équipe de développement sont confrontés à ce problème lorsqu’il s’agit de travailler avec une configuration cohérente de leur IDE et de synchroniser les évolutions et mises à jour. Fini le temps où il fallait installer et configurer manuellement chaque greffon, Eclipse Oomph répond à ce problème.

L’idée de Frauhofer FOKUS est de combiner Oomph, Maven et Docker pour automatiser l’approvisionnement d’une application Eclipse Bureck [2017].

Conclusion

Au fil des ans, le projet Eclipse continue de montrer son dynamisme, historiquement centré sur sa plateforme, l’écosystème se diversifie et agrège des projets parfois alternatifs ou sans rapport direct avec celle-ci. Outre l’ingénierie dirigée par les modèles, vaste sujet, qui m’a paru plus bouillonnante que jamais, trouver une solution pour des applications déployées sur le cloud me semble être le prochain défi pour la plateforme. Les modèles ne pourraient-ils pas être la clé ?

Bravo pour l’organisation impeccable, le programme riche et varié : difficile de choisir parmi les différentes conférences, heureusement petits fours et douceurs étaient là pour nous consoler.

Références

Barbero [2017]
Mikaël Barbero.
Debug java code like a pro.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/2017ecf.pdf.
Benoit [2017]
Florent Benoit.
How to provide a portable developper workspace with eclipse che.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/2017-EclipseCon-France-Chefile_0.pdf.
Bernard [2017]
Alain Bernard.
How ease unleashes the scientific power of airbus’ engineers in
eclipse.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/ECF2017_EASE_full.pdf.
Bureck [2017]
Max Bureck.
From nothing to complete environment with maven, oomph and docker.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/MavenDockerOomph.pdf.
Guidieri et al. [2017a]
Francesco Guidieri, Vincenzo Caselli, and Lorenzo Bettini.
The emf parrsley dsl: an extensive use case of xtext/xbase powerful
mechanism.
2017a.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/EMF%20Parsley%20DSL%20Xtext%20case%20study.pdf.
Guidieri et al. [2017b]
Francesco Guidieri, Vincenzo Caselli, and Lorenzo Bettini.
Lesson learned from using emf to build desktop and web aplications.
2017b.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/EclipseCon_France_2017.pdf.
Mandrikov [2017]
Evgeny Mandrikov.
Code coverage in practice.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/Code%20Coverage%20in%20Practice%20-%20EclipseCon%20France%202017.pdf.
Michot [2017]
Arnaud Michot.
Doc2m update your model from your document in a breeze!
2017.
URL
https://docs.google.com/a/cetic.be/presentation/d/1Qs9IEBR9qUYc3urd3qCum02BZJciZSjUycoL4bMoNNs/edit?usp=sharing.
Viaud and Lasalle [2017]
Benoit Viaud and Jonathan Lasalle.
Emf model getting xxl? an overview of available solutions.
2017.
URL
https://www.eclipsecon.org/france2017/sites/default/files/slides/ECon17_Artal_XXL-Models.pdf.

Les tests unitaires avec Mockito

Les tests unitaires

Egalement appelés « TU », ils sont destinés à tester une unité du logiciel. Afin d’être vraiment unitaires, ils doivent être en totale isolation pour ne tester qu’une classe et qu’une méthode à la fois.

Tester le bon comportement de son application c’est bien, détecter les éventuelles régressions c’est encore mieux ! Et c’est là que réside tout l’intérêt d’écrire des TU.

De la théorie… à la bonne pratique

Un test unitaire doit être véritablement unitaire. Pour cela, les appels aux services, aux bases de données et fichiers doivent être évités. Le TU doit s’exécuter le plus rapidement possible afin d’avoir un retour quasi immédiat.

Un TU faisant partie intégrante du code applicatif, les pratiques suivantes sont recommandées :

  • il doit respecter les conventions de code
  • il doit être simple et lisible,
  • il ne doit tester qu’un  seul comportement à la fois
  • il doit faire le moins d’appel possible aux dépendances
  • l’utilisation de mocks est recommandée pour fiabiliser les TU.

Un mock est un objet qui permet de simuler un objet réel tel que la base de données, un web service…

L’approche TDD (Test Driven Development) reste la meilleure solution pour éviter que les tests soient écrits à la fin du développement de l’application.

Frameworks de mock

L’écriture d’objets de type mock peut s’avérer longue et fastidieuse, les objets ainsi codés peuvent contenir des bugs comme n’importe quelle portion du code. Des frameworks ont donc été conçus pour rendre la création de ces objets fiable et rapide.

La plupart des frameworks de mock permettent de spécifier le comportement que doit avoir l’objet mocké avec :

  • les méthodes invoquées : paramètres d’appel et valeurs de retour,
  • l’ordre d’invocation de ces méthodes,
  • le nombre d’invocations de ces méthodes.

Les frameworks de mock permettent de créer dynamiquement des objets généralement à partir d’interfaces ou de classes. Ils proposent fréquemment des fonctionnalités très utiles au-delà de la simple simulation d’une valeur de retour comme :

  • la simulation de cas d’erreurs en levant des exceptions,
  • la validation des appels de méthodes,
  • la validation de l’ordre de ces appels,
  • la validation des appels avec un timeout.

Plusieurs frameworks de mock existent en Java, notamment :

  • EasyMock,
  • JMockIt,
  • Mockito,
  • JMock,
  • MockRunner.

Dans ce qui suit, nous allons détailler le framework Mockito.

Mockito

mockito

C’est un framework Java très connu permettant de générer automatiquement des  objets ‘mockés‘. Couplé avec JUnit, il permet de tester le comportement des objets réels associés à un ou des objets ‘mockés’ facilitant ainsi l’écriture des tests unitaires.

Configuration du projet

Pour intégrer Mockito à son projet, il suffit simplement de rajouter la dépendance Maven :

<dependency>

<groupid>org.mockito</groupid>

<artifactid>mockito-all</artifactid>

<version>1.9.5</version>

</dependency>

Deux manières sont possibles pour intégrer Mockito dans les tests Junit :

1- Ajouter l’annotation @RunWith (MockitoJunitRunner.class) à la classe de test :

@RunWith(MockitoJunitRunner.class)

public class MyTestClass {

}

2- Faire appel à la méthode initMocks dans la méthode de SetUp :

@Before

public void setUp() {

MockitoAnnotations.initMocks(this);

}

Création d’objets mockés avec @Mock

La création d’objets mockés se fait soit en appelant la méthode mock(), soit en rajoutant l’annotation @Mock pour les instances de classes.

User user = Mockito.mock(User.class);

ou

@Mock

User user;

Mockito encapsule et contrôle tous les appels effectués sur l’objet User. Ainsi user.getLogin() retournera tout le temps null si on ne « stubb » pas la méthode getLogin().

Définition du comportement des objets mockés ou « Stubbing »

Le stubbing permet de définir le comportement des objets mockés face aux appels de méthodes sur ces objets. Plusieurs méthodes de stubbing sont possibles :

  1. Retour d’une valeur unique

Mockito.when(user.getLogin()).thenReturn(‘user1’); //la chaine de caractères user1 sera renvoyée quand la méthode getLogin() sera appelée.

  1. Faire appel à la méthode d’origine

Mockito.when(user.getLogin()).thenCallRealMethod();

  1. Levée d’exceptions

Mockito.when(user.getLogin()).thenThrow(new RuntimeException());

Il faut noter que la méthode retournera toujours la valeur stubbée, peu importe combien de fois elle est appelée . Si on stubb la même méthode ayant la même signature plusieurs fois, le dernier stubbing sera pris en compte.

Mockito.when(user.getLogin()).ThenThrow(new RuntimeException()).ThenReturn(« foo »);

Ici le premier appel va lever une exception, tous les appels qui suivront retourneront « foo ».

  1. Retours de valeurs consécutives

Mockito.when(user.getLogin()).thenReturn(‘user1’,’user2’,’user3’);

Le premier appel retourne user1, le deuxième retournera user2 le troisième user3. Tous les appels qui suivent retourneront la dernière valeur c’est à dire user3.

  1. Ne rien retourner

 Mockito.doNothing().when(user.getLogin());

Espionner un objet avec @Spy

Au lieu d’utiliser l’annotation @Mock, nous pouvons utiliser l’annotation @Spy. La différence entre les deux réside dans le fait que la deuxième permet d’instancier l’objet mocké, ce qui peut être très utile quand nous souhaitons mocker une classe et non pas une interface.

Une autre différence est à signaler est le stubbing. Si nous ne redéfinissons pas le comportement des méthodes de l’objet espionné, les méthodes réelles seront appelées, alors qu’avec @Mock, nous sommes obligés de spécifier leurs comportements, sinon la valeur nulle est retournée par défaut. Dans l’exemple qui suit la méthode getLogin() sera appelée.

@Spy

User user = new User(‘user1’);

user.getLogin() // retourne user1

Vérification d’interactions @Verify

@Verify permet de vérifier qu’une méthode a été bien appelée et que que les interactions avec le mock sont celles attendues.

Nous pouvons également vérifier le nombre total de fois ou la méthode a été appelée (atMost(3),atLeastOnce(),never(),times(5)) , l’ordre des invocations des objets mockés en utilisant inOrder() et aussi vérifier si une méthode a été invoquée avant la fin d’un timeout. Nous pouvons également ignorer les appels stubbés en utilisant ignoreStubs() et aussi vérifier qu’il n y’a pas eu  d’interaction en utilisant verifyNoMoreInvocations().

verify(user).getLogin();

//le test passes si getLogin() est appelée avant la fin du timeout

verify(mock, timeout(100)).getLogin();

Injection

Mockito permet également d’injecter des resources (classes nécessaires au fonctionnement de l’objet mocké), en utilisant l’annotation @InjectMock. L’injection est faite soit en faisant appel au constructeur, soit en faisant appel au ‘setter’ ou bien en utilisant l’injection de propriétés.

public Class DocumentManagerBeanTest{

@Mock EntityManager em;

@Mock UserManager userManager;

@Spy RoleProvider role = new RoleProvider();

@InjectMocks DocumentManagerBean docBean;

@Before public void initMocks() {

MockitoAnnotations.initMocks(this);

}

@Test

public void uploadDocument(){

docBean.uploadDoc(file);

}

}

public Class DocumentManagerBean {

private EntityManager em;

UserManager user;

RoleProvider role

public String uploadDoc(String file){

if (user.hasAcess()){

em.checkFileExists(file);

….

}

}

}

Conclusion

Mockito est un framework de mock qui, associé à Junit, permet :

  • une écriture rapide de tests unitaires,
  • de se focaliser sur le comportement de la méthode à tester en mockant les connexions aux bases de données, les appels aux web services …

Cependant il a certaines limitations, en effet , il ne permet pas de mocker :

  • les classes finales,
  • les enums,
  • less méthodes final,
  • les méthodes static,
  • les méthodes privées,
  • les méthodes hashCode() et equals().

Aussi, les objets ‘mockés’ doivent être maintenus au fur et à mesure des évolutions du code à tester.

Portail Liferay avec GWT intégré en SOA pour Pierre et Vacances

Aujourd’hui je viens vous faire partager une très belle expérience projet. Je vous parlerai donc d’un projet que nous avons réalisé pour notre client Pierre et Vacances, qui a su nous faire confiance jusqu’au bout pour le développement et l’infogérance de son extranet commercial.

Faire des choix en matière d’architecture logiciel en 2010 peut être un exercice difficile, c’est pourquoi l’approche de DocDoku en matière de choix techniques est basée sur les principes suivants :

  • pragmatisme, dans le choix des langages et des technologies,
  • ouverture d’esprit, nous effectuons une veille technologique permanente,
  • mise en contexte, chaque problème étant différent, les réponses à apporter doivent l’être également,
  • industrialisation, il ne s’agit pas de s’emparer de la toute dernière nouveauté mais de bâtir des solutions robustes, matures et maintenables,
  • respect des standards établis, pour garantir la pérennité des applications, et maximiser l’investissement consenti par nos clients, nous nous appuyons sur les standards unanimement reconnus.

Dans le cadre de l’extranet commercial développé pour Pierre et Vacances, les grands principes architecturaux retenus ont été les suivants :

  • utilisation du composant portail open source Liferay permettant un gain de productivité certain en particulier sur les modules génériques (droits d’accès, profils utilisateurs, agenda, publication de news…) mais respectant également la JSR 286, norme de communication entre le portail et les applications qui y sont hébergées, supportée par de nombreux éditeurs (IBM, Sun, Oracle, RedHat). Ceci permet de surcroît de limiter notre dépendance vis-à-vis d’une solution portail en particulier.
  • développement d’une architecture en couches permettant notamment de découpler les composants les uns des autres et de les faire évoluer indépendamment.  Une séparation en couches permet d’adapter en effet l’architecture physique en fonction des besoins de distribution pour une bonne capacité à monter en charge.  Une architecture n-Tiers en 4 couches distinctes a été choisie :
    • La couche d’accès aux données avec JPA-Hibernate dont le rôle est la connexion à la base de données, l’exécution des requêtes ou l’appel des procédures stockées.
    • La couche de service EJB3 et JAX-WS-Metro, ensemble des règles métiers et processus de l’application. Cette couche sera implémentée en Java via des composants transactionnels.
    • La couche métier POJO qui constitue le diagramme de classes des entités (le modèle objet).
    • La couche de présentation avec GWT et Portlet Liferay : l’interface utilisateur affiche les résultats traités par la couche métier.  Ici le framework Ajax GWT a été choisi pour à la fois offrir une ergonomie poussée et une forte maintenabilité.
  • mise en place d’une architecture de type SOA pour pouvoir exposer de façon universelle les fonctions de l’extranet pour les futures applications du SI.

Tout ceci est en production évidemment depuis la fin octobre 2009.

Agilement.

Open Source Java

Ca y est, Sun a annoncé officiellement, à l’occasion de la conférence JavaOne, son intention de passer Java sous licence open source !
C’est une grande nouvelle, cela devrait permettre, entre autres, aux distributions linux d’intégrer une JVM Java en standard, de corriger enfin les bugs de Swing, de faciliter le packaging des applications java en y encapsulant un JRE custom…

Je suis curieux de voir l’impacte à long terme de cette nouvelle licence ; « linux + java » va t-il devenir le couple gagnant ? java va t-il enfin décoller sur le client ?

Java autoupdate

Java bénéficie depuis le JRE (Java Runtime Environment) 1.5 d’une fonctionnalité de mis à jour automatique.
Ainsi à interval régulier (par défaut une fois par mois) le système téléchargera et installera la toute dernière version du JRE si nécessaire.
Seul « petit » hic, la version précédente n’est pas désinstallée ! C’est à l’utilisateur de le faire, s’il y pense bien sûr.
Sachant que la nouvelle politique de Sun est de délivrer ses correctifs plus fréquemment, on peut se retrouver avec 4 ou 5 JRE de près de 70Mo sur son poste alors que l’on pensait télécharger de simples patches !
Ce choix de déploiement (excessivement ?) défensif peut se comprendre en entreprise, mais si Sun veut imposer Java sur le client face à des concurrents tel que Flash il devra sans doute revoir sa copie.

Harmony

Voilà quelques mois, le projet harmony a officiellement démarré à la fondation Apache.
Ce projet a pour but d’offrir une implémentation open source des spécifications de « Java 2 Platform, Standard Edition ».
Concrètement, il s’agit de développer l’environnement d’exécution, les APIs, le compilateur et l’ensemble des outils standards.
Certains pensent que ce projet est sans intérêt car l’implémentation de Sun, bien que sous licence propriétaire, est gratuite.
Je ne pense pas comme cela. Je vois trois avantages majeurs à bénéficier d’un environnement java open source :

  • Plus de plateformes supportées

Java est un langage multi-plateforme. Cependant Sun ne fournit « que » trois verions de son dernier JRE (Java Runtime Environment) 1.5 ; une pour MS Windows (x86 et AMD64), une pour Solaris (SPARC, x86 et AMD64) et une pour linux (x86 et AMD64).
Apple met aussi à disposition de ses clients la dernière JVM pour MacOS (processeur PPC).
Mais que faire si l’on souhaite installer une JVM sur un serveur linux PPC ? Se tourner vers la distribution d’IBM et se contenter de la version 1.4.2.
Pire encore, si l’on utilise l’OS freeBSD il faut se satisfaire d’une version 1.3 qui n’a pas passé les tests de conformité.
Que dire des nouvelles consoles de jeux ; Xbox360, playstation3 et nintendo révolution, aucune d’entre elles ne peut, pour l’instant, faire tourner java.
Le slogan « Write once run everywhere » de java n’est aujourd’hui que partiellement vrai. Le projet Harmony s’il aboutit pourrait changer la donne.

  • Accélérer la correction des bugs

Certaines anomalies concernant l’API Swing (interface graphique) sont enregistrés dans la base de bugs de Sun depuis plus de 7 ans…
Avec une JVM open source, la communauté des développeurs ne serait plus dépendante d’un éditeur et les « bug fix » se feraient certainement plus rapidement.

  • Distribution du JRE plus aisée

Les JRE de Sun bien qu’étant librement téléchargeable n’en demeurent pas moins propriétaire et leur distribution soumise à de nombreuses contraintes. Il n’est pas possible par exemple de livrer une application java avec un JRE allégé des classes non utilisées. Il n’est pas non plus possible d’intégrer le JRE dans les distribs linux (programmes sous licence GPL et propriétaire ne peuvent cohabiter sur le même media).
Interdit aussi de repackager le JRE sous forme de package debian ou rpm et profiter ainsi des mis à jour en ligne du système (l’équivalent, en mieux ;=), du Windows update).
Une fois de plus, un projet comme harmony lèverait ces limitations.

Java 1.5.0_02

Sun vient de rendre disponible la deuxième mise à jour de la JVM 1.5.0. Cette mise à jour mineure certes, possède néanmoins selon moi un intérêt certain car elle corrige le bug non critique mais très irritant des fonts sous MS Windows. En effet, depuis la version 1.4.2, la police par défaut sous l’OS de Microsoft était mal rendue à l’écran notamment sur les caractères ‘C’,’x’ ou ‘8’. Cela n’était vraiment pas du plus bel effet ! Il semblerait que Sun commence à comprendre l’importance de ces « détails » pour l’image de Java auprès du public ou des décideurs.