Classes glorifiées dans le langage Java

Certaines classes de l'API Java standard sont traitées légèrement différemment des autres classes. Je parle de ces classes qui ne pourraient pas être implémentées sans un support spécial du compilateur et / ou de la JVM.

Ceux que je propose tout de suite sont:

• Object (évidemment) car il, entre autres choses, n'a pas de super classe.
• String car la langue a un support spécial pour l'opérateur +.
• Thread car il a cette méthode magique start () malgré le fait qu'il n'y a pas d'instruction bytecode qui "fourche" l'exécution.

Je suppose que toutes les classes comme celles-ci sont d'une manière ou d'une autre mentionnées dans le JLS. Corrige moi si je me trompe.

Quoi qu'il en soit, quelles autres classes existent? Existe-t-il une liste complète des «classes glorifiées» dans le langage Java?

Il y a beaucoup de réponses différentes, j'ai donc pensé qu'il serait utile de toutes les rassembler (et d'en ajouter):

Des classes

• Classes AutoBoxing - le compilateur n'autorise que des classes spécifiques
• Classe - a ses propres littéraux (int.class par exemple). J'ajouterais également son typage générique sans créer de nouvelles instances.
• String - avec son opérateur + surchargé et le support des littéraux
• Enum - la seule classe qui peut être utilisée dans une instruction switch (bientôt un privilège à donner également à String). Il fait également d'autres choses (création automatique de méthodes statiques, gestion de la sérialisation, etc.), mais celles-ci pourraient théoriquement être accomplies avec du code - c'est juste beaucoup de passe-partout, et certaines des contraintes ne pourraient pas être appliquées dans les sous-classes (par exemple, le règles spéciales de sous-classification) mais ce que vous ne pourriez jamais accomplir sans le statut privilégié d'une énumération est de l'inclure dans une instruction switch.
• Object - la racine de tous les objets (et j'ajouterais ses méthodes de clonage et de finalisation ne sont pas quelque chose que vous pourriez implémenter)
• Références : WeakReference, SoftReference, PhantomReference
• Thread - le langage ne vous donne pas d'instructions spécifiques pour démarrer un thread, il l'applique plutôt comme par magie à la méthode start ().
• Throwable - la racine de toutes les classes qui peuvent fonctionner avec throw, throws et catch, ainsi que la compréhension du compilateur d'Exception par rapport à RuntimeException et Error.
• NullPointerException et d'autres exceptions telles que ArrayIndexOutOfBounds qui peuvent être levées par d'autres instructions de bytecode que athrow.

Interfaces

• Iterable - la seule interface qui peut être utilisée dans une boucle for améliorée

Les mentions honorables vont à:

• java.lang.reflect. Array - la création d'un nouveau tableau tel que défini par un objet Class ne serait pas possible.
• Annotations Il s'agit d'une fonctionnalité de langage spéciale qui se comporte comme une interface au moment de l'exécution. Vous ne pouvez certainement pas définir une autre interface d'annotation, tout comme vous ne pouvez pas définir un remplacement pour Object. Cependant, vous pouvez implémenter toutes leurs fonctionnalités et avoir juste un autre moyen de les récupérer (et tout un tas de passe-partout) plutôt que de réfléchir. En fait, il y avait de nombreuses implémentations basées sur XML et basées sur des balises javadoc avant l'introduction des annotations.
• ClassLoader - il a certainement une relation privilégiée avec la JVM car il n'y a pas de langage pour charger une classe, bien qu'il y ait un moyen de bytecode, donc c'est comme Array de cette façon. Il a également le privilège spécial d'être rappelé par la JVM, bien que ce soit un détail d'implémentation.
• Sérialisable - vous pouvez implémenter la fonctionnalité via la réflexion, mais elle a son propre mot-clé privilégié et vous passeriez beaucoup de temps à vous familiariser avec SecurityManager dans certains scénarios.

Remarque: j'ai omis de la liste les éléments qui fournissent JNI (comme IO) car vous pouvez toujours implémenter votre propre appel JNI si vous le souhaitez. Cependant, les appels natifs qui interagissent avec la JVM de manière privilégiée sont différents.

Les tableaux sont discutables - ils héritent d'Object, ont une hiérarchie comprise (Object [] est un supertype de String []), mais ils sont une fonctionnalité de langage, pas une classe définie en soi.

Class, bien sûr. Il a ses propres littéraux (une distinction avec laquelle il partage String, BTW) et est le point de départ de toute cette magie de réflexion.

sun.misc.unsafe est la mère de tous les hacks sales et révolutionnaires.

1. Enum. Vous n'êtes pas autorisé à le sous-classer, mais le compilateur le peut.
2. Beaucoup de choses sous java.util.concurrent peuvent être implémentées sans le support JVM, mais elles seraient beaucoup moins efficaces.

Toutes les classes Number ont un peu de magie sous la forme d' Autoboxing .

Puisque les classes importantes ont été mentionnées, je mentionnerai quelques interfaces:

L' Iterableinterface (depuis 1.5) - elle permet à un objet de participer à une boucle foreach:

Iterable<Foo> iterable = ...;
for (Foo foo : iterable) {

}

L' Serializableinterface a une signification très particulière, différente d'une interface standard. Vous pouvez définir des méthodes qui seront prises en compte même si elles ne sont pas définies dans l'interface (like readResolve()). Le transientmot-clé est l'élément de langage qui affecte le comportement des Serializableimplémenteurs.

1. Throwable , RuntimeException, Erreur AssertionError
2. Références WeakReference, SoftReference, PhantomReference
3. Enum
4. Annotation

Tableau Java comme dans int[].class

java.lang.ClassLoader, bien que le sale boulot soit effectué par une sous-classe non mentionnée (voir 12.2.1 Le processus de chargement ).

Pas sûr à ce sujet. Mais je ne peux pas penser à un moyen d'implémenter manuellement des objets IO.

Il y a de la magie dans la Systemclasse.

System.arraycopy est un crochet dans le code natif

public static native void arraycopy(Object array1, int start1, 
  Object array2, int start2, int length);

mais...

/**
 * Private version of the arraycopy method used by the jit
 * for reference arraycopies
 */
private static void arraycopy(Object[] A1, int offset1,
  Object[] A2, int offset2, int length) {
   ...
}

Eh bien, depuis le traitement spécial d'assert a été mentionné. Voici d'autres types d'exceptions qui bénéficient d'un traitement spécial par le jvm:

• NullPointerException
• ArithmeticException.
• StackOverflowException
• Toutes sortes d'erreurs OutOfMemory
• ...

Les exceptions ne sont pas spéciales, mais le jvm les utilise dans des cas particuliers, vous ne pouvez donc pas les implémenter vous-même sans écrire votre propre jvm. Je suis sûr qu'il existe des exceptions plus spéciales.

La plupart de ces classes ne sont pas vraiment implémentées avec l'aide «spéciale» du compilateur ou de la JVM. Object enregistre certains natifs qui fouillent dans les structures JVM internes, mais vous pouvez également le faire pour vos propres classes. (J'admets que cela est sujet à la sémantique, "appeler un natif défini dans la JVM" peut être considéré comme un support JVM spécial.)

Ce qui est / est / spécial est le comportement des instructions «nouvelles» et «lancées» dans la manière dont elles initialisent ces structures internes.

Les annotations et les chiffres sont cependant assez bizarres.