Javaを使用して独自のWebサイトを作成することを検討しており、使用するフレームワークを決定しようとしています。ただし、Javaフレームワークをすばやく検索すると、50を超える選択肢が返されます。
私のウェブサイトは、最初は自分で構築することを楽しむためのものですが、人気が出てきたら、ある程度のスケーラビリティを備えているか、少なくともそのために再設計できるとよいでしょう。
より人気のあるフレームワークの主な違いは何ですか？1つが他を大幅に上回っている場合はありますか？たとえば、トラフィックの多いエンタープライズアプリケーションとトラフィックの少ない小規模アプリケーション。また、他のものよりも習得と使用がはるかに簡単なものがあるかどうか疑問に思っています。
これらのフレームワークのいくつかの経験があり、推奨できる人はいますか？膨大な数の選択肢は、可能な場合はJavaベースのWeb開発を回避するための早期警告として機能しますか？
回答:
私が使ってきたタペストリー3、自動改札、エコー、およびJSFをかなり広範囲に。私はあなたがそれらを見て、あなたにとって最も簡単に見えるものを選び、あなたが好む仕事のやり方に最もよく合うものを選ぶことを本当にお勧めします。
それらの中で、コンポーネント構築の軽量性とページテンプレートの単純さのために、私が最も快適に作業できるのはWicketでした。これは二重になります。Hibernateやその他のフレームワークの代わりに独自のdbコードを使用している場合（WicketHibernateまたはSpringIntegrationに完全に満足することはありませんでした）。
すべてのレイアウトをJavaで記述してもかまわない場合は、Echoが最適です。今は違うと思いますが、それでもかなり狭いニッチな製品だと思います。彼らは、メジャーリリースごとに開発モデルを変更しているようです。
タペストリーは素晴らしい製品ですが、主に1人の人物が主導するため、開発モデルの点で他の製品とは明らかに大きく異なります。ハワードルイスシップは間違いなく非常に賢いですが、基本的に各リリースとの下位互換性を忘れるという彼らの決定には失望しています。繰り返しになりますが、あなたのニーズにはこれは問題ではないかもしれません、そして私はいつもタペストリー製品がうまく機能するのを見つけました。
JSFは何年も前から出回っていますが、Strutsのすべての問題を解決するためにStrutsの人が作ったもののように感じています。Strutsのすべての問題を実際に理解することなく。製品は明らかに非常に柔軟性がありますが、それはまだ未完成の感触を持っています。私はそれを使用し、それをある程度気に入っており、その将来に大きな期待を寄せています。JEE6で提供される次のリリース（2.0）は、新しいテンプレート構文（Faceletsと同様）と簡素化されたコンポーネントモデル（1つのファイルのみのカスタムコンポーネント...最終的に）で、実際にそれを独自のものにするだろうと思います。
そしてもちろん、独自のフォローを得る100万の小さなフレームワークとツールがあります（基本的なニーズのためのVelocity、生のJSP、Strutsなど）。しかし、私は一般的にコンポーネント指向のフレームワークを好みます。
最後に、Tapestry、Wicket、およびJSFを見て、自分に最も適したものを選択することをお勧めします。あなたはおそらくあなたが非常に速く働きたい方法にぴったり合うものを見つけるでしょう。
私のお気に入りはSpringFrameworkです。2.5 Spring MVCは、新しいアノテーション、設定より規約などを備えた、すごいキックアスです。
非常に単純なことをしているだけの場合は、フレームワークを気にせずに、通常のサーブレットAPIを使用してみることもできます。
コンポーネント指向のWicketフレームワークをお勧めします。これにより、WebアプリケーションをプレーンオールドJavaコードで記述でき、すべてのコンポーネントのモデルとしてPOJOを使用でき、巨大なXML構成ファイルをいじくり回す必要がありません。
Wicketを発見し、Webアプリケーションの開発がいかに簡単であるかを見たとき、Strutsを使用してオンラインバンキングアプリケーションの開発に成功しました。
最近、StripesFrameworkを使い始めました。本当に使いやすいリクエストベースのフレームワークを探しているが、実行していることに制限を課していない場合は、それを強くお勧めします。
ストラットに似ていますが、それをはるかに超えています。非常に少ない構成でhibernateまたはjpaを使用できるようにするプラグインプロジェクトもいくつかあります。
改札も良いと聞きましたが、良いフレームワークはたくさんありますが、使ったことはありません。
自分で試したことはありませんが、
多くの可能性があります...
phpと古典的なaspから来て、それは私に有望に聞こえる最初のJavaWebフレームワークです....
更新：Tapestry 5.2がリリースされたため、以前のように放棄されていません。私の経験は5ではなくタペストリー4であるため、マイレージは異なる場合があります。タペストリーに対する私の意見は、何年にもわたって変わりました。私はそれを反映するためにこの投稿を変更しました。
以前のようにタペストリーをお勧めすることはできなくなりました。Tapestry 5は大幅な改善のようですが、Tapestryに関する私の主な問題はプラットフォーム自体ではありません。それはその背後にいる人々と一緒です。
歴史的に、Tapestryのすべてのメジャーバージョンの更新は、極端な偏見との下位互換性を壊してきました。これは、大幅な書き直しを必要とする新しいコーディング技術またはテクノロジーが組み込まれているためと思われます。
タペストリーの筆頭著者であるハワード・ルイス・シップは確かに優秀な開発者ですが、タペストリープロジェクトの彼の管理を気にかけているとは言えません。タペストリー5の開発は、タペストリー4が出荷された直後に始まりました。私の知る限り、Shipはそれに専念し、Tapestry4を他の寄稿者の手に委ねました。他の寄稿者はShipほど能力がないと感じています。タペストリー3からタペストリー4への苦痛な切り替えを行った後、私はほとんどすぐに見捨てられたと感じました。
もちろん、Tapestry 5のリリースにより、Tapestry4はレガシー製品になりました。アップグレードパスはとても残酷でなかった場合、私はこれで問題はありません再び。そのため、開発チームはかなりうらやましい立場にあります。本質的に放棄されたWebプラットフォーム（Tapestry 4）を引き続き使用するか、Tapestry 5に凶悪なアップグレードを行うか、Tapestryを完全に放棄して、別のプラットフォームを使用してアプリケーションを書き直すことができます。これらのオプションはどれも非常に魅力的ではありません。
Tapestry 5は、この時点からアップデートが破損する可能性を減らすために作成されたと思われます。良い例はページクラスです。以前の化身では、ページクラスはTapestryによって提供された基本クラスから派生していました。このクラスでの互換性のないAPIの変更は、多数の下位互換性の問題の原因でした。Tapestry 5では、ページはPOJOであり、実行時に注釈を介して「魔法のTapestry fairydust」で拡張されます。アノテーションのコントラクトが維持されている限り、Tapestryへの変更はページクラスに影響しません。
これが正しければ、Tapestry5を使用して新しいアプリケーションを作成するとうまくいく可能性があります。でも個人的には、バーナーに手を当てたくないです。
免責事項：私はVaadin（以前はIT Mill）で働いています
RIAishを実行している場合は、Vaadinを確認することをお勧めします。これはオープンソースのUI指向のAJAXフレームワークであり、私にとっては使いやすいです（私はPHPのバックグラウンドを持っています）。
IcefacesとVaadinで同じアプリケーション（つまり、同じ機能セットを持つ2つのアプリケーション）を実行することを比較するケーススタディがあります。一言で言えば、UI開発はかなり速かったと述べています。
調査は会社のウィキでホストされていますが、私を信じさせることはできませんが、客観的で、本物で、真実であると確信できます。
さまざまなソリューションを長い間テストした後、私にとっては次のようになりました。
プレゼンテーションおよびコントローラーレイヤー用のSpringMVC（ただし、私のフローはajaxに基づいているため、Spring Webflowはありません）
すべてのクライアント側のもののためのjQuery
さて、セキュリティの側面のための春のセキュリティ
Hibernate / JPA2
継続のための桟橋（彗星）
非常に急な学習曲線の1か月ですが、今では満足しています。
また、Javaのすべてをスキップして、代わりにScala / LIFTを学習することから少し離れていたことにも言及したいと思います。私に関する限り、最先端のWeb開発（comet、非同期通信、セキュリティ（はい、Spring Securityでも！））に関連するJavaのすべては、まだ少しハックです（証拠によって私を間違って証明してください、お願いします） ！）。私には、Scala / LIFTはよりすぐに使えるオールインワンソリューションのようです。
私がついにScalaを使わないことに決めた理由は
プロジェクトリーダーとして、私は人的資源を考慮する必要があり、Java開発者はScala開発者よりもはるかに見つけやすいです
私のチームのほとんどの開発者にとって、Scalaの機能的な概念は、それ自体が優れているので、理解するのが難しいです。
乾杯Er
それらのすべて-それが問題です;-)
控えめな要件としては、Tomcatサーバーから提供できるサーブレットまたは単純なjspページをコーディングするだけでよいと思います。個人のWebサイトデータには、ストラットなどのWebフレームワークは必要ないと思います。
「JSFを使用する」と言うのは少し簡単です。JSFを使用する場合は、その上にコンポーネントライブラリを選択する必要があります。MyFaces Tomahawk、Trinidad、Tobago（http://myfaces.apache.org/）を使用しますか？それともICEfaces（http://www.icefaces.org/）？ああ、ICEfacesを使用している場合、ビューにJSPまたはFaceletsを使用しますか？
私の意見では、それを伝えるのは難しいです。少なくとも私が取り組んでいるプロジェクトでは、3か月の評価フェーズを実行するのに十分な大きさではないため、すべての有望な代替案を評価する時間はありません。ただし、大きくて活発なコミュニティがあり、1年も経っていないものを探す必要があります。JSFはしばらくの間存在しますが、太陽に押されるため、もう少し存在するでしょう。それが最良の選択かどうかはわかりませんが、良い選択になるでしょう。
トラフィックの多いサイトの場合、サーバー上のクライアント状態を管理しないフレームワークを使用します。Wicket、JSF、およびTapestryがサーバー上のクライアント状態を管理しています。アプリケーションをデスクトップアプリケーションのようにする必要がある場合にのみ、これらのフレームワークを使用します（Wicketが私のお気に入りです）。しかし、私はもっとスケーラブルでシンプルなREST + AJAXアプローチを使おうと思います。
Spring MVCが候補になりますが、Spring MVC 3以降、静的型付けの利点を使用しない奇妙な注釈オーバーロードプログラミングモデルがあります。通常のリターンと組み合わされたメソッドの出力パラメータのような他の醜いものがあるので、1つのメソッドの2つの出力チャネルがあります。Spring MVCはまた、車輪を再発明する傾向があり、他のフレームワークと比較して構成する必要があります。Spring MVCには素晴らしいアイデアがいくつかありますが、あまりお勧めできません。
Grailsは、SpringMVCやHibernateなどの他の確立されたフレームワークを使用するための便利な方法です。コーディングは楽しく、結果はすぐにわかります。
また、テンプレート用のFreeMarkerのようないくつかの小さなヘルパーを備えたサーブレットAPIは非常に強力であることを忘れないでください。
一部のJavaアプリケーションフレームワークに関するコメントをいくつか参照してください（2番目の段落）。
http://swiss-knife.blogspot.com/2009/11/some-java-application-servers.html
以下のために迅速かつ派手なGUIあなたがJSFを使用することができRichFacesのライブラリ。Richfaces UIコンポーネントは使いやすく、デモサイトのコードデモンストレーションで利用できる便利なリファレンスです。おそらく後で、サイトに処理するデータが多くなり、データベースで多くの情報を処理する必要がある場合は、任意のデータベースアクセスフレームワーク（ORM）をプラグインできます。
誰もGWTについて言及していないとは信じられません
本当にシンプルなアプリを探すための私のお気に入りの方法は、Velosurf（http://velosurf.sourceforge.net）を使用したApache VelocityTools（VelocityLayoutServlet）です。））です。
より複雑なアプリの場合は、SpringMVCまたはStruts2。