JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(MyService.class);
factory.setAddress("http://localhost/ws");
MyService client = (MyService) factory.create();

Estas dependencias suelen remplazarse por objetos que simulan ser los reales compartiendo la misma interfaz. Claro que es solo una fachada, su implementación dista mucho de ser la real, pero nos proporcionan un comportamiento determinista y controlado contra el que probar nuestros componentes. EasyMocks es un framework que permite crear estos objetos de forma muy sencilla indicando cual es la interfaz que deben cumplir y cual es el comportamiento que esperamos.

Creando el Mock

Lo primero que necesitamos es decirle al framework cual va a ser la interfaz que queremos implementar en nuestro “mock”. Supongamos que necesitamos testear una clase Cliente que necesita los favores de una clase que implemente Servicio. Lo que vamos a hacer es un “mock” que simule ser una implementacion real de Servicio pero solo la vamos a usar para llevar a cabo el test.

El metodo estatico createMock de la clase EasyMock toma una Interface como parametro (tambien puede ser una clase) y nos devuelve un objeto que la implementa.

Servicio servicioMock = EasyMock.createMock(Servicio.class)

Its Alive!!

Genial, ¿Ya podemos pasarle la referencia servicioMock al Cliente y testear a gusto?… bueno… no tan easy.

A continuacion vamos a hacer que ese servicioMock implemente la operacion sumarDiez que, a partir de un parametro int numero devuelve ese numero incrementado en 10. No va a ser la implementacion real, solo a ’simular’ que esta haciendo algo realmente mediante el metodo EasyMock.expect.

EasyMock.expect(servicioMock.sumarDiez(5)).andReturn(15);

Acabamos de decirle a nuestro servicioMock que cuando alguien invoque al metodo sumarDiez con el numero 5 como parametro el debe devolver 15. No hay implementacion real, solo se pretende estar realizando la operacion. Ademas nuestro mock no sabe que hacer si alguien le pasa el numero 6 como parametro, y nos lo hara saber con una hermosa excepción.

Easymock.replay(servicioMock);

Esto pone al mock en ‘test mode’ indicando que ya podemos usarlo para nuestro test.

Still alive… and well?

Ahora sí podemos meter el servicioMock en nuestro test y admirar a EasyMock en toda su gloria

Ojo que lo que estamos testeando es el comportamiento de Cliente y no de Servicio! es decir que invocarAlMetodoSumarDiezDeServicio() este delegando correctamente e invocando a Servicio.

Cliente cliente = new Cliente();
cliente.setServicio(servicioMock);
int esultado = cliente.invocarAlMetodoSumarDiezDeServicio(10);
assertEquals(15,resultado);

Las posibilidades que tiene Easymock son ilimitadas y podemos simular comportamientos extremadamente complejos. Pueden encontrar mas informacion sobre todo el potencial de EasyMock en su página oficial.

JSE6 incorpora out-of-the-box el engine Rhino asi que tenemos la posibilidad de ejecutar código JavaScript en nuestras aplicaciónes haciendo poco y nada.

 ScriptEngineManager scm = new ScriptEngineManager();
ScriptEngine jsEngine = scm.getEngineByName("JavaScript");

Uhm… listo! estamos listos para interpretar javascript. Por un proceso de discovering (siguiendo la linea de los *Manager de Java) el ScriptEngineManager sabe que hacer cuando le pedimos un Engine de “JavaScript” y nos devuelve una instancia de ScriptEngine.

String script = "var sum = 0; var obj = new Array(1,1,2,3,5,13);"
+ "for each (var item in obj) { sum += item; }"
+ "print(sum);";
jsEngine.eval(script); // 25

el metodo eval del ScriptEngine interpreta el String que le pasamos como parametro y en la consola terminariamos con un “25″. However, el scripting en Java es mucho más inteligente, el metodo eval devuelve un Object que contiene el valor del ultimo statement del script. El mapeo del valor que ‘retorna’ el script contra los tipos de datos de Java es especifico del Engine por lo que nos vamos a encontrar con comportamientos diferentes segun el lenguaje (y el engine) que interpretemos.

 String script = "var sum = 0; var obj = new Array(1,1,2,3,5,13);"
+ "for each (var item in obj) { sum += item; }"
+ "sum;";
Double d = (Double) jsEngine.eval(script);
 System.out.println( d +1 ); //26!!!

Con esta feature de JSE6 es inevitable pensar en dar un paso más en la parametrización de nuestros sistemas  ya no solo parametrizando valores y constantes sino también la logica de determinados procesos a traves de scripts simples en JS, Phyton, Ruby, Groovy, Jaskell o lo que sea. Otra ventaja en el uso de de esta API esta en incorporar lenguajes que nos eliminan el ciclo de code-compile-deploy-test pero sin alejarnos de la plataforma Java.

Estas clases sirven exactamente para nuestros propositos: Transformar objetos en definiciones XML, y definiciones XML en objetos, sin perder nada en el medio. Sin configuraciones ni descriptores extraños estas dos clase son tan faciles de usar como un ObjectInputStream y objectOutputStream.

Objeto -> XML

 Perro p = new Perro();
      FileOutputStream f = new FileOutputStream("perro.xml");
  XMLEncoder xe = new XMLEncoder(f);
      xe.writeObject(p);
      xe.close();

XML -> Objeto

  FileInputStream f = new FileInputStream("perro.xml");
  XMLDecoder xd = new XMLDecoder(f);
      Perro p = (Perro)xd.readObject();

Esta demas decir que el XML contiene todo el grafo del objeto (el perro con sus pulgas, collar, dueño y cualquier otra dependencia) haciendose cargo de forma impecable de las referencias circulares.

Los drawbacks de este metodo si lo comparamos con la serializacion tradicional es el mismo que se le atribuye a RMI vs Webservices: El XML es mas lento y pesado que su par binario. A favor de este método podemos decir que el objeto serializado es un xml que puede editarse en cualquier lado y que se elimina el problema del cambio de version de las clases. Ya no hay que preocuparse por conflictos de versionado con el serialVersionUID porque la unica informacion que se guarda en el xml sobre la clase de las instancias es el nombre.

Java incorpora unos cuantas clases cuyas instancias tienen la propiedad de ser inmutables. Las clases que envuelven los tipos primitivos (Byte, Short, Character, Integer, Long, Float, Double) son inmutables. La clase String es inmutable. ¿Por qué son inmutables?¿Para complicarnos la existencia? No realmente…

Asi como en el experimento del Gato de Schrödinger creamos una clase Gato con un atributo estado de tipo String. El estado del gato nos dice si el gato esta “VIVO” ó “MUERTO”

public class Gato {
    private String estado;
    public void setEstado(String e) {
    this.estado = e;
    }
    public String getEstado() {
    return estado;
    }
}

vamos a suponer que la clase String tuviera un metodo setValue() que me permita cambiar la cadena de texto almacenada en una instancia particular de String. Es decir, supongamos que los objetos String no son inmutables y podemos cambiar el texto que contiene.

public class TestSchrödinger {
public static void main(String[] args) {
Gato gato = new Gato();
String e = "vivo";
gato.setEstado(e);
//El gato esta vivo 
e.setValue("muerto");
//A nuestro String mutable le cambiamos el texto que encapsula.
System.out.println(e);
//Si esto es cierto entonces deberia salir impreso en la pantalla "muerto"
System.out.println(gato.getEstado());
//¿El gato esta vivo o esta muerto?

El problema de la mutabilidad consiste en que los parametros en Java siempre son pasados por valor, inclusos las referencias a objeto pero no el objeto al que apunta. Si un String, por ejemplo, podria cambiar el valor que contiene entonces aparecerian inconsistencia en el estado de los objetos que en algun momento incorporaron ese String a su estado.

Si no les quedo muy claro tal vez este video ayude un poco

El secreto de todo esto de las referencias se encuentra en el package java.lang.ref que consta de un par de clases:

+ Reference
      +WeakReference
      +PhantomReference
      +SoftReference
+ ReferenceQueue

WeakReference es la clase que nos ocupa hoy y sirve para instrumentar a las famosas referencias débiles que mencione tiempo atras. Mirando todo mas pragmaticamente la diferencia entre estas weakreferences y las referencias fuertes radica en el momento de la creacion y el posterior acceso al objeto al que esta apunta. El siguiente codigo muestra el caso tipico entre dos objetos que se referencian mutuamente. La vista representa una pantalla de programa y Modelo algun objeto de dominio de negocio. Ambos objetos necesitan referencias al otro para implementar el patron observer que permita la comunicación correcta de estos dos componentes.

class Vista {
Modelo modelo;
public void imprimirModelo() {
System.out.println(modelo.value);
}
public void setModelo(Modelo m) {
modelo = m;
}
}
class Modelo {
int value;
WeakReference<Vista> vista; //referencia debil a la vista
public boolean existsVista() {
return this.vista.get()!=null;
}
public void actualizarVista() {
Vista miVista = this.vista.get(); //miVista es referencia fuerte a vista
//le avisa a la vista q cambio el modelo y debe actualizarse
//miVista.update();
}
public WeakReference<Vista> getVista() {
return vista;
}
public void setVista(Vista v) { //setter con weakreferences
vista = new WeakReference<Vista>(v);
}
}

La clase vista no tiene ningun comportamiento extraño, no podemos decir lo mismo de la clase Modelo. En ella vemos que la declaracion de una referencia debil se hace mediante la clase WeakReference indicando con generics la clase a la que va a apuntar esta referencia, en nuestro caso Vista.

Los accesors a este atributo son un tanto particulares, el setter recibe una referencia fuerte a Vista y que es envuelta con el constructor de WeakReference y finalmente asignada al atributo. El getter, sin embargo, devuelve un objeto de clase WeakReference. Con este objeto podemos obtener una referencia fuerte al objeto vista utilizando el metodo get().

El metodo existsVista() simplemente devuelve verdadero o falso indicandonos si existe el objeto al que apunta la referencia vista o si ya fue eliminado por el gc.

Un caso tipico de uso de estas clases, a saber:

public class Main {
public static void main(String[] args) {
Modelo m = new Modelo(); //creamos el modelo
Vista v = new Vista(); //creamos la vista
v.setModelo(m); //se aparean la vista y el modelo
m.setVista(v); //hay que recordar que setVista envuelve
//el parametro con una WeakReference
m.value = 77;
v.imprimirModelo();
//Imprime 77... como podria esperarse
v = null; //no queremos usar más la vista.
System.gc(); //pasa el basurero
System.out.println(m.existsVista());
}
}

Imprime false porque la referencia fuerte que apuntaba a la vista ya no lo hace. La unica referencia a ese objeto que queda es el atributo del modelo, que por ser una referencia debil el gc la ignora.

Recomiendo pasar estos pedazos de códigos por el amigo debugger e ir siguiendo el movimiento de las referencias y como desaparecen los objetos por arte de magia. En otro momento seguimos con las referencias fantasmas y blandas.

public class Puzzle {
public static void main(String args[]) {
int x = 0x3;
// AYUDITA: public class declara// una nueva clase. main es el metodo
// principal o entry point //del programa y String[] almacena un array
// de String que son // cadenas de caracteres que se guardan usando
// unicode que es un conjunto //de caracteres donde la letra a se escribe
// con \u0061 la letra b // con \u0062 y linefeed se representa con
// \u000A x++; // se usa  para postincrementar una variable x//
// ++x;// se utiliza para preincrementar una variable x x+=2 incrementa
// en 2 a x; // los literales que empiezan con 0x se tratan como
// hexadecimales en java.
System.out.println(x+1-1);
}
}

La mejor respuesta se lleva un premio

Bueno despues de mucho deliberar (?) decreto que el justo ganador del puzzle es Sherekan! quien se hace acreedora del siguiente premio:

2 (dos) libros “El Lenguaje de Programación Java SL-275″ compuesto por una Guía de Estudiante y Guía Práctica. Publicados por Sun Microsystems. Fuerte el aplauso!

Nota: Este tema es bastante largo y tedioso incluso. Está dividido en varias entregas con el fin de salvaguardar la integridad mental de los posibles lectores ante una indigestión por lectura violenta.

Motivación.

El Garbage Collector es un ser extraño. Repasemos por un segundo como funciona este particular habitante de la JVM. Cuando se inicia un programa en Java y se comienzan a crear objetos aparece un conjunto de referencias denominado root set donde se encuentran las referencias declaradas dentro del metodo main(), o run() si estamos trabajando con varios threads. Luego durante la ejecución del programa aparecerán otras referencias pero como atributos de algún objeto cuya referencia este en el root set. En la imagén, que tomé del excelente Hardcore Java de Robert Simmons Jr, se ve como en un metodo main() se crean tres referencias A, C y H a objetos a partir de las cuales se forma el grafo (fig.1).

Si cambiaramos en A la referencia que posee a B haciendola apuntar a null (fig.2) el Garbage Collector no eliminaria el objeto B puesto que aún existe un camino a traves de C->F->X->D->J->E->B. De esa forma funciona el Garbage Collector, elimina los objetos que no pueden ser accedidos a traves de un camino que se inicie en el root set. Esto es particularmente util para evitar las “islands of isolations” cuando hay un grupo de objetos con referencias entre si pero que no pueden ser accedidos por el thread principal.

Este comportamiento, en un principio benigno, es la principal causa de memory leaks en las aplicaciones cuando tenemos referencias circulares entre dos objetos o más objetos. Supongamos que el grafo representa una aplicación con interfaz gráfica donde A es la GUI y C el objeto a partir del cual se arma la lógica de negocios. El objeto A posee muchas referencias a otros objetos (panels, botones, textfields) y C a todas las clases del negocio. Ademas, como en todas las aplicaciones con GUI, se unen ambos mundos (Vista y Modelo) con algun mecanismo de Listeners que implemente el patrón observer. ¿Que pasa sí, como en el ejemplo anterior, el objeto B es una ventana a la que dejamos de referenciar desde A porque no queremos utilizarla más? Evidentemente aún queda un camino a traves del cual se puede acceder a este objeto, como vimos más arriba, por lo que la ventanita no es elegible para ser eliminada por el garbage collector. Tenemos una ventana en memoria (con todos sus componentes) que no queremos usar más pero sigue apuntada por un listener. Tenemos un Memory Leak.

Los cuatro tipos de referencias.

Java nos provee cuatro tipos de referencias distintos para ayudarnos a evitar problemas como el visto aguas arriba sin ensuciar el codigo con aventuradas técnicas de manejo de Listeners. Estos cuatro tipos de referencia son: Fuerte, Débil, Blanda y Fantasma.

• Referencia Fuerte Las referencias a objetos que se utilizan en java comunmente son referencias fuertes (ó strong references). Su comportamiento es por demas conocido por todos. Apuntan a un objeto y lo mantienen en memoria mientras esta referencia se mantenga. Cuandro creamos un String texto = “algo” estamos creando una referencia fuerte apuntando a un objeto de tipo String.

• Referencia Débil Una referencia debil (weak reference) es una referencia común y corriente pero con una salvedad: Si un objeto es apuntado solo por referencias debiles, sera elegible por el garbage colector para ser eliminado. Es decir, en el momento de elegir que objetos seran eliminados el GC ignora las referencias debiles haciendo como si no existieran.En el grafo original se reemplazan las referencias fuertes circulares, potencialmente peligrosas, por referencias debiles (indicadas en la figura con una flecha doble).

¿Qué sucede si ahora dejamos de apuntar a B desde A? ¡Sorpresa! B es elegible para ser eliminado.

• Referencia Blanda Las referencias blandas (soft reference) se comportan como las referencias debiles pero el garbage collector va a eliminar los objetos unicamente si tiene poco espacio en el Heap. Digamos que si un objeto esta siendo apuntado unicamente por referencias blandas el garbage collector puede elegirlo para eliminación si tiene poca memoria en el heap, sino no necesariamente va a eliminarlo. Este comportamiento sin embargo, como pasa con todo lo relacionado al garbage collector, es dependiente de la implementación y en la práctica las referencias blandas son tratadas como referencias debiles por la Java Virtual Machine.
• Referencia Fantasma El tipo más enigmático de todos y su uso es, por lo menos, tan bizarro como su nombre. La referencia fantasma (phantom reference) apunta a un objeto cuando este ya ha sido eliminado por el GC. Si, una vez que el objeto pasa por el GC la referencia fantasma apunta a él. Sin embargo no puede usarse para acceder a ningún miembro de este objeto, sino solo para saber que estuvo ahí en algun momento. ¿Extraño verdad? Su uso más común es contar cuantos objetos han sido eliminados y en técnicas de profilling.

Con estos cuatro tipos de referencias podemos lograr que nuestros programas hagan un uso más racional de la memoria pero como aplicarlos queda para mas adelante. Antes de terminar esta primera entrega es menester recordar que estos no son structurals patterns o algo parecido sino que java nos ofrece una API estandar para implementarlos programaticamente.

You are not required to catch Error objects or Error subtypes. You can also throw an Error yourself (although other than AssertionError you probably won’t ever want to), and you can catch one, but again, you probably won’t. What, for example, would you actually do if you got an outOfMemoryError? It’s not like you can tell the garbage collector to run; you can bet the JVM fought desperately to save itself (and reclaimed all the memory it could) by the time you got the error. In other words, don’t expect the JVM at that point to say, “Run the garbage collector? Oh, thanks so much for telling me. That just never occurred to me. Sure, I’ll get right on it.” Even better, what would you do if a VirtualMachineError arose? Your program is toast by the time you’d catch the Error, so there’s really no point in trying to catch one of these babies. Just remember, though, that you can!

Katty Sierra es lo más…

boolean Character.isJavaIdentifierStart(char c) 

y

boolean Character.isJavaIdentifierPart(char c)

Ambos devuelven true si el caracter que se le paso como parametro puede utilizarse al comienzo de un identificador o como parte de este respectivamente.
Por lo tanto podriamos declarar tranquilamente una

 public class Murciélago

Lo cual puede llegar a ser medio molesto para andar tipeando los acentos pero esta caracteristica, a veces olvidada, llega como un regalo del cielo cuando hay que hacer una

 public class Ñandu

Ahora no hay más excusas para el horrendo

 private int anio;

en lugar de año