I have always objected to the claim that getters and setters come from the JavaBean contract. That relationship is so loose one can only say that it is a van der Waals-like relationship. Okay, so we steal this idea of deriving a property from an object by removing get or set prefixes and lowercase the following letter, with the exception of a primitive boolean in which the is prefix is stripped as an alternative to get. The relationship to that specification then trails off into the ether.

The real spec that we are following is the yet undefined Java properties specification. What does it take for there to be a property? As Lincoln suggests, the return type on the setter should not be considered. Maybe even annotations can be used as an override of these defaults.

So the rules would be:

getter: a no arguments method whose name is formed by captializing the property name and prepending "get" with a return type equivalent to the property's type
setter: a single arguments method whose name is formed by captilizing the property name and prepending "set" and whose argument type is equivalent to the property's type (no restriction on return type)

Annotations, like in JAX-RS, can be used when these defaults are not sufficient for the class composition used by the application.

Btw: I think the who idea of the "is" prefix for primitive boolean types is half-assed and insufficient and should be supported only for backwards compatibility.

Lincoln, as far as I can tell what you are attempting to do is legal if you have JBoss EL loaded. JBoss EL is much more flexible about what is allowed and is hopefully a preview of EL 2.2.

-Dan