"Java.lang.NoClassDefFoundError: Impossible d'initialiser la classe java.nio.file.FileSystems $ DefaultFileSystemHolder" se produit même s'il n'y a pas de problème pour vérifier le chemin de la classe et l'encodage plusieurs fois.

Même si je recherche sur le net, il n'y a aucune information, donc je l'écrirai à des fins de partage.

Cause

Se produit lorsqu'un répertoire inexistant est défini comme répertoire actuel.

Je ne sais pas si tous les autres systèmes de fichiers ont les mêmes spécifications, mais au moins dans RedHat7, si vous supprimez le répertoire actuel, vous serez dans un répertoire qui n'existe pas.

[root@******** ~]$ cd hoge
[root@******** hoge]$ rmdir ../hoge
[root@******** hoge]$

Se produit lorsque le processus d'initialisation de la classe DefaultFileSystemHolder est exécuté dans cet état. Puisqu'il est utilisé dans la classe java.nio.file.Paths, il semble y avoir de bonnes chances que le processus d'initialisation s'exécute.

Que s'est-il passé dans mon environnement

Un rapport d'échec a été généré indiquant que l'exception suivante s'est produite lors de l'exécution d'un certain programme.

java.lang.NoClassDefFoundError: Could not initialize class java.nio.file.FileSystems$DefaultFileSystemHolder
        at java.nio.file.FileSystems.getDefault(FileSystems.java:176)
        at java.nio.file.Paths.get(Paths.java:84)
・ ・ ・

Puisque NoClassDefFoundError est affiché, je vérifie le chemin de classe et le fichier jar, mais peu importe le nombre de fois que je le vérifie. Si vous essayez google, vous trouverez un rapport de bogue JDK tel que ici qui "se produit lorsque file.encoding est cp037". Cependant, je n'ai pas touché file.encoding en premier lieu ... Ou plutôt, il ne se reproduit pas même s'il est exécuté de la même manière sur le même serveur que le rapport d'échec.

Ce programme envoie les fichiers d'un certain répertoire vers l'extérieur et supprime le répertoire une fois l'envoi terminé. Lorsque j'ai soigneusement examiné les captures d'écran dans le rapport d'échec, il a été exécuté avec le répertoire à supprimer étant le répertoire actuel. Si vous essayez la même chose, elle sera reproduite.

Après un petit débogage, il semble que "sun.nio.fs.UnixException: Il n'y a pas de tel fichier ou répertoire" s'est produit pendant le processus d'initialisation de DefaultFileSystemHolder, mais le point d'occurrence racine n'a pas été dépassé. Hmm. J'espère que quelqu'un qui connaît les informations contenues dans cet article la recherchera.