Sabias que Java posee una clase Void

Posted on May 27, 2016 by admin

Hacía mas de 2 años que quería hacer este post, porque me parece algo bastante curioso. De hecho fue en el 2012 que me enteré de la existencia de la clase java.lang.Void pero lo verdaderamente interesante es que esta clase existe desde la versión 1.1 del jdk.

De acuerdo a la documentación de la API “La clase Void es un comodín para almacenar una referencia a objetos de clases representando la palabra clave void.”

A continuación un ejemplo que muestran el uso de la clase Void. La primera parte es con Generics (que de hecho fue así como me enteré de su existencia), lo que me resulta curioso es que quizás ahora este sea su uso mas extendido aun cuando Generics apareció en la versión 5 de Java. La segunda parte es con reflection el cual creo que fue el primer caso de uso de esta clase Void.

package com.josedeveloper.example;

interface Ejecutable  {

	public T ejecutar();

}

class SumaEjemplo implements Ejecutable {

	int a;
	int b;

	public SumaEjemplo(int a, int b) {
		this.a = a;
		this.b = b;
	}

	public Integer ejecutar() {
		return a + b;
	}

}

class PrintEjemplo implements Ejecutable {

	public Void ejecutar() {
		System.out.println("Esta clase no devuelve nada");
		return null;
	}

	public void prueba() {
		System.out.println("Prueba");
	}

}

public class VoidExample {

	public static void main(String[] args) throws NoSuchMethodException, SecurityException {

		Ejecutable suma = new SumaEjemplo(10, 15);
		System.out.println("Resultado: " + suma.ejecutar());

		Ejecutable print = new PrintEjemplo();
		print.ejecutar();

		//Ejemplo de reflection
		PrintEjemplo ejemploReflection = new PrintEjemplo();

		if (ejemploReflection.getClass().getMethod("prueba").getReturnType() == Void.TYPE)
			System.out.println("el es del tipo void");
	}

}

package com.josedeveloper.example;

interface Ejecutable {

public T ejecutar();

}

class SumaEjemplo implements Ejecutable {

int a;

int b;

public SumaEjemplo(int a, int b) {

this.a = a;

this.b = b;

}

public Integer ejecutar() {

return a + b;

}

class PrintEjemplo implements Ejecutable {

public Void ejecutar() {

System.out.println("Esta clase no devuelve nada");

return null;

}

public void prueba() {

System.out.println("Prueba");

}

public class VoidExample {

public static void main(String[] args) throws NoSuchMethodException, SecurityException {

Ejecutable suma = new SumaEjemplo(10, 15);

System.out.println("Resultado: " + suma.ejecutar());

Ejecutable print = new PrintEjemplo();

print.ejecutar();

//Ejemplo de reflection

PrintEjemplo ejemploReflection = new PrintEjemplo();

if (ejemploReflection.getClass().getMethod("prueba").getReturnType() == Void.TYPE)

System.out.println("el es del tipo void");

}

Sabias que el uso de la annotation override nos advierte de errores en el código

Posted on August 15, 2014 by admin

Seguramente muchos de ustedes se habrán preguntado ¿que hace? o ¿para qué sirve esa @Override que nos coloca automáticamente el IDE al momento de implementar una interfaz? ¿Tendrá algún beneficio?.

Bueno para aquellos con esa interrogante les traigo la respuesta.

Pues si, si nos da un beneficio cuando codificamos y consiste en advertirnos de posibles errores de lógica o compilación en los siguientes casos:

Cuando no estemos sobrescribiendo o implementando ningún método de la interfaz o superclase.
Cuando nos hemos equivocado en la firma del método a sobrescribir.

Es por estos beneficios que deberíamos asumirlo (sobretodo aquellos que venimos de la vieja escuela de Java 1.1, 1.2 o 1.4) como una convención al momento de programar. Ahora bien vayamos a un ejemplo para ver de lo que estamos hablando.

EL siguiente código consta de una super clase la cual vamos a extenderla pero a propósito de este ejemplo sobrescribiremos erróneamente los métodos de la clase de tal forma que no coincidan en su firma con el original (el de la súper clase) o sencillamente no coincida el nombre del método, de tal forma de poder ver como al usar @Override, esta nos indica que hay algo mal, en nuestro código.

package com.josedeveloper;

class SuperClass {
	public int getSomeNumber() { return 0;}
}

public class SubClass extends SuperClass {

	@Override
	public int getSomeNumber(int i) {
		return 0;
	}

	@Override
	public void showsShomething() {
		System.out.println("Show something");
	}

}

package com.josedeveloper;

class SuperClass {

public int getSomeNumber() { return 0;}

}

public class SubClass extends SuperClass {

@Override

public int getSomeNumber(int i) {

return 0;

}

@Override

public void showsShomething() {

System.out.println("Show something");

}

A continuación les dejo par de imágenes donde el IDE nos indica el error

Como pudieron darse cuenta el Editor (en este caso eclipse), nos indica que hay un error en los métodos que estamos intentando sobrescribir.

Ya conocemos el significado de @Override y sus ventajas, ahora lo que resta es que hagamos uso de ella y lo asumamos como una buena practica de programación en Java.

Sabias que el serialVersionUID en las clases Java nos previene de errores en la deserialización

Posted on February 24, 2012 by admin

Estoy seguro que todos aquellos que hemos programado en Java en alguna oportunidad hemos visto como nuestro IDE nos arrojaba un warning (advertencia) indicandonos que “la clase serializable nombre_clase no declara un campo serialVersionUID final estatico de tipo long” y más seguro estoy (por experiencia propia) de que sin meditarlo mucho optamos por la opción que nos daba el IDE (eclipse, netbeans o cualquier otro) para que nos resolviera el warning y asi tener nuestro código limpio de mensajes de advertencia y errores.

Ejemplo de mensaje warning de serialVersionUID

¿Qué es serialVersionUID?

Es un número de versión que posee cada clase Serializable, el cual es usado en la deserialización para verificar que el emisor y el receptor de un objeto serializado mantienen una compatibilidad en lo que a serialización se refiere con respecto a la clases que tienen cargadas (el emisor y el receptor).

¿Qué pasa si no declaro un serialVersionUID?

El proceso de serialización asocia cada clase serializable a un serialVersionUID. Si la clase no especifica un serialVersionUID el proceso de serializacion calculará un serialVersionUID por defecto, basandose en varios aspectos de la clase. Es muy recomendable que se declare un serialVersionUID en las clases serializables, ya que el calculo del serialVersoinUID es muy sensible a detalles de la clase, los cuales pueden variar entre compiladores, es decir, si trabajamos serializando/deserializando objetos y trabajamos con distintos compiladores Java podemos llegar a obtener una InvalidClassException durante el proceso de deserialización debido a discrepancias entre los serialVersionUID calculados por cada compilador. Por eso para garantizar un serialVersionUID que sea indiferente a la implementación del compilador es altamente recomendado declarar un valor explicito del serialVersionUID (de tipo long) y de ser posible que tenga el modificador de acceso private para que afecte unicamente a la clase que lo ha declarado y no a las clases hijas (subclases) que hereden de ella, forzando de alguna manera a cada clase hija a declarar su propio serialVersionUID (Ver imagen abajo).

Ejemplo de herencia de clase Serializable observando warning de serialVersionUID en clase hija

Para mas información no dejen de revisar en la API la interfaz Serializable

Sabias que los literales enteros en Java por defecto son compilados como int

Posted on February 10, 2012 by admin

Este es el primer post de la nueva categoría que he denominado “Sabias que…”, donde les iré contando cosas que me resultan curiosas e interesantes sin que por eso no dejen de ser algunas veces “triviales”, en esta oportunidad les contare algo que algunos puede que desconozcan e incluso puede que llegue a serles útil en el caso de buscar certificarse.

Sin más preámbulos, así como dice el titulo, por defecto todos los literales enteros que declaremos en nuestro programa Java, serán compilados como int (entero). Lo demostrare mediante el siguiente ejemplo, que consistirá de una función que validará el rango de un número entero. Realmente es un ejemplo sencillo pero que cumple con el objetivo del post. A continuación el código.

public class DefaultLiteralExample {

	public static boolean validarRangoEntero(long valor, long min, long max){

		if((min <= valor) && (valor <= max))
			return true;
		return false;
	}

	public static void main(String args[]){
		//Se podría suponer que habia un cast automatico
		//pero NO es asi
		validarRangoEntero(30, 1, 9999999999);

	}
}

public class DefaultLiteralExample {

public static boolean validarRangoEntero(long valor, long min, long max){

if((min <= valor) && (valor <= max))

return true;

return false;

}

public static void main(String args[]){

//Se podría suponer que habia un cast automatico

//pero NO es asi

validarRangoEntero(30, 1, 9999999999);

}

Si compilan el código mostrado anteriormente, les aparecería el mensaje

DefaultLiteralExample.java:14: integer number too large: 9999999999
 validarRangoEntero(30, 1, 9999999999);

1 2	DefaultLiteralExample.java:14: integer number too large: 9999999999 validarRangoEntero(30, 1, 9999999999);

Si hacen uso del IDE Eclipse les aparecería el mensaje “The literal 9999999999 of type int is out of range”.

Es un error de compilación que se resuelve sencillamente agregando la letra “L”, al literal quedando de esta manera 9999999999L.

Como pueden ver es algo muy sencillo, incluso para algunos será trivial pero les aseguro que en una prueba de certificación mas de uno de seguro se equivocaría y diría que el código se compila perfectamente, asumiendo un cast automático.

Si deseas compartir con nosotros eso que te parece interesante y/o curioso, no dudes en hacerlo, así todos aprenderemos.

User's blog

Category Archives: Sabias que …

Sabias que Java posee una clase Void

Sabias que el uso de la annotation override nos advierte de errores en el código

Sabias que el serialVersionUID en las clases Java nos previene de errores en la deserialización

Sabias que los literales enteros en Java por defecto son compilados como int