※ 引述《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 來執行還行不行得通？ 那我講這些東西的重點是？沒有，我只是陳述整個事件始末，陳述一個事實，這個 行為是不是違規的知識分享，法院自會有判斷。 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.238.34.116 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/java/M.1401776340.A.2DA.html ※ 編輯: sbrhsieh (36.238.34.116), 06/03/2014 14:34:30