On Fri, 28 Jun 2024 13:09:19 GMT, David M. Lloyd <d...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/invoke/SerializationBytecodeGenerator.java
>> line 43:
>>
>>> 41: * The private serialization bytecode generator used by {@code
>>> sun.misc.ReflectionFactory}.
>>> 42: */
>>> 43: final class SerializationBytecodeGenerator {
>>
>> I assume the starting point for the prototype should be a supporting class
>> in jdk.internal.reflect rather than here.
>
> Indeed, if you look at the previous revision, that's how I implemented it.
> However, the generator currently needs access to `Lookup.IMPL_LOOKUP` in
> order to generate a nestmate class and accessors for private members on the
> class. If you look at the previous commit ([right here, for
> example](https://github.com/openjdk/jdk/compare/430b5d3b618154a66f03acf4d7a095c046a89687%5E..4e68264689bbbf8e5cf2876ac8dc80e4e7f44f6c#diff-c11ce0e1cedb25e3733a80cd7cb308506d63805ada55b4265252f653df123d88R584-R597)),
> you can see that I _was_ using reflection to grab this field, but that seems
> less than ideal (I couldn't find anywhere else in the JDK which does this).
>
> My next thought was to expose that lookup via `JavaLangInvokeAccess`, however
> looking at the history of this interface gave me an impression that this is
> explicitly undesirable. So my conclusion was that the safest option is to
> push the generator to the "other side" of the barrier and access the
> generators themselves via `JavaLangInvokeAccess`, along the lines of what
> `MethodHandles.Lookup.serializableConstructor` is doing (though in that case
> there is no code being generated).
>
> Another idea I had this morning was that perhaps I could avoid needing the
> private lookup at all, by using reflection with `setAccessible(true)` for
> every serializable field, and unreflecting the result to get getter/setter
> handles, which should bypass access checks. I'll give that a shot and see if
> it works, because in that case we don't need any JLI privileged stuff at all.
> It's a little more clunky than using getfield/putfield but maybe the benefits
> outweigh the difficulties.
Just adding for posterity that one case I did not consider with using an
unprivileged lookup for the generated class is that the class being serialized
isn't necessarily public, and this applies to the types of the fields of the
class as well. This means adapting method handles to handle `Object`, which
might internally involve more `checkcast` than the original solution. I'm still
tinkering with it.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658811216
