/.Jに聞け：Javaを使うメリットは？ 139
ストーリー by hylom
過去の資産もありますし 部門より
過去の資産もありますし 部門より
あるAnonymous Coward 曰く、
当方12年ほどWebアプリをメインに様々なプロジェクトで開発を行ってきましたが、最近は特にサーバサイドにおいてJava（Servlet/JSP）で開発するメリットが見当たらないなと思うこのごろです。
主な理由としては、
- LL言語に比べ、プログラムが冗長になる（例えば、キャスト、正規表現、連想配列処理、文字列フォーマットなど）
- コンパイルするのが面倒
- MVCフレームワークが開発の速度と柔軟性を落とす
- 文字化け
- XMLごり押し傾向
- 文化として変数やメソッドの名前が冗長
などがあります。とにかく全体として何をやるにもアカデミックで冗長で面倒だと思うのはわたしだけでしょうか？
と言うわけで、5年前まではPHPとJSP/Servlet半々で開発してきましたが、今はよほどのことが無い限り使わず、iTextによるPDF帳票作成を残すのみです。皆さんJavaでエンジョイして開発してますでしょうか？
自由度が少ないのがメリットかもね (スコア:4, すばらしい洞察)
Javaはダメなやつでもそれなりに書けるってメリットがある
LLをダメなやつに書かせるともう・・・
同じ単価ならJava屋の方がマシなコード書く気がするね
Re:自由度が少ないのがメリットかもね (スコア:1)
Re:自由度が少ないのがメリットかもね (スコア:1)
Web系はそこまでメモリ管理にシビアな人はいないような気がしてます
#でも言われてみたい
コンパイルが快感 (スコア:3, 興味深い)
静的な型の整合が検証されるとすごく安心してコーディングを継続できる。
Re:コンパイルが快感 (スコア:1)
それを回避するだけでまたコードが長くなり。。。
Re:コンパイルが快感 (スコア:3, 興味深い)
Genericsも(VMを変更しないで対応できるように)単なるシンタックスシュガーでかゆいところに手が届かない。キャストの嵐よりはマシだけど、型変数の記述でますますソースが長ったらしくなる。
Re:コンパイルが快感 (スコア:2)
C#は型推論があるからまだマシだけどね
Re:コンパイルが快感 (スコア:2)
とはいえ、Java8の推論強化されるので、そこに期待したいところ。
M-FalconSky (暑いか寒い)
基幹だとまだまだ (スコア:2)
Javaな感じがしますけどそうでもないんでしょうか？
Re:基幹だとまだまだ (スコア:1)
規模の問題では (スコア:1)
小規模なら使う必要性無いと思う
ある程度以上の規模になると冗長性よりも静的型付けの良さが大きくなる
複数システム間のオブジェクトの受け渡しとか
#VB.NETerだけど
Re:規模の問題では (スコア:2)
既存のクラスでは耐えられなくなり、新しいクラスが次々に出てきてビルドし直し
また実行時にメソッドに投げこまれる（こむ）変数のキャスト、エラー回避などがへヴィーだなと
確かに、変数名のスペル一文字間違ってても通ってしまうのは怖いですが(設定にもよりますが)
適材適所 (スコア:1)
＃ゼロか１００かでしか判断できないの？
Re:適材適所 (スコア:1)
Re:適材適所 (スコア:5, おもしろおかしい)
MLCフラッシュメモリ「1bit電子回路がやられたようだな」
1000Base-T「だが奴は我ら四天王では一番の小物…」
4096QAM装置「0/1しかないとは電子回路の面汚しよ」
アナログ電子回路「とりゃああーーーー！」
代わりがない (スコア:1)
Webには向かないのはほぼ定説で、私も異論はないけど、
例えば今後10年以上使っていく予定の社内の基幹システムを作るのに、Javaに代わる言語はないでしょう。
型があるとかないとかいう問題以前に、10年以上にわたって言語やライブラリの互換性を維持したままサポートが継続されると期待できる言語は他にないです。
（もちろん程度問題です）
・言語仕様が、ライブラリも含めて厳密に定義され文書化されている。
・互換性問題が発生しづらい、シンプルな言語仕様と、平凡で冗長だが安定したライブラリ仕様。
PHPとかRubyとかPythonとか、言語自体が互換性を維持していても、ライブラリやフレームワークの動きが早すぎてどうしようもない。
特に「開発効率が大幅に向上！」系のライブラリは、便利なのは確かだけどインターフェイスの変更が多いですね。
使ってて楽しいけど、これで基幹システムは作れんなあと思う。
Re:代わりがない (スコア:1)
ただJavaも4と6の実行時の互換で、キャストか何かでわかりづらいエラーが出てかなり怒られた覚えがあります。。。
記憶が曖昧で申し訳ない。。。
しかし、バージョン変わった際の違いは、ある程度コンパイルエラーで教えてくれるのはありがたいですね。
意外にPerlなんてその点14年前に書いたのを、最新のサーバに移行しても何の問題も無いものだったりします。基幹システムでは使えませんが。
てか、iTextなんて使って大丈夫か？ (スコア:1)
今のiText、AGPL [wikipedia.org]なんてとんでもなくソース公開義務の範囲が広いライセンスだぞ？
何せWebの閲覧者にもソースコード開示しないといけないんだから。
LGPLかMPLかを選べる旧版を使ってるのかな？
あるいは社内システムならAGPLでもあまり問題ではないと思うが…。
Re:てか、iTextなんて使って大丈夫か？ (スコア:1)
Re:おおよそ同意 (スコア:1)
Re:おおよそ同意 (スコア:1)
それでもあえて、普段の業務経験から聞いてみたかったです。
Re:おおよそ同意 (スコア:1)
あ、Scallaはどうなんだろう。。。
Re:おおよそ同意 (スコア:1)
Re:おおよそ同意 (スコア:1)
Re:Grailsなら何の問題もなし (スコア:1)
Re:何をやるにもアカデミックで冗長で面倒 (スコア:1)
デザインパターンやMVCやXMLによる設定ファイルにこだわりすぎてないかなと。
Re:何をやるにもアカデミックで冗長で面倒 (スコア:1)
デザインパターンを「アカデミック」と言ってるってことは、
ろくにプログラミングをやったことのないド素人ってことだな。
あれこそ実践の中で生まれたベストプラクティス集だろうが。
Re:何をやるにもアカデミックで冗長で面倒 (スコア:1)
売上の追求と仕様変更に追われるうちに、その様な考えになっているのかもしれません。
できれば、デザインパターンを駆使してエレガントに落ち着けたいです。
Re:何をやるにもアカデミックで冗長で面倒 (スコア:1)
> ベストプラクティス
バッドノウハウ集にしか思えない。
Re:何をやるにもアカデミックで冗長で面倒 (スコア:1)
そうでしょうね。アカデミックではないカジュアルな処理系って、悪く言えばその場しのぎのやっつけでもなんとかなるのがいいってことで、形式主義的にしっかり設計してしっかり開発する必要性が無いものをやっつけで作るには最適だからな。
Re:何をやるにもアカデミックで冗長で面倒 (スコア:3, すばらしい洞察)
PHPを使って２～３年で互換性問題ボロボロでるけど、
刷新する予算も時間もなくて死屍累々ってのが現状では。
自分の知ってる所ではそんな感じだった。
一体どこの世界にPHPのバージョンアップに金をジャブジャブ使えるほど
裕福な零細企業があるってんだよ。
＃金も技術もある企業ならどうか？
＃そんな会社は最初からPHPなんて糞言語は使わねえ！
Re:MVCフレームワークが開発の速度と柔軟性を落とす (スコア:1)
xmlゴリ押しというところで私もそう思った。最近はDIとかアノテーションとかのおかげでだいぶマシになった気がしますが、タレコミ者はそれ以前の古いJavaの話をしてる？
＃ といいつつも最近は開発離れちゃって、何が定番フレームワークなのか知らんけど。JSF？SpringMVC？
Re:MVCフレームワークが開発の速度と柔軟性を落とす (スコア:1)
そして、それを取り巻くXML設定ファイルたち
Re:MVCフレームワークが開発の速度と柔軟性を落とす (スコア:1)
XML設定ファイルをゴリゴリ書いているということは、幾分(かなり)古いモノを使っているのだと思うが、そうなると開発の速度と柔軟性に劣るのは是非も無し、といったところか。
Re:MVCフレームワークが開発の速度と柔軟性を落とす (スコア:1)
できればIDE無くても何とかなるのがいいですね。
Eclipseにフレームワークのプラグイン突っ込むのも結構ストレスだったり
Re:そこにJavaがあるから (スコア:1)
Re:漏れ漏れ (スコア:1)
Re:漏れ漏れ (スコア:1)
で、同一パッケージ名乗れば javaの基本パッケージに変なことできそうだなと思ってコード書いてみたら、コンパイラが「このパッケージにはそういうことできません」ていう、あたかもハードコーディングでブロックしているようなエラー吐いてきて萎えた記憶がある。
Re:もっぱら (スコア:1)
Re:もっぱら (スコア:1)
悪くないけど言語仕様がてんこ盛りすぎる。
覚えるのはRubyのほうが楽だが、型安全性と豊富なJavaのライブラリが使えるのはいい。
残念なのはコンパイラがクソ遅い。メモリもやたらと食うし。
Re:もっぱら (スコア:1)
ありがとうございます。一度触ってみます。
Re:もっぱら (スコア:1)
ただやはりMavenなどの環境整備が必要っぽいですね。
詳しく調べてないので違ってたらすみません。
Re:文字化けとか (スコア:1)
ただ、馬鹿な設定でも、相対的に他の言語のほうが問題が少なかったのです。
Re:教育現場でも (スコア:1)
年次が進むごとに先祖がえりするのは、専門分野になるからでしょうか。
Re:文化として変数やメソッドの名前が冗長 (スコア:1)
日本語・マルチバイト変数名とか嫌ですけど、ほぼ英文みたいな変数名もどうかなと
double totalReceivableAmountPerMonth = 0d; // のような
Re:そこで。 (スコア:1)
後は、レンタルサーバが対応してくれるといいですね。
Re:面倒の押し売り (スコア:1)
仕様変更のたびに、既存のクラス設計では耐えられず、新たなクラスが増えていくのも...
Re:Androidアプリ開発者へ転職できる (スコア:1)
Re:JavaEE7ならPHPよりも簡単ですよ (スコア:1)
ただ、JPAについてはPHPの連想配列に読み込むよりも煩雑かなと思ってしまいます。
コンポーネント指向というのはとても惹かれます
ありがとうございます。最近Javaから離れていたので、詳しく調べてみます。
Re:PHPよりは… (スコア:1)
やむ終えず使うのは、AtomやRSSやベンダー独自メッセージぐらいでしょうか
SimpleXMLElementに関してはなぜか型に厳しいｗｗｗｗｗｗｗ