jonykatz曰く、"Cnetの記事によれば、SunがとうとうJavaプログラミング言語のコンパイラである「javac」とJava HotSpot Virtual Machineを2006年末までにオープンソース化するとのことだ。ライセンスはまだ不明。Javaに関してはオープンソース陣営から批判をあびることが多かったが、今回のjavacのオープンソース化はかなり前進であるように見える。"
基盤ができた、と (スコア:5, 興味深い)
オープンソースにするとき、怖いのが
ちょっとした改変の派生バージョンが沢山できてしまい
開発リソースが分かれて、結局全体の開発スピードが
落ちてしまうこととか、ユーザも分かれてしまって
Javaで開発する側も、それぞれのJVM毎の対応を迫られたりしてしまうことだと思うんです。
そうならないためには、オープンソースにしたとしても
中心的なJVMとして、派生JVMを振り切って先頭を走って
開発し続けて、デファクトスタンダードの地位を
キープし続けないとダメだと思う。
今回、Mustang [java.net]開発で培ったコミュニティとの接点と
開発サイクルで、その自信が付いたから
オープンソース化することにしたんじゃないかなぁ。
タイミングとしてはそんな印象を受けます。
Re:基盤ができた、と (スコア:2, すばらしい洞察)
べつに派生バージョンが沢山できてしまって
収拾がつかなくなっている、ということは
ないと思いますよ。
perl、ruby、python、tcl/tk、などなど。
それにJavaなんて、もともとたくさんの
バージョン間で互換性がなくて混乱しているという
現状がありますから、逆にオープンソースな新
バージョンではそれを吸収できるような仕組みが
できないかな、と思ってみたりとか。
Re:基盤ができた、と (スコア:2, おもしろおかしい)
Ruby : 言うほど流行っていないから誰も見向きもしない
Python : Foundationがあって知材管理や方向付けがしっかりしている
tcl/tk : まだあったの？
こんなかんじかな
Re:基盤ができた、と (スコア:1, 参考になる)
Re:基盤ができた、と (スコア:0)
Re:基盤ができた、と (スコア:0)
と続きそうだな
バージョン間で互換性がなくて混乱している (スコア:1, おもしろおかしい)
Re:バージョン間で互換性がなくて混乱している（フレームの元） (スコア:0, すばらしい洞察)
Windowsなんか同一プラットフォーム間でも互換性がないぞ。
Re:バージョン間で互換性がなくて混乱している（フレームの元） (スコア:0, オフトピック)
Re:基盤ができた、と (スコア:0)
はやかったなぁって思う (スコア:2, すばらしい洞察)
ライセンスをクリアにするのって、結構お金かけてるよね。
Re:基盤ができた、と (スコア:2, 参考になる)
よくそういう心配を耳にしますが、開発リソースが分かれるとムダということはみんなわかってますから、実際にforkする事例ってそんなに聞いたことありません。いや、2つぐらいに分かれる事例はそこそこありますけど、3つ以上はほとんど聞いたことがありません。VNCぐらいなんじゃない?
forkが後退とは限らない (スコア:1, 興味深い)
OSSに出資してる企業の側からしたら、forkの可能性ってのは厄介かもしれないけど。
Re:基盤ができた、と (スコア:0)
Re:基盤ができた、と (スコア:1)
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)
1 仮fork(俺fork)
2 しばらくunofficial版/patchとして公開
3 本家に投げる
4a 本家に入る
-> fork終了(して本家追っかけ)
-> branchとして継続して定期的に本家と同期 -> 全部入ったらfork終了
4b 本家に入らない
-> マジfork
という流れかと。
「本家に入らない」のは、方針の違いだったり投げ方が悪かったりすることもあるけど、単にレスポンスが悪いだけのことも。
たとえばlinux kernelなんかCPU/archの数だけforkがある（あった）んじゃないの？
キモはforkじゃなくて、fork後に合流できるかどうかじゃなかろうか。
短期的には「ちょっとした改変の派生バージョンが沢山できて」しまっても、中長期的には「その改変をすべて（よく使われるほとんど）含むバージョン」がデファクトとなり、それに収束すると思う。（なぜなら、派生版をメンテし続けるより上流とマージした方がたいていは開発が楽だから）
それが本家であるかforkであるかは不明だが。
fork がマズイ場合、マズクない場合 (スコア:0)
fork する事により、ある種の規格互換性が失われて、それが利用者世界で大きな不都合となる場合はマズイって事で。 Sunが（表向きに）発言している理由ですよね。
forkっていうか、特殊ケースだけど。
Bugzilla-ja はオリジナル Bugzilla を日本語対応させたコードだけど、本家で運用している Bugizlla は多言語で運用してはいないので（多言語で議論交わす訳にはいかないｗ）本家へ patch を返すような事はしてないんじゃないかな。 本家で利用される可能性は少ないし、patchマージ＆以後の維持を本家に背負わせるコスト（Bugzillaメンテナが多言語に精通しているとは限らないし）、patch 投げるコスト、色々考えると毎回日本語化の枝を生やすのも選択肢としてはアリかなぁと。
個別の事情によって、あらゆる面でfork が最適解というのはありえるかなぁと。
Re:fork がマズイ場合、マズクない場合 (スコア:1)
特殊ケースではなく、むしろ非常によくあるパターンだと思います。
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でとりあえず動かすのに有効ですが（イニシャルコストが低い）、本家追随ｘバージョンアップが毎回かかる（ランニングコストが高い）ので長期的には死亡パターンかと（本家の開発が止まってたら別ですが）。
OSSの代替品が迫ってきてからオープン化 (スコア:3, 興味深い)
あまりいいパターンだとは思えない。
「代替品をOSSで」という動き自体がなんというか、ねえ。
Re:OSSの代替品が迫ってきてからオープン化 (スコア:0)
Re:OSSの代替品が迫ってきてからオープン化 (スコア:1)
Re:OSSの代替品が迫ってきてからオープン化 (スコア:1)
商用(Sun,BEA,IBM)のものに比べれば、まだまともに使えるレベルではないと思うけど。
# Blackdownは知らないので違ったらごめん
Re:OSSの代替品が迫ってきてからオープン化 (スコア:0)
ちなみに、gcjというのはGCCによるJava互換環境で、
OpenOfficeなんかはこれで普通にコンパイル、利用
できるんだとか。
個人的にはmonoとかgnashとかにも頑張ってほしいなぁ。
質問 (スコア:2, 興味深い)
プロプライエタリなモジュール（Re:質問 (スコア:2, 参考になる)
脊髄反射コメント、乙。
さて、「ただし、」以降の事を考えると、既存ライセンスのうち選択可能なものは絞られてくるような気がする。 そのプロプライエタリなモジュールってのは、モジュールという表現から考えてソースコード形式ではなくバイナリコードで提供される可能性があるって事と推測すべきなのかもしれん。
それはそうと、件の記事の末尾でBEA SystemsとIBMについて言及しているけど、BEA Systemsは VM はオリジナルでもライブラリは Sun からライセンスを受けて Sun のものを使ってたんじゃなかったっけ？ 変わった？
Re:プロプライエタリなモジュール（Re:質問 (スコア:0)
コミュニティが十分こなれて来たら、ここの部分をごっそり置き換えたりしないんだろうか。まあ、デリケートな部分は置いておくにしても、フォントの表示なんて既存の技術でいくらでも代替が利きそうなものだが。
# いっそのことGeckoやspidermonkeyも積んで…
Re:プロプライエタリなモジュール（Re:質問 (スコア:1, 興味深い)
SpiderMonkey (Mozilla JavaScript Engine/C) じゃなくて、Rhino (Mozilla JavaScript Engine/Java) が Java SE6 "Mustang" に同梱されるんじゃなかったっけ？
Rhino は OpenOffice.org にも入っているみたいだし、何気に Rhino の配布数が爆発的に増えそうな予感。 Firefox よりも多くなったりしてｗ （これでどこかの有力ソフトが GRE を同梱してくれればｗ）
年末？ (スコア:1, 参考になる)
プリインストールに期待 (スコア:1)
Java はライセンスの問題でそれが出来なかった。
これが今まで Java でアプリ開発する際の懸念でした。
今回の OSS 化と、ライセンスの変更で市販PCへの Java Runtime のプリインストールが進むと良いなぁと期待しています。
Re:プリインストールに期待 (スコア:2, 興味深い)
Re:プリインストールに期待 (スコア:2, 参考になる)
DELLの台数シェアを考えるとそれなり数のPCにはSun Javaが入ってると考えてもいいんじゃ。
-- siu
Re:プリインストールに期待 (スコア:0)
素の環境がほしくて買ったときはAcrobat Reader並みにじゃまだがね。
Re:プリインストールに期待 (スコア:0)
あと、バンドルするなら、Firefoxかなぁ。
Re:プリインストールに期待 (スコア:0)
Re:プリインストールに期待 (スコア:0)
実行バイナリを配布するにあたって発生する義務を実行するのが困難だ、と判断されるケースがあるとバンドルは難しいんじゃないですかね。
例えばバイナリと共に同じ方法でソースも配布せよ、というライセンスだと（収録媒体の都合とかで）場合によっては難しい・・って。 GPLv3はそういう内容だったような。修正されたんだっけか？
Re:プリインストールに期待 (スコア:0)
とりあえず何も変わらない？ (スコア:1)
J2SEのライブラリ部分がオープンソースになると、また違うんだろうけどね。
あんな巨大なものを各社で作るのはあほらしい。頑張りどころでもないし。
つーか、今もSunに金払って買ってるのかな？
# ときに、JCPとかどーなるんだろ
要するに (スコア:0)
Re:要するに (スコア:1)
Can you over the wall?
Re:要するに (スコア:3, おもしろおかしい)
Re:要するに (スコア:0)
極々少数の人を除くと8,000円でオーケーになる
って知ってて言ってるんでしょ？
Re:要するに (スコア:0)
Re:要するに (スコア:1)
そもそも、元々Javaではライセンス料取ってないし。
オープンソース化するものを間違えた (スコア:0)
Re:オープンソース化するものを間違えた (スコア:0)
認定の厳密性をどこまで必要とするか。
CSSのAcidみたく、「うちの製品はクリアした」と開発元が宣言するだけでみんながほぼ満足するなら、無償利用可能とするだけでいいんじゃない？
そうじゃなくて信頼できる機関が互換性試験クリアを認証しているという事実が必要とされるなら、どこかの誰かが認定プロセスを維持しなければならないし、開発元が自称しているだけではあまり価値が無い。
自由に使えるようになっていれば自分で実行してチェックするという手段はあるけどね。 でもそれは容易に実行できるものなのか、いちいちコストをかけなければいけないって