Difference between Mojarra and MyFaces

I am starting on JSF2.0 I used a tutorial as a reference but I have the following question:

The tutorial used 2 libs only: jsf-api.jar, jsf-impl.jar (but also had JSTL) from Mojarra Project.

I tried to dowload them also but seems the site is not reachable. So I used Apache MyFaces but to run the example I had to add 8 jars (commons-*, myfaces-*).
Why do I need more jars if I use MyFaces? Should I prefer Mojarra as lighter? Also the download page is indeed JSF Mojarra?

Thanks

Solution 1:

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.

See also:

• What are the main disadvantages of Java Server Faces 2.0?
• What is the difference between JSF implementations and component libraries

Solution 2:

The answer comes from my blog:

http://lu4242.blogspot.com/2011/06/10-reason-why-choose-myfaces-core-as.html http://lu4242.blogspot.com/2012/05/understandingjsf-2-and-wicket.html

UPDATE JULY 2013: See the series of articles and the update for 2013 at JSFCentral:

http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html

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.

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

Solution 3:

I'd say that it really does not matter.

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.