Classi glorificate nel linguaggio Java

Alcune classi nell'API Java standard vengono trattate in modo leggermente diverso dalle altre classi. Sto parlando di quelle classi che non potrebbero essere implementate senza un supporto speciale da parte del compilatore e / o JVM.

Quelli che mi vengono in mente subito sono:

• Object (ovviamente) in quanto, tra l'altro, non ha una super classe.
• String poiché la lingua ha un supporto speciale per l'operatore +.
• Thread poiché ha questo magico metodo start () nonostante il fatto che non ci siano istruzioni bytecode che "biforcano" l'esecuzione.

Suppongo che tutte le classi come queste siano in un modo o nell'altro menzionate nel JLS. Correggimi se sbaglio.

Comunque, quali altre classi simili esistono? Esiste un elenco completo di "classi glorificate" nel linguaggio Java?

Ci sono molte risposte diverse, quindi ho pensato che sarebbe stato utile raccoglierle tutte (e aggiungerne alcune):

Classi

• Classi di AutoBoxing : il compilatore consente solo classi specifiche
• Class - ha i suoi letterali (int.class per esempio). Aggiungerei anche la sua tipizzazione generica senza creare nuove istanze.
• Stringa - con il suo operatore + -credito e il supporto dei letterali
• Enum - l'unica classe che può essere utilizzata in un'istruzione switch (presto anche un privilegio da dare a String). Fa anche altre cose (creazione automatica di metodi statici, gestione della serializzazione, ecc.), Ma queste potrebbero teoricamente essere realizzate con il codice: è solo un sacco di boilerplate e alcuni dei vincoli non possono essere applicati nelle sottoclassi (ad es. regole speciali di sottoclasse) ma ciò che non potresti mai ottenere senza lo stato privilegiato di un'enumerazione è includerlo in un'istruzione switch.
• Object : la radice di tutti gli oggetti (e aggiungerei i suoi metodi clone e finalize non sono qualcosa che potresti implementare)
• Riferimenti : WeakReference, SoftReference, PhantomReference
• Thread : il linguaggio non ti dà un'istruzione specifica per avviare un thread, piuttosto lo applica magicamente al metodo start ().
• Throwable : la radice di tutte le classi che possono lavorare con throw, throws e catch, nonché la comprensione del compilatore di Exception vs RuntimeException ed Error.
• NullPointerException e altre eccezioni come ArrayIndexOutOfBounds che possono essere lanciate da altre istruzioni bytecode diverse da athrow.

Interfacce

• Iterabile : l'unica interfaccia che può essere utilizzata in un ciclo for migliorato

Le menzioni d'onore vanno a:

• java.lang.reflect. Array : la creazione di un nuovo array come definito da un oggetto Class non sarebbe possibile.
• Annotazioni Sono una caratteristica del linguaggio speciale che si comporta come un'interfaccia in fase di runtime. Certamente non potresti definire un'altra interfaccia di annotazione, così come non puoi definire una sostituzione per Object. Tuttavia, potresti implementare tutte le loro funzionalità e avere solo un altro modo per recuperarle (e un intero gruppo di boilerplate) piuttosto che riflettere. In effetti, c'erano molte implementazioni basate su XML e javadoc tag prima dell'introduzione delle annotazioni.
• ClassLoader - ha certamente una relazione privilegiata con la JVM in quanto non esiste un modo di linguaggio per caricare una classe, sebbene esista un modo bytecode, quindi è come Array in quel modo. Ha anche il privilegio speciale di essere richiamato dalla JVM, sebbene si tratti di un dettaglio di implementazione.
• Serializzabile : potresti implementare la funzionalità tramite reflection, ma ha una sua parola chiave privilegiata e in alcuni scenari passeresti molto tempo a entrare in intimità con SecurityManager.

Nota: ho lasciato fuori dalla lista le cose che forniscono JNI (come IO) perché potresti sempre implementare la tua chiamata JNI se fossi così incline. Tuttavia, le chiamate native che interagiscono con la JVM in modi privilegiati sono diverse.

Gli array sono discutibili: ereditano Object, hanno una gerarchia comprensibile (Object [] è un supertipo di String []), ma sono una caratteristica del linguaggio, non una classe definita di per sé.

Class, ovviamente. Ha i suoi letterali (una distinzione con cui condivide String, BTW) ed è il punto di partenza di tutta quella magia di riflessione.

sun.misc.unsafe è la madre di tutti gli hack sporchi e che spezzano lo spirito della lingua.

1. Enum. Non sei autorizzato a sottoclassarlo, ma il compilatore può.
2. Molte cose sotto java.util.concurrent possono essere implementate senza il supporto JVM, ma sarebbero molto meno efficienti.

Tutte le classi Number hanno un po 'di magia sotto forma di Autoboxing .

Poiché sono state menzionate le classi importanti , menzionerò alcune interfacce:

L' Iterableinterfaccia (dalla 1.5) - consente a un oggetto di partecipare a un ciclo foreach:

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

}

L' Serializableinterfaccia ha un significato molto speciale, diverso da un'interfaccia standard. È possibile definire metodi che verranno presi in considerazione anche se non sono definiti nell'interfaccia (come readResolve()). La transientparola chiave è l'elemento del linguaggio che influenza il comportamento degli Serializableimplementatori.

1. Throwable , RuntimeException, Error AssertionError
2. Riferimenti WeakReference, SoftReference, PhantomReference
3. Enum
4. Annotazione

Array Java come in int[].class

java.lang.ClassLoader, sebbene il lavoro sporco effettivo sia svolto da qualche sottoclasse non menzionata (vedere 12.2.1 Il processo di caricamento ).

Non sono sicuro di questo. Ma non riesco a pensare a un modo per implementare manualmente gli oggetti IO.

C'è un po 'di magia nella Systemclasse.

System.arraycopy è un aggancio al codice nativo

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

ma...

/**
 * 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) {
   ...
}

Bene, da quando è stata menzionata la gestione speciale di assert. Ecco alcuni altri tipi di eccezioni che hanno un trattamento speciale da parte della jvm:

• NullPointerException
• ArithmeticException.
• StackOverflowException
• Tutti i tipi di OutOfMemoryErrors
• ...

Le eccezioni non sono speciali, ma la jvm le usa in casi speciali, quindi non puoi implementarle da solo senza scrivere la tua jvm. Sono sicuro che ci siano altre eccezioni speciali in giro.

La maggior parte di queste classi non è realmente implementata con l'aiuto "speciale" del compilatore o della JVM. Object registra alcuni nativi che esplorano le strutture JVM interne, ma puoi farlo anche per le tue classi. (Ammetto che questo sia soggetto a semantica, "chiama un nativo definito nella JVM" può essere considerato come supporto JVM speciale.)

Ciò che / è / speciale è il comportamento delle istruzioni "nuove" e "lancia" nel modo in cui inizializzano queste strutture interne.

Le annotazioni e i numeri sono praticamente stravaganti.