Pratiquement tout le monde parmi les équipes de développement logiciel a déjà entendu parler du fameux NPE AKA NullPointerException.

Certains développeurs testent systématiquement la nullité d'une variable avant de l'utiliser même s’il y 'a  des fois où ils ont tort de le faire, car le nullpointer est là pour indiquer que quelque chose ne tourne pas rond et nous invite à investiguer d'avantage pour comprendre notre code et prévenir les erreurs.

Dans les cas simples, on voit tout de suite l'origine d'un NEP, et on peut le corriger facilement ;)

Cependant lorsque le code est plus complexe et que  par exemple une exception NPE se produit sur une ligne de code qui permet d'évaluer des instructions et fonctions complexe tels que les lambdas sur une ligne, il est plus difficile de connaitre l'origine du NPE sans devoir débuguer le cas.

a[i][j][k] = 99

Cela veut dire par exemple que si vous avez une NPE en prod, vous devez au préalable exécuter votre code en production pas à pas afin de déterminer le NPE.

La JEP-358 est une amélioration apporté par JAVA14 qui vise à faciliter le débogage des exceptions nullpointer et peut fournir des informations plus précisent concernant la variable à l'origine du NPE.

 Par exemple dans le code ci-dessous

a.i = 99

On aura un message explicite sur plusieurs lignes 

Exception in thread "main" java.lang.NullPointerException:
        Cannot assign field "i" because "a" is null
    at Prog.main(Prog.java:5)

Et pour une ligne encore plus complexe : 

a.b.c.i = 99;

 On aura un message qui permet de savoir l'origine du NPE,

Exception in thread "main" java.lang.NullPointerException:
        Cannot read field "c" because "a.b" is null
    at Prog.main(Prog.java:5)

Cette fonctionnalité peut être particulièrement intéressante  pour les équipes de TMA et peut permettre de gagner beaucoup de temps d'investigation sur les NPE.