Passer votre application Java8 en Java11

Java 8 est encore largement utilisé dans les entreprises aujourd’hui. Il y a même certains frameworks qui n’ont pas encore sauté le pas.
Je vais essayer d’exposer dans cette article les étapes à réaliser pour migrer (simplement) votre application JAVA8 en JAVA 11.

Dans cet article, je prendrai comme postulat que l’application se construit avec Maven.

Pré-requis

Tout d’abord vérifiez votre environnement d’exécution cible! Faites un tour du coté de la documentation et regardez le support de JAVA.

Si vous utilisez des FRAMEWORKS qui utilisent des FAT JARS, faites de même (ex. pour spring boot, utilisez au moins la version 2.1.X).

Ensuite, vous aurez sans doute à mettre à jour maven ou gradle. Préférez les dernières versions.

Configuration maven

Les trois plugins à mettre à jour obligatoirement sont :

Maven compiler plugin

<plugin>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <release>11</release>
          <encoding>UTF-8</encoding>
        </configuration>
      </plugin>

maven surefire / failsafe plugin

Pour ces deux plugins, ajouter la configuration suivante:

 <plugin>
        <artifactId>maven-surefire-plugin</artifactId>
        <version>2.22.2</version>
        <configuration>
        [...]
          <argLine>--illegal-access=permit</argLine>
          [...]
        </configuration>
      </plugin>

Mise à jour des librairies

Bon,la il n’y a pas de magie. Vous devez mettre à jour toutes vos librairies. Mis à part si vous utilisez des librairies exotiques, la plupart supportent JAVA 11 maintenant.

C’est une bonne opportunité de faire le ménage dans vos fichiers pom.xml 🙂

APIS supprimées du JDK

Si vous faites du XML, SOAP ou que vous utilisiez l’API activation, vous devez désormais embarquer ces librairies. Le JDK ne les inclut plus par défaut.

Par exemple:

 <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-core</artifactId>
            <version>2.3.0.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>com.sun.xml.bind</groupId>
            <artifactId>jaxb-impl</artifactId>
            <version>2.3.0.1</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>javax.xml.bind</groupId>
            <artifactId>jaxb-api</artifactId>
            <version>2.3.1</version>
        </dependency>

Modularisation avec JIGSAW

Bon là … je vous déconseille de partir directement sur la modularisation, surtout si vous migrez une application existante. Bien que la modularité puisse aider à réduire vos images docker en construisant vos propres JRE et d’améliorer la sécurité, elle apporte son lot de complexité.
Bref pour la majorité des applications, je vous déconseille de l’intégrer.

Conclusion

Avec toutes ces manipulations, vous devriez pouvoir porter vos applications sur JAVA11. Il y aura sans doute quelques bugs. Personnellement, j’en ai eu avec CGLIB vs Spring AOP sur une classe instrumentée avec un constructeur privé. Sur ce coup j’ai contourné ce problème ( je vous laisse deviner comment 🙂 ).

Premiers pas avec Gradle

Depuis quelques temps je me mets à Gradle. Après de (trop?) nombreuses années à utiliser Maven (depuis la version 0.9…), je me risque à modifier mon environnement de build. Du moins sur des projets démo.

Quand on a fait pas mal de Maven, on est un peu dérouté au début. On a d’un coté, la plupart des actions qui sont configurées de manière implicite et de l’autre on peut tout coder/étendre ou presque.

Je ne vais pas me risquer à faire un comparatif des deux outils. Gradle ( donc fortement orienté ) en a fait un.

Je vais plutôt décrire avec cet article comment on peut démarrer rapidement en configurant son environnement pour être utilisé en entreprise.

Installation

Le plus simple est d’utiliser SDKMAN.

Voici la manipulation pour l’installer:

$ curl -s "https://get.sdkman.io" | bash
$ source "$HOME/.sdkman/bin/sdkman-init.sh"
$ sdk install gradle 6.0.1

Configuration d’un proxy

Et oui comment souvent, passer le proxy d’entreprise est la moitié du boulot :).
Pour le configurer de manière globale (c.-à-d. pour tous vos projets) sur votre poste de travail, vous devez créer un fichier gradle.properties dans le répertoire $HOME/.gradle :

systemProp.http.proxyHost=proxy
systemProp.http.proxyPort=8888
systemProp.http.nonProxyHosts=localhost|127.0.0.1
systemProp.https.proxyHost=proxy
systemProp.https.proxyPort=8888
systemProp.https.nonProxyHosts=localhost|127.0.0.1

Configuration d’un miroir Nexus ou Artifactory

A l’instar du proxy, on va essayer de mettre en place une configuration globale. Pour ce faire, on va utiliser les init scripts. Cette fonctionnalité est très intéressante. Elle permet de centraliser des actions et configurations.
Pour créer un script, il faut tout d’abord créer un fichier .gradle dans le répertoire $HOME/.gradle/init.d.

Voici un exemple pour Nexus:

allprojects { 
  buildscript { 
    repositories {
      mavenLocal() 
      maven {url "https://url-nexus"} 
    }
  }
  repositories { 
    mavenLocal()
    maven { url "https://url-nexus"}
  }
}

Configuration du déploiement dans Nexus / Artifactory

Le déploiement dans Nexus est possible via le plugin maven publish. La configuration fournie dans la documentation est tellement bien faite ( comme le reste d’ailleurs ) que je ne vais que mettre un lien vers celle-là:
Voici le lien.

Conclusion

Après ces quelques actions vous pourrez démarrer des builds avec gradle tout en étant compatible avec un environnement « Maven ».
Enjoy 🙂

Programmmation par aspect avec Spring AOP

Une fois n’est pas coutume, voici un article qui reprend des basiques de la programmation. J’aborde une stack JAVA, mais c’est applicable à d’autres langages.

Il existe une fonctionnalité très intéressante dans Spring (et dans J(akarta)EE) que l’on oublie assez souvent : l’AOP ou encore la programmation par aspect. Cette manière de programmer permet notamment de séparer le code fonctionnel et technique.
Si vous faites du JAVA, vous utilisez déjà l’AOP. En effet, quand vous faites une insertion en base via JPA dans un EJB ou un bean annoté @Transactional, une transaction est initiée au début de la méthode et fermée à la fin.

Avec Spring et notamment dans Spring boot, voici comment initier l’AOP.

Configuration maven

Ajouter le starter AOP:

 <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-aop</artifactId>
        </dependency>

Activation des aspects

Dans la configuration ci-dessous, je prendrai comme exemple le logging des méthodes ( un log en début de méthode et un log en fin ). 

La définition des aspects se fait dans des classes annotées par @Configuration.

@Configuration
@Aspect
@ConditionalOnProperty(name = "debug.enabled", havingValue = "true")
public class DebuggingConfiguration {

private static final Logger LOGGER = LoggerFactory.getLogger(DebuggingConfiguration.class);
private static final String WITHIN_MY_PACKAGE = "within(my.package..*)";

/**
* Log before execution
*
* @param joinPoint the current method
*/
@Before(WITHIN_MY_PACKAGE)
public void logBeforeExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("Beginning of method : [{}]", joinPoint.getSignature().getName());
}
}

/**
* Log after execution
*
* @param joinPoint the current method
*/
@After(WITHIN_MY_PACKAGE)
public void logAfterExecution(JoinPoint joinPoint) {
if (LOGGER.isTraceEnabled()) {
LOGGER.trace("End of method : [{}]", joinPoint.getSignature().getName());
}
}
}

L’utilisation de l’ annotation @ConditionalOnProperty me permet d’activer cette classe de configuration seulement si la propriété debug.enabled est initialisée à true.

Les annotations @Before et @After indiquent à Spring AOP quand exécuter ces méthodes ou sur quelles méthodes. Dans mon cas, quand les méthodes appelées sont définies dans les classes d’un package défini.

Pour plus de détails sur la syntaxe et les possibilités, vous pouvez vous référer à la documentation.


Mocker des méthodes « final » avec Mockito

Auparavant, dans nos tests, quand on voulait mocker des méthodes « final » ou statiques, on devait passer par PowerMock.

Depuis peu, si on utilise Mockito ( >2.1) , on n’a plus besoin d’ajouter PowerMock pour mocker des méthodes « final ».

Bon il reste toujours la gestion des méthodes statiques à gérer autrement qu’avec Mockito, mais cela va dans le bon sens.

Voici comment activer en quelques commandes le mocking des méthodes « final ».

Dans le répertoire src/test/resources, il faut créer un répertoire mockito-extensions avec un fichier nommé org.mockito.plugins.MockMaker.

src/test/resources
└── mockito-extensions
└── org.mockito.plugins.MockMaker

A l’intérieur de ce fichier, vous devrez ajouter le contenu suivant :

mock-maker-inline

Avec cette configuration, vous pourrez dorénavant mocker des méthodes « final » 🙂

Enjoy

Devoxx 2019

En attendant de prendre mon train, j’essaye de me remettre de cette nouvelle édition. Cette année JAVA est revenu au premier plan. Que ça soit via la spécification microprofile, quarkus , graalvm ou encore par les problématiques de migration JDK 8 -> 11. On a pas mal vu des architectures micro services à base de service mesh (istio) et kubernetes.

A coté des sujets techniques, un des sujets majeurs  était le bien être et la bienveillance au travail.

Les vidéos des conférences seront bientôt retransmises sur le channel Youtube de DevoxxFR.

D’une manière générale, le niveau des conférences est toujours très bon.

J’ai particulièrement apprécié les confs suivantes. N’hésitez pas à les visionnez une fois qu’elles seront disponibles sur Youtube.

Il y a aussi certaines conférences ou j’ai eu un bon écho :

Je pense qu’il y a encore bien d’autres conférences qui ont été très intéressantes. J’ ai quelques heures de visionnage à prévoir dans mon agenda 🙂 . Quoi qu’il en soit, merci aux organisateurs pour cette édition. C’était top!

Rendez vous l’année prochaine !

 

Devoxx 2018

L’édition 2018 de DEVOXX touche bientôt à sa fin. Pour ceux qui ne connaissent pas cette conférence, c’est LA conférence sur le développement en France. A titre personnel, je peux plus apprendre en trois jours à cette conférence qu’en formation.

img_20180419_155256624099247.jpg

Tout d’abord un grand merci aux organisateurs. Ils assurent réellement. Bon, pour l’année prochaine, n’hésitez à retenir ma conférence 😉

Si vous n’avez pas eu la chance d’assister aux trois jours, il faut savoir que vous pourrez voir les rediff sur la chaine youtube.

Les tendances

Voici les tendances que  j’ai retenu :

  • Spring, spring et encore spring
  • Du réactif en veux tu en voila
  • Du DDD sinon rien
  • Du devops

et le plus impressionnant pour moi était la conférence de JOSHUA BLOCH(!!!) sur Effective Java. Pas tant dans le contenu, car il reprenait peu ou prou celui du livre, mais de voir une personne de ce calibre (dans le monde JAVA, c’est une rock star) en France, c’est assez impressionnant.

Les keynotes ( dont celle sur le smart building) étaient dans l’ensemble très intéressantes. Les conférences étaient également d’un très bon niveau. J’ai pu découvrir par exemple l’avance que peut avoir l’Estonie sur l’IT ( voir le projet x-road )  par rapport à la France qui lance le projet french road.

Voici quelques conférences qui m’ont plu et interpelé :

Je ne vais pas trop les décrire ( voire pas du tout ), elles seront disponibles prochainement sur la chaine youtube .