パスワードを忘れた? アカウント作成
13160 story

javacとHotSpot JVMがオープンソース化 45

ストーリー by kazekiri
流れは止まらない 部門より

jonykatz曰く、" Cnetの記事によれば、 Sunがとうとう Javaプログラミング言語のコンパイラである「javac」 とJava HotSpot Virtual Machineを 2006年末までにオープンソース化するとのことだ。 ライセンスはまだ不明。 Javaに関してはオープンソース陣営から批判をあびることが多かったが、 今回のjavacのオープンソース化はかなり前進であるように見える。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by kicchy (4711) on 2006年08月16日 16時34分 (#997772)
    前向きに考えると、

    オープンソースにするとき、怖いのが
    ちょっとした改変の派生バージョンが沢山できてしまい
    開発リソースが分かれて、結局全体の開発スピードが
    落ちてしまうこととか、ユーザも分かれてしまって
    Javaで開発する側も、それぞれのJVM毎の対応を迫られたりしてしまうことだと思うんです。

    そうならないためには、オープンソースにしたとしても
    中心的なJVMとして、派生JVMを振り切って先頭を走って
    開発し続けて、デファクトスタンダードの地位を
    キープし続けないとダメだと思う。

    今回、Mustang [java.net]開発で培ったコミュニティとの接点と
    開発サイクルで、その自信が付いたから
    オープンソース化することにしたんじゃないかなぁ。
    タイミングとしてはそんな印象を受けます。
    • Re:基盤ができた、と (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2006年08月16日 16時57分 (#997794)
      オープンソースな言語なんていくつもあるけど、
      べつに派生バージョンが沢山できてしまって
      収拾がつかなくなっている、ということは
      ないと思いますよ。

      perl、ruby、python、tcl/tk、などなど。

      それにJavaなんて、もともとたくさんの
      バージョン間で互換性がなくて混乱しているという
      現状がありますから、逆にオープンソースな新
      バージョンではそれを吸収できるような仕組みが
      できないかな、と思ってみたりとか。
      親コメント
    • by Anonymous Coward on 2006年08月16日 16時57分 (#997795)
      Sunじゃない権利関係のコードもあってオープンソースにしづらいって聞いていたから、頑張ったなぁって感じです。

      ライセンスをクリアにするのって、結構お金かけてるよね。
      親コメント
    • by itoshikazu (15602) on 2006年08月16日 18時15分 (#997878)
      オープンソースにするとき、怖いのが ちょっとした改変の派生バージョンが沢山できてしまい 開発リソースが分かれて、結局全体の開発スピードが 落ちてしまうこととか、ユーザも分かれてしまって Javaで開発する側も、それぞれのJVM毎の対応を迫られたりしてしまうことだと思うんです。

      よくそういう心配を耳にしますが、開発リソースが分かれるとムダということはみんなわかってますから、実際にforkする事例ってそんなに聞いたことありません。いや、2つぐらいに分かれる事例はそこそこありますけど、3つ以上はほとんど聞いたことがありません。VNCぐらいなんじゃない?

      親コメント
      • by Anonymous Coward on 2006年08月16日 19時23分 (#997934)
        むしろ、プロジェクトの行き詰まりを打破するきっかけになることもあるんじゃなかろうか。Xorgなんかは、forkしてから開発速度が上がったような気がするし。

        OSSに出資してる企業の側からしたら、forkの可能性ってのは厄介かもしれないけど。
        親コメント
      • *BSDとか
    • by bero (5057) on 2006年08月18日 5時17分 (#999029) 日記
      本家の開発あるいは外部開発者からのパッチの取り込みが十分に迅速であれば、
      forkは起こらないか、起きてもデファクトスタンダードであり続けるでしょう。
      そうでなければ一番迅速なforkがデファクトになって事実上乗っ取られるでしょう。

      完全乗っ取り:
      - gcc -> egcs -> gcc (egcsがgccという名前になり、旧gccは死亡)

      デファクト乗っ取り:
      - 386BSD -> FreeBSD他
      - NCSA httpd -> Apache
      - XFree86 -> x.org
      - Pascal -> Object Pascal -> Delphi

      fork失敗?:
      - postgresql -> rhdb(redhat database) -> 死亡?

      差別化して並存:
      - emacs -> xemacs
      - NetBSD -> OpenBSD
      - Linux -> embbeded Linux
      - foo -> foo for XXX (XXX=windows等)
      - サッカー -> ラグビー

      差別化してたけど本家が独自部分を取り込んだら事実上死亡:
      - emacs -> nemacs,mule
      - Linux -> embbeded LinuxのXXX(kernel 2.4のforkでpreemptでrealtimeにしたけど、kernel 2.6ではsmp対応のついでにpreemptにもなったので意味なし、等)
      - hoge -> hoge-ja

      実は乗っ取り:
      - 個人プロジェクト等で本家(創始者)より外部patchの開発速度の方が速い場合、ソイツをプロジェクトメンバ/メンテナにして創始者は逃げる -> 俺
      親コメント
    • forkってそんなにマズイこと?実はしょっちゅうおこってんじゃないの?
      1 仮fork(俺fork)
      2 しばらくunofficial版/patchとして公開
      3 本家に投げる
      4a 本家に入る
      -> fork終了(して本家追っかけ)
      -> branchとして継続して定期的に本家と同期 -> 全部入ったらfork終了
      4b 本家に入らない
      -> マジfork
      という流れかと。
      「本家に入らない」のは、方針の違いだったり投げ方が悪かったりすることもあるけど、単にレスポンスが悪いだけのことも。

      たとえばlinux kernelなんかCPU/archの数だけforkがある(あった)んじゃないの?
      キモはforkじゃなくて、fork後に合流できるかどうかじゃなかろうか。

      短期的には「ちょっとした改変の派生バージョンが沢山できて」しまっても、中長期的には「その改変をすべて(よく使われるほとんど)含むバージョン」がデファクトとなり、それに収束すると思う。(なぜなら、派生版をメンテし続けるより上流とマージした方がたいていは開発が楽だから)
      それが本家であるかforkであるかは不明だが。
      親コメント
      • fork する事により、ある種の規格互換性が失われて、それが利用者世界で大きな不都合となる場合はマズイって事で。 Sunが(表向きに)発言している理由ですよね。

        forkっていうか、特殊ケースだけど。
        Bugzilla-ja はオリジナル Bugzilla を日本語対応させたコードだけど、本家で運用している Bugizlla は多言語で運用してはいないので(多言語で議論交わす訳にはいかないw)本家へ patch を返すような事はしてないんじゃないかな。 本家で利用される可能性は少ないし、patchマージ&以後の維持を本家に背負わせるコスト(Bugzillaメンテナが多言語に精通しているとは限らないし)、patch 投げるコスト、色々考えると毎回日本語化の枝を生やすのも選択肢としてはアリかなぁと。

        個別の事情によって、あらゆる面でfork が最適解というのはありえるかなぁと。

        • bugzilla-jaはよく知らなかったのでちょいと調べてみたんですが
          特殊ケースではなく、むしろ非常によくあるパターンだと思います。

          fork(*1)
            l10nなlocal fork
            仮に本家に投げてもlocal杉なので蹴られる
            そのうち死亡

          本家にi18n入る(または入れる)

          fork(*1)はステてfork(*2)して作り直し
          「オマイラはutf8にしさえすればi18nと思っとんのか!」と文句言いながらja修正(*3)
          fork(*2)版をユーザに使ってもらってja部分のバグ出し ← 今ここ
          本家に投げる
          ja開発者は独自メンテしなくてよくなってハッピー
          本家でCJKのCK部分ができる(*3でちゃんとやってれば不要かも)
          jaだけでなくCJK全部の利用者が使えてハッピー

          fork(*1)を独自メンテするのは短期的にはquick hackでとりあえず動かすのに有効ですが(イニシャルコストが低い)、本家追随xバージョンアップが毎回かかる(ランニングコストが高い)ので長期的には死亡パターンかと(本家の開発が止まってたら別ですが)。
          親コメント
  • by Anonymous Coward on 2006年08月16日 16時22分 (#997763)
    「OSSの代替品が出てきてしまったから、それが普及して影響力を失わないように、シェアを握っているプロプライエタリソフトをオープン化」というパターンになってしまった気が。
    あまりいいパターンだとは思えない。
    「代替品をOSSで」という動き自体がなんというか、ねえ。
  • 質問 (スコア:2, 興味深い)

    by Anonymous Coward on 2006年08月16日 17時54分 (#997848)
    「javac」とJava HotSpot Virtual Machine、という言い方は、ライブラリ群は含まれないということでしょうか?
    • by Anonymous Coward on 2006年08月16日 19時23分 (#997935)

      脊髄反射コメント、乙。

      サン、Javaのオープンソース化計画を拡大 - CNET Japan [cnet.com]
      Tolson氏によると、Java SEソフトウェアのフルパッケージは2007年前半、それもたぶん早い時期に、オープンソース化される予定だという。 ただし、画面上にフォントを表示するためのソフトウェアなど、一部のコンポーネントについては、Sunは権利を保有していないため、オープンソースソフトウェアにプロプライエタリなモジュールを添えることになるだろう、とTolson氏は述べた。
      以上、強調表現は我(オレ)

      さて、「ただし、」以降の事を考えると、既存ライセンスのうち選択可能なものは絞られてくるような気がする。 そのプロプライエタリなモジュールってのは、モジュールという表現から考えてソースコード形式ではなくバイナリコードで提供される可能性があるって事と推測すべきなのかもしれん。

      それはそうと、件の記事の末尾でBEA SystemsとIBMについて言及しているけど、BEA Systemsは VM はオリジナルでもライブラリは Sun からライセンスを受けて Sun のものを使ってたんじゃなかったっけ? 変わった?

      親コメント
      • 画面上にフォントを表示するためのソフトウェア

        コミュニティが十分こなれて来たら、ここの部分をごっそり置き換えたりしないんだろうか。まあ、デリケートな部分は置いておくにしても、フォントの表示なんて既存の技術でいくらでも代替が利きそうなものだが。

        # いっそのことGeckoやspidermonkeyも積んで…
        • by Anonymous Coward on 2006年08月16日 20時09分 (#997974)
          # いっそのことGeckoやspidermonkeyも積んで…

          SpiderMonkey (Mozilla JavaScript Engine/C) じゃなくて、Rhino (Mozilla JavaScript Engine/Java) が Java SE6 "Mustang" に同梱されるんじゃなかったっけ?

          Rhino は OpenOffice.org にも入っているみたいだし、何気に Rhino の配布数が爆発的に増えそうな予感。 Firefox よりも多くなったりしてw (これでどこかの有力ソフトが GRE を同梱してくれればw)

          親コメント
  • 年末? (スコア:1, 参考になる)

    by Anonymous Coward on 2006年08月16日 16時24分 (#997764)
    10月までに [slashdot.org]と聞いたのだが、どこかで話が食い違ったのだろうか。
  • 今どき .NET Framework はOSと一緒にプリインストールされてるPCが多いですが、
    Java はライセンスの問題でそれが出来なかった。
    これが今まで Java でアプリ開発する際の懸念でした。

    今回の OSS 化と、ライセンスの変更で市販PCへの Java Runtime のプリインストールが進むと良いなぁと期待しています。

  • JVMに関しては、IBMもBEAもずっと独自でやってるので、いまさらSunベースにするとも思えない。

    J2SEのライブラリ部分がオープンソースになると、また違うんだろうけどね。
    あんな巨大なものを各社で作るのはあほらしい。頑張りどころでもないし。
    つーか、今もSunに金払って買ってるのかな?

    # ときに、JCPとかどーなるんだろ
  • by Anonymous Coward on 2006年08月16日 17時14分 (#997808)
    javaは金にならないから捨て
  • by Anonymous Coward on 2006年08月17日 8時53分 (#998230)
    認定試験の問題をオープンソース化すればもう少し人が集まったかもしれないのにね。javacをオープンソースにしても(ライセンスによるけど)野良バージョンが増えるだけではないですか?
    • 認定の厳密性をどこまで必要とするか。

      CSSのAcidみたく、「うちの製品はクリアした」と開発元が宣言するだけでみんながほぼ満足するなら、無償利用可能とするだけでいいんじゃない?

      そうじゃなくて信頼できる機関が互換性試験クリアを認証しているという事実が必要とされるなら、どこかの誰かが認定プロセスを維持しなければならないし、開発元が自称しているだけではあまり価値が無い。

      自由に使えるようになっていれば自分で実行してチェックするという手段はあるけどね。 でもそれは容易に実行できるものなのか、いちいちコストをかけなければいけないって

typodupeerror

※ただしPHPを除く -- あるAdmin

読み込み中...