Pourquoi NoClassDefFoundError causée par un champ statique de l'initialisation de l'échec?

Voici un intéressant java question.

suivantes simple programme java contient un champ statique initialisé par une méthode statique. En fait, j'ai de la force de la méthode de calculer la intiailize valeur pour élever un NullPointException, Quand je accéder à un champ statique, un NoClassDefFoundError seront soulevées. il semble que la VM traiter la Classe n'est pas complète.

Mais lorsque j'accède à la Classe, il toujours disponible;

Personne ne sait pourquoi?

class TestClass {
    public static TestClass instance = init();

    public static TestClass init() {
       String a = null;
       a.charAt(0); //force a null point exception;
       return new TestClass();
    }
}

class MainClass {
    static public void main(String[] args) {
       accessStatic(); //a ExceptionInInitializerError raised cause by NullPointer
       accessStatic(); //now a NoClassDefFoundError occurs;

       //But the class of TestClass is still available; why?
       System.out.println("TestClass.class=" + TestClass.class);
    }

    static void accessStatic() {
        TestClass a;

        try {
            a = TestClass.instance; 
        } catch(Throwable e) {
            e.printStackTrace();
        }
    }   
}
  • C'est surprenant pour moi, trop! Je ping un ami qui pourrait connaître la réponse; nous allons voir s'il répond.
  • Je pense que, le chargeur de classe ne parvient pas à charger la TestClass en raison de l'exception dans l'initialiseur statique
  • cette partie est triviale; je ne crois pas qu'il demande même à ce sujet. Ce qui est étonnant, est le troisième impression qui montre que TestClass.class dans MainClass contient en fait une référence à un objet physique Class objet. Si la classe n'est pas correctement initialisé, pourquoi sommes-nous autorisés à toucher à tous?
  • TestClass.class ne semble pas déclencher de chargement de classe et on dirait qu'il est accessible et disponible indifférent de savoir si ou non la classe a été chargé.
InformationsquelleAutor ext2 | 2011-06-15
  1. 34

    La réponse à ces questions est généralement enterré quelque part dans les specs... (§12.4.2)

    Ce qui se passe lorsque les classes sont initialisés:

    Les étapes 1 à 4 sont un peu étrangers à cette question. Étape 5 ici est ce qui déclenche l'exception:

    5. Si la Classe de l'objet est dans un erronée de l'état, puis l'initialisation n'est pas possible. Libérer le verrou sur l'objet de Classe et jeter un NoClassDefFoundError.

    6-8 poursuivre l'initialisation, 8 exécute les initialiseurs, et ce qu'il se passe est à l'étape 9:

    9. Si l'exécution de la initialiseurs se termine normalement, puis verrouiller cet objet de Classe, le label de complètement initialisé, informer tous les threads en attente, libérer le verrou, et de compléter cette procédure normalement.

    Mais nous avons eu une erreur dans l'initialiseur, donc:

    10. Sinon, les initialiseurs doivent avoir terminé brusquement en lançant une exception E. Si la classe de E n'est pas une Erreur ou un de ses sous-classes, puis créer une nouvelle instance de la classe ExceptionInInitializerError, avec E comme argument, et l'utilisation de cet objet à la place de E dans l'étape suivante. Mais si une nouvelle instance de ExceptionInInitializerError ne peut pas être créé car un OutOfMemoryError se produit, alors, au lieu d'utiliser un OutOfMemoryError objet à la place de E dans l'étape suivante.

    Yep, nous voyons un ExceptionInInitializerError b/c de l'exception de pointeur null.

    11. Verrouillage de la Classe de l'objet, l'étiquette erronée, informer tous les threads en attente, libérer le verrou, et d'effectuer cette procédure, brusquement, avec raison, E ou son remplacement tel que déterminé à l'étape précédente. (En raison d'une faille dans les premières implémentations, une exception lors de l'initialisation de classe a été ignorée, plutôt que de provoquer une ExceptionInInitializerError comme décrit ici.)

    Et puis la classe est marquée erronée qui est pourquoi nous sommes l'exception de l'étape 5 de la deuxième fois.

    Ce qui est étonnant, est le troisième impression qui montre que TestClass.class dans MainClass contient en fait une référence à un objet physique Class objet.

    Probablement parce que TestClass existe toujours, c'est juste marqué erronée. Il a déjà été chargée et vérifiées.

    • grand. c'est le problème du nom de "NoClassDefFoundError", on doit lire les spec de la comprendre. ni le nom, ni la javadoc explique ce que c'est. parce que tant de java gourous ne comprends même pas après tant d'années, il est sûr de dire que le nom est un échec complet.
    • "(Dû à un défaut dans les premières implémentations, une exception lors de l'initialisation de classe a été ignorée, plutôt que de provoquer une ExceptionInInitializerError comme décrit ici.)" - Dans lequel les versions de Java est cette faille présenter? J'ai vécu cela en Java 1.8.0_25-b17. Un NoClassDefFound erreur a été d'être jeté sur la classe d'initialisation, mais l'exception d'origine a été d'être jeté (me causant de nombreuses heures de stress en essayant de comprendre ce qui n'allait pas avec mon classpath).
    InformationsquelleAutor trutheality
  2. 14

    Oui, c'est généralement pourquoi NoClassDefFoundError est soulevée. C'est mal nommé, c'est tout. Il aurait été nommé en tant que "classe init exception d'échec" ou de quelque chose.

    Parce que le nom trompeur, les programmeurs java qui est eu cette erreur gaspillé des centaines de homme des années à essayer de comprendre pourquoi la classe ne peut pas être trouvé.

    Chaque fois que vous voyez cette exception, vous devriez vérifier le journal d'en haut, et essayer de trouver la cause racine lorsque la classe a échoué à init.

    • La classe est mal nommée, mais le problème est en grande partie de l'entreprise de programmation de décisions. Son application ne devrait pas avoir de essayé pour récupérer à partir de la NoClassDefFoundError la première fois qu'il a été soulevé.
    • Je ne trouve pas ça mal nommée. Il est plus à un mauvais choix de la levée d'une exception de classe pendant l'initialisation de l'échec. Le NoClassDefFoundError a certainement son utilisation dans d'autres circonstances (par exemple, la définition de la classe n'est pas trouvé lors de l'exécution de chemin de classe alors qu'il était sûr qu'il était disponible dans le compile-time classpath).
    • vous avez dit qu'il mieux sur le choix des noms ...
    • C'est injuste pour le programmeur. Dans toutes les applications, les classes sont d'accès par plusieurs threads. Si une classe ne parviennent pas à initialiser, le premier thread accéder à ce qu'il obtienne une erreur d'initialisation, les autres threads accèdent à ce qu'il obtienne une classe def ne trouve pas d'erreur. l'erreur n'est pas seulement mal nommé. il est extrêmement fréquent que statique initialisation échoue, il mérite d'être explicites nom. "classe def", quel qu'il soit, (avis de l'insolite abbr de def), est un jargon inconnu à la moyenne des programmeurs java, et pourtant, il est nommé ainsi du mal qui envoie des gens dans le mauvais message. Complètement cryptique nom serait mieux que celui-ci.
    • le premier thread qui obtient cette erreur doit tirer la prise sur l'ensemble de l'application au lieu de tranquillement en train de mourir. Installer un défaut de l'exception non interceptée pour ce faire.
    • personne ne va mettre à bas l'ensemble du site, car une classe ne parvient pas à init
    • Si le comportement judicieux de l'ensemble de l'application dépend de la non-gestion par défaut des conditions exceptionnelles, le système des exceptions est mal conçu. Si des Erreurs doit arrêter l'ensemble de l'application, ce qui devrait être le comportement du système par défaut par défaut de l'exception non interceptée.
    • Je suis d'accord. Il doit être le comportement du système par défaut par défaut de l'exception non interceptée ... mais il est généralement pas. C'est une faute de Java en première instance ... et de cadres comme Tomcat, etc ... qui ne sont pas compenser pour cela.
    • De loin le plus grand mal de NoClassDefFoundError est qu'il ne prend pas un cause. Cela a entraîné des millions, voire des milliards de dollars en perte de productivité. Un incroyablement idiot décision.

    InformationsquelleAutor irreputable
  3. 3

    Quand je accéder à un champ statique, un NoClassDefFoundError seront soulevées. il semble que la VM traiter la Classe n'est pas complète.

    Que c'est correct ...

    Mais lorsque j'accède à la Classe, il toujours disponible

    Oui.

    Le chargeur de classe n'a pas essayé de supprimer le cassé de la classe parce que:

    • il serait difficile de le faire,
    • il serait extrêmement difficile à faire en toute sécurité,
    • qu'il laisserait de la JVM dans un état dans lequel une application peut facilement perdre beaucoup de temps à plusieurs reprises chargement et rechargement de code cassé, et
    • les spécifications dire (ou au moins l'indiquent) qu'il ne devrait pas; voir d'autres réponses pour plus de détails.

    À entrer dans un état où cette incohérence est visible, votre application a pour attraper ClassDefNotFoundError (ou une super-classe) et a tenté de la récupérer. Il est un fait bien documenté que Error les exceptions sont généralement pas récupérables; c'est à dire si vous tentez de récupérer, la JVM peut se retrouver dans un état incohérent. C'est ce qui s'est passé ici ... à l'égard des classes qui ont été en cours de chargement /initialisé.

    InformationsquelleAutor Stephen C