アカウント名:
パスワード:
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替えるJavaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
＞共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、今作り直していつまでそのまま動くやらね。。。。
＞後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな？むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。一つもあげられないに１００ペリカ。
＞ガベコレがある言語なんて採用して大丈夫なんだろうか。＞処理時間保証とかできるのだろうか？こっちも同様。FUDお疲れ。
キャッシ
> むしろ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とか
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
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とやらを具体的に挙げてからにしなさい。
一つもあげられないに１００ペリカ。
＞ガベコレがある言語なんて採用して大丈夫なんだろうか。
＞処理時間保証とかできるのだろうか？
こっちも同様。FUDお疲れ。
キャッシ
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とか