A look at Seam and Java Pure Faces

by Matt Pickell for JavaPureFaces

A recent comment on this blog asked if Java PureFaces was different than Seam. Being unfamiliar with Seam, I needed to research it and do some reading. My quick review of Seam only skimmed the surface. What I found is that Seam and Java PureFaces are indeed very different, but that there are also some interesting overlaps. Here is a little of what I found:

  • Scope:
    • JPF: Java PureFaces is a presentation tier API allowing for the simple creation of object oriented, java-based views. It is not for business-tier logic. That is performed elsewhere in the application. Java PureFaces does, however, allow simple integration of the presentation-tier with the business-tier since you are able to access absolutely any object in the system directly in a purefaces component (see The magic behind Java PureFaces). It also allows any business logic class to handle its own purefaces presentation through the implementation of the PureComponent interface.
    • Seam: Seam, on the other hand, is an application framework that does not handle presentation-tier. It leaves that to some other JSF-based technology, such as Java PureFaces.
  • Beans:

    Java PureFaces uses only a single JSP page tied to a single bean. As seen in The magic behind Java PureFaces, absolutely any object property or method in the system can be access directly by view components, and there is no need to continuously update the faces-config.xml file. Seam has a version of this object access simplification called bijection. It allows the developer to add an annotation to any object and then access that object directly from the view (also without defining the bean in the faces-config.xml file). Because Seam does not handle the view, it needs to resolve dependencies each time a component is invoked in order to maintain state.

    The major difference between Seam and Java PureFaces here is that :

    • In JPF, stateful POJO’s contain the code to create the view directly. When the view is needed, the components are pulled from the POJO and placed into the JSP page. Because the components are pulled each time, they always represent the current state of the object. Actions from the new view can then directly affect that object’s state, changing it for the next view update. An example of this is shown in Java PureFaces – Clean & Simple HTML Output. The example in the linked post shows a method from a POJO used to create the view. It is easy to see how the current state of the object is woven directly into the view.
    • In Seam, the JSP view pulls data from the application as it is rendered, and the view has no state, so Seam handles the maintenance of state. Seam bijection creates a method for exposing beans to the view for both the simplification of development and the maintaining of state.
  • Navigation:
    • JPF: Java PureFaces eliminates the need to create and maintain hardcoded XML navigation rules; only a single JSP page is necessary and all navigation is handled in Java (the topic of a future post).
    • Seam: Seam also allows the developer to avoid static XML by letting action listener methods return the JSF view id as the outcome.
  • Presentation tier:
    • JPF: Java PureFaces is a layer on JSF specifically intended to be used for simplifying view creation by moving away from static template files and into Java.
    • Seam: The presentation tier for Seam can be any technology that supports JSF (per the articles I read, I understand it is branching out to other technologies also). Java PureFaces could be used as the presentation layer for a Seam implementation.


While Seam and JPF are two completely different frameworks, intended for two different parts of the application, there are similarities that are worth noting. JPF implementations could benefit from Seam’s additions that solve issues such as using the browser back-button and bookmarking – presentation-related topics that are out of reach for the framework. The Seam framework could become even more streamlined and simplified by using JPF as its presentation layer – eliminating additional static template files and possibly simplifying bijection even more.

This was a very quick look at Seam and how it is related to JPF. It is an interesting mix that hopefully we can take a deeper look at in the future.