If "un-intrusiveness" was the factor, I'm not sure if they totally achieved it.
1. Some of the methods have to return a
string which decides how the navigation will be performed. (This is a contract between the bean developer and the framework and hence is a lockin).
2. It is not that our methods can have whatever signature we like. Some methods need to accept a list of JSF specific parameters, which very much binds us to the framework. The only "wriggle room" we get is the name of the method, which can be anything.
3. To indicate an exception, we need to throw a sub class of a runtime FacesException(i don't have anything against runtime exceptions, i think thats really not the focus of this discussion). But, what i want to point to is, we already will be using JSF specific exception hierarchy.
4. In anycase, if we have to be framework independent, a layer can be provided by the application developers (or any other framework that builds over JSF).
Struts achieves the same by urging developers not to code business rules in action classes.
I do not say that an application needs/doesnot need to be JSF application independent. Thats the decision of the architect. In anycase, not using interfaces to achieve the contract between JSF and the application would not alter that decision in any manner.
I'm not totally sure that not using interfaces for this reason is a valid argument. They do provide compile time type checking and a clean and object oriented way of method invocation (virtual functions). Whereas, the approach taken relies on "function pointers".
I understand that JSF is supposed to be "tooled", and the tools will/need to provide compile time checking, but giving up on object oriented ness to depend on a tool does not convince me enough. It also becomes difficult to use existing code checkers or other optimizers etc on code which lacks compile time type checking.
[ October 26, 2004: Message edited by: Dushy Inguva ]