アカウント名:
パスワード:
* Java がどのような仕事で利用されており * 他の言語で作成した場合と比べて利点があったか
別に擁護するほどの義理も思い入れもないんだけど。
僕がJavaで駄目だと思うところはまず実行速度です。 JITの技術がありますが本質的な解決策では無いと思います。 しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。
必要な時にプロセスとして起動するような用途には当然向かないですよ? PerlはともかくAWKを並べてるところを見ると、「テキスト処理」ってUNIXのフィルタプログラム的な使い方を想定してるんじゃないでしょうか?
Javaのソフトウェアをまともに使おうと思ったら、JavaVMは基本的に立ち上げっぱなし、その中でサービスを回して行くような方法しか今のところはないでしょう。それが、いわゆるJ2EEの考え方(のごく一面)ですね。
だからこそ、JavaOSなんて考え方があったんでしょう。要は適材適所ってこと。
awkやperlに比べて不利な点は、 「実行速度が遅い」ことではなく、「起動が遅い」ことではないでしょうか。
一回走り出したら、十分な速度を持っているよーな気が。
ぼくは、ポインタとはまったく別に「参照」というものを理解している人がいたら、そっちのほうに軍配を上げたいです。
C だって「解放忘れ」なら同じ現象が起こるでしょー。
Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
isualC++のメモリリーク警告って静的になめて出すだけなんでしょうか?それとも動的に解析してくれる?
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。 GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
C++ でマルチスレッドプログラムを書く時のメモリ管理の難しさといったら。まあ,気にしなくても動きますけど(皮肉なことに)。
いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、
> GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。 これは、null なのに使おうとしたって事で、C++とJavaに差は余り無い気がします。 GCとは関係ないのでは?
> 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
Javaの必要性 (スコア:1)
僕はいまいちJavaの良さが分かりません。
誰かJavaのすばらしさを語ってもらえないでしょうか。
Re:Javaの必要性 (スコア:1)
Java Applet のことだったり、 JavaScript のことだったりする
ことがあるので、いっかい問い詰めてみたほうがいいです。
Re:Javaの必要性 (スコア:3, 参考になる)
"私は 何々の 言語が素晴しいと思っているんだけど、
それに比べて Java はあまり素晴しいと思えません。
利点教えて!"
っていうのでないと、あまり効果的な意見が述べられないかと
思います。
私は、あらゆる点で Ruby がいちばん好きな言語ですが、
その次くらいに Java が来ます。
私に関しては、ですが...
[よいところ]
* GUI がクラスライブラリとして標準化されているので、
GUI を作るとき、いろいろ悩むことがない。
(C++ だと、VCL か、MFC か、GTK か Qt か... って
悩むし、採用したライブラリが嫌いな人はソースを
見てくれないだろう...)
* やっぱしクロスプラットフォームの利点は大きい。
Windows を強要されなくて済む。
Linux のみを使っていても誰からも怒られない。
環境による差をあまり意識せずに開発できる。
* オブジェクト指向プログラミングしたい場合は、
C や C++ , Perl (, VB) でやった場合と比べると、
上手に書ける。
( STL を除けば、Java と比べて C++ の利点があまり無い )
[嫌いなところ]
* メモリ食うし、やっぱ起動が遅い。ある程度のマシンスペックは必要
* GUI を作成したとき、デフォルトではフォントの見栄えが悪い。
(しょぼい理由だが、実はこれが一番ヤなところでもある。
私は結構見栄えにこだわる)
挙げればキリがないのでこの辺で。
私としては、Java で仕事ができる環境にあったことがないので、
Java の利点が云々という以前に、むしろ Java で
飯が食えるというのは羨ましい話です。
開発環境を強要されて仕事をしなければならないという現状
においては、Java は比較的うれしい環境だと思います。
実際のところ私は 趣味的に使ったことしかありません。
サーバーサイドの利用 -> Perl 等の方がサクサク作れる
GUI アプリ -> Delphi などの方が...
っていう風に感じていますが、仕事で使われている方、
どのような用途で使用されてますか?
私は
* Java がどのような仕事で利用されており
* 他の言語で作成した場合と比べて利点があったか
というのが知りたいです。
Re:Javaの必要性 (スコア:2, 参考になる)
やっぱサーバーサイドです。Servletとして使います。あと、ソケット開いて
メッセージを処理なんてのも一つ作りました。
>* 他の言語で作成した場合と比べて利点があったか
phpやASPも使ったことがあったけど、HTML埋め込みってのはちとつらいです。
ややこしい画面表示になるとわけわかんなくなる(^^;;;;;
java(というかJ2EE)ならTAGライブラリを使ってかなりHTMLとjavaのコードを
分けられるのでその点楽でしたよ。
HTML埋め込みって (スコア:1)
PHPでもわけわかるように書こうとすると、MVCのようにロジックとビューが分離しちゃいますね。
HTML埋め込みは、本当に「埋め込み」程度の分量しかないときには有効だけど、がつがつと動的生成しなきゃいけないときにはむしろ邪魔、でしょう。
Re:HTML埋め込みって (スコア:1)
すらど宴会SNS開放中 [e-meet.jp]
Re:HTML埋め込みって (スコア:1)
XMLCによるビューとロジックの分離は秀逸かと。
Re:HTML埋め込みって (スコア:1)
http://www.idg.co.jp/lw/back/200008/20000830_01_column.html [idg.co.jp]
http://www.atmarkit.co.jp/fjava/rensai/enhydra01/enhydra1_01.html [atmarkit.co.jp]
上の連載記事を読んでXMLCを使ったビューとロジックの分離のやり方はかなり面白かったです。ちょっとこれを参考にしてPHPコードを吐き出させてみよう(笑) ついでにXMLから別なコンパイラを自動生成するXMLコンパイラコンパイラも面白そうかも。
すらど宴会SNS開放中 [e-meet.jp]
Re:Javaの必要性 (スコア:1)
ぼくは、職業的なプログラミングにおいて、プログラムを書くときに「どの言語を使うといいか」という点を考えて言語を選択するということがどの程度行われているかのほうが知りたいです。
正直、利点があるかなんて考えてから Java を選択している人はどのくらいいるのかが疑問です。いっぱいいるのかなあ。
// この前も、小さなプログラムですが、何も考えずに C++ で書き始めてから後悔したばかり。
鵜呑みにしてみる?
Re:Javaの必要性 (スコア:2, 興味深い)
"どの言語を使ったらよいか" と考えるまえに、
"周囲の人間がどの言語を使う能力があるか" という
制約の方が極めて大きかったので、殆ど選択肢は皆無でした。
たぶん /.J を読んでおられる方は、複数の言語を使い回される
方が少くないと思いますが、実際の仕事の現場だと、
"この人は、これこれの言語を知っているから、この仕事
を与えよう" みたいな配分が行われていることが
結構あるのではないでしょうか?
私は、"本当に必要な理由から言語を制限" される分には仕方が
ないと思ったりもしましたが、"他の人が分からないから" という
理由で言語を強要されるのは非常に嫌でした。
知り合いの人から聞いた話ですが、C++ で STL を使ったプログラムを
書いたら、"他の人が分からないから" という理由で、書き直しを
迫られたことがあるそうです。
私に関しても, "オブジェクト指向でプログラムを作成" したときに、
"VB 使っている人が混乱して分からないから" という理由で、
ソースが全部破棄されたことがありました。
"いまさら構造化プログラミングですか..." とがっくりでしたが。
(まぁ、あのときは、まだ初心者で、私の書いた部分に
悪い点もいっぱいあったから仕方ない点もあるんですけど)
私は、最低限
* オブジェクト指向が分かっていない人には C++ は絶対使ってほしくない。
* ポインタが理解できていない人は、C 言語は使ってほしくない。
って思っています。
(保守されられて、泣きたくなったことがあります。)
そういう現状では、Java は強要されても一番うれしい環境ではないかと。
クラスとして分割して切り分ければ、悪いパーツだけ入れ変えることが
できるし。
悲しい現状でした。
Re:Javaの必要性 (スコア:1)
しかし、そーゆー事をする時は、事前に周囲にネゴをとっておかないと難しいでしょう。私が STLを導入した時は、事前に関係者に説明し、世間の実績や、STLによる生産性向上具合を説いて、了承を得てからやりましたよ。
オブジェクト指向の導入もしかり。
# 説得時に、若干、ばら色の脚色をした事は否定はしませんが (藁
もっとも、いつも了承される状況には無いし、職業上の立場もありますから、時には我慢をし機を見て行動しないと、チャンスを失います。
それって要するにCOBOL? (スコア:1)
そーゆーことなら、「仕事で使う」という条件付きならJavaも好きになれるかな? 私がCOBOL好きなのも、「仕事で使う」という条件付きだし。
Re:Javaの必要性 (スコア:1)
どの言語/プラットフォームを使うかなんて、プロジェクトの命運を左右しかねない、非常に重要な判断事項です。ただし、純粋に言語設計がすぐれているから、その言語を使う。という判断は無いです。
製品の特性、顧客の要望、プラットフォーム、手持ちの
リソース(人材,機材)、納期、保守、製品の使われる期間、
移植、再利用性、情報量、趣味
等の条件を考慮した総合評価です。
そうそう、"流行"も重要な要素です。不幸にして顧客がそれを望んでしまう時は... まぁ、自分が流行熱にかかって、どさくさで新言語って時も、絶対無いとは言い切れないが、何かあった時の責任は自分なので決めるときはドキドキするyo。(それがまたいい(爆
今まで、製品としては C, C++, Perl, JavaScript, Javaを使って来ましたが、Javaに対する印象は、
「とっつきにくくヘビーだが、信頼出来る頼もしい奴。開発が一旦軌道に乗れば生産性も上がり易い」
ですね。他人に依頼する時は CよりもJavaの方が安心出来るかな。
(でも本音は VB→Javaと移って来たプログラマは勘弁願いたい)
# ちなみに趣味のプログラムや、軽いツールは最近はRuby。
Re:Javaの必要性 (スコア:2, 参考になる)
JITの技術がありますが本質的な解決策では無いと思います。
しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。
次に移植性です。
Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
移植性 + 速度
で考えるとCの方が上だと思っています。
GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
最後にIDEです。
デバッグが難しいのにろくなIDEが無いために開発が非常に面倒です。
後は思想的な話ですが、そもそもJavaが出てきた時のライセンスが僕は嫌いでした。
「全ての環境で同じプログラムが動く。だからうちにお金を払ってね。」
って思いっきり某社の戦略ですよね。
今はライセンスが変わりましたが、それは単にJavaが最初のライセンスではやらなかったから変えただけであって、根本的な思想は某社と大して変わらない気がします。
dan kamiyubiさんの意見をお聞かせ下さい。
長文失礼しました。
Re:Javaの必要性 (スコア:3, 参考になる)
方の話をすると、
まず実行速度ですが、私の作ってるようなものだと他の要素、通信やデータベー
スが遅いので、今Javaな部分をCで書いたところで数%も速くならない、むしろ
開発速度が重要で、そういう意味では perl,python,ruby などの方が向いてる
と思います。
遅けりゃ負荷分散したらいいやん、ということで最近ではPCクラスタで分散オ
ブジェクトとかすることが多いので、言語標準のライブラリで分散オブジェク
トがしやすいのもありがたいです。
移植性は、Cでは移植性のないコードも書き易いのでその点さすがにC以外の方
がいいのでは。私の知るヘボCプログラマはすぐにリトルエンディアンを前提
にコードを書くのでSPARCにもってくとき苦労しました。
GCだめだからJavaだめってのは何とも…。他のオブジェクトを明示的に解放し
ない言語もだめなんでしょうか。
IDEは確かにあったほうが参入障壁は低いですね。初心者に勧め易いというか。
私のほうでは必要ないので、無いことがデメリットにはなりません。Junitを
使い出してからはいわゆるIDEでデバッグはしたことないです。バグがあった
らまず再現性を出すテストを書きます。Javaは例外時スタックトレースが出る
のでそれで分かることも多いです。あと再現性のだしづらいバグではIDE のあ
り無しはデバグの容易さとは関係ありません。GUIだと例えばマウスを押して
から離すまでの間動くコードのデバグなどはIDEがあっても楽にはなりません。
思想的な話は良く分からないのでパス。まあ、まっとうなソフトウェア技術者
ならC/C++、perl、python、java、lisp くらいは書けて当然なので「要は適材
的所だ」で済むのではないでしょうか。
Re:Javaの必要性 (スコア:1)
「Javaが適材適所の言語である」というのは納得してます。
でも、僕が良く分からないのは適材適所で無いような気がする分野にまでJavaが持ち込まれているような気がします。
例えばReal Time Javaなんていうのは本当に必要なのでしょうか。
dan kamiyubiさんはおそらくJava信者では無いと思いますが、Java信者の人はよく「Java万能」と考えていることがあります。
dan kamiyubiさんの目からみてJavaの可能性はどの程度あると思いますか?
Re:Javaの必要性 (スコア:1)
Java 万能 (スコア:1)
(100% Pure Java にこだわると)Java 言語では
(まともな) JavaVM が書けないのですから、、、
p.s.
任意のアドレスに任意の型でデータを読み書きできる
バイトコードのプリミティブがあれば、比較的まともな
速度で動く JavaVM が Java で書けるのです。
そういうプリミティブがない場合は、しょうがないので
ヒープ空間全体を覆うような強大な byte 型配列をとって、
bastore と baload でちまちま読み込んで論理合成する
しかない!?
コンタミは発見の母
Re:Javaの必要性 (スコア:2, 興味深い)
別に擁護するほどの義理も思い入れもないんだけど。
必要な時にプロセスとして起動するような用途には当然向かないですよ? PerlはともかくAWKを並べてるところを見ると、「テキスト処理」ってUNIXのフィルタプログラム的な使い方を想定してるんじゃないでしょうか?
Javaのソフトウェアをまともに使おうと思ったら、JavaVMは基本的に立ち上げっぱなし、その中でサービスを回して行くような方法しか今のところはないでしょう。それが、いわゆるJ2EEの考え方(のごく一面)ですね。
だからこそ、JavaOSなんて考え方があったんでしょう。要は適材適所ってこと。
Re:Javaの必要性 (スコア:2, 参考になる)
それは実感しますね。
jvmの起動はやっぱり遅い。一方でいったん上がれば遅さが気になることは案外(?)多くない。
複数の関連ある処理(の単位:OOPとそれ以外を比較するときにはこの辺が曖昧な言い方になっちゃいますが)を
繋ぎあわせて使うという状況においては、unixのプロセスモデルより、java(に限らないけど)の
Object単位のモデルのほうが、メリットが多いことが多いです。プロセスだと処理単位間の「壁」が高すぎ。
それがまさに、CGIに対するservlet、makeに対するant、のメリットになっているという触れ込み(^^;。
オフトピだけどant。make時に必要な複数の処理を同一プロセス(^^;でやってくれるのは
たしかに魅力的なんだけど、もう一歩欲しいです。
もしコンパイルが「終わって」も尚プロセスが残っていてくれたら、そして
次のコンパイルにそれを使い回せたら、きっと更に速くなるだろうに、と。
Re:Javaの必要性 (スコア:1)
AWK、Perlを例に挙げたのはUNIXのフィルタプログラム的な使い方を想定してるわけではなく、とにかく遅いって言いたかっただけです。
僕自身AwkやPerlよりも遅いと知ったときに非常に驚いたもので。
「ある特定の用途にはJavaが非常に有用だ」
というのは分かります。
ただ、言語として総合的な観点から見た場合に魅力的な言語だと僕は思えません。
しかし、Java信者ってすごく熱烈的ですよね?
いったいどこに魅力を感じるのかというのが僕にとって興味あることなのです。
Re:Javaの必要性 (スコア:1)
"あーんなに遅いのに、みんな平気で使っているんだろうか?"
って Java を使うときはいつも思っていたのですが、
やっぱしそのように思っている同士がいたということで。
Java の情報って、"けっこう速いですよ、いいですよ"
って思わせる情報ばっかりが見つかって,
"Java ダメじゃん.." って情報はあまり書いている人が
多くないんですよね。
欠点を述べるのって、結構重要だと思うのですよ。
だって、どのような時に Java を使えばいいかという
判断材料としては非常に有効ですから。
いろいろ勉強になりました。
Re:Javaの必要性 (スコア:1)
もちろん実行系の制約ってのは、Javaの思想に起因してるのだろうけど、それは言語としての評価とはちょっと違うように思います。
確かに、環境(言語と実行系を両方含めた話)としてのJavaは、あれこれ不満が多いですけど、ね。
Re:Javaの必要性 (スコア:1)
もちろん「言語」という言葉をそんな厳密に使ってるわけじゃないのはわかってるのです。けど、つい血が騒ぐというかなんというか。
Re:Javaの必要性 (スコア:1)
awkやperlに比べて不利な点は、 「実行速度が遅い」ことではなく、「起動が遅い」ことではないでしょうか。
一回走り出したら、十分な速度を持っているよーな気が。
# emacsみたいにdumpして(比較的)高速に起動するということはできないのだろうか…。Re:Javaの必要性 (スコア:2, 興味深い)
不要なオブジェクトへの活きた参照をいつまでもかかえてしまうようなコーディングをしてしまうと,長時間運用後にVMが落ちることがあります.確かに見つけにくいバグではありますが,GCがない場合のメモリリークはそれ以上に見つけにくいバグですし,何よりも開放してしまったメモリ領域を触る危険性がない方が安心して使えるのではないでしょうか.
Re:Javaの必要性 (スコア:1)
それともぼくが用語の定義を間違えているのかな。このあたりの概念、感覚的にしか把握していません。
Perl より遅くなる理由はない、というのは理解できますが。
// ただ、 Perl と実行速度を比較されているのは Java がなんか気の毒。
鵜呑みにしてみる?
ポインタ(Re:Javaの必要性) (スコア:1)
// なお、ぼくは C/C++ を学んだ後でしか Java や Visual Basic を理解できませんでした。
同様に、Cのポインタをアドレスとはまったく別に理解している人がいたら、そっちのほうがすごいと思いますが、いないだろうなあ……。
// ぼくはアセンブリ言語を学んだ後でしか C を理解できませんでした。これはある面恥ずかしいかも。
なお、ぼくはプログラマではありません。
鵜呑みにしてみる?
Re:ポインタ(Re:Javaの必要性) (スコア:1)
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:ポインタ(Re:Javaの必要性) (スコア:1)
ということは、ほかにも「参照」はあるけどポインタっぽくない言語というのはたくさんあるのでしょうね。不覚。
鵜呑みにしてみる?
Re:Javaの必要性 (スコア:2, 参考になる)
> GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
> 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
C だって「解放忘れ」なら同じ現象が起こるでしょー。
Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
むしろ、C では使われていないポインタに NULL 以外の値が
入っていることがあって、そっちの方が危ないと思うのだがどうか。
#ま、C だって boehm GC みたいなのがあるけどね。
# mishimaは本田透先生を熱烈に応援しています
Re:Javaの必要性 (スコア:2, 参考になる)
Cで動的に確保されたメモリブロックは、明示的に解放しない限り、(少なくとも)そのプロセスの生存中は回収されないのに対して、Javaの場合は、他から参照されなくなったオブジェクトは、ガベージコレクタによって自動的に回収されます。(そもそも、解放するという操作自体がない)
また、 これも、ガベージコレクタがオブジェクトを回収する際の「ヒント」を与えるために使われるテクニックであって、必ずしなければならない、というものではありません。(スコープを外れ、どこからも参照されていなければ、回収される)
# 「ポインタ」という用語も不適切かと。
(未確認ですが、ガベージコレクタの性能の向上で、そういったテクニックをする必要もなくなってきた、というような話もあるらしいです)
Re:Javaの必要性 (スコア:1)
> > C だって「解放忘れ」なら同じ現象が起こるでしょー。
> 少し違うと思います。
> Cで動的に確保されたメモリブロックは、明示的に解放しない限り、(少なくとも)そのプロセスの生存中は回収されないのに対して、Javaの場合は、他から参照されなくなったオブジェクトは、ガベージコレクタによって自動的に回収されます。(そもそも、解放するという操作自体がない)
?よく意味が分からん。
短時間では問題はないが、長時間動かすとVMが落ちるようなプログラム、
というのは明らかにメモリを食い潰しているのであって、
C でこれと同じ状況は「解放忘れ」で簡単に起こる、というだけのことだろう。
> > Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
> これも、ガベージコレクタがオブジェクトを回収する際の「ヒント」を与えるために使われるテクニックであって、必ずしなければならない、というものではありません。
一般論ではもちろんそうだが、
メモリ不足でVMが落ちる、なんて状況では必須だろう
(そうでなければGCが回収しているはずなんだから)。
#「ポインタ」は不適切だったな。すまん
# mishimaは本田透先生を熱烈に応援しています
Re:Javaの必要性 (スコア:1)
という事でしょうか。
サーバー側のJavaが花開いたのは、バックエンドがころころ
変わるのに対応出来る、という事なのでは。
-----------------
#そんなワタシはOS/2ユーザー:-)
どの機能についていっています? (スコア:1)
これってどの機能のことを指していますか?
VC6.0を日常業務に使っていますけど、VC がメモリの解放し忘れ
を指摘してくれたことなど皆無なのですけど、、、
あとデバッガがメモリリークを指摘する機能は 設計がよくでき
ていてちゃんとコーディングされたプログラムに対して行う場合は
有効だけど、いい加減な設計のプログラムに対しては無力だと
思います。
#「ほとんどメモリは使い捨て」の前提で書かれた20万行ぐらいの
#プログラムを NuMega の BoundsChecker に掛けたら数千箇所も
#問題を指摘されてことがある、、、
コンタミは発見の母
BoundsCheckerは、Visual C++とは別製品だよ (スコア:2, 参考になる)
BoundsCheckerは、元々米国のNumega社が開発し、米国Compuware社に買収されて、現在は「Compuware社のNumega製品」ということで販売されています。
私の知る限りでは、M$社にぴったりくっついていて、VC++などとの相性というか、一部のように機能する、ということを売りにしていますが、完全な別会社の別製品です!。
ご参考までに日本コンピュウェアの該当サイトをお知らせしておきます。
ここ [numegajapan.com]です。
この会社の営業やってる知り合いに教えてやろうかと思っちまったい!
Re:どの機能についていっています? (スコア:1)
#63080 の人のメモリ解放のし忘れ検出の機能はこれみたいですね。
これは new して delete されていないものを表示するだけだから、
メモリリークをしている可能性のある箇所を大量表示しちゃうんで
すよね。
ないよりましだけど、本当にメモリリークを潰す必要があるプログラム
(終了のこないサーバープログラムや、プログラムの途中のフェーズ
で大量にメモリが必要になるプログラム)には 使えんです。
コンタミは発見の母
BoundsChecker (スコア:1)
ランタイムベースの非常に強力なエラー検出ツールです。
配列の境界を越えたアクセスをチェックしてくれるのが名前の
由来だと思います。
今はもう持っていないので詳細をチェックできませんが、メモリ
リークやリソースリーク、配列・構造体の境界チェック、ダング
リングポインタの検出ができたはずです。
似たようなツールに Rational 社の purify があります。
コンタミは発見の母
Re:Javaの必要性 (スコア:1)
前者だったら、ワタシはむしろプログラムする人がタコい気がしますし、後者だったらこれはチューリング賞クラスの偉大な機能な気がしますが、どっちなのでしょうか?
-----------------
#そんなワタシはOS/2ユーザー:-)
Re:Javaの必要性 (スコア:1)
ぐわ、VisulaC++のIDEが行う動的チェックってただのスタックチェックなのね。IDEが静的なソースから動的にフローを出してくれてそれでメモリリークを教えてくれるのかと思いましたよ。
pascalerとしてはまったく不要の機能だなぁ・・・
-----------------
#そんなワタシはOS/2ユーザー:-)
GCの必要性 (スコア:2, 参考になる)
C++ でマルチスレッドプログラムを書く時のメモリ管理の難しさといったら。まあ,気にしなくても動きますけど(皮肉なことに)。
Re:GCの必要性 (スコア:1)
>テーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。
え?
http://www.is.s.u-tokyo.ac.jp/~vu/jugyo/processor/process/soft/compilerresume/gc/gc.html
>Copying GCの興味深い性質は、コピーするときにオブジェクトの空きをつめるため、fragmentationが発生しないということである。
によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど?
それとも、その副作用のあるGCしか使う予定が無い、言い換えれば
使おうとしている処理系のGCがお望みのアルゴリズムであることが既に判っている、
という状況なのでしょうか?
そりゃそうと、メモリリークが無くなるってのについては、有り難いと思いますよ。
1:unixプロセスモデル配下の短寿命プロセスならば、最悪でも「間もなく」OSがメモリを回収してくれる
ので有り難味は少ないかもだが、そうでないならそれ以外の管理が必要になる。
2:開放タイミングを決定するのが結構面倒なプログラミング形態も、ある。
ので、あーゆーものは、(プログラマの技量次第というよりも(笑))状況次第で、凄く欲しくなると思うんですが。
Re:GCの必要性 (スコア:1)
(中略)
> フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるか
> どうかは GCのアルゴリズム次第であって、GC一般の性質ではない、と読め
> ますけど?
元コメントは、フラグメンテーションがプログラマに不可視になることを言いたかったんだと、愚考します。
# 違ったらどうしよう。^_^;
新しいjavaコマンド(VM)は並列GCを実装していますね。どんなアルゴリズムを使ってるんでしょうか。興味があります。106CPUでもちゃんと動いてくれるでしょうか。:-)
Re:GCの必要性 (スコア:1)
> GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど?
GC がどのようなアルゴリズムで行われるにせよ、compaction は
行われてるのではないでしょうか? compaction されるというこ
とは、その時点でフラグメンテーションも解消される、ということ
ですよね?違う?
Java の Heap に関しては、激しくオブジェクトの生成/回収を
繰り返してもフラグメンテーションによって新規オブジェクトが
生成できない、とゆー事態には陥ったことがないため漠然とそう
思ってたんですけど…。
UNIX のようにプロセスを起こすコストが結構大きい OS がサーバ
で主流な昨今、比較的容易にお行儀のいい長寿命プロセスを作成
出来る Java は非常に有用だと思います。
Only Jav^Hpanese available :-)
Re:GCの必要性 (スコア:1)
いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、
Re:GCの必要性 (スコア:1)
実際に compaction を行わない GC 実装が存在することはもちろ
ん知っていますし、JavaVM Spec. が Heap 管理については 100%
実装者の裁量に任せている、ことも分かっていますが、しかし、
ご存じの通り Java にはポインタがありませんから、C でのよう
にプログラム側でフラグメンテーションに対処することが非常に難しく、
となると、まっとうな実装者ならばフラグメンテーションが起こら
ないように GC を設計するのではないか、という予想のもと、こと
現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
うところの「それとも、その副作用のあるGCしか使う予定が無い、
言い換えれば使おうとしている処理系のGCがお望みのアルゴリズム
であることが既に判っている、という状況」といえるのではないか、
前の書込みに補足すれば「GC がどのようなアルゴリズムで行われ
るにせよ、JavaVM においては常に compaction は行われている
と考えていいのではないでしょうか?」というのが趣旨です。
#組み込み系まで含めると必ずしも真ではないかもしれませんが、
#J2SE 以上の各社の実装を見ているとそう言えるのではないかと。
J2SE 以上の実装では半ば常識的なことながら、JavaVM Spec. で
はっきり規定された仕様ではない、という点を、G7 さんは暗に指
摘されていたのかな…?
Only Jav^Hpanese available :-)
Re:GCの必要性 (スコア:1)
>にプログラム側でフラグメンテーションに対処することが非常に難しく、
ああ。メモリプールというかmallocに相当するものを自作するという話題ですか。
たしかにjavaでは何処をどういじってもソレっぽいことは出来ないですね。
>現代的な実装の JavaVM に関していうなら、G7 さんの書込みでい
>うところの「それとも、その副作用のあるGCしか使う予定が無い、
>言い換えれば使おうとしている処理系のGCがお望みのアルゴリズム
>であることが既に判っている、という状況」といえるのではないか、
それを称して「現代的」と呼ぶんでしょうか?>識者諸兄
俺は知らないんですが。
>JavaVM においては常に compaction は行われている
そこでいう「JavaVM」がどこまでを指すか?に拠るでしょうね。
Sunなりなんなりの1つ(^^;の実装について語りたいなら、
メーカーに質問するとか、気に入らないなら(金を出して)変更を迫るとか、
いろんな手が有り得そうです。
でも、KaffeやWavaみたいな偽Java(^^;とか、あるいは各種(?)小型組み込み向けJavaとか、も
含めて考えると、その期待が満たされてるかどうかは、また違う話になるわけですよね。
>#J2SE 以上の各社の実装を見ているとそう言えるのではないかと。
上に書きましたが、Kaffeって、どう捉えたらいいんでしょうね?(^^;
J2SEとは…あ、どうせ言えないのか。
Java1.2相当にも、まだなってないんでしたっけかあれ?
… http://www.kaffe.org/ … あ。まだ1.1相当かあ。
Re:GCの必要性 (スコア:1, 参考になる)
> GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
> GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
これは、null なのに使おうとしたって事で、C++とJavaに差は余り無い気がします。
GCとは関係ないのでは?
> 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
これは、メモリリークしているということだとすると、GCのおかげで、それは無くなるんではないでしょうか?
メモリが無くなっているとしても、直接には、別の原因でVMが落ちているのでは無いでしょうか?
GCのおかげで、deleteを書かなくて良いとか、ポインタ変数を、参照出来なくなっても良いとか言うのはかなり良いと思います。
それと、APIまでJava言語に含まれているおかげで、スレッドも大抵のJavaの本で触れられているし、C++に比べ簡単になること自体で本の内容がそれを埋める分だけ色々増えているのは良いです。
Re:GCの必要性 (スコア:1)
関係はあると思います。
ガベージコレクタがオブジェクトの回収をやってくれるおかげで、メモリリークが顕在化しにくくなったため、オブジェクトの管理がいい加減なプログラムでも、それなりに動いてしまう、という話では?
で、その結果、真綿で首を絞めるように、回収されない(できない)オブジェクトがじわじわと蓄積して、
となると。
「Java(の)メモリリーク」などと呼ばれるようです。
# 私自身は「だからGCに利点はそれほどない」とは思いませんが。
Re:Javaの必要性 (スコア:1)
>Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
それはおっしゃる通りです。おれもなんだかんだ言って結局は、
Windowsクライアントでソース書く->Unixのサーバー上にftpしてコンパイル
なんてしたましたし(笑)今はサーバーもクライアントもlinuxだからその点楽。
>移植性 + 速度
>で考えるとCの方が上だと思っています。
write once....は「コンパイル済みのバイナリコードがそのまま移植できる」ということだと思うのだけど。Cの移植性(ソースもってってコンパイルすればOK)とは別の話になると思いますが。
ソースの移植性についても、#ifdef WIN32みたいなマネをする箇所がjavaならかなり減るのでは?、特にGUIについては。
というか、javaにマクロは無いが<-おれにとってはこれがjavaの嫌なとこです(笑)
それに、たとえば顧客にUNIX上で動くPGを納品するときに、ソースに#ifdef WIN32とか書いてあったらマズイ(笑)
速度に関しては、たしかに遅いですね。GUIのアプリをまともに作る気分にはなれない。
>最後にIDEです。
>デバッグが難しいのにろくなIDEが無いために開発が非常に面倒です。
xemacs + javac + jdbで開発してます(笑)
#そいえばCもdbxでやってたな
Re:Javaの必要性 (スコア:1)
「修正してやる」、んじゃないの?