Month: June 2014

Wrapping the constant interface anti pattern into an Enum

Especially in legacy code, we sometimes come across code like this, also known as the Constant Interface Antipattern:

public interface Constants {
   static int DML_DELETE = 0x02; 
   static int DML_INSERT = 0x05;
   static int DML_UPDATE = 0x10; 
}

Since Java 5, a much better alternative is to use an enum. If possible, code like the above which only defines constants should be converted into a corresponding enum. However, sometimes this is not possible, for example when using a library where the source code is not available. Then, we can still take advantage of enums in our own code by wrapping the legacy constants into an enum type. By default, a Java enum only allows to map from the the enum name to the enum itself, but in our scenario we also need to be able to map the legacy integer constants to the corresponding enum. The following code shows how the above interface could be wrapped into an enum:

public enum ConstEnum {
   DML_DELETE(Constants.DML_DELETE),
   DML_INSERT(Constants.DML_INSERT),
   DML_UPDATE(Constants.DML_UPDATE);
   
   private int constValue;

   // we need to create a reverse map for the enum in order to allow reverse lookups
   private static HashMap<Integer, ConstEnum> revMap = new HashMap<>();
   static {
      for (ConstEnum e : values()) {
         revMap.put(e.value(), e);
      }
   }

   // private constructor for the integer value
   private ConstEnum(int someValue) {
      constValue = someValue;
   }

   public int value() {
      return constValue;
   }

   public static ConstEnum enumFor(int value) {
      ConstEnum result = revMap.get(value);
      if (result == null) {
         throw new NoSuchElementException(ConstEnum.class.getName() + " for " + value); 
      }
      return result;
   }
}

The core of this code is the revMap hashmap which is initialized in the static initializer and puts all available enum objects and their corresponding integer values into a hashmap, so that we can look up the enum object by its integer value, which is done in the enumFor() method. The static values() method is provided automatically by the java compiler for all enum types. The following samples show how the enum type can now be used: List all available values:

for (ConstEnum val : ConstEnum.values()) {
   System.err.println(val + "=" + val.value());
}

DML_DELETE=2
DML_INSERT=5
DML_UPDATE=16

Convert legacy int value into enum:

int someValue = 5;
ConstEnum e = ConstEnum.enumFor(someValue);
System.err.println(e + "=" + e.value());

DML_INSERT=5

Switch on a legacy int value:

someValue = 2;
ConstEnum e = ConstEnum.enumFor(someValue);
switch(e) {
   case DML_DELETE : System.err.println("DELETE");  break;
   case DML_INSERT : System.err.println("INSERT");  break;
   case DML_UPDATE : System.err.println("UPDATE");  break;
}

DELETE

Remember: use createInsert with af:table!

I came across this issue (again) yesterday, so I think it is worth to quickly outline it here: Oracle ADF provides two operations on a data collection to create new records, that is create and createInsert. When searching through the documentation, it turns out that the differences are:

  • create
    Opens a slot for a new record in the collection, before the current record. The new record is not added to the collection immediately (as part of the create operation itself), but only after the page has been submitted. The advantage is that no empty, orphaned record is left behind when the user navigates away from the page, without submitting it.

  • createInsert
    This is the same as create, but the new record is added to the collection immediately, as part of the createInsert operation itself.
In other words, after the http request corresponding to the create operation has finished, the collection does not contain a new record – the “new” record is maintained by the ADF framework as a temporary object in the background, until the page is submitted. On the other hand, when using the createInsert operation, then the collection does contains the new record when the http request has returned. This makes a big difference when inserting a row into an af:table component: the af:table requires that the new record is available in the collection in order to render it, otherwise no new row will be visible. So, while create can still be used with forms, make sure that you always use createInsert when adding new rows to an af:table! There is a nice article by Andrejus Baranovski which describes this in more detail: ADF Create and CreateInsert Operations for ADF Table.