One of the projects I'm working on is using a DAO pattern for accessing database and for creating data wrappers of table records. Because of the design, we were forced to subclass a DAO class every time we created a new data class. While it would be easy to change the design to accept a Class object as a parameter that would specify the data type, we hesitated at first because of performance considerations. In many cases we would need to instantiate thousands of objects.
So I made a quick test to compare the performance of creating objects with operator new to creating them with a call to newInstance() of a Class object. It turned out that creating a million String objects took 143 milliseconds with new and 284 milliseconds with newInstance. Not bad at all, absolutely nothing to worry about. This was with 1.4.2 Java. I was actually very (positively) surprised of the performance of Java, considering that using newInstance() requires both a try-catch block and a typecast. A typecast is there because you can't really do much with the object without it.
public static class Test extends TestCase {
private static final Logger log = Logger.getLogger(Test.class.getName() );
public void testNewAndNewInstancePerformance() {
long milliseconds = (new Date() ).getTime();
for (int i = 0; i < 1000000; i++) {
String string = new String();
String string2 = string;
}
log.info("Strings created with new, took " + ( (new Date() ).getTime() - milliseconds) + " milliseconds");
milliseconds = (new Date() ).getTime();
for (int i = 0; i < 1000000; i++) {
try {
Object obj = String.class.newInstance();
String string = (String)obj;
} catch (Exception e) {}
}
log.info("Strings created with newInstance(), took " + ( (new Date() ).getTime() - milliseconds) + " milliseconds");
}
}
(Yes, we would really need something to organize the posts and comments to these posts together. Once again, this started as commenting to a posted comment on the differences of servlet filters and PhaseListeners to my post on getting a reference to FacesContext, but then I realized my answer was getting a bit long, and decided to make it a blog post instead.)
A filter is really executing before the JSF lifecycle has started, i.e. before the faces context for that request has been set up, whereas in PhaseListener's case the faces servlet has the control on processing the request and has already created a faces context for that request. Now, regarding usage, a PhaseListener that would do its thing before RESTORE_VIEW phase would be more or less the same as using a filter before it calls doFilter() and passes the control over to another filter or the servlet. Likewise, a PhaseListener acting after RENDER_RESPONSE would be comparable to a filter that would modify the response after it has called doFilter().
The important difference is that PhaseListeners are part of JSF Lifecycle whereas filters are outside of it. Both have their own uses. Let's take a couple of examples to highlight what they are good for. One obvious usage for filters is authorization - you need to grant an access to different resources that are not served by the same servlet. If you don't want to use container based security for some reason or the other, e.g. if you want to use JAAS, filter based security is a natural choice. One other example might be a case where you need to support legacy software or devices. Say you have an old Struts app but you are gradually merging towards JSF. While you can get an access to the backing beans from the session, you might want to use the filter to invoke the JSF managed bean creation facilities to make sure that beans are created when you try to access them from the Struts code.
A watershed case might be supporting legacy devices I mentioned that can only generate GET requests. With filters, you can forward the request to a different end location and after pre-processing, reduce the problem to a normal JSF navigation case. Then again, if you do not need forwarding, but only a different way of passing parameters and populating backing bean properties, you might just as well use a JSF PhaseListener.
The perfect use case for PhaseListeners would be model2x rendering, i.e. applying XSL transformation to JSF output. The PhaseListener would transform the base JSF page to a form suitable for a specific client. There are lots of different options for XSL transformation in JSF as discussed in Sun's JSF forums (really interesting topic btw, but this is getting out of focus), but if you need to do XSL tranformation within the JSF lifecycle, a PhaseListener is the way to do it. I tried to think of a good example when to use a PhaseListener to modify a request, but couldn't think of any... anyone? I'll add it here if I hear about or figure out a good one.