アカウント名:
パスワード:
AdoptOpenJDKAWSRed Hat(利用者のみ)Azure(利用者のみ)Oracle(有償)IBM(有償?、独自VM)Azul Systems(有償)Google(Androidのみ)
OpenJDKのソースコードがGPLということを考えると、分断されすぎでは…。利用者としては、一元化してもらったほうが安心できるんだけど。有償のところや独自VMのところは何も言わんが、せっかく無償のAWSがAdoptOpenJDKに合流しないのは、なんとも残念感がある。
なぜ統合する必要がある。その全部のVMで動作するのがJavaではないか。
元コメ主だけど、GPLで、かつメンテナンスリリース(機能変更なし)なのだから、結局、ひとつの組織が出したバグフィックスの大部分を他の組織も取り込むのでは? そうしない理由はないよね。
どのベンダもお互いのパッチを取り込むのなら、独自リリースするのは意味に乏しいし、ユーザーに対してあまり正直ではない。だったら素直に合流してほしいってこと。そもそも、たかがメンテナンスリリースでここまで分断するのは異常だ。
一歩譲って、各ベンダーが独自コードベースを持ってもいいけど、upstreamの統合コードベースは維持してほしい。プログラミング言語においては、各ベンダが独自路線に走って、微妙な非互換性が発生するのはマイナスが大きいと思う。ブラウザやかつてのC/C++コンパイラはひどいものだった。あれを繰り返してほしくない。ブラウザやC/C++は代替がないから嫌々でも使われるけど、今のJavaはそこまでの地位にないし。
というか有償の場合でも、コードは統合されたものを使って、ヘルプデスクや緊急バグフィクス対応でお金をもらえばいいと思う。それだけでもサポートとしては十分で、そのためだけにお金を払う組織はたくさんあるよ。
#ちなみにAmazonはバグフィクスだけなく独自の改善をすると言っていて、やめてくれ…と思っている。
Javaの仕様は大きく言語仕様と中間言語の仕様とJavaVMの仕様がありますアマゾンの主張によればその全てで互換性を確保しているようなのでまあ問題ないのではないかとあと仕様には準拠しつつも実装が違うとよそのパッチを取り込むなんてことは当然できないね
Sun の時代から Java って TCK(互換性テストみたいなもん)が全て通らなくてもJava名乗っていいんだよ。時期によって TCK も変更されるし、通さなくてもいいテストのリストも随時更新される。声の大きい一部のベンダーの実装だと、テストを通せないってなると、簡単に除外リストに入るんだよね。
Sun の時代から、互換性なんてクソほどにも考えられた運用じゃなかったよ。ずっと互換性に問題があるから本家以外を使うと動かないってのが当たり前だったんだよ。まぁ、本家の使うと、プラットホーム変わってもだいたい動くけど、バージョン上がると動かないってのがよくあったのだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
ありがたいけど、各ベンダーでばらばらにやらないで統合してほしい (スコア:0)
AdoptOpenJDK
AWS
Red Hat(利用者のみ)
Azure(利用者のみ)
Oracle(有償)
IBM(有償?、独自VM)
Azul Systems(有償)
Google(Androidのみ)
OpenJDKのソースコードがGPLということを考えると、分断されすぎでは…。
利用者としては、一元化してもらったほうが安心できるんだけど。
有償のところや独自VMのところは何も言わんが、
せっかく無償のAWSがAdoptOpenJDKに合流しないのは、なんとも残念感がある。
Re: (スコア:0)
なぜ統合する必要がある。その全部のVMで動作するのがJavaではないか。
Re:ありがたいけど、各ベンダーでばらばらにやらないで統合してほしい (スコア:0)
元コメ主だけど、GPLで、かつメンテナンスリリース(機能変更なし)なのだから、
結局、ひとつの組織が出したバグフィックスの大部分を他の組織も取り込むのでは? そうしない理由はないよね。
どのベンダもお互いのパッチを取り込むのなら、独自リリースするのは意味に乏しいし、ユーザーに対してあまり正直ではない。
だったら素直に合流してほしいってこと。そもそも、たかがメンテナンスリリースでここまで分断するのは異常だ。
一歩譲って、各ベンダーが独自コードベースを持ってもいいけど、upstreamの統合コードベースは維持してほしい。
プログラミング言語においては、各ベンダが独自路線に走って、微妙な非互換性が発生するのはマイナスが大きいと思う。
ブラウザやかつてのC/C++コンパイラはひどいものだった。あれを繰り返してほしくない。
ブラウザやC/C++は代替がないから嫌々でも使われるけど、今のJavaはそこまでの地位にないし。
というか有償の場合でも、コードは統合されたものを使って、ヘルプデスクや緊急バグフィクス対応でお金をもらえばいいと思う。
それだけでもサポートとしては十分で、そのためだけにお金を払う組織はたくさんあるよ。
#ちなみにAmazonはバグフィクスだけなく独自の改善をすると言っていて、やめてくれ…と思っている。
Re: (スコア:0)
Javaの仕様は大きく言語仕様と中間言語の仕様とJavaVMの仕様があります
アマゾンの主張によればその全てで互換性を確保しているようなのでまあ問題ないのではないかと
あと仕様には準拠しつつも実装が違うとよそのパッチを取り込むなんてことは当然できないね
Re: (スコア:0)
Sun の時代から Java って TCK(互換性テストみたいなもん)が全て通らなくてもJava名乗っていいんだよ。時期によって TCK も変更されるし、通さなくてもいいテストのリストも随時更新される。
声の大きい一部のベンダーの実装だと、テストを通せないってなると、簡単に除外リストに入るんだよね。
Sun の時代から、互換性なんてクソほどにも考えられた運用じゃなかったよ。
ずっと互換性に問題があるから本家以外を使うと動かないってのが当たり前だったんだよ。
まぁ、本家の使うと、プラットホーム変わってもだいたい動くけど、バージョン上がると動かないってのがよくあったのだけど。