Java Web Application Framework総合　ver2

Java Web Application Framework総合　ver2 at TECH

[前50を表示]
350:デフォルトの名無しさん
14/04/23 21:47:01.86 bQZ6NqwX
例えば、Strutsを避ける
URLﾘﾝｸ(www.scutum.jp)

Struts2は根本的設計がまずかったり今のメンテナにとって
やる気のでないプロダクトだったりって状態なのかねえ
SIerが貢献することもなく使い続けて情報漏洩しまくらないといいが

>>349
JSの話題はここでは返事もらえないと思うよ

351:デフォルトの名無しさん
14/04/24 01:22:07.08 uw+Asd59
node.js使ったサーバーサイド開発やってるのに
未だにJavaとJavaScriptの違いが解らないアホがいるってのが驚きだわ

352:デフォルトの名無しさん
14/04/24 01:26:25.43 FuqK6IF4
>>350
そのエントリ書いた人、StrutsとStruts2は全くの別物だってことと、
Struts2は少なくとも日本じゃポピュラーじゃないってことを知らなさそう

353:デフォルトの名無しさん
14/04/24 22:11:08.66 MRzySO8u
今更?。Struts2は出た当初から致命的な脆弱性がある欠陥品だと言われていたでしょ。
MBSDで暫定的なものであるが、サーブレットフィルタのソースコードを公開したよ。
URLﾘﾝｸ(www.mbsd.jp)

354:デフォルトの名無しさん
14/04/24 22:42:18.68 MRzySO8u
最近、JavaEEやspringMVCからJavascriptへ
トレンドが移行している印象を受けるね。

JavaSE8もあまり話題にならないけど、どうなの?

355:デフォルトの名無しさん
14/04/24 23:17:35.98 cbIcERKc
【IT】サイト構築ソフト・ストラッツ1(Struts 1)に欠陥　パッチなく官公庁などサイバー攻撃の恐れ [4/24]
ｽﾚﾘﾝｸ(newsplus板)

Struts 1.x使っていた時代遅れ企業終了

>>354
その印象を持ったのはどういう理由？
Java開発案件が減ってJSが増えてる？

356:デフォルトの名無しさん
14/04/25 22:40:29.27 FYFW/3hR
>>355
開発案件に影響は出ていないが、技術的な部分が日進月歩なので表面化しつつある。
WebがHTML5に向かう中で、Javaが担う機能を、どこまでJavascriptで
担えるかというところで微妙になってきた。
基幹業務システムをJavascriptで作る時代がきそうだと。

357:デフォルトの名無しさん
14/04/26 10:22:26.71 /UOqj8HA
乱暴に言えば基幹システム＝DBアクセスだから、サーバサイド開発をゼロにするって無理だろ
JavaScriptから直接SQL叩くことを許可するのか？

358:デフォルトの名無しさん
14/04/26 12:23:42.67 lOzkg/HI
>>357
クライアントではなくてサーバーサイドJavascriptの話をしているのだから
それ的外れな指摘だよ

>>356
Javascriptって、もともとDOM(xml/html)を操作して
画面UIを操作するためにあるような、それくらいしか能がない言語でしょ。
サーバーサイドには機能面で非力すぎるし、また独自仕様乱立とか始めるのがオチ。

359:デフォルトの名無しさん
14/04/26 14:17:54.62 0Ekcs7fW
>>356
＞基幹業務システムをJavascriptで作る時代がきそうだと

これは絶対に来ない
もし基幹業務をJSで作ったとしたら大バカ企業

動的言語は大規模開発だと開発生産性が落ちる。
このデメリットが大きいからFacebookなどもPHPを
静的言語に魔改造しようとしてきた。

JavaがゴミみたいなWebフレームワークしかないのに
大規模サイトで使われてきたのは、静的言語で、
ライセンスが比較的自由だからだろう

360:デフォルトの名無しさん
14/04/26 14:50:52.36 9olkSe8L
サーバーサイドJavaScriptといえばIBMがこういう記事出してるな。
URLﾘﾝｸ(www.ibm.com)
それにIBMのBlueMixなんかは基幹系開発も用途に含むPaaS環境だけど
node.jsやRubyも対象にしてる。

まぁ日本のイントラ基幹系は業界的にも従事する人間の考え方的にも
頭が硬くて柔軟性に欠けるから、node.jsベースの開発なんて無理だろうけど
B2CとかのエンドユーザーがコンシューマーだったらサーバーサイドJavaScriptは
ぼちぼち盛り上がってるんじゃね。

JDK1.0が出た当時だって、動きのあるホームページ作るものでしょ的な
イメージばかりで将来まさかJavaがビジネス基幹系に使われるように
なるなんて誰も想像しなかったわけで。

静的型付けができないとか型推論とか言語仕様的にはJavaScriptそのものは
いろいろ欠点あるけど、CoffeeScript/TypeScript/HaxeとかのAltJSを使えば解決できる。

361:デフォルトの名無しさん
14/04/26 16:46:48.48 Gh1hsEgS
JavaScriptもこんな流行るとは思わんかったよ

362:デフォルトの名無しさん
14/04/26 17:49:10.55 A9kxPHhN
現状ではpaypalの開発が代表的かな。
URLﾘﾝｸ(www.infoq.com)

363:デフォルトの名無しさん
14/04/26 20:18:05.95 lOzkg/HI
node.jsでサーバー書くより
ブラウザでjavaなりc#が動いてくれたほうがよっぽどありがたい

364:デフォルトの名無しさん
14/04/26 21:29:20.02 ro7ZL/nR
>>357-358
SQLではないけどAWSのDynamoDBはブラウザのJSから直接アクセスするための機能が
既に備わってるからあながちあり得ないって事はない

URLﾘﾝｸ(aws.typepad.com)

セキュリティ的には現在のアプリサーバのように一つの権限で全ユーザの情報に
アクセスしてる方がリスクが高いという考え方もできなくはないしね

>>360
そうそう、世紀末くらいまではJavaに対しても>>359みたいな意見が普通だったよね
OSでいえばLinuxもそうだし、その前はWindows、更に前はUnixも基幹系では
使えないって意見が多数派だった
ハードでもPC(x86)サーバもUNIX(RISC)サーバも最初は同じ
それでも使う人達がでてくることでいずれ使えるようになってく
繰り返される歴史からはJSで基幹系作る日が来ないとはとても言えない
個人的に作りたいかどうかは別の話だがw

>>362
世界規模の決済系で使われてるってのは実績としてでかいよね

>>363
Dartがブラウザに乗れば一応それらに近いんじゃないかな

365:デフォルトの名無しさん
14/04/26 21:42:46.56 ro7ZL/nR
あと動的言語かどうかはもちろん、生産性も基幹系で使うかどうかにはたいして影響ないよ
今基幹系で使われてる言語でもCやCOBOLは弱い片付けの言語だし生産性も高くない
それよりベンダのサポートとか人の集めやすさとか世界中で使われてる実績とか
技術とは無関係なところで決まりやすい(それを肯定したいわけじゃないが現実としてね)

366:デフォルトの名無しさん
14/04/26 22:40:13.33 0Ekcs7fW
>>365
大規模開発での静的言語の優位性を否定するとかありえないわ

それとベンダサポートが重要なのはそのとおりだが
人気のある静的言語ほど大手のベンダーが関与してる割合が高い
C#もJavaもそう

動的言語はコンパイラ開発不要で個人レベルでも
作れるからOSSで言語が乱立する
頻繁に不要な仕様変更が入りメンテナンスコストが高くなる
開発生産性というのはバージョンアップなどのコストも含めての話

367:デフォルトの名無しさん
14/04/26 23:26:36.12 ro7ZL/nR
>>366
優位性を否定してるんじゃなくて、その優位性が重要な要素とはならないって言ってる
まぁ、スレ違い気味だしわかれとはいわんよ

368:デフォルトの名無しさん
14/04/27 00:08:06.48 TaRvNbvP
>>363
silverlightやアプレットやってた人間からすると、それは絶対やだ。

369:デフォルトの名無しさん
14/04/27 01:25:17.57 iHo3u08N
動的言語ってchar1単位で操作したりするの向いてないだろ
もうjavascriptを使うこと自体が目的化してるんじゃないか？

370:デフォルトの名無しさん
14/04/27 01:33:26.98 BDQFGh+O
>もうjavascriptを使うこと自体が目的化してるんじゃないか？

フロントエンド系やってる連中は、そんなことを目的にしてたら
デスマーチの深淵に落ちていくことくらいよく解ってるよ。
あいつらはいかに楽をするか自動化をするかってところが目的になってる。

「結果的」にブラウザ上でJavaScriptを動かすために
ローカルPCに仮想環境突っ込んでvagrant, chef, yoemanとかで
環境作って裏ではRubyが動いてたりもうカオス。
でもこの環境構築自体も今やコマンド一発とかそんな世界。

一部分では下手なサーバサイド開発よりも楽できる世界が構築されつつあるが
Webアニメーションとかやってる連中は相変わらず死んでるな。
Androidという魔物に挑んで力尽きていくやつらの亡骸が山積みだ。

371:デフォルトの名無しさん
14/04/27 01:43:14.20 ldpp9/Fe
そもそもweb系でバイト単位の操作をすることはそんなに無い。
仮にそういうのを意識しないといけないことがあっても大体ライブラリでカバーできてるし。

372:デフォルトの名無しさん
14/04/27 11:56:19.52 DSVMBd2h
サーバ側でjavascriptを使うことがメルヘンなのだろう

373:デフォルトの名無しさん
14/04/27 20:26:48.25 iHo3u08N
>>371
アプリケーション層で自由度の低い言語ってありえないだろ
構文解析コンテンツとか作れないじゃん

javascriptはかなり貧弱だから
頻繁に他の言語で実装されたプラグイン呼ぶことになる

そもそもjavascript自体が嫌われているのに
UI層と同じ言語を使いたいという動機だけではデメリットのほうが多いよ

374:デフォルトの名無しさん
14/04/27 20:36:30.94 Y7/VjSrw
Google Apps scriptとか技術的にどこまで応用されるのか
見極めないといけないね。

375:デフォルトの名無しさん
14/04/27 21:28:19.68 ldpp9/Fe
>>373
node.jsだとバイナリデータも扱うこともできるみたいだし、自由度が低いってことは無いと思う。
というか自由度を求めるんなら極端な話Cで全部書けばいいんじゃね？
用途とか目的とかコストとか考えた時、自由度はある程度切り捨てられるものだ。

サーバーサイドでnode.jsやらを使う利点は、学習コストが極端に低いこと。
なんせweb系やるならjavascriptはほぼ必須だから。

とはいえjavascriptで組みたくないってのは同意。

376:デフォルトの名無しさん
14/04/27 22:23:43.64 BDQFGh+O
TypeScriptいいよ

377:デフォルトの名無しさん
14/04/28 09:43:29.05 iyQuG+yT
altJS系の動きも、JSをサーバサイドで使うことより
もっと大規模開発に向いた言語でフロントエンドやりたいって人が多いと思う
結果的に1言語で十分になるならいいことかもしれんが

378:デフォルトの名無しさん
14/04/28 14:01:38.33 xn2yHDgI
ポストJSはDartが一番良さそうだけど（Javaのブラウザ用サブセット同然）
IEのシェアが圧倒的だから、googleの思惑通りにブラウザから
直に動かす言語としては普及させられない

代わりにMSがTypeScriptあたりをごり押しで普及させてくれれば良いのだが
あそこは相変わらず意味不明なことばかりに力を入れているな

379:デフォルトの名無しさん
14/04/29 02:57:59.13 ZSDL+puO
CoffeeScript, TypeScriptを仕事で使ってみて
結局素のJavaScriptとjQueryに戻ってしまった

380:デフォルトの名無しさん
14/04/29 12:31:30.66 97SzX9yM
今のWebはごちゃごちゃ流行りものをやりすぎなんだよとしか言いようがないな。
大体どれも3年後、5年後には失笑されるような技術ばかり。

実験プロジェクト的なものがこの世に存在する意義はあると思うけど、
それらの拙速な製品への適用はほんと愚かだよ。

381:デフォルトの名無しさん
14/04/30 03:20:47.67 2d6NgZQo
ファッションやら家電に車とかで、今これがすごい！流行りはこれ！
みたいにブームを作って商売するのがこの界隈にも増えただけだと思うわ。
HTML5なんかまさにそれだと思う。
需要喚起って意味では良いのかもしれんが完全に手段が目的になってる気がする。
金稼げないと飯は食えんけどさ。

382:デフォルトの名無しさん
14/04/30 03:30:41.63 kmUIe8Mk
Javaだってそうだったじゃん
Jakartaとかから次々と流行り物が出てきてJavaWorldなんかで特集されてみんなおっかけてたじゃん
Strutsだってそうやって流行ったものじゃん

383:デフォルトの名無しさん
14/04/30 06:38:09.24 EevbxBHK
Javaも含めて言ってるんだろ

384:デフォルトの名無しさん
14/04/30 08:39:19.02 cWCT2Qaf
土台となるjavascriptちゃんとしてればいいけど
phpがjavaの後追いしてるのと同じ不毛さを感じる

385:デフォルトの名無しさん
14/04/30 09:10:41.01 3K+DNrAY
例の脆弱性で、ようやくStruts1からの脱却が進みそうですな。

周りの人に聞いてみると、JavaEEが次のフレームワークのファーストチョイスっぽいね。理由は「標準」だかららしい。それじゃOracleの思う壺ですけどね（笑）

OpenSSLの事もあり、OSSのソフトウェアをなるべく避ける風潮が何と無く社内にあり、開発がやり辛くなりそう。

386:デフォルトの名無しさん
14/04/30 10:10:27.63 jTcbfh7J
今はJavaEEかSpringの2択のところが多いな。

387:デフォルトの名無しさん
14/04/30 14:39:09.69 lR7rpqex
NEC製のオレオレフレームワーク使わされそう
ググったらオープンソースのフレームワーク組み合わせただけの糞なんだけど
これをIDEとして売り物にしてるっぽい。独自開発環境なんて開発工数減らすどころか増やすだけだろ
マジあほ

388:デフォルトの名無しさん
14/04/30 17:48:30.62 pr7iIx2Z
その手の国産オレオレフレームワークって
たいていなんかの開発案件で使われたものを
「これ、ヨコ展開して製品化しよう！」とかって
上層部が思いついて出来上がる気がする

変にオープンソースをベースにしてたりするから
無駄な初期学習コストが出ちゃうのと何かあった場合に
コミュニティが蓄積してきたノウハウが使えなかったりして困る

389:デフォルトの名無しさん
14/05/04 07:10:20.23 q7rdqljv
JAVAをつかったWEBアプリを作りたいなとおもっています。

JAVA標準Java EE 6で、JSF2.0を使えば楽にできるものなのかなとおもっています。
ASP.NETのUIコンポーネントモデルと似ているそうです。

今のところ、JSF（Java Server Faces）の話がないのはなぜですか。
JFS 1.Xは不安定らしいが、2は良いらしい。
URLﾘﾝｸ(gihyo.jp)

なにかアドバイスがあればください。お願いします。

390:デフォルトの名無しさん
14/05/04 09:48:13.90 qC+tt7X6
>>389
サンプル作って比べるなり評価すればいいじゃん。
JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

391:デフォルトの名無しさん
14/05/04 09:55:34.05 q7rdqljv
>JSFについてはJSFがやらなかったか、Java EE自体はやらなかったのため。

いや、このスレッドで、話が出ていないんすよ。
ctrl + f →JFS

392:デフォルトの名無しさん
14/05/04 13:32:46.94 l8XNhl16
以前にＪＳＦの専用スレが立っていたはず。過去ログ探してみ

393:デフォルトの名無しさん
14/05/04 13:36:42.43 l8XNhl16
あとWebProg板に関連しそうなスレが立っている。

Java EE part1
ｽﾚﾘﾝｸ(php板)

394:デフォルトの名無しさん
14/05/04 13:51:40.57 bN/4cHLX
JSF2.0でprimefaces使うと確かに
簡単に結構リッチな画面が作れそう

ただJSFは仕組み上
サーバリソース食うんで利用者が多いような
サイトには向かない気がする

EE6だと
JAX-RSとjavascriptか
JSF2.0で画面作るんだと思う

前者は大変だがユーザー数だとか作り込む上で制約が少ない
後者はサクッと作れるが制約が多い

といったイメージ
間違ってたらごめん

395:デフォルトの名無しさん
14/05/04 14:11:11.21 kb+QPMa3
>>391
JSF2 は、ジェット戦闘機の時代に登場した、最強のレシプロ戦闘機っていう感じですかね。

JSF2 は、サーバ側で HTML を作る、Struts、JSF1、Tapestry、Wicket... などの旧来型の
Webアプリの集大成。
でも時代は、クライアントサイドで MVC が完結して、サーバーサイドは API に特化する
という方式に移りつつある。

移行コストが問題。従来型の Web アプリでいいなら、Servlet + JSP の延長線上にある
Spring MVC でいいかとなるし、どうせ新しいことを覚えなきゃいけないなら、
ExtJS + Rest API でやろうかねとなる。

396:デフォルトの名無しさん
14/05/04 14:50:26.51 vh5L8gE2
JSFって、戻るボタン押したらログイン画面に飛ばされる奴？

397:デフォルトの名無しさん
14/05/04 15:09:02.38 tBke0zkk
以前SIerで企業や官公庁向けのWebアプリ開発の仕事してて
今はコンシューマ向けWebサービスの開発してるんだけど
SIerはほんと進歩が無いんだなと感じる。
もっとも、常に「枯れた（安定してる）技術」が重要視される
業界だから、進歩させる必要はないのかもしれないけど
開発者にとってはつまらないんじゃないか。

世間では叩かれまくってるソシャゲ屋なんかは、使ってる
要素技術や仕組み的にはけっこう最先端が多い。
どんどん新しいものを取り込んで実装していく。
不安定なものもあれば、すぐに廃れていくものだったりするんで
これはこれでリスキーだけど、サービス寿命は短いから
これでもいいんだろう。

398:デフォルトの名無しさん
14/05/04 23:26:27.01 +PT15341
>>391
JSF 21レス/396レス
だが

399:デフォルトの名無しさん
14/05/05 01:30:48.46 wGBQOVTp
結局ここでJSFやらJavaEEもおっけーってことかな

スクリプトゴリゴリ書きたくないから
個人的にはJSF2に頑張って欲しい

400:デフォルトの名無しさん
14/05/05 01:34:42.59 uhwl8tdd
>>397
業務アプリにとっての「技術」は目的ではなく手段に過ぎないからな
目的が達成できるならレガシーな技術で十分
先端追いかけてくれる人たちがいるお陰で、周回遅れで安定した(枯れた)技術を採用できるとも思ってる
確かに技術屋には魅力はないだろうが、そういうもんだろう

401:デフォルトの名無しさん
14/05/05 02:57:09.05 wGBQOVTp
>>400

最新の技術に拘る訳じゃないが
新しい方が品質、生産性が高い場合もあるんじゃないかなぁ
学習コストっての問題はあるが・・・

402:デフォルトの名無しさん
14/05/05 03:20:29.45 uhwl8tdd
>>401
あると思う。
でも数多ある新技術がすべて宣伝通りのレベルに達しているかと言うと、期待はずれの技術もまた多いわけで
その辺はイノベーターさんやアーリーアダプターさん達の成果に頼ることになる

403:デフォルトの名無しさん
14/05/05 10:46:41.45 XYbGwOBG
JavaでいうとServlet+JSP以外信用できない
フレームワークは穴だらけ
新しいものは信用できない

404:デフォルトの名無しさん
14/05/05 16:22:20.74 eHaIsNXX
struts普及しすぎたせいで未だにstruts使ってるところ多い感じだ
ドヤ顔で独自フレームワーク開発してますとかほざいたくせにベースにstrutsとか寝ぼけてんのかよ

405:デフォルトの名無しさん
14/05/05 23:41:08.23 wGBQOVTp
strutsは普及しすぎたが故の脆弱性問題かね
OpenSSLといいIEといいこの手の話最近多いけど
他が安全っつうよりはマイナーなだけな感じ

ただオレオレFWが結局同じ問題を抱えてて
各々対処しないといかんのはダサいね

じゃあjavaEEなのかと言うとよくわからない
標準といえど旧EJBのような失敗作もあるし

406:デフォルトの名無しさん
14/05/05 23:55:41.61 qgaxSqth
フレームワークは使ってるってだけでドヤ顔できるかな

407:デフォルトの名無しさん
14/05/06 00:36:47.39 /KCtgeyk
>>400
日本で業務系アプリやってる奴らは
周回遅れどころか10年以上遅れてるだろう
リリース後に1年もたてば十分に安定した技術になる。

ただ時代遅れで新しい技術についていけていないだけなのに
「枯れている」などという言葉で正当化しようとする

フレームワークの有り無しを論じていたり、Strutsがどうこうとか
日本だけ時間が15年くらい止まっている感じだな

408:デフォルトの名無しさん
14/05/06 01:51:30.39 HbPu7+SF
>>407
どうした？業務アプリに親でも殺されたのか？

409:デフォルトの名無しさん
14/05/06 10:04:43.41 p+pOalwe
企業の場合、フレームワークにノウハウを詰め込んでる場合が多いから、土台が古くなってもなかなか変えられない。
下手に変えるとエラい目に会うからな。

410:デフォルトの名無しさん
14/05/06 10:11:07.39 mq0PWr6n
＞strutsは普及しすぎたが故の脆弱性問題かね
JSP系統全体の脆弱性じゃないの

Velocityとかで同じようなことは大丈夫なのかな

411:デフォルトの名無しさん
14/05/06 12:34:59.61 ifeVOml8
OGNLとかBeanUtilsとか個別の要素のバグや仕様だから同じことしてたら問題はある

412:デフォルトの名無しさん
14/05/06 15:00:56.09 q8o8j/Sw
欧米だと、業務系アプリでもどんどん新しい技術採用してるのにな
バックエンドはSpring+MySQLやnode.js+MariaDB、フロントはHTML5ベースで
backbone.jsやAngularJSにしてREST-APIで繋ぎ、サブシステム連携も充分とかさ

413:デフォルトの名無しさん
14/05/08 20:14:41.32 QhqRiqXw
>>393
プログラムとWebプログラミングとで板が分かれていたの知りませんでした。

>>394
JSF2.0は、MSのASP.NETみたいにできるそうです。
でも、MSはサービス運用でライセンスにお金が絡んで自由に使えないのでそんな技術は使いたくありません。
未来に自由をもたらすために、javaで行きます。

LAN内向けサービスなら使えそうですね。
リソースの問題も、今後JSFのバージョンがあがっていくにつれて改善されることを期待します。

>>395 >>399
>JSF2 は、... などの旧来型のWebアプリの集大成
今やJDKの標準技術になっているんですよね。

>JSF2に頑張って欲しい
同感です。

>クライアントサイドで MVC が完結して、サーバーサイドは API に特化するという方式に移りつつある。
余計に処理の流れが複雑になりそう・・
サーバの負担は軽くなりそうですね。

JFS2.0の書籍を大型の本屋に探しに行きましたが、一冊だけでした。
掌田津耶乃「EclipseではじめるJavaフレームワーク入門　第4版」が
JFS2.0を使ったプログラム例と詳細な解説が載ってました。

これ以外に、どうして売っていないのか不思議です。　（JFS2.0は、JDKの標準技術なのに。）
オイラリーのは、JSF1.0を対象に書かれていたので、対象外です。2004年初版でした。

414:デフォルトの名無しさん
14/05/08 21:30:25.66 +3i6oIvP
asp.netもasp.net MVCっていうサーブレットチックなものが主流になってる。

asp.netもjsfも柔軟性にかける割に生産性もそこまで高くないんだよね

415:デフォルトの名無しさん
14/05/08 22:39:57.36 2SfqCKIX
生産性が低いとは思わないけど、まあ、ぎょーむ屋さんがつまんねーLOBアプリをシコシコ作るの専用感はある。

416:デフォルトの名無しさん
14/05/09 04:23:02.68 q6CZdclC
Struts2+Spring DIでStruts2のActionにDIするWebアプリケーションを作ってる。
このアプリの実行時に、DIされるべきフィールドがnullになっててヌルポが発生することがある。
アプリをコンパイルしなおしたらヌルポが発生する場所が毎回変わったりするので原因がよく
わからない。

Tomcatが利用できるメモリ容量を増やしたらヌルポが発生しなかったので、DIに必要な
メモリが足りないのが原因かと思ったんだが、そういうことってありうるのかしら？
みんなTomcatのメモリ容量はどのぐらいにしてる？

417:デフォルトの名無しさん
14/05/09 04:36:52.76 zfIj6OAD
>>414
asp.net MVCがサーブレットと同類のわけないだろ
お決まりの処理は最小限のコードで書ける
ASP.net MVCの生産性の方が圧倒的に上

>>413
掌田津耶乃の本はやめておけ
いろんな言語のフレームワークの本を書いているがどれも評価低い
内容が薄っぺらい、同著者のamazon レビューを見たほうがいい

＞これ以外に、どうして売っていないのか不思議です。

理由はJavaの技術は定番がなく分散してるから
膨大な時間をかけて本を書いても売れない、儲からない
日本語で書いたら日本人しか買わない
どうしても本で学びたければ英語で書かれたものを探したほうがいい

418:デフォルトの名無しさん
14/05/09 04:41:29.70 zfIj6OAD
>>416
いまさらStrutsとは

ヌルポにメモリが関係あるわけないだろ
物理メモリが足りなければ、HDD/SSDなどの仮想メモリが使われる

419:デフォルトの名無しさん
14/05/09 05:03:29.99 q6CZdclC
>>418
うん、おれもStruts使いたくない。

やっぱ関係ないか。再現条件（ヌルポの発生場所）がころころ変わるんで悩んでる。
DIされるべきところがnullになるケースってなんかない？

420:デフォルトの名無しさん
14/05/09 08:34:54.37 EM0RixeL
Spring使ってるのになぜStruts?しかも2とかありえねぇ。
馬鹿なの？アホなの？死ぬの？

SpringMVC使えよ。

421:デフォルトの名無しさん
14/05/09 08:58:40.41 E3wsUlgH
決定権無ければそれでやるしかないよね

422:デフォルトの名無しさん
14/05/09 15:31:47.07 dvOOVkmX
決定権がある人間が無能だと
こうやって現場が疲弊する見本だな

中途半端に要素技術を聞きかじってると
こうなるよな

423:デフォルトの名無しさん
14/05/09 16:52:51.17 vziOY5Cd
>>419 OutOfMemoryErrorをどっかで揉み消してるとか
>>418 PermGen上限を緩めてないなんてのはありがち

424:デフォルトの名無しさん
14/05/10 09:12:05.20 1Do2eZKO
>>420-422
お察しのとおり、途中から参加したプロジェクトなんで変えようがない。
Spring使うならSpringMVC使え、はもっともなんだろね。

>>423
MaxPermSizeを大きくするとヌルポが起きないので、そこかなーと思ってる。
OutOfMemoryErrorのもみ消しはしてないと思う。

425:デフォルトの名無しさん
14/05/10 11:23:10.80 gSo5tcfL
やっぱTomcat使ってるとこ多いよね

javaEE にするならTomEEでいいかな？

426:デフォルトの名無しさん
14/05/10 11:50:16.02 ZoW/vxHI
Tomcatで十分だろ。意味わからん
オレオレアーキテクトのオレオレフレームとオレオレコンテナとか誰得だよ

427:デフォルトの名無しさん
14/05/10 12:57:17.13 2YlfM5m7
趣味ならなんでもおｋ

428:デフォルトの名無しさん
14/05/10 13:05:01.57 ++ojgnt3
将来が有望なWEBアプリのフレームワークって？

JFS2を推したいのだが・・・

他の技術では、HTMLを噛むのでコードが煩雑になりはしないかと躊躇する

429:デフォルトの名無しさん
14/05/10 16:08:55.06 ReRBG8qB
HTMLをサーバ側で作ってレスポンスに送り出すのか
サーバからは必要な情報だけJSONとかで取得して
ブラウザ側でDOM生成するかで何を使うかが変わってくるな

HTML自体の修正が必要な場合は、個人的好みとしては
後者のほうが修正から反映までの手間が少なくて好きだ。
サーバ側でやると、サーバ側もデプロイしなおしとかあるし

430:デフォルトの名無しさん
14/05/10 16:18:20.94 lrUbXucJ
最近は後者な流れじゃない？

431:デフォルトの名無しさん
14/05/10 16:19:03.56 6O8ipEn6
こいつ一昔前までseasar2押してたタイプだ

432:デフォルトの名無しさん
14/05/11 15:40:23.86 CQcMSGFV
>>429
>ブラウザ側でDOM生成する

せっかく、ASP.NETは、サーバー側で要求を受け付けて処理してHTMLを出力するうまい方法（抽象化されたサーバコントロール）を、
実現していたのに（JFS2みたいに）、今からはブラウザ側がHTMLを自分で作成するのですか。

ブラウザ側でHTMLをコントロールするタイプなら、
何が推しですか？

そういうタイプWEBアプリって、サーバーは基本的なプログラムとデータをクライアントに提供して、
クライアントがその基本的なプログラムを処理することで適切なHTMLを自分で組み立てる感じでしょうか。

433:デフォルトの名無しさん
14/05/11 15:55:27.33 moCMHB5P
>>432
ブラウザ側でいろいろやるのは別に良い方法というわけじゃないよ

ただJavaの世界ではサーバサイドのフレームワークが
ろくでもないものばかりだから、そういう開発をやる人が出てきただけ

ASP.netやASP.net MVCに比べると開発に時間もかかるし
ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
セキュリティも低下する

434:デフォルトの名無しさん
14/05/11 20:28:02.82 UwOOPA9c
>ASP.netやASP.net MVCに比べると開発に時間もかかるし
>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

いまどきの大手SIerって、こういう時代遅れタイプで占められてるんだよな
だからStruts1が幅を効かせてきたわけだ

435:デフォルトの名無しさん
14/05/12 00:07:44.85 wroz7708
>>433
>ただJavaの世界ではサーバサイドのフレームワークがろくでもないものばかりだから
>（ブラウザ側でいろいろやる）そういう開発をやる人が出てきただけ

結局は、消極的な理由なんですか。

近年のクライアントのパワーが上がってきたことと、
サーバーの負担を減らすために、クライアントサイドでhtml構成作業を行うようになったのだと思っていた。
あと、ポストバックをなくすために。

>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>セキュリティも低下する

ブラウザ環境で意図した動作をしないというのは困りものだな。

うーむ。
だったら、サーバーサイドのフレームワークとして、JFS2.xに期待するなあ。
なんだって、JDKの標準機能に組み入れられたのでしょ。
JFS2には将来性があると思う。

436:デフォルトの名無しさん
14/05/12 00:09:39.92 wroz7708
>>417
>理由はJavaの技術は定番がなく分散してるから
>膨大な時間をかけて本を書いても売れない、儲からない
>どうしても本で学びたければ英語で書かれたものを探したほうがいい

JAVAって、いろいろ分散していて、いったい何が標準なのかぜんぜんわからないですものね。
JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
今後は、日本語で書かれた書籍も増えてくるかもしれないですね。

ほんと、期待しています。

ASP.NETはいいんだけど、運用保守にお金がお金がかかるかかる。ライセンス問題が非常にやっかい。
MSのご機嫌取りしなきゃいけなくなる。アプリの運用を人質にされて、MSに振り回されるのは勘弁。
なので、ASP.NETは将来を見越したら、取り組みたくないんだなあ。

437:デフォルトの名無しさん
14/05/12 00:23:29.96 f+OP7VZY
>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。

一応、そのあたりの差異を吸収することも目的の一部に含むのが
jQueryのようなJSのフレームワークなわけで
サーバーサイドの人間は何かというとJSを目の敵にするけど
どちらも使えたほうが、この先業界内で生き残っていける確率は上がるでしょ

企業的には「フルスタックエンジニア」なんて名前の便利屋や何でも屋を
求めるようになってきてるし。

438:デフォルトの名無しさん
14/05/12 00:40:16.62 h1G1q1Ck
どうでもいいが「JFS」じゃなくて「JSF」な
JavaServer Faces（JavaとServerの間は空けないのがお約束）

439:デフォルトの名無しさん
14/05/12 00:42:07.47 wroz7708
>フルスタックエンジニア

それでも、htmlやJAVA SCRIPTを触らなくても良い、高度に抽象化された一元的プログラミングをしたい・・・

440:デフォルトの名無しさん
14/05/12 00:43:03.15 wroz7708
>>438
ありがとう

441:デフォルトの名無しさん
14/05/12 01:00:32.81 KacrXp1d
>>ブラウザのバージョンがあがるとJSがエラー起こして動かなくなる
>>セキュリティも低下する
>
>ブラウザ環境で意図した動作をしないというのは困りものだな。
というかバージョン変わったりブラウザが変わったりすると動作しなくなる可能性があるのはJAVAでも同じことだと思うけど違うの？

442:デフォルトの名無しさん
14/05/12 01:14:18.80 /hsNV+iO
>>441
Webアプリでクライアント側のJREは使わないでしょ
サーバサイドでJavaだから、サーバ側のアップグレードしなければ
バージョンアップのエラーは出ない

ブラウザ側でJSを多用するWebアプリは、ユーザのブラウザの種類や
バージョンに依存するようになってしまう

これはJSじゃなくてHTML/CSSの互換性の話だけど
XP時代にIE6用に設計した業務システムを作ってしまい、
悲惨な目にあった企業はたくさんあるのは有名な話。
OSのアップグレードやPCのリプレースもできなくなった。

クライアントブラウザの指定がしやすい業務システムであっても
なるべくサーバサイドでやるほうがあとあと問題は出にくいと思うよ

443:デフォルトの名無しさん
14/05/12 01:20:14.46 /hsNV+iO
>>442補足しておくと
ブラウザバージョンアップでレイアウトの崩れ程度は起こる可能性は
どの技術でもありうるけど、ブラウザ側でJSを使わなければ
エラー吐くような事態にはならないから新バージョンへの対応もしやすいということ

DartはもうIE9のサポートを打ち切ったらしい
ブラウザのバージョンアップですぐに動かなくなるようではだめだ
DartはJavaScriptに変換する言語ね

444:デフォルトの名無しさん
14/05/12 01:27:57.76 KacrXp1d
>>442
ちょっとよく分からない。
サーバーサイドですべて出力するにしろ、ブラウザで動作するものを作るわけだよね？
JREで動作させるものじゃないとすると、結果はHTML出力とかになると思う。
だったらブラウザが新しくなったら動作しなくなるとかあるんじゃないの？

445:444
14/05/12 01:30:28.95 KacrXp1d
>>443
見てなかった済まない。
しかし昔の業務用アプリならともかく、最近のものでJavascriptを一切使わないってありえないと思うんだけどな。

446:デフォルトの名無しさん
14/05/12 01:41:02.37 h1G1q1Ck
>>445
このスレは昔ながらの業務アプリしか作らなくて済んでる化石のようなエンジニアの巣窟なの

447:>>53
14/05/12 01:47:49.33 iJz1i67B
サーバー側で要求を受け付けて処理してHTMLを出力する方式は
wicketでもjsfでもセッション多用でレプリケーションの同期が多発
Playがセッション使わせたくないのもこの辺が原因でしょ

448:デフォルトの名無しさん
14/05/12 02:04:03.42 /hsNV+iO
>>445
一切使わないなんて言ってないんだけどな
>>442でも「なるべくサーバサイドでやる」とはそういう意味だ

>>446
業務アプリでJSが必須の機能少ないけどな
どういう機能か言ってみなよ

ユーザデータチェックのValidationではJS使うけど
業務アプリでJSでしか実現できない機能を求められることは少ない

449:デフォルトの名無しさん
14/05/12 03:22:01.12 KacrXp1d
>>448
いやまあそれ言っちゃうとJSのほうだってなるべくHTMLは書くようになると思うよ。
JSが受け持つ範囲は多くなるけど。
全てのデザインをJSで組むっていうのはまずありえないかなと。HTMLで書くほうが早いし簡単だし。

あと>>446への返信に横入り。
「業務アプリ」で「最低限の機能」しか求められることが少ないって書いてあるけど、それって反論じゃなくて、
書いていることに対して認めているように見えるけど良いの？

450:デフォルトの名無しさん
14/05/12 10:18:24.45 NL4i9DSa
そもそも業務アプリなんかWebでやりたくねぇわ

451:デフォルトの名無しさん
14/05/12 10:37:30.53 GdHpjeGh
>>436

> JFS2.0が、ASP.NETのようなサーバーサイド技術のJAVA標準なのだから、
> 今後は、日本語で書かれた書籍も増えてくるかもしれないですね。
>
> ほんと、期待しています。

JSFが何年も前の1のころからJ2EE (いまで言うJavaEE)の標準になっていたが、結局流行らなかった。

流行るものは、結局標準化どうかではなく、そのプロダクトが使いやすいか(いいものか)どうかなんだよ。

452:デフォルトの名無しさん
14/05/12 12:03:24.64 3xPUgV6E
標準だとしてもOracleだぜ？
何だかんだ言ってもMSの方がマシだろ

453:デフォルトの名無しさん
14/05/12 17:15:35.33 YqgznOAd
すれち

454:デフォルトの名無しさん
14/05/13 22:10:38.32 QItZX2Cn
酷い製造現場に入っちまったわ
少なくとも6年以上は前のフレームワークを使って色々やってるんだが
雛型作り上げるまでのプロセスがむちゃくちゃ

455:デフォルトの名無しさん
14/05/14 02:03:31.02 B2iG6znP
6年前って2008年か… マシな方じゃね？
10年前のJ2EEで止まってる方が酷いと思うわ

456:デフォルトの名無しさん
14/05/17 00:35:29.68 PXPFtWqe
技術の蓄積が云々でStruts1

457:デフォルトの名無しさん
14/05/17 02:08:09.45 C6+8ucAK
Struts1内臓の自社製フレームワークだ

458:デフォルトの名無しさん
14/05/24 10:45:14.85 zWM8Vigu
URLﾘﾝｸ(zeroturnaround.com)

459:デフォルトの名無しさん
14/05/24 18:26:53.21 qfxUsSTH
GWTとかVaadinって意外と使われているのね
Vaadinはそのうち開発頓挫しそうな空気だけど

460:デフォルトの名無しさん
14/05/25 20:03:15.10 gGsDT7q8
結論：Flexでおｋ

461:デフォルトの名無しさん
14/05/28 00:27:43.53 9OS265q7
GWTが流行るか、javascriptがdartに進化するべきだった
半端なJSフレームワーク乱立とか糞すぎる

462:デフォルトの名無しさん
14/05/28 03:27:10.38 1YkJU2y3
なんかもう

フロントコントローラ　：　Jersey + 好みのDIコンテナ
テンプレートエンジン　：　お好み（Thymeleafがよさげ）
DB　：　スクラッチ、ヘルパーライブラリ、ORMお好み
フロントエンド　：　軽量のMVCFWお好みで

こんな感じでいいような気がしてきた（想像）
上手く設計できれば結構いい感じにできそう（想像）

今はWebはPythonとかLL中心でアプリはAndroidやってるからJava資産活用できるしWebもJavaでやりたいって
上に言ってはいるけどなかなか通らない。

463:デフォルトの名無しさん
14/05/28 06:46:29.77 sLOdIin8
ウチはWebはJavaかASP.NETでしかやらせてくれない
物凄く簡単なのでもJava

めんどくさい

464:デフォルトの名無しさん
14/05/29 10:16:48.53 bCwfT6SY
>>461
その通りなんだけど、世の中全体としては、
もっと JSフレームワークが乱立して、みんなで右往左往する流れになってるからな・・・
30代後半になったけど、JSの流れにはついて行けなくなった。

jquery を覚えるだけでも精一杯（管理職業務も増えてきてなかなか開発できなくなったってのもあるけど）