Classes glorificadas na linguagem Java

Algumas classes na API Java padrão são tratadas de maneira ligeiramente diferente de outras classes. Estou falando sobre aquelas classes que não poderiam ser implementadas sem suporte especial do compilador e / ou JVM.

As que eu proponho imediatamente são:

• Object (obviamente) pois ele, entre outras coisas, não tem uma superclasse.
• String já que o idioma tem suporte especial para o operador +.
• Thread uma vez que tem este método start () mágico, apesar do fato de que não há nenhuma instrução bytecode que "bifurque" a execução.

Suponho que todas as classes como essas são de uma forma ou de outra mencionadas no JLS. Corrija-me se eu estiver errado.

De qualquer forma, que outras classes existem? Existe alguma lista completa de "classes glorificadas" na linguagem Java?

Existem muitas respostas diferentes, então pensei que seria útil coletar todas (e adicionar algumas):

Aulas

• Classes de AutoBoxing - o compilador só permite classes específicas
• Classe - tem seus próprios literais (int.class por exemplo). Eu também adicionaria sua tipagem genérica sem criar novas instâncias.
• String - com seu operador + sobrecarregado e o suporte de literais
• Enum - a única classe que pode ser usada em uma instrução switch (em breve, um privilégio a ser concedido a String também). Ele faz outras coisas também (criação automática de método estático, manipulação de serialização, etc.), mas isso poderia teoricamente ser realizado com código - é apenas um monte de boilerplate, e algumas das restrições não podem ser aplicadas em subclasses (por exemplo, regras especiais de subclasse), mas o que você nunca poderia realizar sem o status privilegiado de um enum é incluí-lo em uma instrução switch.
• Object - a raiz de todos os objetos (e eu adicionaria seus métodos de clone e finalização não são algo que você possa implementar)
• Referências : WeakReference, SoftReference, PhantomReference
• Thread - a linguagem não fornece uma instrução específica para iniciar um thread, em vez disso, ela a aplica magicamente ao método start ().
• Throwable - a raiz de todas as classes que podem trabalhar com throw, throws e catch, bem como a compreensão do compilador de Exception vs. RuntimeException e Error.
• NullPointerException e outras exceções, como ArrayIndexOutOfBounds, que podem ser lançadas por outras instruções de bytecode além de athrow.

Interfaces

• Iterable - a única interface que pode ser usada em um loop for aprimorado

As menções honrosas vão para:

• java.lang.reflect. Array - criar um novo array conforme definido por um objeto Class não seria possível.
• Anotações Eles são um recurso de linguagem especial que se comporta como uma interface em tempo de execução. Você certamente não poderia definir outra interface de Annotation, assim como não pode definir uma substituição para Object. No entanto, você poderia implementar todas as suas funcionalidades e apenas ter outra maneira de recuperá-los (e um monte de clichês) em vez de reflexão. Na verdade, havia muitas implementações baseadas em XML e em tag javadoc antes que as anotações fossem introduzidas.
• ClassLoader - certamente tem um relacionamento privilegiado com a JVM, pois não há uma forma de linguagem para carregar uma classe, embora haja uma forma de bytecode, então é como Array nesse aspecto. Ele também tem o privilégio especial de ser chamado de volta pela JVM, embora isso seja um detalhe de implementação.
• Serializável - você pode implementar a funcionalidade por meio de reflexão, mas ela tem sua própria palavra-chave privilegiada e você gastaria muito tempo se familiarizando com o SecurityManager em alguns cenários.

Nota: Eu deixei de fora da lista coisas que fornecem JNI (como IO) porque você sempre poderia implementar sua própria chamada JNI se quisesse. No entanto, as chamadas nativas que interagem com a JVM de maneira privilegiada são diferentes.

Arrays são discutíveis - eles herdam Object, têm uma hierarquia compreendida (Object [] é um supertipo de String []), mas são um recurso de linguagem, não uma classe definida por si só.

Class, claro. Ele tem seus próprios literais (uma distinção com a qual ele compartilha String, BTW) e é o ponto de partida de toda aquela magia de reflexão.

sun.misc.unsafe é a mãe de todos os hacks sujos e destruidores do espírito da linguagem.

1. Enum. Você não tem permissão para criar uma subclasse, mas o compilador pode.
2. Muitas coisas em java.util.concurrent podem ser implementadas sem suporte JVM, mas seriam muito menos eficientes.

Todas as classes de Número têm um pouco de magia na forma de Autoboxing .

Como as classes importantes foram mencionadas, mencionarei algumas interfaces:

A Iterableinterface (desde 1.5) - permite que um objeto participe de um loop foreach:

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

}

A Serializableinterface tem um significado muito especial, diferente de uma interface padrão. Você pode definir métodos que serão levados em consideração mesmo que não estejam definidos na interface (como readResolve()). A transientpalavra-chave é o elemento de linguagem que afeta o comportamento dos Serializableimplementadores.

1. Throwable , RuntimeException, Error AssertionError
2. Referências WeakReference, SoftReference, PhantomReference
3. Enum
4. Anotação

Array Java como em int[].class

java.lang.ClassLoader, embora o trabalho sujo real seja feito por alguma subclasse não mencionada (consulte 12.2.1 O processo de carregamento ).

Não tenho certeza sobre isso. Mas não consigo pensar em uma maneira de implementar manualmente os objetos IO.

Existe alguma magia na Systemclasse.

System.arraycopy é um gancho para o código nativo

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

mas...

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

Bem, já que o tratamento especial de assert foi mencionado. Aqui estão mais alguns tipos de exceção que têm tratamento especial pelo jvm:

• Null Pointer Exception
• ArithmeticException.
• StackOverflowException
• Todos os tipos de OutOfMemoryErrors
• ...

As exceções não são especiais, mas o jvm as usa em casos especiais, portanto, você não pode implementá-las sem escrever seu próprio jvm. Tenho certeza de que existem mais exceções especiais por aí.

A maioria dessas classes não é realmente implementada com a ajuda 'especial' do compilador ou JVM. O objeto registra alguns nativos que vasculham as estruturas internas da JVM, mas você também pode fazer isso para suas próprias classes. (Eu admito que isso está sujeito à semântica, "chama um nativo definido na JVM" pode ser considerado um suporte especial da JVM.)

O que / é / especial é o comportamento das instruções 'novas' e 'lançadas' sobre como inicializam essas estruturas internas.

No entanto, as anotações e os números são bastante assustadores.