※ 引述《darkk6 (Mr. Pan)》之銘言：
: → sbrhsieh:不懂darkk6 的意思 06/03 11:50
: → sbrhsieh:若我沒誤解，那你有能力變更 final field 的值。 06/03 11:59
: → sbrhsieh: 要 06/03 12:00
: 在不考慮 Security 的問題下，確實有方法 access final field.
: IntegerCache 的 low , high , cache 都是 static final
: 要改變還是可以做點 tricky 的方式去修改，剛剛寫了一個範例如下
: http://ideone.com/XO1zGU
: 原本 IntegerCache 的範圍是 -128~127 , 因此 129 不在範圍內
: 這個例子中，我把 cache 範圍擴增到 -128~1000 , 接著把
: 129 的 cache 值改為 5 (其實可以在第一個 trick 就處理，但我分開寫)
: PS : 其實重點就是把 Field 的 final 拿掉啦~
我雖然知道 JVM(至少 sun/Oracle implementation 是)沒有做 final field
access 方面的 enforcement，但是我之前有自己試驗過類似你的做法卻失敗了。
你的 sample code 我在 Oracle JVM 試過確實可行，同時我也發現了我自己的
試驗為什麼會失敗了(嚴格來說我還是不知道為什麼 :D)，主要是我習慣在 REPL
的模式下試驗，我先試未修改 Field object 的 modifier 的情況下去變更
final field 的值，如預料是行不通的。接著在接續上一個試驗的狀態下，試著去
修改同一 Field object 的 modifier，即使把 final bit 移除，依然無法透過
該 Field object 來變更 final field 的值。
或許你也能在你使用的 JRE 重製出我形容的現象，試著把你的 sample code
裡的 setFinalStaticValue method 稍作修改：
private static void setFinalStaticValue(Field fd,Object val){
try{
fd.setAccessible(true);
Field mdfField = Field.class.getDeclaredField("modifiers");
mdfField.setAccessible(true);
try {
fd.set(null, val);
}
catch (Exception e) {}
//重點是這裡，把 final 屬性拿掉
mdfField.setInt(fd, fd.getModifiers() & ~Modifier.FINAL);
fd.set(null, val);
} catch(Exception e){
e.printStackTrace();
}
}
編譯後試試看你使用的 JRE 來執行還行不行得通？
那我講這些東西的重點是？沒有，我只是陳述整個事件始末，陳述一個事實，這個
行為是不是違規的知識分享，法院自會有判斷。