Constructing records through reflection and module restrictions

[Brian Goetz]

Let’s take about 100 steps back. Why do you think that records should be immune to the ordinary access control of the language?  And why are you focusing only on the constructor and not the other members of the record that presumably would be needed to access its state?  Why is modularity special here and not private records?

There are a whole host of assumptions in this line of thinking, and I think we should start at the beginning. What problem are you trying to solve?

Sent from my iPad

> On Dec 7, 2024, at 8:36 AM, Florian Weimer <fw at deneb.enyo.de> wrote:
> 
> 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.