Constructing records through reflection and module restrictions

[Florian Weimer]

As far as I can see, constructing through reflection currently needs
access to the record constructor.  Try to use MethodHandles.lookup()
to access the constructor from a different module, I get:

java.lang.IllegalAccessException: symbolic reference class is not accessible: C1, from class C2 (module M)

If I use the Class instance for the record with
MethodHandles.privateLookupIn(), creating the lookup fails with:

java.lang.IllegalAccessException: module M1 does not read module M2

If I understand this correctly, in general, this is required to
preserve module encapsulation.  For record classes, I assume a
different choice could be made.  Has there been any discussion whether
it is important to restrict the creation of forged record instances?
The current behavior allows using records as capabilities: The
constructor invocation might be restricted to certain contexts that
perform additional checks before construction.  Exposing the
constructor would allow bypassing that.  On the other hand, access to
constructors would enable programming patterns were records are
created through some form of deserialization, dynamically based on
record layout (for example, a CSV file reader that produces a record
for every input row).

But perhaps I'm wrong and there is a way to create record instances
using unprivileged reflection.