It is what it is

The embbeded type support for Chromattic brings much power to object modeling on top of Java Content Repository that allows to fully take advantage of how JCR models node types. JCR type model provides two features that don’t match the Java type mode.

The first feature is multiple inheritance that is supported natively by JCR which allows a type to extend several super types. The other feature is the mixin support which is pretty much similar to multiple inheritance except that it can be dynamic, meaning that a node can be assigned with a mixin type. Conversely a mixin type can be removed from a node.

Both features are difficult with classic Java inheritance and the most appropriate way for modeling those is to leverage object delegation. Actually often object delegation is preferable over inheritance as it decouples the object types and provides support for dynamicity.

Mixin type support

The following example is taken from GateIn and it shows how several java type can support templatization with the embedded support.

The Templatized class is a delegate object that provides a relationship to a Template type.

@MixinType(name="templatized")
public abstract class Templatized {

  @OneToMany(type=RelationshipType.PATH)
  @MappedBy("template")
  public abstract Template getTemplate();
  public abstract void setTemplate(Template template);

}

The Page class has an embedded relationship with a Templatized type.

@PrimaryType(name="page")
public abstract class Page {

  // Returns null if the mixin is not present
  @OneToOne(type=RelationshipType.EMBEDDED)
  public abstract Templatized getTemplatized();

  // Controls the life cycle of the mixin
  public abstract void setTemplatized(Templatized templatized);
}

At runtime this would likely be used in the following manner:

Page page = session.findByPath(Page.class, "page");
Templatized templatized = session.create(Templatized.class);
page.setTemplatized(templatized);
Template template = session.findByPath("template");
templatized.setTemplate(template);

Primary type support

Likewise Chromattic supports primary type, the only difference is that the dynamicity aspect does not occur therefore the relationship always exists between the types and it is obviously not possible to destroy it. This feature provides to my opinion a very good alternative for reusability.

Supports in GateIn

The embedded type feature has been added for GateIn in order to allow the Model Object for Portal (MOP). Indeed the model itself does not care about certain aspects and the portal needs to be able to make the base model richer than it is. With the embedded type we have the opportunity to keep the base model simple and have GateIn add its own mixins such as security, templatization, etc… Likewise eXo WCM that is built on top of GateIn will be able to add its own mixins for the purpose of web content management.

The CRaSH 1.0.0 Beta 2 has been released, you can download it there and the documentation has been updated with the new features.

The most important feature brought by that release is the brand new support for SSH thanks to the Apache SSHD project. SSH access is more suitable for remote access on public networks and SCP can be used to import or export content from the repository.

Configuration is now possible via the web.xml file and the following can be configured:

• SSH username, password, port and key file
• Telnet port

I came across the generics self-bounding pattern, thanks to Olivier’s blog [in french] that uses it to describe fluent extensible interfaces. After a bit of research I found a very interesting forum thread that was talking about that pattern more in depth, in particular how it is possible to extend the pattern to a couple of classes.

Let’s just start with a simple example, a binary tree class:

abstract class Node<E extends Node<E>> {
   public E left;
   public E right;
}

class FooNode extends Node<FooNode> {
}

class BarNode extends FooNode {
}

class JuuNode extends Node<JuuNode> {
}

With that design, we constraint the Node class to be subclasses and have its children to be a subclass of its own subclass, and now we can write:

FooNode root = new FooNode();
root.left = new FooNode();
root.right = new BarNode();

But that is not possible:

FooNode root = new FooNode();
root.left = new JuuNode();

If you have carefully read the forum thread, someone posted an interesting extension of the pattern that uses two classes.

The Reflext framework I started to write a few months ago was using a visitor pattern to visit a set of types. There are several ways to visit a set of types, one of them is to visit the class hierarchy of super classes and implemented interfaces. There are many ways to implement the visitor pattern, one of them relies on decoupling the visitor from the code (or strategy) that takes care of doing the visit. The main interest is to reuse the visiting strategy many times and avoid the visitor to care about how visit is done, the visitor only cares about the overall strategy.

Based on this assumption, we can define two interfaces named Visitor and VisitorStrategy that will vary together, as it makes sense to use a hierarchy visitor with the hierarchy visitor strategy. Let’s start with the base interfaces. We use it a Type object as visited object, in the reflext framework it’s a TypeInfo interface that represents a type (which can be either runtime reflection or APT compile time reflection).

interface Visitor<V extends Visitor<V,S>, S extends Strategy<V,S>> {
  // The interface is empty as the base visitor does not provide an API
}

interface Strategy<V extends Visitor<V,S>, S extends Strategy<V,S>> {
  void visit(Type type, V visitor);
}

Now we can define the hierarchy visitor and its strategy

interface HierarchyVisitor<T extends HierarchyVisitor<T>> extends
  Visitor<T, HierarchyStrategy<T>> {

  // The API for hierarchy visit
  void enter(Type type);
  void leave(Type type);
}

abstract class HierarchyStrategy<T extends HierarchyVisitor<T>> extends
  Strategy<T, HierarchyStrategy<T>> {
  public void visit(Type type, T visitor) {

    // We only accept type which are java classes
    if (type instanceof Class) {
      if (accept(type)) {

        // Visitor callback
        enter(type);

        // Now visit the super class if we have one
        Class clazz = (Class)type;
        Class superClazz = clazz.getSuperClass();
        if (superClazz != null) {
          visit(superClazz, visitor);
        }

        // And now visit the interfaces
        for (Class itf : clazz.getInterfaces()) {
          visit(itf);
        }

        // Visitor callback
        leave(type);
      }
    }
  }
  abstract boolean accept(Type type);
}

We can see that the hierarchy visitor and its strategy vary together because they are constrained by design. The last piece missing is the to make vary the strategy (otherwise we would make the visitor and its strategy the same class…). We do it via an enum that provides several strategies

enum HierarchyScope {
  ALL() {
    public <T extends HierarchyVisitor<T>> HierarchyStrategy<T> get() {
      return new HierarchyStrategy<T>() {
        public boolean accept(Type type) {
          return true;
        }
      }
    }
  },

  ANCESTORS() {
    public <T extends HierarchyVisitor<T>> HierarchyStrategy<T> get() {
      return new VisitorStrategy<T>() {
        public boolean accept(Type type) {
          return (type instanceof Class) && !((Class)type).isInterface());
        }
      }
    }
  };

  public abstract <T extends HierarchyVisitor<T>> HierarchyStrategy<T> get();

}

Et voilà, now we can use safely the visitor. I’m not convinced that is a great piece of software, I’m just sure that it was very fun to write and research. Without the mentioned blogs and my favorite IDE (Intellij IDEA) it would have been nearly impossible to write correctly :-).

Self-bounding generics is a curious beast, it’s even called there “That Recursive Java Generics Thing”. Have fun!

At the beginning of the year I started to write management capabilities in eXo Portal. It already had some management features but it was not really in a usable shape, it was indeed exposing every service of the kernel on the JMX registry, which was very confusing because it was exposing too much information and not the right information, it was just not usable.

Usability is word that matter, even in management, so my idea was, let’s expose management in a usable way. So I went on designing a way to expose management information based on Java annotations (well it’s pretty obvious to do that isn’t it?).

An important point was also to not tie the management to JMX. Indeed even if JMX is the kind of standard for exposing management in Java, I wanted to be able to expose the same management interface using Rest. The idea is to leverage the gadget server of GateIn and provide management information to gadgets.

So I went on designing the management contract (Java 5 annotations) that are agnostic of the management layer. Of course this is not enough for exposing the management in JMX nor in Rest. So we do have custom JMX annotations that describe how a management interface should be exposed in the JMX registry.

Here is an example of a managed service:

@Managed
@NameTemplate({@Property(key = "service", value = "cache"),
@Property(key = "name", value = "{Name}")})
@ManagedDescription("The Cache")
public interface Cache

   @Managed
   @ManagedName("Name")
   @ManagedDescription("The cache name")
   public String getName();

   @Managed
   @ManagedDescription("Evict all entries of the cache")
   public void clearCache();

   ...

}

The @Managed, @ManagedName and @ManagedDescription are the agnostic annotations. The @NameTemplate is an annotation that has only a sense for the JMX layer. The @Managed* annotations really focus on giving a clear and non programmatic description of the management interface.

There a few more features in the framework such an @ManagedBy annotation to specify a delegate for management interface to avoid to clutter the service with management, a ManagementAware interface for programmatically registering new managed object, a management context facility for correctly scoping managed resources (so several instances of the same service can be registered several times with different names in a transparent manner).

Recently I spent time to develop in the kernel layer the plugability for management provider. It is still in the trunk so nothing is really commited yet in GateIn. This plugability allowed my to write the Rest management provider in GateIn. It was also a good way for me to learn a bit more about JAX-RS (many thanks to Stephane that came a few weeks ago at the Mars JUG to talk about Rest and also for helping me a bit tonight ). So I’m still not yet a Rest expert but I have a few bits of management stuff coming to Rest:

@Managed
@NameTemplate({@Property(key = "service", value = "cache"),
@Property(key = "name", value = "{Name}")})
@ManagedDescription("Exo Cache")
@Rest("cache")
public interface Cache
{
   ...
}

The @Rest (it’s not yet definitive) expose the management interface on the Rest connector. For now I’m only considering JSON in my experiment.

management returns a list of the managed services annotated with the @Rest annotation,
aka “resource list”
/management/{resource} returns the management interface description, for instance in our case
we have {name:”cache”,description:”The Cache”,properties:[{name:"Name", description:
"The cache name"}],methods:[{name:"clearCache",description:"Evict all entries of the
cache"}]}

The good news is that we have already plenty of useful management interface in GateIn that were developed a few months ago by our team and all those will be soon available via Rest!!!

Le Mars JUG fera son inauguration le jeudi 15 octobre 2009 lors de l’Agile Tour.

Emmanuel Bernard a accepté d’être le parrain du JUG et cela nous fait très plaisir, il sera aussi le premier conférencier du JUG et nous parlera d’Hibernate Search, un projet qui permet de faire des requetes full-texte tout en utilisant Hibernate. Il explorera entre autre comment les recherches approximatives telles que la recherche phonetique sont implementées.

Les passionnés d’Agilité et de Java seront comblés car le JUG s’est associé à l’Agile Tour (participation gratuite, inscription ici) pour l’inauguration. Le but est de créer une synergie entre les deux évènements qui sont en général assez rare dans la région PACA. Je tiens à remercier Viaxoft et plus particulièrement Karine pour cette collaboration.

Dimitri Rodolphe Baeli un collègue d’eXo Platform sera lui présent mais durant l’Agile Tour pour faire un tour des pratiques TDD en entreprise.

Le but du Mars JUG est de fédérer autour de Java et de créer une communauté dans notre région, j’espère que vous répondrez présent à l’appel le 15 octobre.

I’ve been working with Java 5 Generics for about one year now and one pattern that emerged from my experience is the use of generics to create enumerations that provide type safety (I don’t claim to be the inventor of that pattern, actually I don’t even claim it is a pattern).

Often type safety can be achieved by using method type variables like

public abstract <N extends Number> createNumber(Class<? extends N> numberType, String stringValue);

The drawback of this solution is that all the classes must belong to the same hierarchy, in that example they all need to be a subclass of java.lang.Number. The most direct workaround is to free the type variable from its upper bound java.lang.Number. That makes the choice very large since any subclass of java.lang.Object can be accepted.

It is also impossible to prevent some subclass to be used as type argument at compilation time. Failure would have to happen at runtime with an java.lang.IllegalArgumentException thrown for instance.

Those two limitations makes the method not easy to understand the first time you see it, specially when it is part of an API, and it is not possible to make it type safe (actually not as far as I know ) as Java Enums cannot be used as a generic declaration.

So I had to find a way to express an enumerated type that would be type safe. The solution I found is actually not an enumeration in the old/classic way we use to know it before Java 5 Enums (i.e it is class that has a private constructor with public static fields) and therefore it cannot be used in a switch statement. That probably is the only drawback I found but it is a more acceptable issue than the two problems I had before.

Let’s assume we represent a concept of simple types which are arbitrarily defined by String, Boolean and Integer with

public class SimpleType<S> {

   public static final SimpleType<String> STRING =
      new SimpleType<String>(String.class);

   public static final SimpleType<Integer> INTEGER =
      new SimpleType<Integer>(Integer.class);

   public static final SimpleType<Boolean> BOOLEAN =
      new SimpleType<Boolean>(Boolean.class);

   private final Class<S> javaType;

   private SimpleType(Class<S> javaType) {
      this.javaType = javaType;
   }
}

Now we can easily use it as a type safe enumeration, for instance here is how I would write a parse method:

/*
 * Note : yeah this is not really OO and it could be
 * possible to have an abstract parse(String s)
 * method on the SimpleType class and have the static
 * method delegate to it. I leave it as an exercise
 * for the reader.
 */
public <T> T parse(SimpleType<T> simpleType, String s) throws NullPointerException {
   if (simpleType == null)
      throw new NullPointerException("No null simple type is accepted!");
   if (s == null)
      throw new NullPointerException("No null string can be parsed!");
   if (simpleType == SimpleType.STRING)
      return s;
   if (simpleType == SimpleType.INTEGER)
      return Integer.valueOf(s);
   if (simpleType == SimpleType.BOOLEAN)
      return Boolean.valueOf(s);
   throw new AssertionError("impossible!);
}

This way we enforce the set of types that can be passed as arguments in our method and we do it in a manner that will enforce the developer to write type safe code.

Next time I’ll show you have it is possible to improve the pattern efficiency and usability by adding methods on the Type Safe Enumeration class.

I have been working during the past few days on a reflection framework for Java. Beside the complexity of the actual reflection layer, the developer is pretty much left to himself to perform advanced operations such as type variable resolution or annotation discovery based on the type inheritance hierarchy.

Furthermore this reflection framework is implemented with the runtime java reflection API (java.lang.reflect.Type and its implementations) and the compile time java reflection API (javax.lang.model.type.*). It means you can perform compile time reflection or runtime reflection with the same code. I forgot to mention that the java compile time API is awful.

The first reason I wrote this framework was to perform type variable resolution based on a specific class. I needed to perform such operations for a new project (that I will announce soon, stay tuned).

Let me give you an example:

public class A<V> {

  private final V value;

  public A(V value) {
    this.value = value;
  }

  public V getValue() {
    return value;
  }

public class B extends A<String> {
  public B(String value) {
    super(value);
  }
}

Now if we want to know what is the value of the type variable V at runtime for the class B, the code to perform the resolution is pretty tricky to write and requires a fairly good knowledge of the java type system, although it’s a very intuitive operation to do. Let me give you another example:

public class Event<S> {

  private S source;

  public Event(S source) {
    this.source = source;
  }

  public S getSource() {
    return source;
  }

}
public interface Listener<S> {

  void onEvent(Event<S> event);
}

public class FooListener implements Listener<String> {
  void onEvent(Event<String> event);
}

Although we all know that Java type erasure will not give us the type of S at runtime from instances of the Event class, any implementation of the Listener interface will carry the information about the type variable. Note that it may not be possible to resolve it if the subclass does not bind the variable to a type. It is therefore possible for the framework broadcasting events to know if a listener is able to receive events from a particular source.

Since Java 6 it becomes very easy to process source code at compile time (as exhibited by Gavin King during his researches about the type safe criteria API for JPA). For instance it would be possible to replace the need for CGLib at runtime by a library that would perform a similar work at compile time (actually I wrote pretty much that in the forthcoming project). The advanced Java reflection framework helps to hide the java compile time reflection API. The compile time API is source code oriented but does expose the same semantics as the runtime API.

Another neat feature is the resolution of annotations along a type hierarchy which is very useful if you want to determine the annotation of a type or a method taking in account the type hierarchy. Very useful in the following situation

@Foo
public interface A {
  @Bar void m();
}

public class B implements A {
  public void m() {
  }
}

Finally the framework has some nice stuff coming in, such as the inclusion of the visitor pattern that allows you to perform an operation along the hierarchy of a type, the obtention of the raw class type of any type which attempts to unify the raw type of a parameterized type and the elimination of the synthetic methods due to the return type covariance.

I plan to host that reflection framework project soon somewhere (under LGPL) because I think it will be useful to anyone performing advanced operations with the Java reflection. What is missing for now is a decent name for the project since I haven’t been able to come up with something nice. If you have a good suggestion, don’t hesitate to send me an email (go on www.julienviet.com for the @).

Vendredi 7 avril j’ai participé au BarCamp Marseille 2 pour promouvoir la création du Marseille JUG.

Les évènements orientés nouvelles technologies sont plutot rares sur Marseille et c’est ma première participation à un BarCamp. A vrai dire je ne connaissais pas ce concept avant cette occasion dont j’ai connu l’existence via le Twit de Charles, rencontré de visu justement durant l’occasion.

L’école d’ingénieur Supinfo Marseille hébergeait le BarCamp pour l’occasion ce qui m’a donné l’occasion de visiter les docks qui ont été rénovés il y a quelques années. J’avais déjà visité un peu les docks et j’ai constaté que l’intérieur des batiments est aussi beau que l’aspect extérieur le laisse penser.

A présent, venons en aux faits! furent présents lors de la réunion:

• Alain Defrance formateur Java à Supinfo
• Yann Vigara revenu de Paris il y a quelques mois et qui démarre une activité d’hébergeur Java
• Alexandre Terasson et Florien Berton élèves à Supinfo
• Cyril Bourgès étudiant en master SIS de Luminy
• Moi même

La réunion a d’abord commencé par les cordialités d’usage à savoir la présentation de chacun des participants.

Il faut savoir que notre aventure du Marseille JUG a débuté il y a quelques semaines.  Khaled, Colin, Alain et moi même nous sommes déjà rencontré plusieurs fois avant le BarCamp (malheureusement Khaled et Colin n’ont pas pu participer au meeting BarCamp). Nous avions donc déjà donné une direction au JUG et cela a été l’occasion d’exposer nos décisions. Je rassure tout de même, celles ci sont assez standard et nous n’auront pas une gouvernance basée sur le totalitarisme, en fait la plupart d’entre elles émargent de la lecture de la mailing list des JUG leaders français. Voici donc les points que nous avons discutés:

• Direction collégiale avec des status basés sur la notion de co présidents. Cela nous est apparu comme le mode idéal et a suggéré par un JUG ayant ce mode de gouvernance
• Volonté de faire une réunion unique avant fin juin 2009 et mise en place d’un calendrier de réunions pour la saison 2009/2010
• Recherche de partenaires et de sponsors financiers pour aider le JUG

Il apparaît que Supinfo fournira un partenariat afin que le JUG puisse profiter des locaux de l’école. Ceux ci semblent idéaux car modernes et avec une position géographique très avantageante. Nous souhaiterions effectuer une réunion mensuelle du JUG, vraisemblablement le mercredi qui est un jour où nous pourrions utiliser la salle aussi bien l’après midi que le soir (probablement 18h).

Finalement nous avons conclu qu’à présent la prochaine action à effectuer est de s’occuper de tout le travail administratif qui fondera le JUG en tant qu’assocation 1901. Ceci est un mal plus que nécéssaire pour la création du JUG.

Longue vie au Marseille JUG!

Le Riviera JUG organise sa deuxième rencontre le 10 avril sur le theme SOA, si vous êtes intéressé vous trouverez plus d’information sur cette page.