viernes, 29 de mayo de 2009

Anotaciones en java 5

  Saludos y gracias por leer acerca de java, mi blog que en estos momentos desarrolla las ventajas e innovaciones de la programación con la versión 5 de java (J2SE 5.0). Espero le sea de ayuda.

  Ahora hablaremos de otra característica que fue agregada en java 5 que es la facilidad de metadatos a través de las llamadas anotaciones pertenecientes al paquete java.lang.annotation. Las mismas pueden utilizarse para generar o crear información adicional que beneficie tanto a los desarrolladores (documentando el código fuente, por ejemplo), como a usuarios de la aplicación que no están relacionados a la programación (metadatos en tiempo de ejecución). En anotaciones fue creado el concepto de retención, existe tres tipos de políticas de retención para las anotaciones:

    • SOURCE: la anotación sólo está disponible al momento de la programación, es decir, en el código fuente.
    • RUNTIME: la anotación puede estar disponible en tiempo de ejecución.
    • CLASS: Disponible en el archivo de clase, pero descartada en ejecución.

  En el JAVA API DE ANOTACIONES aparecen 4 anotaciones:

    • @Target: A quien podría o debe aplicarse la anotación.
    • @Documented: La anotación debe ser documentada por javadoc u otra herramientas de documentación.
    • @Inherited: Para heredar anotaciones de superclases, aunque no para interfaces.
    • @Retention:  Indica cuando va estar disponible la anotación, puede ser algunas de las tres políticas explicadas anteriormente:
@Retention(RetentionPolicy.SOURCE)
@Retention(RetentionPolicy.RUNTIME)
@Retention(RetentionPolicy.CLASS)

  Pero además de estas cuatro que aparecen en el JAVA API existen otras dos más:

    • @Deprecated: Para marcar un método como desaprobado, no debe ser utilizado en la programación ya que de seguro puede generar problemas, aunque esté disponible.
    • @Override: Se coloca antes de un método y se utiliza para indicar al compilador que se sobrescribirá el método de la superclase y por lo tanto este método debe estar definido en la clase primaria, de no ser así se genera un error en tiempo de compilación.
  Vamos a lo que más creo necesario, veamos un código ejemplo:

public class ClasePadre{
  public void metodo(){
        System.out.println("Metodo clase padre invocado");
  }

  @Deprecated
  public static void metodoestatico(){
    System.out.println("Estatico Desaprobado");
  }

  public static void main(String[] args) {
    ClasePadre ce = new ClasePadre ();
    ce.metodo();
    metodoestatico();/*Metodo desaprobado*/
  }
}

class ClaseHija extends ClasePadre {

  public void metodo(int x){}
  @Override
  public void metodo(){}
  @Override
  public void metodo(String cadena) {}
}
  En el código anterior la clase padre no tiene problemas y debe compilar aunque use un método desaprobado (deprecated), pero la clase hija no, veamos porque. El primer método que recibe un parámetro entero no tiene problemas ya que aunque no es heredado de la clase padre, el compilador crea este método para la clase hija, el segundo tampoco tiene problemas ya que sobrescribe el método de la súper clase (tiene la misma firma), pero el tercero si genera un error de compilación ya que el código afirma que sobrescribirá el método de la clase padre pero la firma es distinta, aquí se genera un error de compilación.
Bueno, por ahora no tengo más que decir, nos “vemos” en una próxima edición.