Re: [閒聊] 魔法 JNI

看板java作者AmosYang (LetMeGoogleThatForYou)時間15年前 (2010/04/30 17:01)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串3/4 (看更多)

※ 引述《AmosYang (LetMeGoogleThatForYou)》之銘言： : 推 costbook:這種好東西竟然開放下載耶，感謝分享 04/30 08:30 Java 比 .Net 好就好在這些文件整理得好，在官方網站上就可輕易找到 : 推 zanyking:C#裡就很直接的給你unsafe區塊，等於是挖個窗口直接做 04/30 09:53 C# 比 Java 好就好在比較務實，以 developer 為中心 (唯一一點遺憾的就是沒有像 Java 的 throws …至少 make it optional... 讓想用的人去用，不想用的人就不要用…) : 推 james732:感謝分享很棒的資料!! 04/30 10:30 不客氣 : → sbrhsieh:實際上JVM本身就沒有enforce final field 的不變性質在.. 04/30 15:43 : → sbrhsieh:定義該 field 的 class 內。 04/30 15:44 : → sbrhsieh:final field setter method 可以在 bytecode level 實現 04/30 15:46 sbrhsieh 提出的這點倒讓我想起來一些更有趣的事，根據我的記憶，在 JDK 1.1, 1.2, 1.3, 1.4, 1.5 ... 一路發展下來有一段時間其實 final field 可以用 reflection 去改其 value 接下來幾個版本又不能改然後再下來幾個版本又變回可以改現在最新的 Java 6 裡可以不可以改…我不知道…有空的人可以試一試剛去問某 Java 強者這到底是在搞什麼鬼他說有興趣的話去看 JSR-000133 Java Memory Model and Thread Specification 裡面有一章專門講 final field 我懶得去看了…有興趣的人請自行取用 XD -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 65.87.177.87 ※ 編輯: AmosYang 來自: 65.87.177.87 (04/30 17:03) 順藤摸瓜又摸出這個 http://www.javaspecialists.eu/archive/Issue096.html 文章有點舊，但無損其價值，可以從 "Java 5 - "final" is not final anymore" 讀起摘錄最重要的一段 (給與我一樣懶得去讀JSR133的人…XD) When Narve Saetre mailed me that he managed to change a final field in JDK 5 using reflection, I was hoping that a bug had crept into the JDK. However, we both felt that to be unlikely, especially such a fundamental bug. After some searching, I found the JSR-133: Java Memory Model and Thread Specification. Most of the specification is hard reading, and reminds me of my university days (I used to write like that ;-) However, JSR-133 is so important that it should be required reading for all Java programmers. (Good luck) Start with chapter 9 Final Field Semantics, on page 25. Specifically, read section 9.1.1 Post-Construction Modification of Final Fields. It makes sense to allow updates to final fields. For example, we could relax the requirement to have fields non-final in JDO. If we read section 9.1.1 carefully, we see that we should only modify final fields as part of our construction process. The use case is where we deserialize an object, and then once we have constructed the object, we initialise the final fields, before passing it on. Once we have made the object available to another thread, we should not change final fields using reflection. The result would not be predictable. It even says this: If a final field is initialized to a compile-time constant in the field declaration, changes to the final field may not be observed, since uses of that final field are replaced at compile time with the compile-time constant. This explains why our iq field stays the same, but country changes. ※ 編輯: AmosYang 來自: 65.87.177.87 (04/30 17:33) ※ 編輯: AmosYang 來自: 65.87.177.87 (04/30 17:33)