幅広い分野のJavaと名前空間なき脆弱なるPHP
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2006/04/25(火) 01:21:04ID:???まだまだほど遠い。
Javaを越えるには名前空間のサポート、Web以外の分野携帯電話、ドライバ開発、
GUI、COBOLをリプレースできるほどの金融システム、自動販売機、火星探査機
にも使えるようでなくては、PHPには未来はなく、VB同様いつまでたっても馬鹿に
される厨房向け言語に成り下がるであろう。
PHPの仕事は確実に増えているとはいえ、まだまだ、Javaに多い金融システムを
構築するほどの言語としては適していない。アクセス数だけが多い、
はてなダイアリーやmixi、Yahoo程度の小さなプログラムを作ることにしか
向いていないのだ。PHPだけで銀行口座の引き落としや銘柄の注文など
二重引き落としの恐れがありあぶなっかしくてやっていられない。
過去スレ：
【戦場は】PHP王とJava乞食【ｴﾝﾀｰﾌﾟﾗｲｽﾞ】
http://pc8.2ch.net/test/read.cgi/php/1140124172/
【5.1発表】PHP一色 さようならPerl【Javaを凌駕】
http://pc8.2ch.net/test/read.cgi/php/1134820417/l50
【明暗】金持ちPHP様・貧乏Perl様【格差】
http://pc8.2ch.net/test/read.cgi/php/1132681055/
【5.1登場】PHP時代到来 他言語終了【Perl即死】
http://pc8.2ch.net/test/read.cgi/php/1129715894/
優秀な言語が色々ある時代 粗悪PHPの出る幕なし
http://pc8.2ch.net/test/read.cgi/php/1127441561/
今はPHPの時代Perlがこの先生きのこるのは無理3
http://pc8.2ch.net/test/read.cgi/php/1116912721/
これからはPHPの時代Perlはもう終わりバイバイ2
http://pc8.2ch.net/test/read.cgi/php/1046194468/
Perlはもう時代遅れPHPの時代
http://pc2.2ch.net/php/kako/1036/10369/1036915437.html
0516nobodyさん
2006/06/02(金) 21:56:54ID:???0517nobodyさん
2006/06/02(金) 22:17:46ID:???0518nobodyさん
2006/06/02(金) 22:21:33ID:???無責任なデータの扱いしてるってのは設計の問題だろ
「バグが見つけにくい」事はあっても「バグが出やすい」ってことはない
0519nobodyさん
2006/06/02(金) 23:54:51ID:???問題が起こるとしたら>518のいう通り、タコなデータの扱い方してるだけ
0521nobodyさん
2006/06/04(日) 12:27:31ID:???0522nobodyさん
2006/06/04(日) 12:45:14ID:???0523nobodyさん
2006/06/04(日) 14:48:50ID:???Java5 にバージョンアップできず、いつまでも Java 1.x のまま。
COBOL に続いて Java はレガシーシステムの山を築いた。
その失敗から Java5 にも手を出せない。所詮は Sun 手動。
なのでアメリカではコードを自由に変更できる PHP5 に注目が集まっているんだろうね。
0524nobodyさん
2006/06/04(日) 18:38:28ID:???0525nobodyさん
2006/06/04(日) 20:47:56ID:???> Java 1.x のまま
を
> Java 1.4 のまま
に読み替えてやれや。
この文脈で言えば、Java1.xがJava5以前のものを指しているのは明らかだろ。
>>523
>なのでアメリカではコードを自由に変更できる PHP5 に注目が集まっているんだろうね。
これはない。
0526nobodyさん
2006/06/04(日) 21:41:59ID:???0527nobodyさん
2006/06/05(月) 01:00:01ID:???どう見ても拡大解釈です本当にあ(ry
0528nobodyさん
2006/06/05(月) 08:14:22ID:???なんかかっこいいぜ！
0529nobodyさん
2006/06/05(月) 08:14:57ID:???↓
0530nobodyさん
2006/06/05(月) 11:47:28ID:???0531nobodyさん
2006/06/06(火) 00:54:13ID:???0532nobodyさん
2006/06/06(火) 03:02:30ID:???Javaはもうだめぽ・・・
0533nobodyさん
2006/06/06(火) 07:38:08ID:???カスタムタグを使って <c:out ... /> やら <c:forEach ...></c:forEach> と書くことが推奨されている。
どうみてもPHPとは違う方向に進んでいる。それもややこしく難しい方向に。
0534nobodyさん
2006/06/06(火) 08:18:08ID:???まあ変数の再利用がほぼできないから処理は書けないわけだが
0535nobodyさん
2006/06/06(火) 09:11:49ID:???0536nobodyさん
2006/06/06(火) 17:02:20ID:???それは Java5 のダメな部分じゃなかろうか。
enum と generics だけでよかった。
static import とかねじ込んだやつは死ねば良いのに。
0537nobodyさん
2006/06/06(火) 17:24:17ID:???0538nobodyさん
2006/06/06(火) 19:09:08ID:???static importはユーティリティ系のメソッドやヘルパーメソッドをつかうにはすごく便利です。
例えば
public class HtmlHelper {
public static String nl2br(String str) { ... }
public static String escape(String str) { ... }
public static String encode(String url) { ... }
}
とかいうクラスがあったとして、これをstatic importすると、まるでPHPやPerlの関数のような感じで
Webプログラムがかけたりします。
それまではプログラム中でわざわざ「HtmlHelper.encode(url)」と書くか、またはstaticメソッドではなくinstanceメソッドにしたうえで
「HtmlHelper h = new HtmlHelper(); h.encode(url);」と書かなきゃいけなかったから、
static importのおかげでヘルパーメソッドは使いやすくなりました。
こういうことが今までできなかったJavaはうんこだったけど、Java5でちんこぐらいにはなったんじゃないでしょうか。
0539nobodyさん
2006/06/06(火) 20:16:20ID:???頑張れよｳﾝｳﾝ
0540nobodyさん
2006/06/06(火) 21:11:36ID:???0541nobodyさん
2006/06/06(火) 23:47:54ID:???APサーバで動くJavaにたかだかApacheのモジュールでしかないPHPを
比べちゃいけないでしょ。
0542nobodyさん
2006/06/07(水) 02:14:00ID:???0543nobodyさん
2006/06/07(水) 03:36:39ID:???0544nobodyさん
2006/06/07(水) 03:41:19ID:???ハードM＝Java使い
ﾓﾃﾓﾃｶﾞｲ＝PHP使い
世間的にはこんなイメージだよね
0546nobodyさん
2006/06/07(水) 10:14:36ID:???たぶん、APサーバという語彙が頭にないもんだから、専用サーバとか言い出したんでしょう。
なんかここ、PHP厨が必死でJavaをこきおろしてるのね。なんか哀れ。
Javaの欠点をまともに指摘できてないから、余計に哀れっぽさが目立つ。
0548nobodyさん
2006/06/07(水) 11:19:15ID:???Java関連の用語ってテクニカルタームとマーケティング用語が混じってわけわからんし
0549nobodyさん
2006/06/07(水) 11:21:27ID:???皮肉には聞こえんが。。。
まあ元の>>541も言語としてのPHPとmod_PHPをｺﾞｯﾁｬにしてる時点でｱﾚだが
0550nobodyさん
2006/06/07(水) 15:03:36ID:???たかだかApacheのモジュールですむのがいいんじゃないか。
WebサーバはApacheであることがおおいから、それとは別にtomcatとか用意しないといけないJavaのほうがずっと面倒。
でもJava屋はその面倒なのを「エンタープライズだ」とかいって喜んでやるんだよな。わけわからん。
0551nobodyさん
2006/06/07(水) 15:25:06ID:???>> Javaの欠点をまともに指摘できてないから、
指摘しても聞く耳持たないから。。。
ほんとに宗教としか言いようが無い。
> 専用サーバーを用意しないと動かない
>>550が説明してくれてる
0552nobodyさん
2006/06/07(水) 16:17:28ID:???Javaも同じ
Java言語で記述できるバイナリははAPサーバで動くものだけじゃないよ
0553546
2006/06/07(水) 16:33:18ID:???言っても仕方ないから言わない、というのなら、レスをしないというのが普通でしょう。
論理不要で書くのは自己満足に過ぎないし、それを自覚しないのは恥をかいてるのに気づかないこと。
>>543-544のような、相手をなんとか見下そうという態度が、哀れを誘うんですよ。
しかも匿名掲示板という、見下すことで得られる自尊心すら薄い場なので、そんな少しの自尊心の
ために書くのかと思うとなおのこと哀れです。
なお、俺はJava持ち上げる気はないですよ。欠点も少なからずありますから。
ただここのところ、PHP厨の情けないレスが多かったので書いたまでです。
0554nobodyさん
2006/06/07(水) 23:27:09ID:???0555nobodyさん
2006/06/07(水) 23:36:27ID:???0557nobodyさん
2006/06/08(木) 00:43:31ID:???鯖側プログラムでPHPってmod_phpしかないと？
鯖側プログラムでJavaってAPサーバを必要とするものしかないと？
0558nobodyさん
2006/06/08(木) 02:03:11ID:???> 鯖側プログラムでPHPってmod_phpしかないと？
何がありますか？
> 鯖側プログラムでJavaってAPサーバを必要とするものしかないと？
何がありますか？
お願いだからCGIなんて言葉出さないでよ。
0559nobodyさん
2006/06/08(木) 02:19:58ID:???重い処理をこなすにはJavaやPerlの方が優れてるわけだし。
0560nobodyさん
2006/06/08(木) 04:06:30ID:???Javaこわいです（＞＜）
0561nobodyさん
2006/06/08(木) 05:12:23ID:???0565nobodyさん
2006/06/08(木) 13:41:54ID:???どんなｼｮﾎﾞ鯖だよwwww
PHPで富豪的にｷﾒるのがﾊｲｶﾗなんだよwwww
0566nobodyさん
2006/06/08(木) 20:20:32ID:???0567nobodyさん
2006/06/08(木) 23:35:53ID:???それはそれでPHPらしくていいじゃない
0568nobodyさん
2006/06/09(金) 00:37:29ID:???0569nobodyさん
2006/06/09(金) 00:57:54ID:???0570nobodyさん
2006/06/09(金) 07:31:04ID:???APサーバで動くJavaに対して、
たかだかApacheのモジュールでしかないPHPは
比較になりません。
0571nobodyさん
2006/06/09(金) 07:38:36ID:???0572nobodyさん
2006/06/09(金) 08:07:40ID:???0575nobodyさん
2006/06/09(金) 10:29:11ID:???JavaやPHPやVBやC#から使用されるもの
言語とフレームワークをゴッチャにしてないか
0576nobodyさん
2006/06/09(金) 19:10:42ID:???Windowsサーバでしか動かないという縛りには興味なし。
もうPHPはJavaに寄生するかParrotに寄生するか、
もしくはZendがPHP用のAPサーバを作るのを待つしかないよ。
0577nobodyさん
2006/06/09(金) 20:05:34ID:???会社が合併する時に別 AP サーバで死ぬほど苦労するよ。
まぁ、Java の互換性問題は今にはじまった話ではないが。
0578nobodyさん
2006/06/09(金) 21:48:07ID:???Javaなら環境問題がない
PHPなら環境問題がない
全部嘘
確かに趣味でチョロチョロやる次元なら互換性を意識する事は少ない
しかし仕事で作るアプリとなると途端に細かい環境問題が多発する
そりゃもうWindowsもLinuxもUnixも変わらんですよ
互換性だの環境問題だのなんてのは今も昔も評価の対象にならない
0579nobodyさん
2006/06/09(金) 23:46:23ID:???だから、ある程度までなら互換性を語ってもいい気はする。
本職相手に言う台詞じゃないけど。
0582nobodyさん
2006/06/10(土) 12:35:05ID:???馬鹿はお前だPHP厨。
互換性を気にする必要がないならJavaでやりたい放題やりゃいいだろボケ。
PHPみたいな簡易言語なんか使ってるから脳が溶けるんだよアホが。
0583nobodyさん
2006/06/10(土) 12:50:47ID:???スレタイで持ち上げると必死になるのか?
0584nobodyさん
2006/06/11(日) 01:21:53ID:???互換性を気にする必要が無いならどの言語でもやりたい放題できる
互換性を気にする必要があるならJavaもPHPも使い物にならない
お前、脳味噌溶けて耳からこぼれてるんじゃないか？
0585nobodyさん
2006/06/11(日) 10:44:08ID:???0586nobodyさん
2006/06/11(日) 13:31:14ID:???＞互換性を気にする必要が無いならどの言語でもやりたい放題できる
＞互換性を気にする必要があるならJavaもPHPも使い物にならない
条件同じならAPサーバ擁するJavaが有利だなって言ってんだけど、
脳みそ溶けてなくなっちゃってるから分からない？
0587nobodyさん
2006/06/11(日) 16:10:49ID:???0589nobodyさん
2006/06/11(日) 19:15:53ID:???ほかにAPサーバが有利な点は？
0591nobodyさん
2006/06/11(日) 22:25:40ID:???負荷分散っていうか、好きなときにAPサーバを追加してシステムの処理量を増強させられる
スケーラビリティーとかはPHPはJavaに負けてるかなぁ。PHPでムリとは言わんが大変すぎ。
0592nobodyさん
2006/06/11(日) 22:27:57ID:???Javaと同じことが出来ないのは当然じゃないか？
0593nobodyさん
2006/06/11(日) 22:57:34ID:???前提でならまぁ意味はあると思うよ。
0594nobodyさん
2006/06/11(日) 23:12:17ID:???「PHP コネクションプーリング」でぐぐれ
それからJavaでプーリングしやすいのは、Servletだと１プロセスで処理を行うから。
Apache+PHPだとプロセスが複数作成され、そのプロセスごとにコネクションが必要となるから
プーリングされてないようにみえるけど、FastCGIのように１プロセスを使い回すようにすると
プーリングされる。
でもこの方法は共有サーバでは使いにくいから、ほとんど使われない。
逆にJavaは１台のサーバで百人が共有するという使い方ができない。
負荷分散は、poundつかうかApache2ならmod_proxy_balancerを使う。APサーバがないとできないことじゃないし、
APサーバの利点として強調するほどのことでもない。
0595nobodyさん
2006/06/11(日) 23:14:49ID:???PHPではたぶんできない。
0596nobodyさん
2006/06/11(日) 23:20:32ID:???イメージと違ってちょっと意外だった。
0597nobodyさん
2006/06/11(日) 23:23:30ID:???不可能とは言わないけどさ。
それから、FastCGIって1プロセス内だけで処理はしてないよね?
要はプロセスを複数起動してリクエストに待機するだけだからコネクションプーリングに関しては
mod_phpと基本的に変わらん気が。
0598nobodyさん
2006/06/12(月) 00:39:32ID:???0599nobodyさん
2006/06/12(月) 16:17:44ID:???お前は負荷分散がどういうものか理解しているのか？
鯖を複数置いてリクエストを分散すればそれでOKだと思っていないか？
0600nobodyさん
2006/06/12(月) 18:18:34ID:???Javaの利点だけを取り出して「PHPは糞」って言うのはバカ
PHPの利点だけを取り出して「Javaは糞」って言うのはアホ
0601nobodyさん
2006/06/13(火) 00:13:59ID:???それでOKじゃないの？
セッションを別鯖に引き継ぐとかの話が出てくると
耐障害性とか可用性とかの話だからまた別物だろ。
トランザクションとかの管理はDB側に持たせないと
どの道PHPでは使い物にならないから、
アプリ鯖は簡単に増やせそうに思うのだが。
0602nobodyさん
2006/06/13(火) 00:19:44ID:???>mod_phpと基本的に変わらん気が。
なんでやねん。
mod_phpはApacheの設定(max_clientsとか)に左右される。
apacheプロセスの寿命は結構短い。
FastCGIだとApacheとは無関係にプロセス数や寿命を設定できる。
プロセス数を少なく、寿命を長くすればそれでOK。
Javaのサーバは１プロセスマルチスレッドだから有利なのは確かだけど、PHPはPHP以外のソリューションと
組み合わせて利用できるから、Java屋が思ってるほど悪くない。
0604nobodyさん
2006/06/13(火) 00:33:49ID:???0605nobodyさん
2006/06/13(火) 00:58:32ID:???レガシーな負荷分散はそのイメージだよな
ハードウェアのロードバランサって言えばそれだし
だからそれはそれであり
Javaの各種フレームワークやASP.NETの負荷分散が実現するものには更に上のものがある
リクエストとレスポンスを分けるとか、各層のロジックの中で負荷の大きなプロセスだけを分散するとか、複数ページに渡るトランザクションを負荷分散しても一元的に管理できるとか、、、
mod_phpじゃ無理な高次元の負荷分散ができるわけで
0606nobodyさん
2006/06/13(火) 06:43:04ID:???0607nobodyさん
2006/06/13(火) 09:32:57ID:???です。だから Yahoo! や Wikipedia のような
超規模アクセス・サイトでは Java ではなく PHP を使います。
スケーリングが簡単。
0608601
2006/06/13(火) 09:33:21ID:???そんなのできるのか。Javaで食ってるのに知らなかった。
ってかEJBの事か。そんな大きな案件した事無い。
>>606
Poundでは>>605の言ってる不可分散は実現できないような気がするんだが。
みたところロードバランサ+SSLアクセラレーターのソフトウェア版じゃないのか？
0609nobodyさん
2006/06/13(火) 09:59:57ID:???こんな簡単なことも分からない方がいらっしゃるようですね。
嘆かわしいです（＞＜）
0610nobodyさん
2006/06/13(火) 10:01:41ID:???違う
分散したい負荷の種類が違うから
あそこは単純なリクエスト/レスポンスの負荷分散が目的だから、単純な処理機構を持つperlやphpをロードバランサで分散する手法を取っている
データコミットの分散も複雑ではないためにデータ層で受け止められるし
こういう目的では確かにphpやperlの方が楽
いわゆるEnterpriseな負荷分散は高負荷の処理を並列処理するのが目的だから、phpやperlとロードバランサでは目的が達成できない（実はできなくはないが面倒
こういう場合はフレームワークやAPサーバ/OSのレベルでサポートされるJavaや.NETの方が楽
適材適所
数スレ前から出てる当たり前の結論だがな
0611nobodyさん
2006/06/13(火) 10:06:14ID:???WebProgは最終出力がhttpなんだから、どんな処理系を使っても構築できないサイトはない
しかし、サーバ側処理の現実的な実装という意味では各処理系それぞれのadvantageがある
全てのサーバの処理能力が最速スパコンを超えるような爆速で、ネットワークもそのI/Oに負けない爆速なら負荷分散もへったくれもなく同期を取っても一瞬で処理が完了するだろうが、そうはいかないから色々な手法が存在する
WebProgは表側であるクライアント側なんて大した問題じゃなくて、裏側であるサーバ側が問題なんだよ
0612nobodyさん
2006/06/13(火) 11:17:59ID:???けどさ、現実的にはアイドルタイムが長いプロセスがしょっちゅう殺されたり、
余りのプロセスが足りなくなったから新しいプロセスを起動したりするよ。
0613nobodyさん
2006/06/13(火) 12:10:46ID:???PHPを貶めたいだけの書き込み乙。
0614nobodyさん
2006/06/13(火) 12:25:29ID:???現実的には一度立ち上げたfcgiプロセスをずっと使いまわす設定はありえないよ。
そうすると、最高負荷時を見込んでfcgiプロセスをあらかじめ用意することに
なるけど、最高負荷のときのメモリ負荷をずっと維持しつづけるということになるわけで、
これはあんまりといえばあんまりな設定だと思うけど...
おれ、プロパーなPHPerだよ。別に貶す意図はないよ。
0615nobodyさん
2006/06/13(火) 20:56:00ID:???>最高負荷のときのメモリ負荷をずっと維持しつづけるということになるわけで
ここがよくわからん。
最高負荷を見越して設定するのはよしとして、その最高負荷がなんでずっと維持されるん？
■ このスレッドは過去ログ倉庫に格納されています