February 18, 2019
Hot Topics:

The Java Framework Landscape

  • June 29, 2006
  • By Michael Nash
  • Send Email »
  • More Articles »

Dependencies and Classpath Conflicts

A common difficulty when combining multiple projects is a clash or conflict in the dependencies of the projects. Cocoon and Struts are good examples: Both projects depend on another Apache project from the Jakarta Commons group of projects, called "commons collections." Ordinarily, the commons collections package is bundled into a binary .jar file, and placed in the appropriate directory (WEB-INF/lib) where the remainder of the package's classes can find and utilize it. Struts, however, needs a different (newer) version of this jar file than does Cocoon. Attempting to run Cocoon with the newer file, in an effort to satisfy Struts' requirements, causes errors in Cocoon. The reverse is true if we use the older file: Struts won't operate correctly.

There are two solutions to this problem: the first is to modify and recompile either Cocoon to use the newer library, or Struts to use the older one. The problem with this solution is that it results in an "orphan" customized version of either Struts or Cocoon. You can no longer just download new versions of the two frameworks; you must concern yourself with the version of a particular library they are using—and each framework uses dozens of libraries.

Another, possibly better, solution is to let each framework run in its own environment, using its own copy of the library. This can be achieved either through running each in a separate virtual machine, or with a different classloader within the same virtual machine. Because both Struts and Cocoon can be run as Web applications, leaving them in two separate Web application contexts will use (under most servlet containers) a separate and distinct classloader for each of them, solving the problem. Of course, then you have no means to communicate between the two, and have failed to integrate the two projects.

The solution to this is communication: Rather than bundling the two frameworks or projects together, let them remain separate, but provide for a means for them to communicate. If they can transfer information and method requests between themselves, you can achieve the desired integration without conflict. This is exactly the technique that the Keel framework does; it provides a communication layer between frameworks (depending on configuration, JMS is the default choice for this layer, but Axis and several others are possible). This layer has the added advantage of providing a basis for distributed systems and clustering, and allows the overall application to scale to handle large user loads easily.


A seemingly minor problem can crop up when combining projects: Each project reads its configuration information in a different way, from a different source. In the case of a Turbine service, for example, configuration is supplied by means of a Configuration object. When you use Turbine's cache service via, say, Avalon, you must deal with the fact that Avalon uses a different mechanism for providing its configuration to components (a life-cycle method, specifically). Because of the component-oriented design of both frameworks, however, the Configuration object passed to the service is independent from the method used to populate the object. It is therefore a simple matter to "map" from one configuration object to another, allowing you to plug the Turbine service into Avalon with very little work. This is a good example of separation of concerns—the actual configuration information is read in one component, and used in another.

For some less flexible projects, the code that supplies a service directly accesses configuration information from the source (reading it from a file or a resource on the classpath, for instance), making it difficult to "uncouple" the service from its configuration source. The solution in this case is either to supply the configuration the way the underlying service requires it, or to re-factor the service to read its configuration from a generic object (like Configuration) that can be populated elsewhere.

Separation of Concerns

The concept of separation of concerns provides many of the attributes you need when integrating multiple projects. If your application code concentrates on the business logic at hand, it is easier to integrate with multiple service implementations. If your services concentrate only on their own service, they are more easily re-used in other projects. The principal of "do one thing and do it well" is not a new one, but before the advent of frameworks and component development, it was hard to achieve in software engineering. If an application wanted a particular service, it would either build it in directly, or create its own API library for the service. Re-use was rare, and it was common for service functionality to be interlaced with application logic.

Choosing a Framework

As I've touched on above, choosing a framework is an important choice, and has long-term ramifications for your development project. It often is beneficial to choose a framework with an active and diverse community using it because this community becomes an important element of ongoing support.

Certain frameworks have unique advantages in special situations, though, and must not be discarded just because they are not widely popular. For example, Echo is ideal for Swing-based application developers who need to write a Web-based UI to look and work as much like their desktop application as possible.

The availability of professional services and consulting can also be an important element to look for.

Picking a framework to build on may be the most important step of your next application project—choose well!

About the Author

Michael Nash is the president of JGlobal Limited, a software development, consulting, training and support company specializing in open source Java technologies. He is also a core developer of the Keel meta-framework, the author of two books and a number of articles and papers about next-generation web-application development with Java, and a member of the JSR-127 (JavaServer Faces) Expert Group. He can be reached at mnash@jglobal.com.

Page 2 of 2

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date