あるAnonymous Coward 曰く、損害保険ジャパン日本興亜が、コスト削減や効率性向上のためCOBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替えるそうだ（日経ITpro）。数年をかけて順次移行する計画で、現在のシステムでは年間で500億円以上もの保守費用がかかっているらしい。このプロジェクトは2015年4月からスタートしており、今年10月にはこのプロジェクトのために日立と合弁会社を設立するなどしている（発表PDF）。
COBOL に罪は無い (スコア:3, 興味深い)
古いシステムだから場当たり対応繰り返して、手が付けられなくなったって話で
どの言語からスタートしてても同じことだと思う。
Javaでも10年選手のシステムだと、リプレースするかこのまま続けてくかに悩まされてる。
Re: (スコア:0)
構造化も出来ない頃のコードとかもあるし
悪いのは更新してこなかった企業だな
Re:COBOL に罪は無い (スコア:1)
機能に直接関係しない更新が行えるのは、リプレース時だけです。
Re: (スコア:0)
同じことしてたら同じ未来が来るわけで、Javaのフレームワークの寿命なんてもっと短いし
ロックインされるって意味では同じだし。
それこそStruts1なシステムをこの先もずーーーーっと保守していく人もいるんだろうね。
「過去ソースの保守はやめて新規開発する」ってだけの話ですよね。 (スコア:2)
まあ，なんでJavaやねん，とも思ったが，
裾野が広いつーか，揃えられる頭数でいったら，Javaは良い選択しかもしれない。
ただ，他言語より人員の質がピンキリな気もするが…
ガベコレの件も含め，余所が真似したくなるような結果になると良いですね。
Java死すべし (スコア:0)
>COBOLで組まれたシステムの大半をJavaやオープンプラットフォームへ切り替える
Javaかぁ、Java…… うーん、Javaなぁ…… なんでJavaなんだろうなぁ……
あと、ITProのコメント欄がすごい。
>なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。
共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
Re:Java死すべし (スコア:2)
俗人化の反対は尊師化だろう (スコア:2)
俗人化の反対を考えると、聖人化か、仙人化か、尊師化でしょう。
髪型から尊師を考えるとRichard M. Stallman [google.co.jp]ですよね。
Re:俗人化の反対は尊師化だろう (スコア:2)
聖イグヌチウス調べました。なるほどrmsは聖人でしたね。勉強不足でした、すみません。
Re: (スコア:0)
"仙人か"? "専任化"のtypoですか?
Re: (スコア:0)
属人化のtypo俗人化を皮肉っているだけですよ。
Javaが俗人ならCobolはなんだ？って。
Re:Java死すべし (スコア:1)
属人化が俗人化してるのは置いといて、
自分の周りじゃJava書けない人は見たこと無いけど、COBOL書ける人は皆無だな。
このコメント書いた人の職場ってどこなんだろう。
大手ベンダーの大型ホスト担当の部署で、他の部署を見たことも無いような人かな？
もう二十年近く前、この業界入りたての頃にCOBOL書かされたけど
ベンダーやバージョン別の方言？みたいなのが酷くて面倒くさかった。
統一規格みたいのがあるということになってるのに、何だったんだあれは。
あれに比べりゃJavaのほうが圧倒的にマシだろう。
Re:Java死すべし (スコア:1)
今のJavaの価値の99%はJVMの価値、
こと並列処理において、こなれたJITコンパイラと、規格化されたメモリ一貫性モデル、高速なコンカレントGCを備えたJVMに勝るものはない。
現在において、シングルスレッドで間に合わないプログラムは、JVM上で実行するのが最善であり、
JVMを使用しない場合、生産性、保守性共に多大なディスアドバンテージを負うのである。
Re: (スコア:0)
Javaにしたら年間保守費が倍になったりしてｗ
ガベコレがある言語なんて採用して大丈夫なんだろうか。
処理時間保証とかできるのだろうか？
Re: (スコア:0)
運用が始まってから、リソースリークで目も当てられないことになるのか。
Re: (スコア:0)
銀行のオンラインシステムならともかく保険会社のシステムなら応答速度のシビアさはそんなに求められないのでは。
Re:Java死すべし (スコア:2)
Re: (スコア:0)
まぁ、今ではCOBOLほとんど使われないので、COBOLかけない人もいっぱいいると思う。
＞共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
そう思う。
後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
今作り直していつまでそのまま動くやらね。。。。
Re: (スコア:0)
> 後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので
それは発展途上の言語ならばどれも同じじゃない？
PHPであってもそれは同じ。
Re:Java死すべし (スコア:1)
業務システムなら私も発展途上の言語でプログラム作るのは間違いだと思うな。
Re: (スコア:0)
発展途上ならねぇ…
Re: (スコア:0)
きちんと設計された言語なら、後方互換性は保証されているでしょ。
ロードマップもひかず場当たり的な変更をしてるから、そうなるんですよ。
FUD乙 (スコア:0, 興味深い)
＞後、JAVAはコロコロバージョンあげてしかも平気で過去のAPIを切り捨てるので、
ウソばっか。
たぶん使ったことの無い人のご意見だね。やっぱCOBOLerのFUDかな？
むしろJavaは過去との互換性が高くて、APIをなかなか切り捨てないことで有名なんだが。
違うというなら、まずはその切り捨てた過去のAPIとやらを具体的に挙げてからにしなさい。
一つもあげられないに１００ペリカ。
＞ガベコレがある言語なんて採用して大丈夫なんだろうか。
＞処理時間保証とかできるのだろうか？
こっちも同様。FUDお疲れ。
キャッシ
100ペリカ払ってね (スコア:1)
http://www.oracle.com/technetwork/jp/java/javase/overview/8-compatibil... [oracle.com]
Re:100ペリカ払ってね (スコア:1)
> Thread.stopメソッドは、リリース1.2以降廃止されています
1.2って何年前だよ
むしろ下位互換性を重要視している実証なんじゃないの、これｗ
Re: (スコア:0)
〉むしろ下位互換性を重要視している実証なんじゃないの、これｗ
その通り
でも、彼は「一つもあげられない」に賭ちゃったからしょうがないね
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)
引用訂正：ITProのコメントは
なぜにCOBOLからJAVAに替えれば、IT投資が減るのか意味わかりません。COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。JAVAのが俗人化すると思いますが。。
共通オブジェクトの設計こそ、高度なプログラマーでなければ無理ですが。。
までです。
Re:Java死すべし (スコア:2)
> COBOL書けない人は見た事ないけど
EXCEL使えないって人は見た事ないけど
って話に聞こえる。
Re:Java死すべし (スコア:1)
うちの周りは、JAVA書けない人は見た事ないけど、COBOLかけない人は多数います・・・
＃なんか、日本人が「日本語書けない人は見たことないけど、英語をかけない人は多数います。」、
＃アメリカ人が「英語書けない人は見たことないけど、日本語をかけない人は多数います。」って言ってるのと同じ気がしてきた
Re: (スコア:0)
これCOBOL書いてる人の発言だろうな
＞COBOL書けない人は見た事ないけどJAVAを書けない人は多数います。
こんな人見たこと無いわ。
逆に、Java書ける人ならいっぱい知ってるけど、COBOL書ける人見たこと無いわ。
＞JAVAのが俗人化
俗人化なんて今時言う？
今コード見てる中小会社のコードだと俗人化してて笑うけど、
それなりの企業なら俗人化なんて今時あり得ないよ。
Re:Java死すべし (スコア:2)
自分みたく，Androidアプリのプログラミング止まりでも
Javaが使える，には違いないわけだし。
金融システム経験のあるプログラマでJavaが使えるのがいない，ってえのも，いるだろ？普通？みたいな。
フロントエンド作ってるやつらは使えるだろ？
一から作るんだから，ちゃんと金融システムを策定できるシステムエンジニアの存在こそが必要なんであって，
言語がどうの，ってのは，それこそシステムにしたときのパフォーマンスとかそういう部分の話になるだけで，
プログラマーなんざどうとでも集められるというか。
Re: (スコア:0)
Re: (スコア:0, すばらしい洞察)
Re: (スコア:0)
先に言っとく。
(#2900985) の人気に嫉妬
Re: (スコア:0)
> なのに言葉をそのまんまに捉えて「COBLOerなんてそんなにいないよ！」とか
いや、「COBOL書けない人は見た事ない」って人もいるってば。
Re:Java死すべし (スコア:1)
勉強したのにJava書けないけどCOBOLは書けるというのは、頭を使わずにルールに従ってなにか書き写す作業をしているだけの人だから、別にいなくていい。
Re: (スコア:0)
> オープンプラットフォームへ切り替える
open cobol ってあったよなと、調べたら、
2013年から gnu cobol に変わったって、書いてあった。
こういうのじゃ、性能的にダメなんかね？
Re:Java死すべし (スコア:1)
食わず嫌いな気がする
Javaができる人なら、COBOLなんて教科書を一通り読めばすぐソースを読めるくらいの難度の言語でしょ
逆は無理な場合もありますが。
GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わない
JavaなのにソースがCOBOLに見えてくるようなのでいいのならですけど
…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思う
Re: (スコア:0)
>>GCが何とか言っている人もいるけど、COBOLからそのまま移植するならガベージアウトするような変数は使わない
Javaのプログラマでそこまで質のいいのを数揃えるのは不可能ですｗ
＃「そこまで質のいい」＝「その程度のことがなんとか理解できる」
Re: (スコア:0)
文法的には仰る通り、COBOLは単純な言語だと思います。
COBOL79準拠のソースを見たりすると正直かなり頭痛がする事間違いなし。
＃サブルーチンの概念がないので、GOTOでそれっぽく処理するとか
>…という問題ではなく、多分COBOLソースから仕様書をひねり出すのが大仕事なのだと思う
まさにこれだと思います。
Re: (スコア:0)
gnu cobolに変更することでコストが抑えられるのならやる意味があるんじゃないでしょうか。
Re: (スコア:0)
性能よりも責任の所在が不明確なのがまずいのでは。
Re: (スコア:0)
費用面が移行の主な理由でしょ。COBOLやれる奴なんていまどきほとんどいないから、
高単価の高齢プログラマー抱えてるところと言い値で契約するしかないんじゃない?
ベンダーロックイン状態で酷い目に遭ってるから、そう言う状況を改善したいんじゃないかな。
それよりも気になる社名 (スコア:0)
社名を短くしたら結構な経費削減になるんじゃないかと思うの
今考えた新社名 (スコア:2)
今考えた新社名を12文字以内で書いてみました。
「損害保険日々興亜」...悪くない。漢字で落ち着く保守的社名。
「損害保険ジャパジャパコア」...テーマソング作りやすい。ラッキィ池田が振付を考案。
「損保ジャジャコー」...モンスターぽいので新キャラとしてポケモンに参戦。
Re: (スコア:0)
年末調整の欄に書くときいつも困る
Re: (スコア:0)
「株式会社三菱UFJフィナンシャル・グループ」も株主総会の質問で指摘されていたな。
回答したのは「株式会社三菱UFJフィナンシャル・グループ取締役代表執行役社長グループCEO」だったけど。
Re:それよりも気になる社名 (スコア:3, おもしろおかしい)
略称は「大損」か