Me suena a: println(null.CONSTANTE);

Pues solo por poner un ejemplo de lo que dice @java.daba.doo:

Ammm si no mal recuerdo en un libro leí algo de esto, y resulta que estos atributos de las clases son conocidos también como 'variable de clase' y son accesibles para todas las instancias, no recuerdo bien pero todas tiene acceso a ellas ( algo así como su propia copia), y no es necesario incluso crear una instancia de ellas para usarlas.

Esta padre el post. saludos a todos : )

Esta liga responde a tu pregunta tu duda. : )

A lo que voy es que me hacia ruido eso de pner null a la instancia de la cal quieres obtener el valor, que digo que me figura algo como   y todo eso porque en los estaticos no puedes usar el this... No se si me exprese mal, quiero decir que sintacticamente yo lo veo raro como se obtiene e valor de una constante (convencional) mediante reflexion

Lo que dices Rodrigo, esta aqui... (digamos que son aspectos basicos de Java)

Not all combinations of instance and class variables and methods are allowed:

• Instance methods can access instance variables and instance methods directly.
• Instance methods can access class variables and class methods directly.
• Class methods can access class variables and class methods directly.
• Class methods cannot access instance variables or instance methods directly—they must use an object reference. Also, class methods cannot use the this keyword as there is no instance for this to refer to.

fente:

En otras palabras esto:

Es extraña la forma en que la funcionan los atributos de clase en Java. A ver si en el spec dice algo al respecto.

Por lo pronto lo que sí sé es que:

Dan lo mismo cuando se trata de atributos de clase, son ignorados y reemplazados directamente por:

Por eso no sale el Npe, pero a ciencia cierta no sé que regla del lenguaje aplica ahí.

Tal vez mas tarde explique eso de static como lo entiendo, es algo muy interesante, y que ocupo mucho. Les dejo por mientras:

Lo interesante tambien son los metodos estaticos (tal ves el mas famoso sea System.out.print()).

Ok, esto ya llego al final. la escencia es que de un objeto null se pueda extraer informacion. Lo interesante viene aqui:

Static hace nuestra constante como una prpiedad de clase y no de instancia.

No podemos hacer   porque para empezar null no es algo tipado (es como decir que quieres un taco de carne pero no dices de que: si de perro, rata, gato, pollo, humano, marciano, programador java... etc).

ID_BLAH_BLAH_AAA es una constante de clase lo que significa que no necesitas instancia para acceder a ella (pero si necesitas referenciar a la clase de la cual obtienes el "valor de la cosntante de clase")

Entonces es por esa logica que puedes hacer   en donde estas obteniendo el valor de la constante de clase (no instanciada) y en el caso de la reflexion tampoco necesitas instancia y es por eso que puedes llamar a get(null)

Dice: Dame el valor de ID_BLAH_BLAH_AAA de "LaClase" cuya instancia sea: null
 

Es importnante notar que si se define el objeto del que se extrae la propiedad "de clase"

si se pudiera representar directamente creo que si seria algo asi:
 

pero como null no puede ser tipado (porque no tiene sentido hacerlo aunque algo tipado SI puede ser null) hay que invocar la referencia nula de la clase:
 
(porque si pones una variable tipo LaClase sin el final por ejemplo notaras que su valor por default es null... eso sucede en todas las propiedades que se definan fuera de los metodos de las clases (se autoasigna su valor default... dentro de los metodos es otra historia)

El realidad esto es un concepto basico que ejemplifica la pregunta: ¿que significa "static"?

beto.bateria: Eso no es un método estático.   es un método de instancia, de la clase  . La clase   tiene una variable estática llamada   de tipo PrintStream.

No sé a qué te refieras con que usas mucho "eso de static"...

En el cóidgo que Oscar pone de ejemplo:
 

la regla que aplica es la que debe aplicar si la variable es estática, acceder a ella de manera directa sin importar lo que hay antes del operador punto (.), aunque lo que hay antes de ese operador puede provocar un efecto lateral, devolviendo siempre un objeto de clase N. Si esto no sucede el compilador anuncia el error.

El valor null puede ocupar el lugar que el corresponde a un objeto. El compilador no ejecuta, solamente comprueba sintaxis y semántica. Por esa razón,
 

son dos sentencias sintáctica y semánticamente correctas. La segunda provocará el disparo de una excepción.
Pero, la sentencia
 
no la admite el compilador, porque null no puede ser dereferenciado.

Por ejemplo, puedo escribir
 

y el resutlado por supuesto es false.

Sin embargo no puedo escribir
 

Todos los lenguajes que trabajan con apuntadores le dan un tratamiento diferente a null que a los valores de los tipos primitivos.

@bferro exacto! lo mismo sucede por ejemplo con

Me parece que eso descomponiendolo en lineas es lo mismo que hacer:

y si, claro que es valido!

Claro que es false porque null en java no tiene tipo: ni object

y

¿sera por que pones u primitivo? Eso si lo detecta el compilador

me suena como cuando haces algo "iegal" que es valido sintacticamente
 

Eso por ejemplo genera un lindisimo : "unreachable statement" al poner System.out.println(""); despues del do-while... a que voy con esto? que aun asi hay cosas que si se vaidan en tiempo de compilacion y creo que lo que mecniona bferro es un poco por eso pues un primitivo lo comparas con otro primitivo y del mismo tipo aunque hay "cosas que parecen raras" cuando haces char=int... para oros casos podriamos eso de las clases envolventes

Raro que no funcione el autoboxing en  . Supongo que solamente se activa en asignaciones a variables y recepción de parámetros.

a lo que me referia es
  y de ahi aplicar e instanceof, claro ahi ya 5 no es un primitivo sino un objeto

"unreachable statement" es un error semántico y aunque la sintaxis es correcta, el compilador también realiza análisis semántico y por eso anuncia el error. Puedes "repasar" los errores semánticos usando Jakes como compilador.
Otro ejemplo sencillo de error semántico es al asignación entre tipos incompatibles, aunque la expresión tenga una sintaxis correcta.

Por cierto, ahora estaba buscando algo para complementar otro post de @OscarRyz ( ) y me encontre con algo que suena muy loco.

En esta liga publican algo (que bueno no va muy ad hoc con lo del titulo) que me llamo la atencion una linea en especial.

Quedamos que en la linea que escribio @bferro   marcaba un error semantico según yo argumentando que era un tipo primitivo que se pretendia comparar con un objeto... hasta ahí todo bien (parecia todo OK, pero hoy me encuentro con algo (que la verdad desconocía) que puedes hacer esto   entonces como sospechas:

Raro que no funcione el autoboxing

pero lo que me saca de onda es si de int puedes tener su class entonces quiere decir que lo puedes procesar como objeto (que pienso eso es util para el autoboxing)... entonces por que chihuahuas no funcionara?... ahora, será correcto que los primitivos tienen un tipo de clase?

Si mal no recuerdo, metieron eso del .class a los primitivos por consistencia, eso viene desde mucho antes del autoboxing y se usa para el mapeo entre los primitivos y sus envoltorios.  

Java como todo lenguaje hace uso de literales.
Un grupo de esos literales son los literales clases y dentro de los literales clases están aquellos para los tipos primitivos y para void (Java considera que Void (con mayúscula) es un "pseudo tipo".

Es el caso de   que aquí se menciona. El literal   es la referencia a un objeto de tipo   (con anterioridad a la técnica de genéricos y autoboxing era un tipo de  ). El objeto   es de tipo  

Para la reflexión son necesarios estos literales clases para los tipos primitivos; por ejemplo cuando se quiere expresar la firma de un método que se quiere obtener por reflexión y que admite argumentos de tipos primitivos.

A pesar de que JLS establece de que int.class es de tipo  , sigue manteniendo la distinción entre primitivos y objetos. Es un reflejo de no tratar a los primitivos como objetos y buscar algo que los pueda tratar de manera uniforme.
Va un ejemplo:

Imprime
¿int Methods? = 0
¿Integer Methods? = 41
Signature = public void reflexion.IntegerReflection.intReflection(int,java.lang.Integer)

A ver entonces, un compilador de un lenguaje de programación con tipeo estático puede validar durante la compilación errores semánticos como los aquí descritos y/o hacer transformaciones cuando sabe que va a suceder con el resultado.

Por ejemplo, lo que mencionaron  , sabe que el 5 es una literal y que nunca va a ser un object y manda el error. También sabe que el println que no va a llegar después de un while infinito. O por ejemplo este otro:

Es transformado por el compilador en esto:

Aunque esto último no es privativo del tipeo estático.

Con independencia del tipado, los compiladores siempre realizan análisis semántico y evalúan lo evaluable en tiempo de compilación. Esto último sigue determinadas reglas.