On 6/15/20 11:58 PM, Mandy Chung wrote:
> This patch also proposes `sun.misc.Unsafe::objectFieldOffset` and
> `sun.misc.Unsafe::staticField{Offset/Base}` not to support records.
Note this would break otherwise innocuous introspection for records, for
example dumping the VM
layout with JOL:
http://openjdk.java.net/projects/code-tools/jol/
Amusingly, with the rest of Unsafe available the barn is still full open.
Here's the sketch for the
workaround: get the field list with getDeclaredFields, optionally guess the VM
layout (the rules are
not that hard, and JOL does it routinely), instantiate a Record with whatever
arguments, poke the
test patterns with Unsafe.put*, read them back from record components to
verify. It would get me the
same objectFieldOffset in a round-about way.
And speaking from JOL maintainer standpoint, that one would be very tempting to
do, because it would
not depend on whatever protection shenanigans a particular JDK release tries to
enforce.
> This change impacts 3rd-party frameworks including 3rd-party
> serialization framework that rely on core reflection `setAccessible` or
> `sun.misc.Unsafe::allocateInstance` and `objectFieldOffset` etc to
> construct records but not using the canonical constructor.
> These frameworks would need to be updated to construct records via its
> canonical constructor as done by the Java serialization.
Are we absolutely sure that what ObjectInputStream.readRecord() does fits the
3rd party
serialization libraries? Does it work for them performance-wise? (Are we even
sure about that for
JDK itself?) Because if it is not, 3rd party lib maintainers would proceed to
hacking in the
"objectFieldOffset workaround" and we would get the cobra-effect-like
strengthening of dependency on
Unsafe quirks.
> No change is made in JNI. JNI could be considered to disallow
> modification of final fields in records and hidden classes (static and
> instance fields). But JNI has superpower and the current spec already
> allows to modify the value of a final static field even after it's
> constant folded (via JNI Set<type>Field and SetStatic<type>Field), then
> all bets are off.
It is fun to consider JNI to be more powerful than Unsafe. This seems
backwards. The intent to break
Unsafe users might be defensible, but this power oddity is still quite odd.
--
Thanks,
-Aleksey
