module readability and exceptions in api

[Michał Zegan]

W dniu 14.10.2018 o 09:27, Alan Bateman pisze:
> On 13/10/2018 15:12, Michał Zegan wrote:
>> :
>> hmm so it is not a good idea to, say, generate a bytecode/class to be
>> defined as part of currently loaded module X by means of
>> MethodHandles.Lookup.defineClass or something like that if this bytecode
>> would have to access module Y that is currently not readable by X,
>> because I have no control over class loader of X and cannot augment it's
>> delegation?
> This isn't really a module issue. When spinning code at run-time then
> you have to take visibility into account. I'm sure there are custom
> class loaders around that do have some support for dynamically updating
> how they delegate but it's not something that the ClassLoader API has
> any support for.
It is not a module issue directly, however if I generate bytecode at
runtime and define it to an existing package of an existing module, then
either I have the ultimate control of this module and know which class
loader is used there, or I have no control over it because it is
application module, then it is a bigger problem.
> 
> -Alan
> 
>