Javaはもう死んだの?

1 デフォルトの名無しさん 2018/04/29(日) 04:48:48 ID:
どうなのよ

2 デフォルトの名無しさん 2018/04/29(日) 13:23:53 ID:
死にかけ

3 デフォルトの名無しさん 2018/04/29(日) 13:25:10 ID:
なんで?

4 デフォルトの名無しさん 2018/04/29(日) 14:22:00 ID:
oracle

5 デフォルトの名無しさん 2018/04/30(月) 03:50:36 ID:
死んだというか殺されかけてる

6 デフォルトの名無しさん 2018/04/30(月) 13:15:56 ID:
生きてる

7 デフォルトの名無しさん 2018/04/30(月) 14:29:26 ID:
>>3
Oracleがライセンス料をせしめるために、リリースモデルを変更した。
>>6のいうように今はまだ生きているが、>>2,5のいうように殺されかけているというのも事実。
Java8のOracleからの無償サポートが切れる頃には>>1に先見の明があったと言うことになるかもしれない。
すなわち、お前はもう死んでいると。

8 デフォルトの名無しさん 2018/04/30(月) 15:41:57 ID:

9 デフォルトの名無しさん 2018/04/30(月) 16:02:05 ID:
SIerの次の選択肢はなんだろう

10 デフォルトの名無しさん 2018/05/01(火) 01:12:08 ID:
マジかよ今勉強中なんだけど

11 デフォルトの名無しさん 2018/05/01(火) 04:53:30 ID:
>>8
リンク先見てきたけど、公開されているビルドの日付が2017年とかになっているんだが、
そんな装備で大丈夫か?

12 デフォルトの名無しさん 2018/05/01(火) 07:52:44 ID:

13 デフォルトの名無しさん 2018/05/01(火) 23:09:17 ID:
死んでないどころかよく使われてるのに
金を取るとか元締めが言い出すから
みんな悪口を言ってるんだよ

14 デフォルトの名無しさん 2018/05/02(水) 17:43:06 ID:
OpenJDK を Windows で使うにはどうすればいいですか?

15 デフォルトの名無しさん 2018/05/08(火) 06:15:15 ID:
>>13
まだ生きているが、Javaの取り柄である互換性の堅持が捨てられて、同じバージョンを使うためだけに
金をむしられるようになった時点で、将来的な死が確定したも同然。

16 デフォルトの名無しさん 2018/05/08(火) 07:45:50 ID:
>>15
OpenJDKつこたらええやんけ
開発者に金が回るのはええことやし
製品にもその金が落とされるってことやで
ええことづくめやん
SUNのように潰れるよりよっぽどマシ

17 デフォルトの名無しさん 2018/05/08(火) 08:10:36 ID:
>>16
LTSのプランすらまだ固まってないのに?

18 デフォルトの名無しさん 2018/05/08(火) 11:04:50 ID:
今後のAndroidアプリって、何で作るのがいいの?

19 デフォルトの名無しさん 2018/05/08(火) 14:57:59 ID:
googleは一時期OpenJDK推奨とかやってた気がするが

20 デフォルトの名無しさん 2018/05/08(火) 15:01:03 ID:
最悪小鳥でも構わんけどソースコンバータ用意してくり

21 デフォルトの名無しさん 2018/05/08(火) 17:18:50 ID:
>>16
OpenJDK を Windows にビルドできますか?

22 デフォルトの名無しさん 2018/05/08(火) 18:51:01 ID:
死んでないからこそ悪口を言われる言語

23 デフォルトの名無しさん 2018/05/16(水) 21:34:46 ID:
死んだよ。

24 デフォルトの名無しさん 2018/05/17(木) 12:47:27 ID:
いつかは死ぬと思うけどもうしばらくは生きそう

25 デフォルトの名無しさん 2018/05/18(金) 00:26:57 ID:
グーグルが敵対的買収して中のゴミを全部切ればいいのに

26 デフォルトの名無しさん 2018/05/18(金) 06:09:03 ID:
>>25
互換性を保つためにゴミすら切らない。だから、一度覚えれば末永く使える。それがJavaのいいところ。
Jigsawによってモジュール化されたゴミを切りやすくなった。
Googleの買収を待つまでもなく、Oracleが色んな物を切り捨て始めた。
そして切り捨て前のバージョンを使いたければ金を払えと。
Javaは死んだ。あるいは今生きているとしても死ぬことが確定した。

27 デフォルトの名無しさん 2018/05/20(日) 11:06:14 ID:
(目先の利益で言語寿命を削るような決断したゴミ経営を)全部切ればいいのに

28 デフォルトの名無しさん 2018/05/21(月) 15:00:31 ID:
Pythonに抜かれました

29 デフォルトの名無しさん 2018/05/22(火) 00:52:19 ID:
無料でなければ、プログラミング言語は死ぬのか…

30 デフォルトの名無しさん 2018/05/22(火) 05:25:37 ID:
>>29
まともな言語は有料のものしかなかった昔ならともかく、今時有料の言語が生き残る余地はない。

31 デフォルトの名無しさん 2018/05/22(火) 11:35:00 ID:
ク、CUDA...

実質有料

32 ◆QZaw55cn4c 2018/05/22(火) 18:35:55 ID:
>>31
今 VC++ でコンパイルできないみたいなんだが

33 デフォルトの名無しさん 2018/05/23(水) 19:17:23 ID:
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』

JL2IM

34 デフォルトの名無しさん 2018/05/23(水) 20:28:44 ID:
と、いうか…
無償を前提にして開発されたシステムやアプリケーションがサクッと死ぬか死にかけると思う。

35 デフォルトの名無しさん 2018/05/24(木) 22:21:48 ID:
有償ってのはFUDでしょ?
>>8によればオラクル、IBM、レッドハット等のメジャーなOpenJDKのベンダーがAdoptOpenJDKに参加するっていう
OpenJDKは永久に不滅

36 デフォルトの名無しさん 2018/05/25(金) 05:17:59 ID:
>>35
半年ごといろんな機能が切り捨てられて非互換になっていく言語で開発しようと思う人は少ない。

37 デフォルトの名無しさん 2018/05/25(金) 17:15:30 ID:
>>36
そういう間違った認識する人には難しいだろうな

38 デフォルトの名無しさん 2018/05/25(金) 22:38:19 ID:
実際には互換性を大事にするあまり
J2SE 1.4ぐらいの頃のゴミを今でも引きずっている

まだ若かったC#が互換性を破壊してまでジェネリクスを実装したのに対し
結構長く続いていたJavaは互換性を維持するために型パラメータを消去するという
それはそれで強引なやり方でジェネリクスを実装
これは型が実行時に分からなくなる、性能が悪くなると言ったデメリットがある
今でも改善されてない

39 デフォルトの名無しさん 2018/05/26(土) 02:13:26 ID:
もともと10年ほど前から有用性を感じなくなった
java使わなくてもいい
もっといい言語いっぱいある

40 デフォルトの名無しさん 2018/05/26(土) 11:22:15 ID:
しかし世界で人気あるのは今でもjavaが圧倒的に1位
30年後はどうなっているかわからんけど、人気ある言語を使うべき
なんのためにプログラミングしてるのかを考えれば疑問は起こらない

41 デフォルトの名無しさん 2018/05/26(土) 11:27:39 ID:

42 デフォルトの名無しさん 2018/05/26(土) 12:29:37 ID:
>>41
それ2017年じゃん
都合悪くなると昔のランキング出してくるんだなw

https://furien.jp/columns/385/

43 デフォルトの名無しさん 2018/05/26(土) 12:48:49 ID:
>>41はGoogle SearchやGoogle Trend、GitHub、Twitterなど10のオンラインソースが元
>>42はチュートリアルの検索回数

44 デフォルトの名無しさん 2018/05/26(土) 12:58:39 ID:
>>42
PYPL引っ張ってくるならそれこそ最新版を出そうよ
http://pypl.github.io/PYPL.html

45 デフォルトの名無しさん 2018/05/26(土) 13:01:49 ID:
>>44
そうくると思ったけどさあ、誤差じゃん
3位以下なんて太刀打ちできないんだけど

そもそもjavaは世の中のインフラから医療や宇宙産業まであらゆるもので使われてるから無くすことができない
pythonなんてたかがAIの波に乗っただけじゃん

46 ◆QZaw55cn4c 2018/05/26(土) 15:30:08 ID:
>>38
>Javaは互換性を維持するために型パラメータを消去するという
>やり方でジェネリクスを実装

>これは型が実行時に分からなくなる、
実行時に型情報は基本的に不要なのでは?

>性能が悪くなると言ったデメリットがある
なぜ性能が悪くなるの?というか、本当に性能が悪くなるの?どういう現象から「悪くなった」と判断したの?

47 デフォルトの名無しさん 2018/05/26(土) 16:11:51 ID:
>>46
Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する

値型は型パラメータに出来ず一旦オブジェクトに変換されるため
より速度低下が深刻
そのためInt型だけを扱うListクラスが作られたりする
二度手間だが仕方ない

型パラメータがコンパイル時に消されるため
当然ながらリフレクションで型パラメータを知る事は出来ない

48 ◆QZaw55cn4c 2018/05/26(土) 16:27:47 ID:
>>47
>Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する
それはコンパイル時のチェックではないか?

>型パラメータがコンパイル時に消される
のであれば実行時に型をチェックすることはできないし、していないのではないか?

49 デフォルトの名無しさん 2018/05/26(土) 21:59:14 ID:
>>48
コンパイル時にリスト変数を使う関数自体に型チェックの命令を入れる

ジェネリクスが無いときは手動でリストから取ったデータを目的の型にキャストしていたが
このチェックを自分で書かなくて良くなっただけとも言える

実際、リスト操作で生成されるバイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする

リスト変数自体には型パラメータの情報は存在しないので
リフレクションでは型パラメータを取り出せない

50 ◆QZaw55cn4c 2018/05/26(土) 22:37:20 ID:
>>49
>コンパイル時にリスト変数を使う関数自体に型チェックの命令を入れる

それは本当ですか?それを裏付ける資料はありますか?
「型チェックの命令を入れる」とのことですが、jvm 言語仕様上はどんな命令になるのですか?

ジェネリクスが無いときは、リスト取得時に
>目的の型にキャストしていた
そのとおりだが、実際に実行コードが増えるわけではない、あくまでソース文面での整合をとるためだけなのではないですか?

>バイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする
つまり「型チェックの命令を入れ」ないのではないですか?

51 ◆QZaw55cn4c 2018/05/26(土) 23:11:00 ID:
>>47
>Listに値を出し入れする時に正しい型かをチェックするので不必要なオーバーヘッドが発生する
オーバーヘッドというのは実行時の計算リソースの追加消費のことですよね

>>49
>リスト操作で生成されるバイトコードはジェネリクス使ってないコードと使ってるコードで同じになったりする

この二つは矛盾しますよね

52 デフォルトの名無しさん 2018/05/27(日) 07:01:10 ID:
>>12
Docker用のファイルしかないみたいなんですが。

新着レスの表示
■トップページに戻る■ お問い合わせ/削除依頼