masakikatakai
しんさんにしつも〜ん。EJBに日本語を使わないと効率が絶対的に落ちますか？私個人としてはここはこだわらないほうがいいと思うのです。
まずEJB自体は日本語をいくら使っても問題はありません。問題が発生するのは日本語が使われる確率がもっとも高いEntityでのみ発生するというところがこの問題のいやらしさをあらわしています。
私は基本的には変数名等に積極的に日本語は使いませんが、ウィザードで生成されるエンティティクラスはDBの構造をそのまま創ります。結果、日本語のフィールドが生成されて問題が発生します。
ですが、エンティティだけではありますが、日本語で表記されるわかりやすさというのはやはりメリットです。個人で書くような全体がすぐに見渡せるようなコードだけならそんなに問題はありません。たくさんのテーブルとフィールド名、それらとプロパティ名を一致させないとやはりわかりにくくなります。
int kin = item.get商品単価() * input.get数量();
くらいはあっても問題はないでしょう。英文を機械翻訳させた無理やりつけたネーミングのプロパティ名で資料片手に四苦八苦するよりははるかにいいと思います。
@Remoteが使えないというのはJUnitが使えないということですから非常に問題になります。テストがしやすいかどうかというのは大きく品質に左右するので大問題となります。
JPAのエンティティクラスはウィザードで生成されます。その際テーブルのカラムに日本語が使われることは今では非常に多いのです。EUCというのは開発者にとってもユーザーとの橋渡しの容易さで最重要項目でしょう。テーブルを作成してそのままということはなく、構造が変わるたびに削除後、ウィザードで作り直したりします。本当は更新するシステムがほしいのですが。IDの設定しなおしが面倒すぎます。
この不具合はメソッド名は日本語でも問題はなく、フィールド名のみに反応します。ですからウィザードによってprivateなフィールドの変数名がテーブルのカラム名に依存せず自動生成されていれば、たとえば、field01、field02･･･のような連番ならば問題は起こりません。7bit圏から文句が飛び出すと思いますが、同じフィールドに立ってもらって苦痛を味わってもらうという意味ではありでしょう。とりあえず、こういう回避方法もありです。プロパティ名としては(つまりget,setのメソッド)日本語のままで現状問題は出ませんから。
ただそうなると、あとでウィザードではなく自分で追加する際にprivateなフィールドをセットした後、ALT+INSERTで手軽に作れなくなるのも面倒ですが。プロパティ名って確かリファクタリングができないですよね。
あと、いまのうちに膿を出しておかないと今年登場予定のJavaSE7でプロパティ構文が実装されたとき、たぶん、いろんなところで問題になります。J2SE5.0の構文のようにコンパイラ等が解決するのでしょうから、いままでのようなメソッド名の規約で簡単に逃げるということはできないでしょうし。
最後の最後で最初の質問にお答えします。
絶対的に開発効率は落ちています。おそらくこれが解決されれば効率は1.3倍くらいはいけるのではないでしょうか。これだと数値的に微妙に見えるでしょうか。4週間かかる仕事が3週間くらいですむようになります。そしてバグは大幅に減ると思います。不要なテストコードがデプロイされるというのもこまりものです。
今のところこの問題だけが正直開発時に我慢ができないくらいの不満だったりします。他のバグが一切直らなくてもこれだけは直ってほしい個人的P1です。実際運用で回避ができず、クラッシュするのでP2くらいはあるでしょうけど。
この問題が回避できないのであればGlassfishやSun Java System Application Serverから逃げ出すのも手かもしれません。JPA実装としてはTopLinkが一番使い勝手がいいのであまり移りたくもないのですが。
