上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

役に立ったらぽちっとよろしく。 人気ブログランキングへ

今日も相変わらず、Toplinkのバグは手強い…。普通にフィールドにアクセスしただけでInvocationTargetExceptionやらjava.lang.NoSuchMethodErrorが発生した。…で、毎度の事だけどバグ対策のサイトは英語…うーんFetchTypeを統一すると治るとか…。たぶんToplink内部の動的ウィービングが関係しているんだろうけど…そんな事を知らんユーザだとこれは面食らうと思う…。ぶっちゃけ、ホコ天で車にはねられたようなものだ…。で、結果論なんだけど…ここしばらくToplinkと付き合ってきて思ったのは、バイトコード変換はやっぱりバグの温床になってる気がする。

以前Javaのバイトコード変換についての議論があって、で危険だからやめよう→どこがそんなに危険なんだ?→こんな素晴らしい機能なのに→あーだこーだ…っていう議論があった。

おいらが思うにバイトコード変換は何も危険でないし、それが出来るのはJavaの実行環境がうまく出来ててその上きちんと仕様化されてるJavaの長所の証明みたいなもんだと思う。そして、何より応用範囲が広くて素晴らしい技術だと思う。

…けども、やっぱし問題もある。最大の問題は初心者と上級者の隔たりを大きくしてしまう所。実現したい事は動的ウィービングとかそんなシンプルな事なのに、それが可能なのは技術的、時間的に見てフレームワークの開発者だけってのは何かおかしな気がする。で、その上級者にとってもやっぱり茨の道であるのは変わりない。おかげでToplinkはバグだらけなわけで…。同じ事がもしJavaの言語機能としてあれば…きっとここまでバグは出ないはず…。

思うにJavaの言語としての性能の方が、VMの性能に追っつけてないからバイトコード変換って技術が生まれたのだと思う。で、きっと同じ理由でJRubyとかも作られてるのかな…。うーんだとするとJavaの将来は…って将来考えてる場合じゃない。将来より今…どーするよこのToplinkのバグ…全部LAZYか全部EAGERかって、何そのAll or Nothingみたいなの…。

役に立ったらぽちっとよろしく。 人気ブログランキングへ


おまけ:DB周りのデバッグ

デバッグ中にブレークポイントでトランザクションを停めている時に、あ、今DBの値どーなってんだっけ?って思った時においらが時々使う方法。

set transaction isolation level read uncommitted;

こうすればトランザクションに割って入って他の接続から値を調べられる。

スポンサーサイト
コメント
この記事へのコメント
コメントを投稿する

トラックバック
この記事のトラックバックURL
この記事へのトラックバック
Copyright © ふらふら技術者の日記 All Rights Reserved.
Powered by FC2 Blog
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。