MojarraとMyFacesの違い
私はリファレンスとしてチュートリアルを使用したJSF2.0から始めていますが、次の質問があります：
チュートリアルでは2つのライブラリのみを使用しました：jsf-api.jar、jsf-impl.jar（ただしJSTLもありました）Mojarra Projectから。
私もそれらをダウンロードしようとしましたが、サイトに到達できないようです。そのため、Apache MyFacesを使用しましたが、サンプルを実行するには8つのjar（commons-*、myfaces-*）。
MyFacesを使用する場合、なぜもっと多くのjarファイルが必要なのですか？軽いものとしてモジャラを好むべきですか？また、ダウンロードページは確かに JSF Mojarra ？
ありがとう
MyFacesを使用する場合、なぜもっと多くのjarファイルが必要なのですか？
それらのcommons-*依存関係はMyFacesにバンドルされていません。一方、Apache.orgの他のライブラリを使用している場合、これらのライブラリも使用しますcommons-*依存関係の場合、最終的にはライブラリの合計サイズが小さくなります。
Mojarra 2.1.6以降の単一のJARファイル形式javax.faces.jar 利用可能です。
より軽いモジャラを好むべきか
これは引数ではありません。 JSF実装の堅牢性と適切なメンテナンスを確認する必要があります。
Mojarraの祖父、Sun JSF RI 1.0、およびRI 1.1の初期バージョンは、厄介なバグで散らかっていました。その瞬間（2004年から2006年頃）、MyFacesは間違いなくより安定した選択肢でした。
2006年初頭の1.1_02および1.2_02以降、新しいSun/Oracle JSF開発チームは素晴らしい仕事をしました。バグ修正だけでなく、パフォーマンスの強化も行います。 Mojarra 1.2の寿命のほぼ中間（2007年から2009年頃）に、MojarraはMyFacesよりも優れた選択肢でした。
新しい部分的な状態保存管理に付属するJSF 2.0以降、MyFacesは、特に大きなコンポーネントツリーを使用する場合に、状態デルタを計算する異なるはるかに効率的なアプローチのため、パフォーマンス面でより良い選択でした。 Mojarraは、バージョン 2.1.22 以降にのみ追いつきました。 2.0/2.1のタイムラインでは、Mojarraには <ui:repeat> 複合/ネストされたコンポジション（壊れた状態の保存、最後の反復形式のみの処理、失敗した<f:ajax>など）および flash scope implementation （最初の実装は完全に防弾ではありませんでした）。 MyFacesにも独自のバグがありましたが、それらは管理しやすいものでした。
現在、JSF 2.2では、どちらが優れているかを事前に言うことはできません。多くの場合、バグは後でしか公開されず、堅牢性は余波の間にしか評価できません。あなたが「感じている」実装が何であれ、それを選ぶだけです。問題レポート（ MyFaces および Mojarra ）を参照して、以前に修正された問題と現在未解決の問題について学習します。特定のバグが発生した場合は、両方の実装を試して、一方と他方を除外してください。必要に応じて報告し、両方の実装の全体的な品質を高く保ちます。
また、ダウンロードページは確かに JSF Mojarra ？
彼らのホームページは何度か移動されました。現在（2017年9月）は https://javaserverfaces.github.io にあります。ライブラリは org.glassfish:javax.faces Maven Centralで も。ソースコードは javaserverfaces/mojarra GitHubのプロジェクト 。インストール手順は README.md あそこ。
こちらもご覧ください：
答えは私のブログから来ています。
http://lu4242.blogspot.com/2011/06/10-reason-why-choose-myfaces-core-as.htmlhttp://lu4242.blogspot.com/ 2012/05/understandingjsf-2-and-wicket.html
2013年7月更新：JSFCentralの一連の記事と2013年の更新を参照してください。
http://www.jsfcentral.com/articles/understanding_jsf_performance_3.html
最初に見ると、両方のJSF実装（MyFacesとMojarra）は同じことを行います。同じ標準に基づいているからです。ある実装から別の実装に変更できるという事実は、JSF標準仕様の品質の事実です。
しかし、一番下には、MyFaces Core 2.xがMojarraよりも優れている理由がたくさんあります。注：私はMyFacesプロジェクトのコミッターであるため、ここで私の視点のみを示します。
- 多くの問題が修正されました。 2.0.0-alphaから2.0.7への2.0.xブランチでのみ、835の問題が解決されました。これにより、一定期間にコミュニティから提供された貢献とフィードバックの数の「生の」尺度が得られます。これは、期間中に解決された問題の数値です：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。
2012年5月更新： 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
コードよりもコミュニティ：MyFacesコミュニティは、JSFに関して卓越した知識を持つ多くの人々と関係があります。ユーザーと開発者のメーリングリストへの登録は、何が起こっているのかを知り、フィードバックを受け取り、JSFに興味がある他の人々を知るための最良の方法です。 MyFacesメーリングリスト を参照してください
Apacheは、Sun/Oracleからすべてを取得して改善することでよく知られています。この場合、MyFaces Coreには、部分的な状態の保存、複合コンポーネントなど、いくつかの優れた最適化があります！.
MyFaces CoreはOSGiに対応しています。クラスロードをさらに制御する必要がある場合、特別な設定を処理するためのSPIインターフェイスを提供します。
MyFaces Coreには、facelets 1.1.x！との互換性があります。 org.Apache.myfaces.REFRESH_TRANSIENT_BUILD_ON_PSS web config paramをtrueに設定するだけで、特別なモードが有効になります。 c：ifタグまたはc：forEachまたはui：includeはもう壊れていません！ PDATE MAY 2012コンポーネントツリーを動的に更新するためにfaceletが使用される場合、パーツでも状態サイズを縮小する改良されたアルゴリズムがMyFaces Core内で行われました。このパラメーターは不要になりました。
MyFacesには他のプロジェクト（トリニダード、トバゴ、トマホーク、ExtVal、CODI、オーケストラ、PortletBridge RIなど）があります。これらのプロジェクトはすべてMyFaces Coreに対してテストを行うため、バグがある場合は、より迅速に処理されました。
Svnを使用してチェックアウトし、MyFacesプロジェクトを簡単にビルドできます。これらはすべてMavenベースであり、ほとんどのIDEがMavenサポートを提供しているためです。
現在（2011年6月）のMojarraには、状態の保存に関連するいくつかの厄介なバグがありますが、MyFacesには実装が完全に異なるため、バグがありません。実際、MyFacesの部分状態保存アルゴリズムは、MojarraよりもJSF 1.2状態保存との互換性が優れています。しかし、Mojarraのメンバーはそれに取り組んでいますが、修正するには数ヶ月、さらには数年かかることに注意してください。
MyFacesでイノベーションが起こります。
2012年5月更新
この記事を参照してください WebアプリケーションのJSF実装としてMyFaces Coreを選択する10の理由
MyFaces、Mojarra、およびWicketのパフォーマンス比較を表示したい人のために JSF 2とWicketの理解：パフォーマンス比較
2013年7月更新
この比較は、Spring MVC、Tapestry、Grails 2、Wicketなどの他のフレームワークを含むように拡張されました。 JSFCentralの記事を参照してください。 JSFCentralでJUL 2013を更新
私はそれは本当に重要ではないと言うでしょう。
私は最近、MyfacesとPrimefacesを使用してJSF 2.0プロジェクトを開始しました。先週、バグを調査するために、Mojarraで実行しようとしました。必要なのは、JARの交換とweb.xmlのMyfaces固有のエントリの削除だけで、すべてが問題なく機能しました。確かに、これはすべてのJSF機能を使用するわけではないプロトタイプでしたが、標準への準拠による互換性のこのデモには非常に感銘を受けました。
MyFacesを使用する場合、なぜもっと多くのjarファイルが必要なのですか？
- myfaces-implおよびmyfaces-api JARは、Mojarraのjsf-implおよびjsf-apiと同等です。
- myfaces-bundleには、便宜上これらの両方が含まれています。3つすべてではなく、これまたは他の2つが必要です。
- commons- *は、コレクションを処理するための便利な基本機能を含むライブラリ、Java Beanなど、そうでなければ再実装する必要があります（おそらくより遅く、より多くのバグがあります）。他の多くのプロジェクトはこれらを使用します）同様に。
何か他のことをする理由がない限り、私は一般的にMojarraの実装に固執します。私はNetbeansを使用しているため、GlassFishの下で実行されるMojarraを使用する「デフォルト」プロジェクトセットアップを使用するのが最も簡単です。
最後にMyFacesを使用していました。これは、トマホークを使用することを考えていたためで、同じソースからJSF実装を使用するのが妥当と思われました。ただし、代わりにPrimefacesに切り替えましたが、Mojarraの下では正常に動作します。
現在、JSF-2.0コンポーネントライブラリがオンラインになり、多くの開発が行われているようです。したがって、何か問題が発生した場合に備えて、JSFの実装を学習し、切り替えられるようにする必要があります。
MyFacesに含まれるjarの数が多いのは、単なる参照実装よりも多くの機能があるためです。
which IDE使用していますか？Eclipseを使用している場合、jsf 2.0プロジェクトの作成中にjarがダウンロードされます。これを確認してください。 http://www.icesoft。 org/training/icefaces-self-serve-training.jsf
MojarraとMyFacesには大きな違いはありません。どちらがより安定したバージョンであるかを確認できます。 Baluscが言ったように、MyFacesは最も安定したバージョンです（2005-2006年）。また、多くの人が2.0の後にMojarraを使用し始めました。これは、myfacesと比較して安定しているためです。
Mojarra（2.2.8）で深刻な頭痛の種を抱えていました。以前のフォームの更新による2回目のユーザーインタラクション後にのみ実行されるajaxメソッドなどの奇妙な動作です。すべてがMyFacesで削除されました。