[Nestmates] Add a core reflection API to get nestmate information
peter.levart at gmail.com
Mon Nov 20 09:20:24 UTC 2017
On 11/20/2017 07:36 AM, David Holmes wrote:
>>>> I don't quite understand why should a Class.isNestmateOf(Class)
>>>> behave any differently than real VM access check.
>>> Purely because of the difference in exception handling. The view was
>>> that the reflection API should mostly "absorb" exceptions.
>> Absorbing exceptions is generally a bad idea. In this particular
>> case, you are trying to hide an implementation detail and instead lie
>> to the user about the nest membership. Some information is lost on
>> the way and that's not helping the user at all. Not being in the same
>> nest and not being able to evaluate the answer are two different
>> things and as much as someone might think the user shouldn't care,
>> the need to discriminate them is probably going to arise and users
>> will have to do sub-optimal things to accomplish that. Why not give
>> them the precise tool to start with?
> That was my personal initial position too. But the EG discussions went
Your comment in the issue:
...describes how access checking for private members behaves in VM and
what are the outcomes when class attributes are missing or not
consistent (access is denied - IllegalAccessError is thrown) vs. when
nest-host class can not be resolved (NoClassDefFoundError is thrown). I
think this is sound.
In reflective API, it is common practice for IllegalAccessException to
be thrown where VM would throw IllegalAccessError, but
NoClassDefFoundError is thrown as is when various reflective methods are
invoked. For example, Class.getDeclaredField(fieldName) throws
NoClassDefFoundError when the field's type can not be resolved. Likewise
for method's and constructor's parameter types. Class.getDeclaredField()
is not trying to hide the return type resolution error by lying about
the existence of the field and throwing NoSuchFieldException instead. So
why should Class.isNestmateOf(Class) hide the NoClassDefFoundError and
lie about nest membership instead?
I agree that Class.getNestMembers() is a special case, but I think it
should nevertheless propagate NoClassDefFoundError when nest-host can
not be resolved, while resolution errors for other nest-members listed
in nest-host could just skip them from the result (to allow for
optimized jars). Although maybe, jar optimizers should rather "patch"
the nest-host attribute and remove members that are not included. They
would have to be aware of nestmate attributes to not accidentally remove
the nest-host class from the optimized jar anyway, or rearrange
attributes to designate one of remaining classes to be new nest-host in
More information about the valhalla-spec-observers