アカウント名:
パスワード:
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替えるJavaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
>共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、今作り直していつまでそのまま動くやらね。。。。
>後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな?むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。一つもあげられないに100ペリカ。
>ガベコレがある言語なんて採用して大丈夫なんだろうか。>処理時間保証とかできるのだろうか?こっちも同様。FUDお疲れ。
キャッシュのあるCPUを使って、仮想記憶のあるOSを使ってれば、ハードリアルタイム性の保証はできねーよ。証券取引所みたいにms単位の動作保証が必要なら別だけど、その場合はハードやDBレベルから特注じゃね。
そもそもCOBOLシステムって、そこまでのリアルタイム性を保証してるか?「次の日の朝までに終わらせる」みたいなバッチ処理とか多いんじゃないの?99%以上はコンカレントなGCを使えば十分だと思うけどね。
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
> Thread.stopメソッドは、リリース1.2以降廃止されています
1.2って何年前だよむしろ下位互換性を重要視している実証なんじゃないの、これw
〉むしろ下位互換性を重要視している実証なんじゃないの、これwその通りでも、彼は「一つもあげられない」に賭ちゃったからしょうがないね
> むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
deprecated なメソッドがいつまでも残ってたり、1.5 で generics 導入したのに VM の互換性維持に傾注して、バイトコードでは型情報消えてるくらいなのにね。そでも互換が大事だったってのはすごくよく分かる。実際 Java の言語仕様は超安定してる。
(標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
> (標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、> フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
たぶん、org.foo.hoge.* を使ってたら、いつの間にかJSRに入ってて、APIが変わって、javax.huga.* になったが、org.foo の更新が止まって、新しい Java に対応しなくなって、古いプログラムが動かなくなった人だよ。(非標準の機能が標準に入って仕様が変わった)
昔のJavaあるあるだよ。でもこれは、Java言語自体の後方互換性の問題じゃないからな。
そういうの今でもあるけどそれはJCPが悪い。仕様もRIも更新止まってるのにBD-Jの実装の一部としてだけは残ってるJMFとか
> APIをなかなか切り捨てない
切り捨てられずに残りっぱなしで同等の別の物が…とかはあるけどね。Swingとかももうそういうフェーズにはいってるんだろうか。
でも実際コンパイルオプションに動作バージョン指定があったし互換性はなるべくなんとかするようにしてると思う。Java自体は。
参考までに非互換いろいろ。8は他の人もあげてるけど、基本的に開いたとこ以降全部が非互換なので(言語だけじゃなくて、ランタイムの話とかもでてきてるけど、とりあえず先頭のThread.stopだけ見てもしょうがない)
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com] http://www.oracle.com/technetwork/jp/java/javase/jdk7-relnotes-418459-... [oracle.com]
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ? -- Debian初級
Java死すべし (スコア:0)
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替える
Javaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。
>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。
共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
Re: (スコア:0)
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
>共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
今作り直していつまでそのまま動くやらね。。。。
FUD乙 (スコア:0, 興味深い)
>後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな?
むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。
一つもあげられないに100ペリカ。
>ガベコレがある言語なんて採用して大丈夫なんだろうか。
>処理時間保証とかできるのだろうか?
こっちも同様。FUDお疲れ。
キャッシュのあるCPUを使って、仮想記憶のあるOSを使ってれば、ハードリアルタイム性の保証はできねーよ。
証券取引所みたいにms単位の動作保証が必要なら別だけど、その場合はハードやDBレベルから特注じゃね。
そもそもCOBOLシステムって、そこまでのリアルタイム性を保証してるか?
「次の日の朝までに終わらせる」みたいなバッチ処理とか多いんじゃないの?
99%以上はコンカレントなGCを使えば十分だと思うけどね。
100ペリカ払ってね (スコア:1)
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
Re:100ペリカ払ってね (スコア:1)
> Thread.stopメソッドは、リリース1.2以降廃止されています
1.2って何年前だよ
むしろ下位互換性を重要視している実証なんじゃないの、これw
Re: (スコア:0)
〉むしろ下位互換性を重要視している実証なんじゃないの、これw
その通り
でも、彼は「一つもあげられない」に賭ちゃったからしょうがないね
Re: (スコア:0)
> むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
deprecated なメソッドがいつまでも残ってたり、
1.5 で generics 導入したのに VM の互換性維持に傾注して、バイトコードでは型情報消えてるくらいなのにね。
そでも互換が大事だったってのはすごくよく分かる。実際 Java の言語仕様は超安定してる。
(標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、
フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
Re:FUD乙 (スコア:1)
> (標準以外の)ライブラリやフレームワークの流行り廃りが激しいし、
> フルスクラッチはやだもんなので、そのレイヤで困ることは多いけど。
たぶん、org.foo.hoge.* を使ってたら、いつの間にかJSRに入ってて、APIが変わって、javax.huga.* になったが、org.foo の更新が止まって、新しい Java に対応しなくなって、古いプログラムが動かなくなった人だよ。(非標準の機能が標準に入って仕様が変わった)
昔のJavaあるあるだよ。
でもこれは、Java言語自体の後方互換性の問題じゃないからな。
Re: (スコア:0)
そういうの今でもあるけどそれはJCPが悪い。
仕様もRIも更新止まってるのにBD-Jの実装の一部としてだけは残ってるJMFとか
Re: (スコア:0)
> APIをなかなか切り捨てない
切り捨てられずに残りっぱなしで同等の別の物が…とかはあるけどね。
Swingとかももうそういうフェーズにはいってるんだろうか。
でも実際コンパイルオプションに動作バージョン指定があったし互換性はなるべくなんとかするようにしてると思う。
Java自体は。
参考までに非互換いろいろ。
8は他の人もあげてるけど、基本的に開いたとこ以降全部が非互換なので(言語だけじゃなくて、ランタイムの話とかもでてきてるけど、とりあえず先頭のThread.stopだけ見てもしょうがない)
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
http://www.oracle.com/technetwork/jp/java/javase/jdk7-relnotes-418459-... [oracle.com]