On Fri, 28 Jun 2024 14:04:13 GMT, David M. Lloyd <d...@openjdk.org> wrote:
>> 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. Done; the generator is now able to use a non-privileged lookup to generate the accessor classes, and thus I moved it back to `jdk.internal.reflect`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1658837413
