On Wed, 31 May 2023 00:48:18 GMT, Mandy Chung <mch...@openjdk.org> wrote:
>>> Is it more straight-forward to keep a `ClassValue<Boolean>` and each >>> wrapper instance class has an entry of `TRUE` value; otherwise, `FALSE`? >> >> Then we still need to obtain the implemented interface and original method >> handle information every time they are queried. Having these information (or >> the method handle providing access) computed early is more convenient. >> >>> If we can avoid implementing sun.invoke.WrapperInstance, this package >>> access check issue would go away. Do you think you can look into it? >> >> Apparently, calling utility methods from `sun.invoke`, like the >> `ensureOriginalLookup` in this patch, also triggers this check. However, I >> still think removing the `WrapperInstance` supertype is better, as this >> makes the code cleaner in reflection. > >> Apparently, calling utility methods from sun.invoke, like the >> ensureOriginalLookup in this patch, also triggers this check. > > It should not trigger `checkPackageAccess` if it does not implement the > interface AFAICT. > > It would trigger module-access check. `java.base` can export `sun.invoke` to > the dynamic module (it may be worth considering putting the internal > interface in a specific package for the dynamic module' use - `sun.invoke` is > ok since it currently has one interface but hard to catch when someone adds a > new class/interface in `sun.invoke` unintentionally and leak out sensitive > API. > Then we still need to obtain the implemented interface and original method > handle information every time they are queried. Having these information (or > the method handle providing access) computed early is more convenient. I was thinking the wrapper instance class still implements some private methods to get the implemented interface and original method handle which can be accessed only `java.base` via deep reflection. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1210972245
