New proposal for #ReflectiveAccessToNonExportedTypes: Open modules & open packages
Jochen Theodorou
blackdrag at gmx.org
Tue Nov 1 15:32:41 UTC 2016
I must say I am partially to the whole story.
My main problem is code I do not have under control, but suddenly need
"extended" rights for. If this comes from a another module I will have
by default no chance of doing this anymore because of
#AwkwardStrongEncapsulation.
This proposal shows a way around it, but only if I instrument or
otherwise transform the bytecode to add the annotation. If I have that
level of control I can do all sorts of things. My simple problem here
is, that this may work for a framework you program against, but not for
a library that happens to have to process the class without the class
knowing anything about that library. And normally you do not want to
have a bytecode/class transformer, just to use the library properly. Not
to mention, that the point of time in which you get a hold on the
object, it might be much too late to do any modifications to the class....
Well... it makes me ask the question: Does #AwkwardStrongEncapsulation
impose additional limitations for the redefinition of already loaded
classes?
bye Jochen
More information about the jigsaw-dev
mailing list