Wednesday, February 29, 2012

mojarra or myfaces

Why do I need more jars if I use MyFaces?

Because those dependencies are not bundled in MyFaces. On the other hand, if you're using other libraries from Apache.org which also use those dependencies, then you ultimately end up with smaller total size libraries.


Should I prefer Mojarra as lighter

This is a non-argument. You should look at how robust and well maintained the JSF implementation is.

The grandfather of Mojarra, Sun JSF RI 1.0, and the early versions of RI 1.1 were cluttered by nasty bugs. At that moment (around 2004-2006), MyFaces was definitely the more stable alternative.

Since 1.1_02 and 1.2_02 around early 2006 the new Sun/Oracle JSF dev team did great work. Not only with bugfixing, but also with performance enhancements. About halfway the Mojarra 1.2 lifetime (around 2007-2009), Mojarra was the better choice than MyFaces.

Right now, with Mojarra 2.0/2.1, one can't really say beforehand which one is better. Bugs often expose only later and robustness can only be evaluated during the aftermath. Just pick whatever implementation you "feel" is the best. Browse through their issue reports (MyFaces and Mojarra) to learn about the previously fixed issues and the currently open issues. If you encounter a specific bug, try with both implementations to exclude the one and other. Report if necessary to keep the overall quality of the both implementations high.


At first view, both JSF implementations (MyFaces and Mojarra) do the same, because they are based on the same standard. The fact that you can change from one implementation to other is a fact of the quality of JSF standard spec.

But on the bottom there is a lot of reasons why MyFaces Core 2.x is better than Mojarra. Note I'm a committer of MyFaces project, so I'll give you here just my point of view:

  • A lot of issues has been fixed. Only in 2.0.x branch from 2.0.0-alpha to 2.0.7 it has been closed 835 issues. This gives a "raw" measure of how many contributions and feedback has been provided by the community over the time. This is the numbers for closed issues over the time: 2.0.0-alpha: 274, 2.0.0-beta: 58, 2.0.0-beta-2: 41, 2.0.0-beta-3: 39, 2.0.0: 51, 2.0.1: 148, 2.0.2: 77, 2.0.3: 63, 2.0.4: 23, 2.0.5: 27, 2.0.6: 29, 2.0.7: 5.

  • Community over code: MyFaces community counts with a lot of folks with outstanding knowledge on JSF. Suscribe to user and dev mailing list are the best way to know what's going on, receive feedback and know other people interested in JSF. See MyFaces Mailing Lists

  • Apache is well known to take everything from Sun/Oracle and make it better. In this case, MyFaces Core has some cool optimizations over partial state saving, composite components and much more!.

  • MyFaces Core is OSGi friendly. It provides some SPI interfaces to deal with special setups, when you need more control over classloading.

  • MyFaces Core has better compatibility with facelets 1.1.x!. Just set org.apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config param to true, and a special mode will be activated. No c:if tags or c:forEach or ui:include broken anymore!.

  • MyFaces has other projects (Trinidad, Tobago, Tomahawk, ExtVal, CODI, Orchestra, PortletBridge RI, ....) that helps keep code tune up, because all those projects test against MyFaces Core, and if there is a bug, it is handled more quickly.

  • You can checkout using svn and build easily any MyFaces project, because all of them maven based and most IDEs provides maven support.

  • Mojarra at the current time (JUN 2011) has some nasty bugs related to state saving, that MyFaces does not have because its implementation is completely different. In fact, MyFaces partial state saving algorithm offers better compatibility with JSF 1.2 state saving than Mojarra. But note Mojarra guys are working on that, but fix that will take them months, even years.

  • Innovation happens on MyFaces.


    I recently started a JSF 2.0 project using Myfaces and Primefaces. Last week, to investigate a bug, I tried to run it on Mojarra. All it took was exchanging the JARs and removing Myfaces-specific entries in web.xml - and everything worked without any problems. Admittedly this was a prototype that doesn't use all of the JSF functionality, but I was quite impressed by this demonstration of compatibility via standards compliance.

    Why do I need more jars if I use MyFaces?

    • myfaces-impl and myfaces-api JARs are the equivalent of Mojarra's jsf-impl and jsf-api.
    • myfaces-bundle contains both of these for convenience, you need either this or the other two, not all three.
    • commons-* are libraries that contain useful basic functionality for dealing with collections, Java beans, etc. that one would otherwise have to reimplement (probably slower and with more bugs). Many other projects use these as well.

5 comments:

Juan Carlos said...

Excellent post! I just had doubts about that, I used Mojarra, and efectivelly, it has a lot of bugs.

Juan Carlos said...
This comment has been removed by the author.
Anonymous said...

i advice you not to copy-and paste people's ideas and articles. this is completely fraud article from stackoverflow.
you make the IT awful.
please respect the etiquette and leave being miserable...

Anonymous said...

DONT COPY PASTE FROM STACKOVERFLOW LOSER!

Anonymous said...


Greetings, nice webpage you've got presently.