You are here: Home ยป Blog

Runtime-defined properties in EL expressions

Posted on Monday, January 12 2015 at 08:47 | Category: Oracle ADF & JDeveloper | 1 Comment(s)

Expression Language (EL) is used to access application logic (Managed Beans) from the presentation logic (JSF pages and page fragments). Assume that we have a class called com.example.SomeBeanImpl which is registered as a managed bean called someBean. Then, an expression like #{someBean.someProperty} essentially calls the getSomeProperty() method of the com.example.SomeBeanImpl class whenever the expression is used in a read operation, and calls the setSomeProperty() method of the com.example.SomeBeanImpl class whenever the expression is used in a write operation. Note that this requires that there are explicit setter and getter methods for each property accessible from an EL expression. If the expression tries to access a property for which there is no corresponding getter or setter, an exception is thrown.

So, adding the getters and setters for the properties is a compile time operation - the class needs to contain the required methods. However, for some scenarios, it might be useful to be able to define properties at runtime. In fact, the ADF engine does this in several places - one example are the "row" or "node" variables for the <af:table> or <af:treeTable> components to reference one row of a table or a tree table. Even though there is one specific java class used inside the ADF runtime which represents one row or node, it is possible to access all of the table's attributes through those classes (and the ADF runtime does not synthesize any specific classes during build- or runtime):

<af:table value="#{myManagedBean.allEmployees}"  
          var="emp">    <!-- Internally, instanciates a class used as the container for one row -->
    <af:outputText value="#{emp.ename}"/>   <!-- Accesses the "ename" property of the row -->
    <af:outputText value="#{emp.deptno}"/>  <!-- Accesses the "deptno" property of the row -->

In this example, we can access the ename and the depto properties of the row container class, even through this internal container class will certainly not have corresponding getters and setters available (as their names depend on the attributes of the associated view objects). ADF internally further routes those accesses to the proper view object rows.

EL Resolvers

The J2EE concept which allows such "dynamic" beans with properties defined at runtime is called "EL Resolvers". Essentially, the EL engine is using EL resolvers each time it needs to evaluate an expression. For example, by default there is a BeanELResolver which resolves properties which correspond to the JavaBeans specification, using getter and setter methods as described above. However, there are also other resolvers like MapELResolver which can access properties which are stored in a Map, and it is also possible to define custom EL resolvers to implement a custom property resolver for more unique requirements. Resolvers can be chained together by using a CompositeELResolver - the CompositeELResolver iterates over all its resolvers until one resolver was able to evaluate the expression.

The Java EE 5 Tutorial: EL Resolvers  gives additional information and shows a list of standard resolvers. The JavaServer Pages Specification, chapter JSP2.9: Resolution of Variables and their Properties describes the resolution process in more detail and shows the order in which the CompositeELResolver resolves properties by default. The JavaDoc at describes the Java classes used in the EL resolvers API.


A simple approach to implement beans with runtime properties as described above is to have the managed bean implement the Map interface. This lets the default CompositeELResolver use the MapELResolver to resolve its expressions. According to 5 Reasons to Use Composition over Inheritance in Java and OOP, we will not inherit from a container class, but implement the required interface and then delegate to a HashMap instance:

public class DynamicPropertyBean implements Map<String, Object> {
    public DynamicPropertyBean() {
        put("value1", 42L);
        put("value2", "Hello");

    private Map<String, Object> theMap = new HashMap<>();

    public int size() {
        return theMap.size();

    public boolean isEmpty() {
        return theMap.isEmpty();

    // All additional required methods from the Map interface

If this bean is registered with the name dynamicBean, we can access the properties "value1" and "value2" like #{dynamicBean.value1} and #{dynamicBean.value2}. All other property names will return an empty value - there will be no exception thrown, and the CompositeELResolver will also not try any other resolver further down in the chain, such as BeanELResolver, to resolve the property name. If we want to catch accesses to unknown properties, we either need to further tweek the methods which implement the Map interface (instead of simply delegating), or implement a custom EL resolver.

Some background on Generics: dumping a Map

Posted on Wednesday, December 17 2014 at 11:16 | Category: Java | 0 Comment(s)

In Java, dumping a Map to see what key/value mappings it contains is quite easy. Lets assume we have a factory method which returns a map, containing some String to Long mappings:

Map<String, Long> map = createMap();

The toString() method of the Collection classes usually provide a useful implementation, so that we can simply use


to dump the map. If we want to have more control over the output format, e.g. one line per map entry, we can use a simple loop to iterate over the entries:

Set<Entry<String, Long>> entries = map.entrySet();
for (Entry<String, Long> entry : entries) {
    String key = entry.getKey();
    Long value = entry.getValue();
    System.err.printf("%s=%s\n", key, value);

When running this code with the map returned from the createMap() method, we get

Exception in thread "main" java.lang.ClassCastException: com.example.Key cannot be cast to java.lang.String
	at com.example.MapSample.main(

Ehm... wait a moment ... why do we get this exception in the line which executes String key = entry.getKey();? We did not get any compile time errors or even warnings, and entry.getKey() is declared to return a String due to the definition of entry as Entry<String, Long>. Also, the Map is declared as Map<String, Long> - so each key element in the map must be a String, right?


Lets examine how the map is created in the createMap() factory method:

private Map<String, Long> createMap() {
    Map result = new HashMap();
    result.put("one",  1L);
    result.put(new Key(), 3L);
    result.put("two",  2L);
    result.put("five",  5L);
    result.put("four",  4L);
    return result;

Obviously, we are allowed to use different types than String as a key, an instance of the Key class in this case. This is possible since Map and HashMap are used as raw types here, instead of parameterized types. The Java compiler will issue some warnings, but will still compile the method as such (and even the warnings can be switched off with an annotation like @SuppressWarnings({ "unchecked", "rawtypes" })).

Remember that Generics (paremeterized types) are syntactic sugar only - internally, during runtime, everything is raw types, with the necessary casts automatically applied where necessary. These casts succeed when the parameterized types are used throughout the application. If this was properly done in the createMap() method, the compiler would not let us use Key as a key value. However, due to the usage of Map as raw type, we can. And then, during runtime, the casts mentioned before will fail horribly. In the example above, entry.getKey() still returns an Object reference, but due to the type parameters the compiler automatically casts the result to a String. You can verify this in the byte code which contains a corresponding checkcast instruction after entry.getKey() has been invoked.

The general rule is: do not use raw types. Especially with large legacy code bases, there are sometimes occasions where Collections are still created without the proper usage of type parameters (but later returned through parameterized types). Thus, the learning is: Even if you get a reference to a properly parameterized Collection type, do not be surprised if there are other types stored in it when you iterate over the Collection values or keys.

Back to our dumping method, we can simply solve the issue by not forcing any implicit casts:

Set<Entry<String, Long>> entries = map.entrySet();
for (Entry<String, Long> entry : entries) {
    Object key = entry.getKey();
    Object value = entry.getValue();
    System.err.printf("%s=%s\n", key, value);

When run, this will produce the expected output:


Adding a Method Call Activitiy to an ADF task flow

Posted on Monday, December 15 2014 at 12:47 | Category: Oracle ADF & JDeveloper | 0 Comment(s)

New Oracle ADF tutorial: How to add a Method Call Activitiy to a task flow. Also describes the manual approach, to get a better understanding of what happens in the background.

Incompatible Java 8 changes in the Collections runtime classes

Posted on Tuesday, December 09 2014 at 13:15 | Category: Java | 0 Comment(s)

Suppose that we want to implement a HashMap (let's call it OrderedHashMap) where the values can also retrieved by their index, where the index refers to the order in which the key/value pairs have been inserted. The following unit test shows how such a class shall be used:

public void testPutGet() {
    OrderedHashMap<String, String> ohm = new OrderedHashMap<>();
    ohm.put("Z", "LetterZ");    // 0
    ohm.put("A", "LetterA");    // 1
    ohm.put("D", "LetterD");    // 2
    ohm.put("K", "LetterK");    // 3

    assertEquals(ohm.get(0), "LetterZ");
    assertEquals(ohm.get(3), "LetterK");

The straight forward implementation of the class OrderedHashMap is to inherit from one of the existing Collection classes and simply implement the additional functionality, e.g. like

public class OrderedHashMap<K, V> extends LinkedHashMap<K, V> {
    private static final long serialVersionUID = 6354582314971513369L;

    private List<V> items = new ArrayList<>();

    public V get(int index) {
        return items.get(index);

    public V put(K key, V value) {
        return super.put(key, value);

With this code, the above unit test succeeds. Lets add an additional unit tests for one of the other methods inherited from LinkedHashMap, putAll():

public void testPutAll() {
    OrderedHashMap<String, String> ohm = new OrderedHashMap<>();
    ohm.put("Z", "LetterZ");    // 0
    ohm.put("A", "LetterA");    // 1
    ohm.put("D", "LetterD");    // 2
    ohm.put("K", "LetterK");    // 3

    OrderedHashMap<String, String> ohm2 = new OrderedHashMap<&ht;();

    assertEquals(ohm2.get(0), "LetterZ");
    assertEquals(ohm2.get(3), "LetterK");

This unit test also succeeds and shows that we can copy the elements from one OrderedHashMap to a second one, using putAll().

Unless we switch to Java 8.

If we run the above sample with the Java 8 runtime, the test fails with an exception:

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
	at java.util.ArrayList.rangeCheck(Unknown Source)
	at java.util.ArrayList.get(Unknown Source)
	at com.example.OrderedHashMap.get(
	at com.example.test.OrderedHashMapTest.testPutAll(

This is an issue I came across when I was trying to translate a grammar with ANTLR (not using the latest version) - see also

The background is that the LinkedHashMap class (or one of its super classes) changed the implementation of putAll() so that it no longer calls put() to insert the new elements in the destination map. Hence, our own implementation is no longer able to catch this call to update the List at the same time a new key/value pair is added to the map.

If you do similar things, you should check if there are such differences between the Java 7 and the Java 8 runtime which might affect your code. 

In general, this is a good example to Favor Composition over Inheritance in Java and Object Oriented Programming. The main problem is that the sub class depends on the behaviour of the superclass, and hence becomes fragile (and breaks when the superclass behaviour changes in an incompatible way). Collections are always a bad candidate for subclassing - instead, create a new class which implements the desired interfaces and then delegates to the necessary Collection classes. This is more effort at the beginning (to implement all the necessary interface methods), but makes the class much more resistent against modifications in the runtime classes. See also Effective Java, Second Edition: Item 16: Favor composition over inheritance.

Displaying results 17 to 20 out of 115