There are a few downsides to customizing or extending a framework. Although I’ve suggested that customization is a forecasted goal of using a framework, as with other things in software development, there are trade-offs.

When extending a framework, one of the biggest issues that you may face is what to do when newer versions of the framework are made available. Unless the framework developers paid careful attention to backward compatibility, your application may no longer work correctly with a newer version of the framework. The Struts framework, for example, underwent some significant changes to its APIs between Versions 1.0 and 1.1. In particular, the perform( ) method is no longer the controller’s preferred method for invoking the Action; instead, it uses the execute( ) method. Fortunately, the developers working on the Struts framework were careful and ensured that the new functionality was compatible with applications built using earlier versions.

You should take that same care when building your applications. If, for example, you override methods of the Struts framework to achieve specialized behavior, it’s not out of the realm of possibility that the method will be deprecated or removed in future Struts versions. In fact, several comments in the framework source indicate that certain portions of the Struts framework eventually will be retired. Although it’s nearly impossible to protect your application from all potential changes, it’s best that you go into developing it with your eyes wide open. Using a framework, even one that is as good and as complete as Struts, is not a silver bullet. You will have the same upgrade issues whether you build your own framework or use one provided by another source.