パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

Java 1.4SE正式リリース」記事へのコメント

  • 未だにJava人気あるんですね。
    僕はいまいちJavaの良さが分かりません。
    誰かJavaのすばらしさを語ってもらえないでしょうか。
    • 「Java は駄目」とか言う人の話をよく聞いてみると、
      Java Applet のことだったり、 JavaScript のことだったりする
      ことがあるので、いっかい問い詰めてみたほうがいいです。
      親コメント
      • Re:Javaの必要性 (スコア:3, 参考になる)

        by himuro (547) on 2002年02月15日 12時00分 (#63063) ホームページ
        そうですね。

        "私は 何々の 言語が素晴しいと思っているんだけど、
        それに比べて 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, 参考になる)

          by hatoku (1188) on 2002年02月15日 12時30分 (#63083) 日記
          >* Java がどのような仕事で利用されており

          やっぱサーバーサイドです。Servletとして使います。あと、ソケット開いて
          メッセージを処理なんてのも一つ作りました。

          >* 他の言語で作成した場合と比べて利点があったか
          phpやASPも使ったことがあったけど、HTML埋め込みってのはちとつらいです。
          ややこしい画面表示になるとわけわかんなくなる(^^;;;;;
          java(というかJ2EE)ならTAGライブラリを使ってかなりHTMLとjavaのコードを
          分けられるのでその点楽でしたよ。
          親コメント
        • by tix (7637) on 2002年02月15日 12時37分 (#63089) ホームページ
          * Java がどのような仕事で利用されており
          * 他の言語で作成した場合と比べて利点があったか

          ぼくは、職業的なプログラミングにおいて、プログラムを書くときに「どの言語を使うといいか」という点を考えて言語を選択するということがどの程度行われているかのほうが知りたいです。

          正直、利点があるかなんて考えてから Java を選択している人はどのくらいいるのかが疑問です。いっぱいいるのかなあ。

          // この前も、小さなプログラムですが、何も考えずに C++ で書き始めてから後悔したばかり。
          --
          鵜呑みにしてみる?
          親コメント
          • by himuro (547) on 2002年02月15日 12時57分 (#63101) ホームページ
            私の経験ですが、

            "どの言語を使ったらよいか" と考えるまえに、
            "周囲の人間がどの言語を使う能力があるか" という
            制約の方が極めて大きかったので、殆ど選択肢は皆無でした。

            たぶん /.J を読んでおられる方は、複数の言語を使い回される
            方が少くないと思いますが、実際の仕事の現場だと、
            "この人は、これこれの言語を知っているから、この仕事
            を与えよう" みたいな配分が行われていることが
            結構あるのではないでしょうか?

            私は、"本当に必要な理由から言語を制限" される分には仕方が
            ないと思ったりもしましたが、"他の人が分からないから" という
            理由で言語を強要されるのは非常に嫌でした。

            知り合いの人から聞いた話ですが、C++ で STL を使ったプログラムを
            書いたら、"他の人が分からないから" という理由で、書き直しを
            迫られたことがあるそうです。

            私に関しても, "オブジェクト指向でプログラムを作成" したときに、
            "VB 使っている人が混乱して分からないから" という理由で、
            ソースが全部破棄されたことがありました。
            "いまさら構造化プログラミングですか..." とがっくりでしたが。
            (まぁ、あのときは、まだ初心者で、私の書いた部分に
            悪い点もいっぱいあったから仕方ない点もあるんですけど)

            私は、最低限
              * オブジェクト指向が分かっていない人には C++ は絶対使ってほしくない。
              * ポインタが理解できていない人は、C 言語は使ってほしくない。
            って思っています。
              (保守されられて、泣きたくなったことがあります。)

            そういう現状では、Java は強要されても一番うれしい環境ではないかと。
            クラスとして分割して切り分ければ、悪いパーツだけ入れ変えることが
            できるし。

            悲しい現状でした。
            親コメント
            • by wawawa (3653) on 2002年02月15日 13時53分 (#63128)
              ご同情申し上げます。

              しかし、そーゆー事をする時は、事前に周囲にネゴをとっておかないと難しいでしょう。私が STLを導入した時は、事前に関係者に説明し、世間の実績や、STLによる生産性向上具合を説いて、了承を得てからやりましたよ。

              オブジェクト指向の導入もしかり。

              # 説得時に、若干、ばら色の脚色をした事は否定はしませんが (藁

              もっとも、いつも了承される状況には無いし、職業上の立場もありますから、時には我慢をし機を見て行動しないと、チャンスを失います。
              親コメント
            • サブジェクトでほぼみんな言っちゃったけど、その辺の事情ってのは、全くCOBOL的だな。となると、仕事で使う分には申し分ない言語と言えなくもない。また、「使える言語はJavaです」ってのは、かつての「使える言語はCOBOLです」って言ってるのと同じと。

              そーゆーことなら、「仕事で使う」という条件付きならJavaも好きになれるかな? 私がCOBOL好きなのも、「仕事で使う」という条件付きだし。
              親コメント
          • by wawawa (3653) on 2002年02月15日 13時35分 (#63119)
            では、どういう判断でJavaを選んでいるとお思いで?

            どの言語/プラットフォームを使うかなんて、プロジェクトの命運を左右しかねない、非常に重要な判断事項です。ただし、純粋に言語設計がすぐれているから、その言語を使う。という判断は無いです。

              製品の特性、顧客の要望、プラットフォーム、手持ちの
              リソース(人材,機材)、納期、保守、製品の使われる期間、
              移植、再利用性、情報量、趣味

            等の条件を考慮した総合評価です。

            そうそう、"流行"も重要な要素です。不幸にして顧客がそれを望んでしまう時は... まぁ、自分が流行熱にかかって、どさくさで新言語って時も、絶対無いとは言い切れないが、何かあった時の責任は自分なので決めるときはドキドキするyo。(それがまたいい(爆

            今まで、製品としては C, C++, Perl, JavaScript, Javaを使って来ましたが、Javaに対する印象は、

            「とっつきにくくヘビーだが、信頼出来る頼もしい奴。開発が一旦軌道に乗れば生産性も上がり易い」

            ですね。他人に依頼する時は CよりもJavaの方が安心出来るかな。
            (でも本音は VB→Javaと移って来たプログラマは勘弁願いたい)

            # ちなみに趣味のプログラムや、軽いツールは最近はRuby。
            親コメント
      • Re:Javaの必要性 (スコア:2, 参考になる)

        by loginPenguin (7275) on 2002年02月15日 11時13分 (#63037)
        僕がJavaで駄目だと思うところはまず実行速度です。
        JITの技術がありますが本質的な解決策では無いと思います。
        しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。

        次に移植性です。
        Write Once Run Anywareとか言っていますがはっきり言って実現されて無いと思います。
        移植性 + 速度
        で考えるとCの方が上だと思っています。

        GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
        GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
        1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。

        最後にIDEです。
        デバッグが難しいのにろくなIDEが無いために開発が非常に面倒です。

        後は思想的な話ですが、そもそもJavaが出てきた時のライセンスが僕は嫌いでした。
        「全ての環境で同じプログラムが動く。だからうちにお金を払ってね。」
        って思いっきり某社の戦略ですよね。
        今はライセンスが変わりましたが、それは単にJavaが最初のライセンスではやらなかったから変えただけであって、根本的な思想は某社と大して変わらない気がします。

        dan kamiyubiさんの意見をお聞かせ下さい。
        長文失礼しました。
        親コメント
        • Re:Javaの必要性 (スコア:3, 参考になる)

          by dan kamiyubi (6091) on 2002年02月15日 13時28分 (#63114) ホームページ 日記
          皆さんおっしゃられているとおり向き不向きの話だと思うので私の向いている
          方の話をすると、

          まず実行速度ですが、私の作ってるようなものだと他の要素、通信やデータベー
          スが遅いので、今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 くらいは書けて当然なので「要は適材
          的所だ」で済むのではないでしょうか。
          親コメント
          • by loginPenguin (7275) on 2002年02月15日 13時52分 (#63126)
            非常に勉強になります。
            「Javaが適材適所の言語である」というのは納得してます。
            でも、僕が良く分からないのは適材適所で無いような気がする分野にまでJavaが持ち込まれているような気がします。
            例えばReal Time Javaなんていうのは本当に必要なのでしょうか。
            dan kamiyubiさんはおそらくJava信者では無いと思いますが、Java信者の人はよく「Java万能」と考えていることがあります。
            dan kamiyubiさんの目からみてJavaの可能性はどの程度あると思いますか?
            親コメント
            • 名指しで召喚するのは勘弁してほしいな。必要性とか可能性は、見出すものだと思う。RealTimeJavaは不勉強でよくしりませんけど、技術的に困難なことに挑戦する姿って尊いじゃないですか。RealTimeJavaにチャレンジしようとしているひとのやる気をそぎたくない。ぜひがんばってほしい。「Java万能」という人の理由は「(あらゆる場合に)Java捨て」という人の理由とたいして違わないでしょう。ほかの人も指摘してたけどJava実行環境とJava言語の違いがついてないのかもしれない。
              親コメント
            • ... のわけがないじゃないですか。

              (100% Pure Java にこだわると)Java 言語では
              (まともな) JavaVM が書けないのですから、、、

              p.s.

              任意のアドレスに任意の型でデータを読み書きできる
              バイトコードのプリミティブがあれば、比較的まともな
              速度で動く JavaVM が Java で書けるのです。

              そういうプリミティブがない場合は、しょうがないので
              ヒープ空間全体を覆うような強大な byte 型配列をとって、
              bastore と baload でちまちま読み込んで論理合成する
              しかない!?
              --
              コンタミは発見の母
              親コメント
        • by visha (779) on 2002年02月15日 11時46分 (#63053) 日記

          別に擁護するほどの義理も思い入れもないんだけど。

          僕がJavaで駄目だと思うところはまず実行速度です。 JITの技術がありますが本質的な解決策では無いと思います。 しかもテキスト処理なんかはJITを使ってもAwkよりもPerlよりも遅い。

          必要な時にプロセスとして起動するような用途には当然向かないですよ? PerlはともかくAWKを並べてるところを見ると、「テキスト処理」ってUNIXのフィルタプログラム的な使い方を想定してるんじゃないでしょうか?

          Javaのソフトウェアをまともに使おうと思ったら、JavaVMは基本的に立ち上げっぱなし、その中でサービスを回して行くような方法しか今のところはないでしょう。それが、いわゆるJ2EEの考え方(のごく一面)ですね。

          だからこそ、JavaOSなんて考え方があったんでしょう。要は適材適所ってこと。

          親コメント
          • Re:Javaの必要性 (スコア:2, 参考になる)

            by G7 (3009) on 2002年02月15日 14時47分 (#63150)
            >必要な時にプロセスとして起動するような用途には当然向かないですよ?

            それは実感しますね。
            jvmの起動はやっぱり遅い。一方でいったん上がれば遅さが気になることは案外(?)多くない。

            複数の関連ある処理(の単位:OOPとそれ以外を比較するときにはこの辺が曖昧な言い方になっちゃいますが)を
            繋ぎあわせて使うという状況においては、unixのプロセスモデルより、java(に限らないけど)の
            Object単位のモデルのほうが、メリットが多いことが多いです。プロセスだと処理単位間の「壁」が高すぎ。

            それがまさに、CGIに対するservlet、makeに対するant、のメリットになっているという触れ込み(^^;。

            オフトピだけどant。make時に必要な複数の処理を同一プロセス(^^;でやってくれるのは
            たしかに魅力的なんだけど、もう一歩欲しいです。
            もしコンパイルが「終わって」も尚プロセスが残っていてくれたら、そして
            次のコンパイルにそれを使い回せたら、きっと更に速くなるだろうに、と。
            親コメント
          • by loginPenguin (7275) on 2002年02月15日 12時07分 (#63066)
            実のあるコメントありがとうございます。
            AWK、Perlを例に挙げたのはUNIXのフィルタプログラム的な使い方を想定してるわけではなく、とにかく遅いって言いたかっただけです。
            僕自身AwkやPerlよりも遅いと知ったときに非常に驚いたもので。
            「ある特定の用途にはJavaが非常に有用だ」
            というのは分かります。
            ただ、言語として総合的な観点から見た場合に魅力的な言語だと僕は思えません。
            しかし、Java信者ってすごく熱烈的ですよね?
            いったいどこに魅力を感じるのかというのが僕にとって興味あることなのです。
            親コメント
            • by himuro (547) on 2002年02月15日 12時16分 (#63072) ホームページ
              私もみなさんの意見を聞いてちょっと安心しました。

              "あーんなに遅いのに、みんな平気で使っているんだろうか?"

              って Java を使うときはいつも思っていたのですが、
              やっぱしそのように思っている同士がいたということで。

              Java の情報って、"けっこう速いですよ、いいですよ"
              って思わせる情報ばっかりが見つかって,
              "Java ダメじゃん.." って情報はあまり書いている人が
              多くないんですよね。

              欠点を述べるのって、結構重要だと思うのですよ。
              だって、どのような時に Java を使えばいいかという
              判断材料としては非常に有効ですから。

              いろいろ勉強になりました。
              親コメント
            • 先に挙がった不満点って「言語」じゃなくて「実行系」の話ばかりだと思うんだけど。
              もちろん実行系の制約ってのは、Javaの思想に起因してるのだろうけど、それは言語としての評価とはちょっと違うように思います。
              確かに、環境(言語と実行系を両方含めた話)としてのJavaは、あれこれ不満が多いですけど、ね。
              親コメント
              • いや、言葉の使い方が気になった、というだけなのです。個人的に、「(プログラム)言語の善し悪し」と言ったら、言語仕様のことと考えてしまうので。だから、「実際の実行系とは別でしょ」と。
                もちろん「言語」という言葉をそんな厳密に使ってるわけじゃないのはわかってるのです。けど、つい血が騒ぐというかなんというか。
                親コメント
            • by iwa (2980) on 2002年02月15日 18時06分 (#63223)

              awkやperlに比べて不利な点は、 「実行速度が遅い」ことではなく、「起動が遅い」ことではないでしょうか。

              一回走り出したら、十分な速度を持っているよーな気が。

              # emacsみたいにdumpして(比較的)高速に起動するということはできないのだろうか…。
              親コメント
        • by moonbear (4602) on 2002年02月15日 11時55分 (#63059)
          実行速度の不満についてはそのうち解決するでしょう.静的かつ強い型付けの言語なので,PerlやRubyと比べて原理的に遅くなる理由はありません.

          不要なオブジェクトへの活きた参照をいつまでもかかえてしまうようなコーディングをしてしまうと,長時間運用後にVMが落ちることがあります.確かに見つけにくいバグではありますが,GCがない場合のメモリリークはそれ以上に見つけにくいバグですし,何よりも開放してしまったメモリ領域を触る危険性がない方が安心して使えるのではないでしょうか.
          親コメント
          • by tix (7637) on 2002年02月15日 12時48分 (#63093) ホームページ
            Java はダウンキャストのときに動的型チェックをする必要があるので、 statically strongly typed ではなく dynamically strongly typed だと思います。

            それともぼくが用語の定義を間違えているのかな。このあたりの概念、感覚的にしか把握していません。

            Perl より遅くなる理由はない、というのは理解できますが。

            // ただ、 Perl と実行速度を比較されているのは Java がなんか気の毒。
            --
            鵜呑みにしてみる?
            親コメント
        • Re:Javaの必要性 (スコア:2, 参考になる)

          by mishima (737) on 2002年02月15日 12時13分 (#63069) ホームページ 日記
          > GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
          > GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
          > 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。

          C だって「解放忘れ」なら同じ現象が起こるでしょー。

          Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
          むしろ、C では使われていないポインタに NULL 以外の値が
          入っていることがあって、そっちの方が危ないと思うのだがどうか。

          #ま、C だって boehm GC みたいなのがあるけどね。
          --
          # mishimaは本田透先生を熱烈に応援しています
          親コメント
          • Re:Javaの必要性 (スコア:2, 参考になる)

            by k6p (7828) on 2002年02月16日 3時01分 (#63418)
            C だって「解放忘れ」なら同じ現象が起こるでしょー。
            少し違うと思います。
            Cで動的に確保されたメモリブロックは、明示的に解放しない限り、(少なくとも)そのプロセスの生存中は回収されないのに対して、Javaの場合は、他から参照されなくなったオブジェクトは、ガベージコレクタによって自動的に回収されます。(そもそも、解放するという操作自体がない)
            また、
            Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
            これも、ガベージコレクタがオブジェクトを回収する際の「ヒント」を与えるために使われるテクニックであって、必ずしなければならない、というものではありません。(スコープを外れ、どこからも参照されていなければ、回収される)
            # 「ポインタ」という用語も不適切かと。

            (未確認ですが、ガベージコレクタの性能の向上で、そういったテクニックをする必要もなくなってきた、というような話もあるらしいです)
            親コメント
            • ちょっとスレッドの流れを読み直して頂きたいが。

              > > C だって「解放忘れ」なら同じ現象が起こるでしょー。
              > 少し違うと思います。
              > Cで動的に確保されたメモリブロックは、明示的に解放しない限り、(少なくとも)そのプロセスの生存中は回収されないのに対して、Javaの場合は、他から参照されなくなったオブジェクトは、ガベージコレクタによって自動的に回収されます。(そもそも、解放するという操作自体がない)

              ?よく意味が分からん。
              短時間では問題はないが、長時間動かすとVMが落ちるようなプログラム、
              というのは明らかにメモリを食い潰しているのであって、
              C でこれと同じ状況は「解放忘れ」で簡単に起こる、というだけのことだろう。

              > > Java は free を呼ぶ替わりに使わなくなったポインタに逐一 null を入れろ、ってだけ。
              > これも、ガベージコレクタがオブジェクトを回収する際の「ヒント」を与えるために使われるテクニックであって、必ずしなければならない、というものではありません。

              一般論ではもちろんそうだが、
              メモリ不足でVMが落ちる、なんて状況では必須だろう
              (そうでなければGCが回収しているはずなんだから)。

              #「ポインタ」は不適切だったな。すまん
              --
              # mishimaは本田透先生を熱烈に応援しています
              親コメント
        • GCの必要性 (スコア:2, 参考になる)

          by goodlife (5595) on 2002年02月15日 12時34分 (#63086) 日記
          GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
          GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。
          GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが,メモリフラグメンテーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。

          C++ でマルチスレッドプログラムを書く時のメモリ管理の難しさといったら。まあ,気にしなくても動きますけど(皮肉なことに)。

          親コメント
          • by G7 (3009) on 2002年02月15日 14時57分 (#63154)
            >GC を単にメモリリークを防ぐためのものと考えると大したありがたみはありませんが,メモリフラグメン
            >テーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。

            え?

            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:開放タイミングを決定するのが結構面倒なプログラミング形態も、ある。

            ので、あーゆーものは、(プログラマの技量次第というよりも(笑))状況次第で、凄く欲しくなると思うんですが。
            親コメント
            • by nasb (3002) on 2002年02月15日 15時26分 (#63162) 日記
              > > メモリフラグメンテーションを防ぐためのものと考えれば,その恩恵は計り知れないと思います。

              (中略)

              > フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるか
              > どうかは GCのアルゴリズム次第であって、GC一般の性質ではない、と読め
              > ますけど?

              元コメントは、フラグメンテーションがプログラマに不可視になることを言いたかったんだと、愚考します。

              # 違ったらどうしよう。^_^;

              新しいjavaコマンド(VM)は並列GCを実装していますね。どんなアルゴリズムを使ってるんでしょうか。興味があります。106CPUでもちゃんと動いてくれるでしょうか。:-)
              親コメント
            • > によると、フラグメンテーションを無くす機能(つーか嬉しい副作用?)を期待できるかどうかは
              > GCのアルゴリズム次第であって、GC一般の性質ではない、と読めますけど?

              GC がどのようなアルゴリズムで行われるにせよ、compaction は
              行われてるのではないでしょうか? compaction されるというこ
              とは、その時点でフラグメンテーションも解消される、ということ
              ですよね?違う?

              Java の Heap に関しては、激しくオブジェクトの生成/回収を
              繰り返してもフラグメンテーションによって新規オブジェクトが
              生成できない、とゆー事態には陥ったことがないため漠然とそう
              思ってたんですけど…。

              UNIX のようにプロセスを起こすコストが結構大きい OS がサーバ
              で主流な昨今、比較的容易にお行儀のいい長寿命プロセスを作成
              出来る Java は非常に有用だと思います。
              --
              Only Jav^Hpanese available :-)
              親コメント
              • by nasb (3002) on 2002年02月15日 20時31分 (#63293) 日記
                > GC がどのようなアルゴリズムで行われるにせよ、compaction は 行われて るのではないでしょうか?

                いいえ。G7さんが紹介してくれましたURLがよい資料なので、詳しくは そちらを見てください。ここでは簡単に言いますと、GCは古典的には、

                1. Reference Count (被参照数が0になったオブジェクトを回収)
                2. Mark & Sweep (生きているオブジェクトにマークをつけ、最終的にマークがつかなかったオブジェクトを回収)
                3. Copying (生きているオブジェクトを別の領域に詰めながらコピーして、元の領域をまとめて回収)
                の3種類がありまして、他の多くのバリエーションもこれらの何らかの発展形 になってます。このうち、1.と2.はcompactionしません。
                親コメント
              • > このうち、1.と2.は compactionしません。

                実際に 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 :-)
                親コメント
              • by G7 (3009) on 2002年02月16日 13時46分 (#63516)
                >ご存じの通り Java にはポインタがありませんから、C でのよう
                >にプログラム側でフラグメンテーションに対処することが非常に難しく、

                ああ。メモリプールというか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, 参考になる)

            by Anonymous Coward on 2002年02月15日 18時30分 (#63232)
            よく理解できません。

            > GCを利点として挙げる人がいますが、それも僕はどうかと思っています。
            > GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。

            これは、null なのに使おうとしたって事で、C++とJavaに差は余り無い気がします。
            GCとは関係ないのでは?

            > 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。

            これは、メモリリークしているということだとすると、GCのおかげで、それは無くなるんではないでしょうか?
            メモリが無くなっているとしても、直接には、別の原因でVMが落ちているのでは無いでしょうか?

            GCのおかげで、deleteを書かなくて良いとか、ポインタ変数を、参照出来なくなっても良いとか言うのはかなり良いと思います。

            それと、APIまでJava言語に含まれているおかげで、スレッドも大抵のJavaの本で触れられているし、C++に比べ簡単になること自体で本の内容がそれを埋める分だけ色々増えているのは良いです。
            親コメント
            • by k6p (7828) on 2002年02月16日 2時28分 (#63411)
              # 親コメント [srad.jp]の位置がおかしいと思います(goodlifeさんのコメント [srad.jp]に対してではなく、loginPenguinさんのコメント [srad.jp]に対するものですよね?)が、それはともかく、
              > GCがあるためにむちゃくちゃなプログラムでもある程度動いてしまいます。

              これは、null なのに使おうとしたって事で、C++とJavaに差は余り無い気がします。
              GCとは関係ないのでは?
              関係はあると思います。
              ガベージコレクタがオブジェクトの回収をやってくれるおかげで、メモリリークが顕在化しにくくなったため、オブジェクトの管理がいい加減なプログラムでも、それなりに動いてしまう、という話では?
              で、その結果、真綿で首を絞めるように、回収されない(できない)オブジェクトがじわじわと蓄積して、
              > 1時間ぐらいだったら動くけど長時間動かしているとVMが落ちることがありますし、その時のバグを見つけるのが非常に大変です。
              となると。

              「Java(の)メモリリーク」などと呼ばれるようです。

              # 私自身は「だからGCに利点はそれほどない」とは思いませんが。
              親コメント
        • by hatoku (1188) on 2002年02月15日 12時50分 (#63095) 日記
          >次に移植性です。
          >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でやってたな
          親コメント
      • by mark (4383) on 2002年02月15日 22時17分 (#63349)
        > いっかい問い詰め

        「修正してやる」、んじゃないの?
        親コメント

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

処理中...