¿Por qué no está disponible getClass() como método estático?

Question

En contextos estáticos, ¿cómo es que no puede llamar a una versión estática de getClass() (en lugar de tener que usar my.package.name.MyClassName.class)?

¿No es el compilador lo suficientemente inteligente como para determinar cuándo usar métodos de objetos + cuándo usar métodos estáticos?

---

para mayor claridad NOTA:

no estoy diciendo que un static getClass() debe usarse en lugar del método no estático getClass() (que es bastante obvio - si SpecialFoo es una subclase de Foo , entonces el getClass() de un Foo podría devolver Foo.class o SpecialFoo.class o algo más y debe determinarse en tiempo de ejecución).

Estoy diciendo que me pregunto por qué no hay dos versiones de getClass(), que es un método estático que sólo se aplica en un contexto estático, y el método no estático normal getClass(). Si no es posible, entonces no es posible, y esa es la respuesta. Si es posible, pero no se ha hecho, entonces es una opción histórica, y tal vez haya una buena razón para ello. Eso es lo que me gustaría saber.

Sería muy bueno para declarar

final static Logger logger = LoggerFactory.getLogger(getClass()); 

en lugar de

final static Logger logger = LoggerFactory.getLogger(my.package.name.MyClass.class); 

en el que el primero podría ser copiado textualmente de una clase a la siguiente, mientras que el segundo se requiere para copiar el nombre de la clase en cada archivo.

Answer 1

Si nada más, porque no es legal tener tanto una versión de un método (y no staticstatic probablemente porque es legal, si desalentado, para llamar a un método en un static no static contexto).

También me parece que este método, aunque útil en el contexto de la definición de un registrador o lo que sea, podría ser confuso en otros contextos, como cuando se llama desde un método de instancia.

Answer 2

Cada objeto es una instancia de una clase en Java y ninguna clase puede ser una instancia de otra clase. Es por eso que getClass() no es estático ya que solo tiene sentido en el contexto de un objeto: estás tratando de encontrar para un objeto en qué clase es una instancia de. Si se trata de una función estática, se le puede llamar fuera de un objeto - pero no tiene sentido escribir

String.getClass() 

porque ya se sabe que está "pidiendo" la clase String!

Answer 3

Porque si getClass() fuera estático, su código debería definirse en una clase, probablemente Object. Allí, no puede determinar la clase de llamadores y no hay una instancia de objeto que la llame.

Editar:

No se trata del nombre; podría estar muy bien getClass2(). Estoy diciendo que si se define un método estático, no se puede saber la clase que lo llama:

public class Object { 

    public static Class<?> getClass2() { 
     return ...? 
    } 

} 

Answer 4

getClass() proporciona una funcionalidad diferente que el .class estática. Se usa para obtener la clase de tiempo de ejecución de la instancia a la que se llama.

Object o = new String(); 
o.getClass() // returns Class<String>  
Object.class // returns Class<Object> 

Answer 5

No sería un método estático getClass() devolver la clase de objeto a la clase de la variable que contiene el objeto es de? Eso cambiaría la semántica de getClass(). Ejemplo:

Interface foo = new FooImpl(); 
foo.getClass(); // returns Class<FooImpl> because the runtime type is FooImpl. 
       // If getClass() was static, it would return Class<Foo>. 

Answer 6

Además de otras respuestas (que explican por qué no podemos hacer un método estático con la misma firma que el método 'getClass()' no estático), uno se preguntaría si sería posible tener, digamos un static Class getStaticClass() de modo que, por ejemplo, String.getStaticClass() sería equivalente a String.class. Pero, de nuevo, este método no podría ser un método "normal" ¿Dónde se definiría? en el objeto? Entonces, ¿cómo sabe este único método qué devolver (String.class o Object.class) cuando se llamó como String.getStaticClass() o Object.getStaticClass()? ¿Lo decidiría en tiempo de ejecución? De ninguna manera.

Un método estático no tiene sentido porque String.class es conocido (resuelto) en tiempo de compilación. El método no tiene nada razonable que hacer en tiempo de ejecución; tendrías que hacer un poco de magia de compilación para que el resultado de esa llamada al método se resuelva en tiempo de compilación.

Answer 7

Puede implementar uno usted mismo. Obtén la stacktrace y encuentra la clase de llamante.

En realidad, el registrador podría lib implementado que sí

static Logger logger = LoggerFactory.getLogger(); // auto detect caller class 

Answer 8

Se puede utilizar esta expresión idiomática

Class<?> cl=new Object(){}.getClass().getEnclosingClass(); 

Por ejemplo:

static class Bar { 
    public static void main(String[] args) { 
     Class<?> cl=new Object(){}.getClass().getEnclosingClass(); 
     System.out.println(cl==Bar.class); //will print true 
    } 
}