Javaはもう死んだの?
■ このスレッドは過去ログ倉庫に格納されています
>>3
Oracleがライセンス料をせしめるために、リリースモデルを変更した。
>>6のいうように今はまだ生きているが、>>2,5のいうように殺されかけているというのも事実。
Java8のOracleからの無償サポートが切れる頃には>>1に先見の明があったと言うことになるかもしれない。
すなわち、お前はもう死んでいると。 >>8
リンク先見てきたけど、公開されているビルドの日付が2017年とかになっているんだが、
そんな装備で大丈夫か? 死んでないどころかよく使われてるのに
金を取るとか元締めが言い出すから
みんな悪口を言ってるんだよ OpenJDK を Windows で使うにはどうすればいいですか? >>13
まだ生きているが、Javaの取り柄である互換性の堅持が捨てられて、同じバージョンを使うためだけに
金をむしられるようになった時点で、将来的な死が確定したも同然。 >>15
OpenJDKつこたらええやんけ
開発者に金が回るのはええことやし
製品にもその金が落とされるってことやで
ええことづくめやん
SUNのように潰れるよりよっぽどマシ >>16
LTSのプランすらまだ固まってないのに? 今後のAndroidアプリって、何で作るのがいいの? googleは一時期OpenJDK推奨とかやってた気がするが 最悪小鳥でも構わんけどソースコンバータ用意してくり >>16
OpenJDK を Windows にビルドできますか? グーグルが敵対的買収して中のゴミを全部切ればいいのに >>25
互換性を保つためにゴミすら切らない。だから、一度覚えれば末永く使える。それがJavaのいいところ。
Jigsawによってモジュール化されたゴミを切りやすくなった。
Googleの買収を待つまでもなく、Oracleが色んな物を切り捨て始めた。
そして切り捨て前のバージョンを使いたければ金を払えと。
Javaは死んだ。あるいは今生きているとしても死ぬことが確定した。 (目先の利益で言語寿命を削るような決断したゴミ経営を)全部切ればいいのに >>29
まともな言語は有料のものしかなかった昔ならともかく、今時有料の言語が生き残る余地はない。 >>31
今 VC++ でコンパイルできないみたいなんだが 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
JL2IM と、いうか…
無償を前提にして開発されたシステムやアプリケーションがサクッと死ぬか死にかけると思う。 有償ってのはFUDでしょ?
>>8によればオラクル、IBM、レッドハット等のメジャーなOpenJDKのベンダーがAdoptOpenJDKに参加するっていう
OpenJDKは永久に不滅 >>35
半年ごといろんな機能が切り捨てられて非互換になっていく言語で開発しようと思う人は少ない。 >>36
そういう間違った認識する人には難しいだろうな 実際には互換性を大事にするあまり
J2SE 1.4ぐらいの頃のゴミを今でも引きずっている
まだ若かったC#が互換性を破壊してまでジェネリクスを実装したのに対し
結構長く続いていたJavaは互換性を維持するために型パラメータを消去するという
それはそれで強引なやり方でジェネリクスを実装
これは型が実行時に分からなくなる、性能が悪くなると言ったデメリットがある
今でも改善されてない もともと10年ほど前から有用性を感じなくなった
java使わなくてもいい
もっといい言語いっぱいある しかし世界で人気あるのは今でもjavaが圧倒的に1位
30年後はどうなっているかわからんけど、人気ある言語を使うべき
なんのためにプログラミングしてるのかを考えれば疑問は起こらない >>41
それ2017年じゃん
都合悪くなると昔のランキング出してくるんだなw
https://furien.jp/columns/385/ >>41はGoogle SearchやGoogle Trend、GitHub、Twitterなど10のオンラインソースが元
>>42はチュートリアルの検索回数 >>44
そうくると思ったけどさあ、誤差じゃん
3位以下なんて太刀打ちできないんだけど
そもそもjavaは世の中のインフラから医療や宇宙産業まであらゆるもので使われてるから無くすことができない
pythonなんてたかがAIの波に乗っただけじゃん >>38
>Javaは互換性を維持するために型パラメータを消去するという
>やり方でジェネリクスを実装
>これは型が実行時に分からなくなる、
実行時に型情報は基本的に不要なのでは?
>性能が悪くなると言ったデメリットがある
なぜ性能が悪くなるの?というか、本当に性能が悪くなるの?どういう現象から「悪くなった」と判断したの? >>46
Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する
値型は型パラメータに出来ず一旦オブジェクトに変換されるため
より速度低下が深刻
そのためInt型だけを扱うListクラスが作られたりする
二度手間だが仕方ない
型パラメータがコンパイル時に消されるため
当然ながらリフレクションで型パラメータを知る事は出来ない >>47
>Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する
それはコンパイル時のチェックではないか?
>型パラメータがコンパイル時に消される
のであれば実行時に型をチェックすることはできないし、していないのではないか? >>48
コンパイル時にリスト変数を使う関数自体に型チェックの命令を入れる
ジェネリクスが無いときは手動でリストから取ったデータを目的の型にキャストしていたが
このチェックを自分で書かなくて良くなっただけとも言える
実際、リスト操作で生成されるバイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする
リスト変数自体には型パラメータの情報は存在しないので
リフレクションでは型パラメータを取り出せない >>49
>コンパイル時にリスト変数を使う関数自体に型チェックの命令を入れる
それは本当ですか?それを裏付ける資料はありますか?
「型チェックの命令を入れる」とのことですが、jvm 言語仕様上はどんな命令になるのですか?
ジェネリクスが無いときは、リスト取得時に
>目的の型にキャストしていた
そのとおりだが、実際に実行コードが増えるわけではない、あくまでソース文面での整合をとるためだけなのではないですか?
>バイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする
つまり「型チェックの命令を入れ」ないのではないですか? >>47
>Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する
オーバーヘッドというのは実行時の計算リソースの追加消費のことですよね
>>49
>リスト操作で生成されるバイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする
この二つは矛盾しますよね >>12
Docker用のファイルしかないみたいなんですが。 CORBA, JavaFXの次はJava8の目玉の一つだったNashornまで切り捨てるらしい。
ttp://openjdk.java.net/jeps/335
これはもうだめかもわからんね。 >>16
OpenJDKなんて、ワザと不具合仕込まれたモンキーモデルやん。あんなの使えるか。 オラクルに金を払えば3年間は安泰らしい…
は?金払ってたったの3年????3年ぽっち????
普通5年以上10年未満だろ…
まぁ、Javaの出版社やクズライターが苦悩するな、確実に。
「JavaXX対応!!」
というオビだけすげかえて、裏表紙をめくると「2015年 初版」などという詐欺商法が流行するであろう。 ■ このスレッドは過去ログ倉庫に格納されています