Me suena a: println(null.CONSTANTE);

Hoy tuve una extraña experiencia a retornar el valor de una constante mediante reflexion, algo asi como lo hace el getElementById en el javascript, despues de unas lineas lo hice funcionar (es csa facil) pero me llamo la atencion la forma en que se puedehacer

 

(Bueno en mi caso se desean obtener puros String)

la cosa es que me llamo la atencion cuando hice el   senti que ibaa tronar y que no deberia ser asi pero funciono, yo lo que veo es que tiene cierta logica porque las constantes estan definidas asi:

 

lo que me dice es que por ser estaticas no necesitan instancia alguna para ser accesibles... pero por otra parte se esa obteniendo el valor de un objeto que es null... por ejemplo:

 

el codigo anterior creo que puede ser similar a este (porque estas obteniendo el valor de una clase cuya insancia es  :

 

y aunque sea null no hay ningun  ... Se me hace curioso, esto me suena a println(null.CONSTANTE). Existe alguien que tambien se le haga raro?...

.
.
.
.

Pues es eso 'nomas, se me hizo raro! (me suenta un poco a contradiccion)... que piensan ustedes?

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de rodrigo salado anaya

static xxxx

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 : )

Imagen de rodrigo salado anaya

Esta liga respon...

Esta liga responde a tu pregunta tu duda. : )

A lo que voy es que me hacia

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

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

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í.

Imagen de beto.bateria

Cierto

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.

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"?

Imagen de ezamudio

System.out.println()

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"...

Imagen de bferro

La regla que aplica

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

@bferro exacto! lo mismo sucede por ejemplo con

 

Me parece que eso

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

 

y si, claro que es valido!

(null instanceof

 

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

Imagen de ezamudio

autoboxing

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

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

Imagen de bferro

"unreachable statement" es un error semántico y ....

"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.

Ah jijos, que raro!

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?

Imagen de ezamudio

Consistencia

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.  

Imagen de bferro

literales clases

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

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.

Imagen de bferro

Los compiladores siempre hacen validación semántica

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.