Skip navigation

Como había comentado en el anterior post, mas de un grupo está trabajando en una implementación de Java Context and Dependency Injection ( aka jsr-299 ) por un lado lo tenemos al grupo de Apache con Gurkan Erdogdu a la cabeza y por otro al grupo de JBoss con Pete Muir.

Lo que no esperaba encontrarme es que ambos tengan diferencias en los fuentes de la interfaces, y no me refiero a la implementación lo cual es completamente entendible, pero si no nos ponemos de acuerdo en las interfaces de entrada… stamo fritos stamo.

Importante, tener en cuenta las versiones que tomé como referencia:

  • De la implementación de referencia ( RI ) de Pete Muir utilicé la version 1.0.0.BETA1 ya que es la última que cerraron
  • De la RI de Gurkan Erdogdu tomé la última revisión trunk del SVN público al día de la fecha

Pero ¿Qué tipo de diferencias podemos llegar a tener en las interfaces, clases y anotaciones ( teniendo un documento q regule esto ) que influyan en el comportamiento? Hasta ayer me animaba a decir ninguna, pero no es este el caso. Veamos las diferencias:

*Nota: Cuando quiera referirme a la diferencia de códigos voy a utilizar “gurkan” para el código de de OpenWebBeans y “pete” para el código de WebBeans.

 

En las clases

Es lo mas difícil de analizar, ya que no solo tienen que mantener el mismo contrato público ( nombre de métodos, cantidad y tipo de parámetros ) si no que su implementación, sin necesidad de tener las mismas lineas de código debe tener el mismo resultado. Por suerte, solo tenemos dos clases y son fácil de analizar :D.

javax.inject.AnnotationLiteral

Esta clase ayuda a representar una anotación en forma de una instancia para poder usarla como parámetro de un inyección manual de un componente.

public boolean equals(Object other)

gurkan – tiene mejores validaciones
pete – posible NullPointerException en linea 141 cuando el método de una anotación devuelva un valor nulo.

javax.inject.TypeLiteral
Esta tiene el mismo fin que la anterior, pero para tipo de datos en general como “List<String>”. Al ser tan simple la dos son básicamente lo mismo salvo un pequeño gran detalle, la implementación de Pete no sobre-escribe los metods equals y hashCode. No es trivial la diferencia.

 

Pasemos ahora por las las interfaces, en realidad clases abstractas y interfaces 

 

 javax.inject.manager.Bean

No estoy seguro, pero creo que esta diferencia puede traer problemas de compatibilidad ( compilar con una y utilizar otra en tiempo de ejecución ) y según lo que dice el capitulo 3.11 en la página 39 ( jeje paresco un abogado ) la versión de Gurkan tiene la razón.

pete – public abstract Set<? extends InjectionPoint> getInjectionPoints();
gurkan – public abstract Set<InjectionPoint> getInjectionPoints();

 

javax.inject.manager.Decorator

Acá hay un problema grave, los nombres de los métodos no concuerdan. Y según la documentación, específicamente en la página 113 de jsr-299 dice que Pete tiene razón.

pete – public abstract Set<Annotation> getDelegateBindings();
gurkan – public abstract Set<Annotation> getDelegateBindingTypes();

 

javax.inject.manager.Manager

La verdad no se que diferencias puede traer, pero ya que estamos la nombramos. Si alguien sabe, que me lo explique. 

pete – public <T> T getInstanceToInject(InjectionPoint injectionPoint, CreationalContext<?> creationalContext);
gurkan – public <T> T getInstanceToInject(InjectionPoint injectionPoint, CreationalContext<T> context);

Y por último, pero no memos importante, las anotaciones:

Acá podemos categorizar las diferencias para analizarlo mas detalladamente, desde la menos reelevante a la mas _peligrosa_
  1. Existencia / ausencia de @javax.lang.annotation.Documented: No hace mucha diferencia, solo si la anotación va a ser documentada o no.
  2. Existencia de @javax.inject.Production: Pertenece a las mismas APIs de las que estamos hablando. Su funcionalidad es habilitar o inhabilitar la anotación en distintas configuraciones de deployment. Por ejemplo, si anotamos con @Production la anotación @Model, @Model será ignorada en un deployment que no sea el de producción
  3. Diferencias en el atributo @Target: Teniendo uno o mas valores vamos a poder usar la anotación en mas o menos lugares.
  4. Existencia / ausencia de @javax.lang.annotation.Inherited: Creo que es la diferencia que hace mas ruido. Si agregamos esta información a una anotación afectará por transición a todas las subclases de la clase anotada.

javax.annotation.Named

pete – @Target( { TYPE, METHOD, FIELD })
gurkan – @Target( { TYPE, METHOD })

javax.webbeans.Model

gurkan – @Production
gurkan – @Documented
gurkan – @Inherited

javax.interceptor.Interceptor

gurkan – @Inherited

javax.context.ApplicationScoped

pete – @Target( { TYPE, METHOD, FIELD })
gurkan – @Target( { TYPE, METHOD })

javax.context.ConversationScoped

pete – @Target( { TYPE, METHOD, FIELD })
pete – @Documentend
gurkan – @Target( { TYPE, METHOD })

javax.decorator.Decorator

gurkan – @Inherited

 javax.event.Asynchronously

pete – @Documented

javax.inject.Disposes

gurkan – @Documented

javax.inject.New

pete – @Target( { FIELD, PARAMETER })
gurkan – @Target( { METHOD, FIELD, PARAMETER })

javax.inject.Production

pete – @Target( { TYPE, METHOD, FIELD })
gurkan – @Target( { TYPE, METHOD })

javax.inject.Standard

pete – @Target( { TYPE, METHOD, FIELD })
gurkan – @Target( { TYPE, METHOD })

 

Fuentes

  • Versión 1.0.0.BETA de WebBeans desde svn 
  • Revisión 764218 de OpenWebBeans desde svn
  • Jsr-299 versión actualizada desde el sitio oficial
Anuncios

2 Comments

  1. Buen post.. mas o menos voy captando la idea…
    Sin embargo, me gustaria ver algo andando.. es posible esto?
    Y otras preguntas me surgen de puro desconocimiento del tema son:
    1) WebBeans supuestamente iba a tomar lo mejor de Seam, Wicket y otro que ni recuerdo que era en pos de mezclar las ventajas para hacer un desarrollo mas RAD. Si ya me equivoco en esa orientacion, me gustaria saber.
    2) Con las betas que hay hasta el momento, se puede hacer uso de las cosas que habia en SEAM y Wicket? si es asi.. ver un CRUD estaria mas que bueno.
    3) Que exactamente era el tercer producto del cual no me acuerdo como se llamaba y para que demonios servia?
    4) SEAM va a cumplir con el standard de Web Beans? alguna idea sobre esto? porque deberia adaptar o crear una manera plugueable de meter Wicket y el tercero en discordia.

    Saludos, espero que mis comentarios construyan y no molesten!

  2. Pero como no señor don salaboy, todo es posible. Siempre tan estructurado.
    Tus comentarios no molestan para nada, todo lo contrario… me ayudan a saber que es lo que mas le interesa a un posible lector.
    Voy a tomar tus preguntas como tema de mi próximo posteo, así que solo pido un poco de pasiencia :)

    Sautes


Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: