Java Web Application Framework総合　ver2

**デフォルトの名無しさん** · 2013/07/21(日) NY:AN:NY.AN

Java用のWeb Application Frameworkについて語るスレッド

海外では多数のFrameworkがあるのに、日本語の情報は意外と少ない
開発生産性、パフォーマンス、ドキュメントの充実度、安定性、使いやすさなどを
比較しながら、最高のフレームワークを探してみるスレッド

前スレ
http://toro.2ch.net/test/read.cgi/tech/1338707919/

Web Application Framework　のリスト
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

特徴の比較
http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks#Comparison_of_Features

**デフォルトの名無しさん** · 2013/12/11(水) 23:32:27.89

>>181
すれち

**デフォルトの名無しさん** · 2013/12/11(水) 23:34:15.13

MS厨はなぜ粘着するのでしょうか？

**デフォルトの名無しさん** · 2013/12/11(水) 23:45:27.57

ステマ

**デフォルトの名無しさん** · 2013/12/11(水) 23:47:27.13

>>182-183
>>171-176のような無駄レスは文句をいわないくせに
ASP.netの文字が出ると感情的に批判してくるのな

**デフォルトの名無しさん** · 2013/12/11(水) 23:51:42.85

>>185
ここでやってくれ、さようなら
http://toro.2ch.net/test/read.cgi/win/1146488925/

**デフォルトの名無しさん** · 2013/12/11(水) 23:57:24.28

>>186
開発と関係ない板のURLはって馬鹿じゃないの？
少しはJavaの話でもすれば？

**デフォルトの名無しさん** · 2013/12/12(木) 00:06:14.84

すれちに馬鹿といわれちゃった、わーん！！！

**デフォルトの名無しさん** · 2013/12/12(木) 00:07:31.28

ておばちゃんか、しょうがねーな

**デフォルトの名無しさん** · 2013/12/12(木) 10:16:01.45

真性のカスだなｗ

**デフォルトの名無しさん** · 2013/12/15(日) 20:46:37.58

http://news.mynavi.jp/news/2013/12/13/062/index.html
Spring Framework 4.0正式版リリース - Java 8、Java EE 7に対応

**デフォルトの名無しさん** · 2013/12/18(水) 00:19:57.11

すれちだろ

**デフォルトの名無しさん** · 2013/12/18(水) 00:33:41.58

GlassFish使っててJBossへの乗り換えを検討してる所は少ないの？
JerseyMVCとか試そうかと思ってた矢先だったからなぁ

**デフォルトの名無しさん** · 2013/12/20(金) 12:37:54.79

一生プログラマーでいたいならフルスタックとかで楽すればいいよｗ

**デフォルトの名無しさん** · 2013/12/22(日) 00:56:53.89

あんだけ某関係者の人がTomcatはオワコンこれからはGlassFishとかとDisってたのに
いつの間にかGlassFishの方がオワコンになっていたのか。

まあ、今もTomcat使って古いフレームワーク（StrutsとかSAとか）で動かしてる（爆）だからどうでもいいけど。

**デフォルトの名無しさん** · 2013/12/22(日) 02:58:54.87

Java自体が終わりそうだけどね
ライブラリがクソすぎる

**デフォルトの名無しさん** · 2013/12/22(日) 07:51:22.48

>>196そうか残念、さようなら

**デフォルトの名無しさん** · 2013/12/22(日) 08:45:35.32

asp.netが強すぎるからな

**デフォルトの名無しさん** · 2013/12/22(日) 09:49:22.90

>>198
そうか、どうでもいいけど、さようなら

**デフォルトの名無しさん** · 2013/12/22(日) 13:04:11.82

Tomcatは起動が重いんだよな。
Jettyが軽くていい感じなんだけど、Tomcatに比べて日本語情報が少ない感じ。
JDBC使うのに、JNDI周りの情報も少ない。

**デフォルトの名無しさん** · 2013/12/22(日) 17:38:03.86

JBossが最強だろ

**デフォルトの名無しさん** · 2013/12/22(日) 18:44:49.04

ローカル試験で使う分にはWinstoneも軽くて良いですよ。
なにせjarファイル1個で動いて、160kbくらいだし

**デフォルトの名無しさん** · 2013/12/22(日) 20:04:05.19

JSON返すだけとかなら、Netty直利用とかも良いですよ。

まあ、ネタはおいといて、Jetty組み込んででExecutable WAR配布とか、利用側はお手軽で良いな。
Javaでもセルフホストしやすい軽量スタックとか、そっちが流行らないかな～。

**デフォルトの名無しさん** · 2013/12/22(日) 20:05:57.66

組み込みサーバー＋JavaFXは今後の選択肢として大いに有り得るらしい
JAX-RSとCDIが使えないほどの軽量サーバーならちょっと勘弁だが

**デフォルトの名無しさん** · 2013/12/22(日) 20:08:51.41

JAX-RSの実装もCDIの実装も、アプリケーション中に含めて組込サーバーといっしょに配布するで良いじゃん。

**デフォルトの名無しさん** · 2013/12/22(日) 20:25:15.91

JBoss覚えるか。どう考えても最強だわ

**デフォルトの名無しさん** · 2013/12/22(日) 20:39:18.03

jbossって起動に10分掛かるだろ

**デフォルトの名無しさん** · 2013/12/22(日) 20:42:11.68

情弱乙

**デフォルトの名無しさん** · 2013/12/22(日) 20:43:02.29

WildFly

**デフォルトの名無しさん** · 2013/12/22(日) 20:59:18.59

richfacesでイベントを呼び出せない、俺涙

**デフォルトの名無しさん** · 2013/12/22(日) 22:29:12.90

>>209
8.1が出てからだろ

**デフォルトの名無しさん** · 2013/12/23(月) 15:42:07.91

>>209
WildFlyってRHELとFedoraの関係なんだろ？
名前変えられると、テンション下がるわー

**デフォルトの名無しさん** · 2013/12/23(月) 16:25:18.46

>>212
横だけど、間違ってる、名前の問題だけ

**デフォルトの名無しさん** · 2013/12/23(月) 16:31:32.49

むしろASがエンタープライズで使えない誤解すら生んだろうね

**デフォルトの名無しさん** · 2013/12/24(火) 20:16:25.04

JSFで画面作ってる時に、http://java.sun.com/jsf/core ってのを使うけど
これ、primefaceとかrichfacesと何が違うの？

**デフォルトの名無しさん** · 2014/03/10(月) 05:55:51.25

age

**デフォルトの名無しさん** · 2014/03/10(月) 07:39:49.81

3年ニートしてる間にseasar2ってオワコンになってたのかよ
使われなくなるのって開発ストップしたからバグとかセキュリティホールが見つかっても
修正されないからって意味合いが大きいからなん？

**デフォルトの名無しさん** · 2014/03/10(月) 15:24:45.00

作りが悪いからに決まってるじゃん
名前が違うだけのspringだし
独創性がないから宣伝はspringの悪口だけ
目玉のHotDeployはバグバグで動かないのにサクサク開発()

とどめに後発のPlay Frameworkがもっと高い技術力とサポートで
同じようなことしてるからまるで存在意義がない

**デフォルトの名無しさん** · 2014/03/10(月) 18:54:22.97

スプリングググったらver4まで出ててワロタｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
初代スプリング触ったときゴミすぎで2度と触りたくないと思ったけど進化してたんだな

**デフォルトの名無しさん** · 2014/03/10(月) 20:45:17.51

SpringMVC、使いやすいよ。
RESTと親和性高いし。
もうこれ以外使うきしない。

**デフォルトの名無しさん** · 2014/03/10(月) 20:54:36.49

俺はPlayを使うね！！

**デフォルトの名無しさん** · 2014/03/11(火) 02:51:10.09

javaしかやったことないから他の言語のwebアプリ状況がどんなもんか知らんけど
純粋にjava嫌いな層ってフレームワーク多すぎていろんところで開発スタイルバラバラすぎるからじゃねーの
勤勉でもないから触ったことないフレームワーク使ってるとお作法覚えるのもたりーんだよな

**デフォルトの名無しさん** · 2014/03/11(火) 03:14:13.37

>>222
javaやったことなくてそろそろ手を付けようかなと思ってこのスレ見てるけど、
設定含めすべてにおいてめんどくさそうだからじゃね。
もちろんフレームワークの選別とか作法とかも分からないってのはあるが。

**デフォルトの名無しさん** · 2014/03/11(火) 07:23:44.74

めんどくさいというイメージはだいたいStrutsのせい

**デフォルトの名無しさん** · 2014/03/11(火) 07:42:49.43

ASP.NETが神すぎる

**デフォルトの名無しさん** · 2014/03/11(火) 12:51:19.90

型コンバートやバリデーションをコントローラでやって
アノテーションつけまくる最近のスタイルが嫌いだ

**デフォルトの名無しさん** · 2014/03/11(火) 17:07:04.92

Convention over Configurationとかってまだ流行ってんの？

**デフォルトの名無しさん** · 2014/03/11(火) 17:20:32.04

Java言語をマスタしても、フレームワークのお作法覚えないとダメだし
フレームワークも色々で、プロジェクトによっては勉強しなおさないといけないし
言語だけマスタしてた時に比べて、大変だよね。

**デフォルトの名無しさん** · 2014/03/11(火) 17:28:37.61

>>227
Play frameworkは、さほどCoCにこだわってないように見えるね。
ルーティングは、routeファイルに必ず書くし。

**デフォルトの名無しさん** · 2014/03/11(火) 19:30:14.12

>>228
チームで開発するときはアーキテクトさんが更にもう一枚「オレオレフレームワーク」でくるんで使わせるのではないか？

設定ファイル等々にしても集中管理するから末端プログラマが触る機会なんてないはず
プログラマに素のままのフレームワークを使わせるなんて危険すぎるが

**デフォルトの名無しさん** · 2014/03/11(火) 22:35:21.22

一周まわって、フレームワークなしのサーブレットに、必要最低限の機能を持つ基底クラスだけ自分で作って使うのがベストだと思う。

**デフォルトの名無しさん** · 2014/03/11(火) 22:58:08.03

>>230
オレオレ作った場合、プログラマに使い方を説明してる？

**デフォルトの名無しさん** · 2014/03/11(火) 23:54:00.32

>>232
APIドキュメント、サンプルプログラム、コメント付き各種設定ファイルなど一通り揃えて、取り合えずば簡単に動くものを用意
説明用の資料パワポや説明会は必要に応じて。

**デフォルトの名無しさん** · 2014/03/14(金) 00:09:52.72

更新止まったActiveObjectsやBeanKeeperの後継とかなくて
結局JPA + Hibernateに落ち着くのか

**デフォルトの名無しさん** · 2014/03/14(金) 00:16:16.03

Seamってまだ息してんの？ｗ

**デフォルトの名無しさん** · 2014/03/14(金) 03:00:36.47

JAX-RSはフォームデータを渡した場合は@FormParamで受け取るしかない？
Servlet感覚で可変のフォームデータを受け取ってパースしたかったんだけど…

**デフォルトの名無しさん** · 2014/03/15(土) 15:19:19.23

アノテーションもりもりMVCとかO/Rマッパー考えたやつはセンスないな
素直にServletとJDBCで十分じゃまいか

**デフォルトの名無しさん** · 2014/03/15(土) 15:32:33.28

>>237
狂おしいほど同意

**デフォルトの名無しさん** · 2014/03/15(土) 15:33:42.26

servletでmemcached使いたいんですが
MemCachedClient mcc = new MemCachedClient();
mcc.set("name", "Naoki Takezoe");
ってやったあとmccのインスタンスはどこにしまっておけばいいんですか？

**デフォルトの名無しさん** · 2014/03/15(土) 16:16:57.22

>>238
開発者が100人位いるような大規模開発だとどうするの？
皆が勝手にConnection.prepareStatementとかやるわけ？

**デフォルトの名無しさん** · 2014/03/15(土) 16:27:57.63

100人も集めて何作ってるんだよｗ

**デフォルトの名無しさん** · 2014/03/15(土) 16:33:36.62

案件規模とかそういうのはどうでもいいんだけど、
IDEの恩恵に頼って楽してコード書きたいから、そもそも今更自前でSQL書きたいとは思わないな。

あの書きづらい読みづらい、毎回同じような記述するだけのSQL文を構築していく作業って、
なんかこうテキストエディタでコーディングするのが好きな人向けな感じ。
あんなものは、パフォーマンスチューニングが必要になってから、必要最低限だけ書きゃいいのにな。

それにServletとかJDBCみたいなクソ仕様は、二度と触りたくないなｗ
あのあたりは、なんかもうかなりレガシーコードの塊になってしまってて、時代に沿ってない内容になりすぎてる。
インターフェイスの設計に失敗してる箇所が多くて、ラッパー噛まして使うのが前提みたいな状態。

**デフォルトの名無しさん** · 2014/03/15(土) 16:44:35.64

多くて3人くらいだわ

**デフォルトの名無しさん** · 2014/03/15(土) 16:51:05.57

Seasar2はSAStruts+S2JDBC、S2JUnitくらいしか触ってたことないが、
- ドキュメントが総じてクソい、ほぼメンテされてない
- できることが少ないわりに何パターンかあったりして説明が乏しい
- フォームのバリデーションより先に処理を挟みたいなら有志の拡張かフィルター使うしかない
- 設定ファイルを減らすための命名規約の呪いがパッケージを強要したりクラス名を制限したりしてくる
- JPA実装してるけど一部しかサポートしてない
- 自動投入用のテストデータのフォーマットがExcel
- おまけにキモっぽいHotDeployはバグ多すぎ

殆ど良かったイメージが残ってないな。

最近なら、Servlet使うならSpring、使わないならPlayの2択でだいたいなんとかなりそうな気がする。

**デフォルトの名無しさん** · 2014/03/15(土) 16:58:45.19

>>241
大企業の基幹システム開発なら100人規模なんてザラ

**デフォルトの名無しさん** · 2014/03/15(土) 18:28:18.81

>>245
そういう案件だとザラだけど高確率で炎上じゃね
そんなに人使う必要がある時点で発注側にも問題アリだよ

**デフォルトの名無しさん** · 2014/03/15(土) 19:19:45.31

>>246
どんなに大規模な基幹系でも、高々10人、20人程度で開発しきれるはずと申すか？

**デフォルトの名無しさん** · 2014/03/15(土) 19:26:41.17

どんなに大規模でもサブシステムに分割できるはず

**デフォルトの名無しさん** · 2014/03/15(土) 19:30:27.26

サブシステムことに開発標準を作ると申すか？

**デフォルトの名無しさん** · 2014/03/15(土) 19:40:36.57

開発標準とは何かな
そんなもの見たことないけど

**デフォルトの名無しさん** · 2014/03/15(土) 20:11:03.06

RDBでSQLのWHEREを書かないで、KVSみたいに全部javaで書くライブラリを作ってみる
http://ideone.com/4FZZeN

**デフォルトの名無しさん** · 2014/03/15(土) 20:45:31.84

何でみんなそんなにSQLを嫌ってるの？
SQL書けばええやん。

**デフォルトの名無しさん** · 2014/03/15(土) 21:31:07.36

同意。
トラブったときはSQLのほうが圧倒的に楽
昔Hibernateで痛い目にあった。。。

**デフォルトの名無しさん** · 2014/03/15(土) 21:46:03.69

>>241

**デフォルトの名無しさん** · 2014/03/15(土) 22:33:43.53

引用アラシ発見

**デフォルトの名無しさん** · 2014/03/15(土) 22:51:59.47

apacheのdbutilsが程よくJDBCをラップしてくれて好きだった
DBアクセスは自分でSQL書く方が好み
どっちも個人的な好みだから他人には強要しないけど

**デフォルトの名無しさん** · 2014/03/15(土) 22:55:50.30

フレームワーク厨は強要してくるからなー

**デフォルトの名無しさん** · 2014/03/16(日) 00:26:39.56

くだらない問い合わせはORマッパー通した方がくだらない間違いも起こりにくいだろ
複雑な問い合わせだけはSQL直書きするようにすればいいだけやん
目糞鼻糞だけど

**デフォルトの名無しさん** · 2014/03/16(日) 05:05:07.42

SQLで書けば、コード量は多めでも、読解難度は低い。
ORMを駆使すると、コード量は少なめで、読解難度が高くなる。

他人が書いたコードを引き継いだ時に殺意を覚えるのは、後者。
特に、とっくに廃れたORMの場合。

**デフォルトの名無しさん** · 2014/03/16(日) 05:18:27.85

流れるようなインターフェース()の悪口はそこまでだ

ｵﾚｵﾚ色が強いと大変ね

**デフォルトの名無しさん** · 2014/03/16(日) 06:28:50.92

おまえらはORマッパーが出来た背景を少しは調べたほうがいい
2、3人で開発するなら知らんけどそれなりの規模で大量のオナニーSQL文見せられてもかなわんだろ

**デフォルトの名無しさん** · 2014/03/16(日) 06:38:36.02

Oracle使った時SQLは全部ストアドに書くとかやったことあるわ
SELECTのReturnはXML
あれもある意味O/Rマッパーなんだろうか

**デフォルトの名無しさん** · 2014/03/16(日) 09:03:49.32

SQLをまったく意識しなくてよくなるようなまっぱができれば使いたいが

**デフォルトの名無しさん** · 2014/03/16(日) 09:17:10.22

O/Rマッパー黎明期から期待に胸を膨らませて追っかけてきたけど
保守段階までトータルで見ると、少なくとの日本の人月ベースで
コスト計算する業界では見合わないと思ってる。

初期HibernateのHQLなんかも設計思想はものすごく好きだった。
Torque、Castorなんかも試した。Torqueはクラス数が爆発しがちで
仕様がコロコロ変わる案件で地獄をみた。
Cayenneも良かったな。旧NeXT製のEOF(Enterprise Object Framework)
なんかの流れを彷彿とさせる設計は美しかったが、
日本ではマイナーで使える技術者が育たず広がらなかった。

とはいえ、素のJDBC使うのはめんどいし、もはやS2系は死んだ。
個人的に残された希望は枯れたMyBATISくらいかな。
SQLの透過性とシンプルにも使えるO/Rマッピングの融合がバランスいいよ。

**デフォルトの名無しさん** · 2014/03/16(日) 09:28:37.06

業務アプリなんかだと結局メイン部分はパフォーマンスや
堅牢性が大事になってきてSQLで書かないといけない。
まっぱが使えるのはマスタメンテくらいになる。
マスタメンテくらいのSQLなら別に複雑でもないからまっぱにする意味もない。
つまり使い道が無い。パフォーマンスや堅牢性も備えてはじめて使えるようになる。

**デフォルトの名無しさん** · 2014/03/16(日) 09:48:24.48

だよな。複雑なビジネスロジックをオブジェクト操作で
動的にSQL作るような仕組みだと、仕様変更とかバグ修正の場合に
マジックハンドでモノを掴むみたいな感じになるよ。
SQLならものの数分で終わるような対応が丸一日かかったり。

ただ、O/RマッピングとSQLの動的生成は違うものだから
ここは混同しちゃいかんな。
生JDBC使ったって最後はbeanにマッピングされるわけだし。

**デフォルトの名無しさん** · 2014/03/16(日) 10:12:47.25

JPAは再帰処理がないのが不満に思えたが
昨今の大規模環境ってJOIN禁止ルールとかあるみたいだし気にしなくていいのかな？

**デフォルトの名無しさん** · 2014/03/16(日) 17:26:09.65

JOIN禁止ってマジ話？
そんなプロジェクトに放り込まれたらプロマネ殴り倒す自信あるよ

**デフォルトの名無しさん** · 2014/03/16(日) 18:32:30.12

一部のコンシューマーサービスにおける設計の話を一般論扱いされても。
それにむしろ、そういうケースではMicro-ORMだろうし。

**デフォルトの名無しさん** · 2014/03/16(日) 18:53:19.88

指定数表以上の結合禁止、右外部結合禁止は見たことあるが、
結合そのものを禁止しているところは見たことないな。

**デフォルトの名無しさん** · 2014/03/16(日) 19:00:58.43

まあ将来的には結合なんてしなくてよくなるのが理想だよ。
だからまっぱは理想なんだけど今のハードではまだまっぱには無理がある

**デフォルトの名無しさん** · 2014/03/16(日) 19:36:35.66

逆だろ、将来的にはいくら結合しまくっても性能が劣化しないのが理想だよ

**デフォルトの名無しさん** · 2014/03/16(日) 19:41:36.95

結合時の性能劣化がなくなるよりも先にＲＤＢが廃れそうだなｗ

**デフォルトの名無しさん** · 2014/03/16(日) 19:44:29.10

え？結合なんかしたらSQLみたいじゃん

**デフォルトの名無しさん** · 2014/03/16(日) 19:53:56.08

抽象度が高くかつ表現力のあるマッピングAPIが、現状の言語仕様やHW的な限界で現実的ではないという話と、
リレーショナルモデルを相手にする以上、結合を考えないなんて意味がない話だし、本質的に性能劣化は発生する
みたいな話が混在してね？

**デフォルトの名無しさん** · 2014/03/16(日) 23:08:47.31

ソーシャルゲーム業界だと、たいがいJOIN禁止だな
詰めSQLやるようなチューニングはしない
大規模構成のMySQLをmemcachedとあわせてKVS的に使ったりって感じ
大規模にサーバまたいでデータ結合やったりするからJOINなんか使ってたら
保守できなくなる

**デフォルトの名無しさん** · 2014/03/17(月) 03:54:31.81

ORM使いにくいって感じる状況、ORMへの知識不足が原因じゃなけりゃ、
大元のDB設計とかがいまいちだったりする感じのこともけっこうありそうな

そもそも、言うほどパフォーマンスに問題が合ってSQL書かないと行けないような自体って起きるかなぁ
そういうのって、どっかうまいこと作れてないか、
体感できない性能差を突き詰めたいだけでチューニングを行なってる人かのどっちかってことも少なくない気がする

**デフォルトの名無しさん** · 2014/03/18(火) 02:18:31.77

ORMはEager fetch, Lazy fetchの問題を解決不可能なんだよ

**デフォルトの名無しさん** · 2014/03/18(火) 09:36:03.49

>>277
DB設計が大元ってｗ
ORMを理解してないのはお前だろ
ORMを使う動機はドメインモデルをRDBに永続化することなのに
なんでDB設計が先にくるんだよアホかｗｗｗｗ

ていうかみんなわかってなさすぎｗ
テーブルモジュールで設計していながらORM語ってんだろ？ｗｗ

**デフォルトの名無しさん** · 2014/03/18(火) 11:18:48.08

>>279
世の中の全てがモデルファーストでシステムを全て作れるわけではないし(そんなの本当に新規開発だけ)
パフォーマンスのために非正規化したりテーブル設計を崩すこともある

他システム連携があったりすると、そのDBにアクセスしてくるのはJavaだけとは限らない

もうちょっと世の中でいろんな経験をしてごらん。
見えなかったものが見えてくるよ

**デフォルトの名無しさん** · 2014/03/18(火) 16:21:01.00

次の仕事でPlay使うかもしれんとここ数日予習してるんだけどさ、
何か凄いstaticだらけで違和感覚えるんだが、
これはこういうものだと思って慣れるしかないの？
テストとかしずらくね？

工夫すれば一応DI使えるみたいだけど、entity注入するのはそれはそれで変な気もするし…

Java Web Application Framework総合 ver2

Java Web Application Framework総合　ver2