アカウント名:
パスワード:
AdoptOpenJDKAWSRed Hat(利用者のみ)Azure(利用者のみ)Oracle(有償)IBM(有償?、独自VM)Azul Systems(有償)Google(Androidのみ)
OpenJDKのソースコードがGPLということを考えると、分断されすぎでは…。利用者としては、一元化してもらったほうが安心できるんだけど。有償のところや独自VMのところは何も言わんが、せっかく無償のAWSがAdoptOpenJDKに合流しないのは、なんとも残念感がある。
なぜ統合する必要がある。その全部のVMで動作するのがJavaではないか。
そして、その理想が現実とは程遠いのが Java ではないか。
サーバサイドなら普通に動くだろ。動かないとしたらJava界以外のDBやミドルウェアとかシステムの自体に問題がある。
>サーバサイドなら普通に動くだろ。
お、新人かな?
うごかないJREのマイナーバージョン違いで不具合が出て修正の為のスケジュール遅延から、マジモンの損害賠償になったプロジェクトを知っているので
以前Pure JavaのプログラムがTru64 UNIX版JVMで動くのにSunのx64のJVMで動かなくて難儀したことがある。
少なくとも他の言語を使ったことがあったら、そんなセリフは出ないだろう。
むしろjavaが異常なほど高い互換性を持っていて、他の環境に移るときでも「書き直さない」という習慣ができてしまった。
動くことを期待してるから、互換性問題が話題になる。期待さえされてない環境だと、試そうとスラしない。
OSに依存しない部分のプログラムは大概どの言語も普通に動くよ。Javaは一回書けばどこでも動くを高らかに宣言した割に、じゃあWindowsで開発したモジュールがMacでそのまま動くの?と言われればいやそれはちょっと…ってなる。
最初からマルチOS意識して書く前提ならJavaの利点って何だっけ?ってことになる。
> むしろjavaが異常なほど高い互換性を持っていて、
ここが笑いとろうとしたとこ?
新人さん、いらっしゃ~い
10年後「・・・そんなふうに考えていた時期が俺にもありました」
元コメ主だけど、GPLで、かつメンテナンスリリース(機能変更なし)なのだから、結局、ひとつの組織が出したバグフィックスの大部分を他の組織も取り込むのでは? そうしない理由はないよね。
どのベンダもお互いのパッチを取り込むのなら、独自リリースするのは意味に乏しいし、ユーザーに対してあまり正直ではない。だったら素直に合流してほしいってこと。そもそも、たかがメンテナンスリリースでここまで分断するのは異常だ。
一歩譲って、各ベンダーが独自コードベースを持ってもいいけど、upstreamの統合コードベースは維持してほしい。プログラミング言語においては、各ベン
Javaの仕様は大きく言語仕様と中間言語の仕様とJavaVMの仕様がありますアマゾンの主張によればその全てで互換性を確保しているようなのでまあ問題ないのではないかとあと仕様には準拠しつつも実装が違うとよそのパッチを取り込むなんてことは当然できないね
Sun の時代から Java って TCK(互換性テストみたいなもん)が全て通らなくてもJava名乗っていいんだよ。時期によって TCK も変更されるし、通さなくてもいいテストのリストも随時更新される。声の大きい一部のベンダーの実装だと、テストを通せないってなると、簡単に除外リストに入るんだよね。
Sun の時代から、互換性なんてクソほどにも考えられた運用じゃなかったよ。ずっと互換性に問題があるから本家以外を使うと動かないってのが当たり前だったんだよ。まぁ、本家の使うと、プラットホーム変わってもだいたい動くけど、バージョン上がると動かないってのがよくあったのだけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ありがたいけど、各ベンダーでばらばらにやらないで統合してほしい (スコア:0)
AdoptOpenJDK
AWS
Red Hat(利用者のみ)
Azure(利用者のみ)
Oracle(有償)
IBM(有償?、独自VM)
Azul Systems(有償)
Google(Androidのみ)
OpenJDKのソースコードがGPLということを考えると、分断されすぎでは…。
利用者としては、一元化してもらったほうが安心できるんだけど。
有償のところや独自VMのところは何も言わんが、
せっかく無償のAWSがAdoptOpenJDKに合流しないのは、なんとも残念感がある。
Re:ありがたいけど、各ベンダーでばらばらにやらないで統合してほしい (スコア:0)
なぜ統合する必要がある。その全部のVMで動作するのがJavaではないか。
Re:ありがたいけど、各ベンダーでばらばらにやらないで統合してほしい (スコア:1)
そして、その理想が現実とは程遠いのが Java ではないか。
Re: (スコア:0)
サーバサイドなら普通に動くだろ。
動かないとしたらJava界以外のDBやミドルウェアとかシステムの自体に問題がある。
Re: (スコア:0)
>サーバサイドなら普通に動くだろ。
お、新人かな?
Re: (スコア:0)
うごかない
JREのマイナーバージョン違いで不具合が出て修正の為のスケジュール遅延から、マジモンの損害賠償になったプロジェクトを知っているので
Re: (スコア:0)
以前Pure JavaのプログラムがTru64 UNIX版JVMで動くのにSunのx64のJVMで動かなくて難儀したことがある。
Re: (スコア:0)
少なくとも他の言語を使ったことがあったら、そんなセリフは出ないだろう。
むしろjavaが異常なほど高い互換性を持っていて、
他の環境に移るときでも「書き直さない」という習慣ができてしまった。
動くことを期待してるから、互換性問題が話題になる。
期待さえされてない環境だと、試そうとスラしない。
Re: (スコア:0)
OSに依存しない部分のプログラムは大概どの言語も普通に動くよ。
Javaは一回書けばどこでも動くを高らかに宣言した割に、じゃあWindowsで開発したモジュールがMacでそのまま動くの?
と言われればいやそれはちょっと…ってなる。
最初からマルチOS意識して書く前提ならJavaの利点って何だっけ?ってことになる。
Re: (スコア:0)
> むしろjavaが異常なほど高い互換性を持っていて、
ここが笑いとろうとしたとこ?
Re: (スコア:0)
新人さん、いらっしゃ~い
Re: (スコア:0)
10年後
「・・・そんなふうに考えていた時期が俺にもありました」
Re: (スコア:0)
元コメ主だけど、GPLで、かつメンテナンスリリース(機能変更なし)なのだから、
結局、ひとつの組織が出したバグフィックスの大部分を他の組織も取り込むのでは? そうしない理由はないよね。
どのベンダもお互いのパッチを取り込むのなら、独自リリースするのは意味に乏しいし、ユーザーに対してあまり正直ではない。
だったら素直に合流してほしいってこと。そもそも、たかがメンテナンスリリースでここまで分断するのは異常だ。
一歩譲って、各ベンダーが独自コードベースを持ってもいいけど、upstreamの統合コードベースは維持してほしい。
プログラミング言語においては、各ベン
Re: (スコア:0)
Javaの仕様は大きく言語仕様と中間言語の仕様とJavaVMの仕様があります
アマゾンの主張によればその全てで互換性を確保しているようなのでまあ問題ないのではないかと
あと仕様には準拠しつつも実装が違うとよそのパッチを取り込むなんてことは当然できないね
Re: (スコア:0)
Sun の時代から Java って TCK(互換性テストみたいなもん)が全て通らなくてもJava名乗っていいんだよ。時期によって TCK も変更されるし、通さなくてもいいテストのリストも随時更新される。
声の大きい一部のベンダーの実装だと、テストを通せないってなると、簡単に除外リストに入るんだよね。
Sun の時代から、互換性なんてクソほどにも考えられた運用じゃなかったよ。
ずっと互換性に問題があるから本家以外を使うと動かないってのが当たり前だったんだよ。
まぁ、本家の使うと、プラットホーム変わってもだいたい動くけど、バージョン上がると動かないってのがよくあったのだけど。