[問題] Java 反射機制於 compile 時檢查

[cyclone350 (老子我最神)]

大家好



java 專案裡面多多少少會使用到反射機制寫程式

比較常見的像是 criteria ...


例如程式碼

final CriteriaQuery<User> q = cb.createQuery(User.class);
final Root<User> users = q.from(User.class);
final Predicate condition = cb.equal(users.get("privilegeLevel"), 5);

q.select(users)
 .where(condition)
 .orderBy(cb.asc(users.get("userId")));

其中 privilegeLevel 會直接對應到 entity 的 field

若是 entity 修改 privilegeLevel 欄位名稱，在 compile 階段並不會檢查到

而到真正 runtime 時才會發現錯誤。



想請問有無方法可以在 compile 時可以檢查的 ?
(ide plugin 或 build tool plugin 都可)



除了 compile 檢查以下我目前知道以下幾種解法

1. 讓所有開發工程師都明白這件事情，在修改程式碼時會更小心注意。

2. 使用 http://goo.gl/zhhdLh 文章的方法。

3. 修改程式有發生錯誤的風險，所以不要修改程式。


方法 1... , 可讓發生錯誤降低，但無法保證不會發生...

方法 2... , 可以杜絕錯誤，但個人有點不愛，因為除了 Criteria 外還有 hql，
            需要把整個專案(跟DB有關)翻掉重寫，我們專案沒有 test 流程，
            若是人工修改人工測試，會消耗非常巨量的時間。

方法 3... , 最安全的做法，但我覺得同時也是最糟糕的做法。


三個方法要選的話我會選 1


不過目前想到最完美的方法就是有現成的 compile 時段就可以檢查的，

想請問各位前輩有無這種工具或套件，若沒有的話，你們專案是如何解決

這類問題的 !?


--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.192.133
※ 文章網址: https://www.ptt.cc/bbs/java/M.1443350301.A.F12.html
推 NullLife: 我覺得用ORM來說 改field的時候 就相當於下DDL改column
→ NullLife: 名稱 也就等於你相關的SQL語句都必須修改
→ NullLife: 除非用mapping啦，以JPA來說就有annotation可以不耦合
→ NullLife: field名稱 所以我覺得重點還是在為什麼要去修改名稱勒?
並非為了修改名稱而修改名稱，在某些情況下可能會無意的修改，例如你要把

不同的專案的某些功能整合在一起，而他們有共用的 Entity，但是 Entity 又

不一致，在整合程式時若是在沒有警覺的情況下是有可能犯下這種錯誤。

Ex: 專案1 的 entity field name = iAmAField
    專案2 的 entity field name = iAmAfield


方法 1 就是告知大家有這種情況，下次修改或整合程式時必須注意這種狀況。

是想說如果有現成的工具幫忙檢查會更好 XD。

※ 編輯: cyclone350 (123.193.192.133), 09/27/2015 20:40:33
推 NullLife: SOGA 工具我是不曉得 但用Eclipse的時候 在字串那邊
→ NullLife: 就可以用ctrl點看看有無link 我覺得這已經夠方便了 XD
→ qrtt1: 覺得寫 unit test 才是比較好的方法。
→ wuliou: 我想你還是寫unit test吧
→ bitlife: 有陽春工具可解決本篇問題,但對寫在sql內的field/table名
→ bitlife: 稱修改就沒用,方法是把所有table及fields在coding時期從
→ bitlife: db讀出來,每個table做成一個以table name為名的class,然
→ bitlife: 後所有該table的欄位成為該對應class的final static字串
→ bitlife: 假設需要A表格的b欄位,程式就寫A.b
→ bitlife: 當table有變動,就重跑一次抓表格/欄位工具,哪裏編不過就
→ bitlife: 知道了
→ swpoker: 這種就只能執行時才能知道~所以unit test吧
→ marsyang1: http://stackoverflow.com/questions/3037593/how-to-
→ marsyang1: generate-jpa-2-0-metamodel
→ marsyang1: 參考參考，我自己是用spring data,為了整合性使用quer
→ marsyang1: y dsl,但做法都差不多。
推 marsyang1: 組query會是用metamodel的class,不會用反射
感謝大家回應 :)

先回 unit test 的部分，其實一直有在補啦 ><，因為這是一個蠻有歷史的專案，

交給我的時候... 有點亂就是了...

所以一有空閒時間就會

1. 看程式補文件
2. 重構
3. 補 unit test

不過這一部分老闆不正視就很難騰出時間。

spring data 的方案花的成本跟原先 2 是一樣的。

個人也覺得 spring data 很好用，之前開發新專案就是用 spring data。


目前看來應該只能方法1 跟補足 unit test 並行了
※ 編輯: cyclone350 (123.193.192.133), 10/04/2015 14:45:36
→ adrianshum: 我有想過用類似 Mockito 的做法寫Util 去 runtime
→ adrianshum: 生成 method name e.g.nameOf(c(Foo.class).method())
→ adrianshum: 不過因為某些原因沒有動手做。可以考慮
→ adrianshum: 不過 property name/variable name 真的有點難搞
→ adrianshum: QueryDSL 應該是暫時最可行的做法了