Nous aimons l’idée d’avoir des classes immuables pour des entités accédées en lecture seule (données de référence, etc). Un objet avec des fields final, uniquement des getters et un constructeur avec arguments a l’avantage d’être auto-documenté et sans ambiguité.

Cette approche est hélas délicate à mettre en oeuvre avec JPA (v1 comme v2):

• L’annotation @Entity ne supporte pas l’attribut mutable, il faut utiliser l’extension Hibernate @org.hibernate.annotations.Entity(mutable = false).
• JPA autorise le mapping de fields final (e.g. @Basic final String name;) mais exige un no-arg constructor ; on peut y voir un paradoxe.

Nous avons donc trouvé l’arrangement suivant pour mapper des entités immuable :

@Entity
@org.hibernate.annotations.Entity(mutable = false)
public class Gender implements Serializable {
   /**
    * JPA requires a public or protected no-arg constructor
    */
   protected Gender() {
     this(null, null);
   }
   public Gender(Long id, String name) {
      super();
      this.id = id;
      this.name = name;
   }
   private static final long serialVersionUID = 1L;
   @Id
   @GeneratedValue(strategy = GenerationType.AUTO)
   private final Long id;
   @Basic
   private final String name;
   public String getName() {
     return name;
   }
   @Override
   public String toString() {
     return new ToStringBuilder(this).append("id", this.id).
      append("name", this.name).toString();
   }
}

Nicolas Lecoz et Cyrille Le Clerc (Xebia)

Nous partageons votre intérêt pour les initiatives d’Adobe autour de AIR et nous sommes particulièrement frappés par la volonté d’Adobe de nous faire évoluer d’une approche browser centric dans laquelle les RIA [1] sont encapsulées dans des pages HTML vers une approche widget centric dans laquelle l’utilisateur ne lance plus un browser web mais un widget qui est présent sur son home screen (banal sur les téléphones mobiles, Gadget Windows Vista, Widget Mac OS X, etc).

Nous avions été très amusés, lors du Paris JUG sur Flex, d’entendre James Ward, évangéliste Flex et représentant d’Adobe au JCP, dire que le HTML était une technologie legacy et montrer le widget AIR eBay Desktop qui se substitue à la version HTML du site d’enchères !

Cyrille (Xebia)

[1] Flash, Applet avec Java SE Update 10, etc

Je me permets de réagir au point 3 des conventions de nommage pour langage Java. Initialement, je ne saisis pas trop de l’intérêt du postulat initial: si un objet suit la convention Javabean et propose des accesseurs en écriture, l’objet n’est par définition pas immuable.

Concernant le contre-exemple Hibernate, je pense qu’il est tout à fait pertinent que les entités soient par défaut modifiables. Si le besoin se fait sentir de disposer directement d’objet immuable depuis une requête Hibernate, il est tout à fait envisageable d’exploiter l’opérateur NEW, par exemple:

SELECT NEW samples.ProductImmutable(p.name, p.code, p.price) FROM samples.Product p

De même, même si Spring pousse à l’utilisation de Beans, l’approche par constructeur et l’immuabilité restent possibles.

Pour la partie RIA/JavaFX, je constate que Flex a une avance certaine mais que Adobe mise surtout sur AIR qui est une autre paire de manches (en particulier nouveau runtime à déployer).

Rich Hall comme nouveau collègue dans l’équipe GlassFish c’est une excellente nouvelle!