Java 1 5 Support

Overview

Unified EL adds support for Java 5. Java 5 enumerations are directly supported as types in EL expressions. Java 5 generics cannot be used directly, but symbols can now typed using generics, so symbol and type resolution is now affected.

Enumerations

The following is an example of enumeration use in an EL expression:

#{myColor == 'blue'}

Let's say that myColor resolves to an instance of a Java enumeration Color. EL will attempt to coerce 'blue' to a enumeration value the Color type in order to make the comparison. This creates several possible validation opportunities:

• is 'blue' coerciable to an Enumeration? If not, the JSF runtime may throw an exception.
• is Enum.valueOf(Color.class, 'blue') a valid value? If 'blue' is not a valid value for Color, this will cause an IllegalArgumentException at runtime.

In both cases we should be able to validate these issues.

Generics

The support for generics in Unified EL provides new validation opportunities and support requirements. Consider the following expression:

#{mapVar['key'] > 8}

If mapVar resolves to a java.util.Map, then we can check the following things:

• is mapVar a Map<String, ?> ? If it is not, then mapVar['key'] may be guaranteed to return null, since no matching of type String could have been added to the map.
• is mapVar a Map<?, T> where T can be coerced to an something comparable to the number "8" with the ">" sign? If not, the comparison may fail at runtime.

In this way generics support, where applicable, can improve design-time validation of EL.

Generics does create a new requirement however. Consider that a tag author may now require a particular kind of template class for an attribute. For example, consider the following tag example:

<myNS:MyTag value=#{mustBeMapThatReturnsString}/>

This tag wants the value attribute to return a Map<?, String>. We must now be able to validated such bounded generics that are implicitly referenced through an tag's expected EL result type.