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