Class.getRecordComponents security checks

Attila Szegedi szegedia at gmail.com
Sat Mar 20 16:17:07 UTC 2021


> On 2021. Feb 21., at 21:57, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Attila Szegedi" <szegedia at gmail.com>
>> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoyé: Dimanche 21 Février 2021 21:14:48
>> Objet: Class.getRecordComponents security checks
> 
>> Hey folks,
>> 
>> Why are security checks for Class.getRecordComponents as strict as those for
>> e.g. getDeclaredMethods? I would’ve expected they’d be as strict as those for
>> e.g. getMethods. Specifically, the difference is the:
>> 
>>> “the caller's class loader is not the same as the class loader of this class and
>>> invocation of s.checkPermission method with
>>> RuntimePermission("accessDeclaredMembers") denies access to the declared
>>> methods within this class”
> 
> Good question, getRecordComponents() list the record components not the record accessors,
> while each record component has a corresponding accessor method, the reverse is not true.
> 
> so here, what you are asking is more like asking fields than methods, so it's more like getDeclaredFields() than getMethods(),
> hence the runtime check if there is a SecurityManager enabled.

But the whole point is that accessors are methods, and not fields, I thought. And even if it were so, we have a distinction between getFields and getDeclaredFields. There’s no separation of getRecordComponents vs. hypothetical getDeclaredRecordComponents.

I’m convinced I don’t understand this issue completely, and I remain confused. I appreciate you trying to clear it up, the problem of continued failure to understand is most likely inside my head :-)

> 
>> 
>> step. Aren’t record accessors supposed to be public?
> 
> yes, at least for the code generated by javac, accessors are always public
> (the class itself may be non public, and the package may not be exported).

Right, but for non-record classes you could also invoke e.g. getMethods() on it.

Attila.



More information about the core-libs-dev mailing list