Difference between Mojarra and MyFaces

Question

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

Look

This question is very constructive. – Inseparable

Answer 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

Hoover

balusc - would you mind to update your answer? I've seen you doing work with the mojarra team. Your answer is almost a year old... It would be important to me since my team wants to move a 1000+ pages business application from myfaces 1.2 to JSF 2... I am - lets say -slightly- reluctant knowing how many bugs we had to fix for JSF 1.2 and how long it took us. – Commentate

I don't work for Mojarra. I just use Mojarra extensively and I am an avid bug reporter for Mojarra. I don't see what should be changed. If you were already using MyFaces, just stick to it unless you encounter a heavy MyFaces-specific bug which doesn't manifest in Mojarra. – Hoover

so how buggy does it feel? would you suggest moving from 1.2 to 2? – Commentate

as now (in 2023) we have jackarta faces, Mojarra, and MyFaces updated to version 4 (soon 4.1, then 5)... what are the implementation differences? could you update your answer? – Squarely

Answer 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

Transplant

If you're going to copy and paste content from elsewhere then you need to properly attribute your source. – Gesso

I rollback the edited content, it seems someone trying to make some spam. – Transplant

Why did you roll this back? You've copied and pasted this from someone else's website therefore it needs proper attribution. – Gesso

@Gesso It looks like Kumar's blog is the copy/paste. lu4242's blog and this answer both pre-date it. See the discussion at meta.stackexchange.com/q/169699/1288 – Lindquist

I went with MyFaces exclusively due to the fact that it works with mvn tomcat7:run and tomcat:run (with .xhtml files being editable/refreshable). This was a dealbreaker for my company. – Houppelande

Answer 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.

Alkalinize

Answer 4

I generally stick with the Mojarra implementation unless there is some reason to go with something else. I use Netbeans, so it is easiest to use the "default" project setup which uses Mojarra running under GlassFish.

Last I was using MyFaces, it was because I was thinking of using Tomahawk and it seemed reasonable to use the JSF implementation from the same source. However I have switched to Primefaces instead and that works fine under Mojarra.

Right now there seems to be a lot of development going on with JSF-2.0 component libraries coming online. So you should learn and be able to switch between the JSF implementations in case something goes wrong.

The reason MyFaces has more jars in it is that it has more functionality than just the reference implementation.

Xiphisternum

Answer 5

which IDE you are using? if you are using eclipse then it will download jars while creating jsf 2.0 project. Check this http://www.icesoft.org/training/icefaces-self-serve-training.jsf

Rexfourd

Answer 6

There is not much difference between mojarra and MyFaces. You can to check which one is more stable version. As Balusc has said, MyFaces is the most stable version(in 2005-2006). Also, many people started using the Mojarra after 2.0 because it has become stable compared to the myfaces

Disavowal

Answer 7

I was having serious headaches with mojarra (2.2.8), weird behaviours such as ajax methods only running after the second user interaction due to previous form updates. All gone with MyFaces.

Confusion

Not ranting but honestly trying to get clarification: How do you know it was Mojarra's fault (and which version) and not you doing something wrong where Mojarra rightfully failed and MyFaces is unrightfully accepting something that was against the specs? And what was the error? And did you file bug reports? – Lacewing

Life is too short to submit bug reports (just kidding). Well, i "believe" it's a mojarra bug (couldn't find official bug report though - Only this: https://mcmap.net/q/17394/-h-commandbutton-h-commandlink-does-not-work-on-first-click-works-only-on-second-click). Maybe it has been fixed on versions above 2.3 (I was using 2.2), I should have updated my pom.xml before posting this answer like you suggested. But give me a discount, it was late yesterday and i already wasted 6 hours trying to fix this problem. Gonna test this again later and post an update if i can fix by upgrading mojarra libs. – Confusion

ok, thanks, but keep in mind that 2.2 and 2.3 are jsf api versions. Mojarra is 2.2.0, 2.2.1, 2.3.0 etc... – Lacewing

This is awkward, but i tried to update to the latest version (jun/2017) which is 2.3.2, and... The error persists. Wether it is an error or user (me) screw up, I cant's say for sure... All i know is that the code looks ok. But it doesn't happen with MyFaces so guess i'll have to stick to it. – Confusion

Understandable, but your case should be a new Q with a minimal reproducible example, otherwise it is not very helpful to others (abd we are unable to maybe file a bugreport) – Lacewing