Difference between Mojarra and MyFaces

Why do I need more jars if I use MyFaces?

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

Noted should be that since Mojarra 2.1.6 a single JAR file format is available as javax.faces.jar which is since Mojarra 2.3.9 renamed to jakarta.faces.jar.

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.

Since JSF 2.0, which came with new partial state saving management, MyFaces was performance wise the better choice due to a different and much more efficient approach of calculating state deltas, particularly when using large component trees. Mojarra caught up only since version 2.1.22. During the 2.0/2.1 timeline, Mojarra had only serious issues with <ui:repeat> in complex/nested compositions (a.o. broken state saving, processing only last iterated form, failed <f:ajax>, etc) and with flash scope implementation (initial implementation was totally not bullet proof). MyFaces also had its own set of bugs, but they were manageable.

Right now, with JSF 2.2, 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.

Also the download page is indeed JSF Mojarra?

Their homepage has been moved around several times. Currently (Nov 2019) it's located at https://eclipse-ee4j.github.io/mojarra. You can find the libraries in org.glassfish:jakarta.faces in Maven Central too. You can find the source code in eclipse-ee4j/mojarra project in GitHub.

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.

UPDATE MAY 2012: 2.1.0: 47, 2.1.1: 6, 2.1.2: 84, 2.1.3: 9, 2.1.4: 74, 2.1.5: 7, 2.1.6: 35, 2.1.7: 52

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!. UPDATE MAY 2012 An improved algorithm was done inside MyFaces Core that reduce the state size even in parts when facelets is used to update the component tree dynamically. This param is no longer necessary.
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.

UPDATE MAY 2012

See this article 10 reason why choose MyFaces Core as JSF implementation for web applications

For the guys who want to see a performance comparison betwen MyFaces, Mojarra and Wicket look Understanding JSF 2 and Wicket: Performance Comparison

UPDATE JULY 2013

The comparison was extended to include other frameworks like Spring MVC, Tapestry, Grails 2 and Wicket. See the article at JSFCentral : Update JUL 2013 at JSFCentral

Difference between Mojarra and MyFaces

See also:

Tags:

Jsf

Jsf 2

Myfaces

Mojarra

Related

Recent Posts