Java - "final" tiene truco

 
Vista:

"final" tiene truco

Publicado por Yo (1 intervención) el 15/03/2002 05:12:52
Hola a todos:
Quería comentar una cosa me me ha pasado y que me ha vuelto loco 2 días por si os encontrais con lo mismo. Y a ver asi tiene solucion. La cuestión es que tenía una clase de constantes de la cual leía dichas constantes desde otras clases. El misterio"inexplicable" (igual ya lo sabíais, yo se poco Java) consistía en que recompilaba la clase de constantes y las clases que se supone leían de ella ni se enteraban de los cambios. Incluso borraba todo rastro de la clase de constantes (.class y .java) y las demás clases seguían funcionando como si estuviera ahi!!!. ¿Como era posible?

Después de darle vueltas y experimentar "descubrí" (me gustaría que los libros lo contaran) que cuando compilas una clase, las propiedades constantes de otras clases a las que haga referencia las carga en su propio .class. Es decir, no existe ningún vínculo entre la propiedad "final" y las clases que la leen ya que se han creado su propia copia en el .class. Hasta tal punto es así que te cargas el .class de la clase de constantes y las demás clases ni se enteran. Yo pretendía actualizar la configuración de un site con esta clase de constantes, pero visto que tendría que recompilar todas las clases del sistema cada vez que cambiara esta clase de constantes, prefiero no usar el modificador final nunca más. Tiene truco, y eso nadie te lo cuenta.... joer...
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder

RE:

Publicado por Jose A. (53 intervenciones) el 24/03/2002 08:48:26
Es una optimización a nivel de compilación, y no un requisito del lenguaje. Ese es el motivo de que escasee la información sobre estos hechos
Pero algo hay:

http://developer.java.sun.com/developer/TechTips/2000/tt0829.html

En los últimos parrafos se describe el fenomeno que has descubierto. Aquí te he puesto el final del árticulo:

"Unfortunately, this optimization can lead to major compile-time confusion. If you change a final field, you have to
remember to recompile any other class that might reference the field. That's because the 'reference' might have been optimized away. Java
development environments do not always detect this subtle dependency, something that can lead to very odd bugs. So, the old C++ adage is
still true for the Java environment: When in doubt, rebuild all"

¡Hasta otra!

Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar