今更の議論

まさか仕事中に、検査例外と非検査例外の議論が出るとは思わなかった。
監視用ログに出力されていないエラーが存在し、エラーログのみに出力される例外が存在し、それがRuntimeExceptionを継承した例外クラスだったから、RuntimeExceptionがいけないんだと。
いや、それ、単に例外のキャッチ方針と監視用ログへの出し方の問題でしょ。いくら監視用ログへ出力する内容を精査したいからって、業務ＡＰで細やかにハンドリングした結果、Catchが漏れたルート存在したから、RuntimeExceptionが悪いって、短絡過ぎる議論だったので、検査例外がJava言語の失敗の一つという結論は１０年前には出ましたし、事実、Java以外では検査例外は実装されていません、と一言（嘘、二言）で一蹴しておいた。（もちろん、本心ではそんなことは思っていないが、まま仕方なし。）

ところで、１１月から上司が変わったのだが、エンタープライズな開発にJavaは向いていないという点で、その上司と意気投合してしまった。かと言って、新しい言語を作っても、会社から爪弾きにされる（過去事例あり）し、どうしたものかねと会話をしていた。システム開発って、複雑なようでシンプルで、一部の機能を除いて、複雑な機能は必要ない。
例えばコレクションに関して言うと、ぶっちゃけ、ListとMap、さらにはArrayListとHashMapばかりで、それ以外は利用してなくね？さらに、全体の半分はBean系ではないかと思わせるぐらい、無駄にBean系クラスが多い。なので、最近は、開発規模が500KSと言われても、実際に意味のあるビジネスロジックは200KS相当と考えるようにしている。
と考えれば、ビジネスロジックを抽象化して記述する方法と、それらが利用するライブラリ群やそれらを利用するフレームワーク群をJavaで書くみたいな感じができると嬉しい。