RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

[Jim Laskey (Oracle)]

I’m not sure if we can determine supplied classes vs others unless we provide a flag or the set of supplied modules.  At any rate, the rules for cross module optimization would still be complex.

ModuleEntry.findEntry: I was half thinking the same once I realized the limits of the lookup.  The complication is that a ModuleEntry may exist in several pools (direct copy).  So, though we have to create new LinkModules each pass, we would also be forced to create new ModuleEntrys for each pass.  In practice, I’m not sure findEntry will be used frequently in relation to the #plugins x #classes.

— Jim


> On Jul 11, 2016, at 7:10 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> Hi Jim.
> 
> Do you anticipate support across module boundaries given your comment?
> 
> 282         // Navigating other modules via requires and exports is problematic
> 283         // since we cannot construct the runtime model of loaders and layers.
> 
> it might be possible to emulate runtime resolution at link time for the set of idk.modules but not possible by default for non-idk modules because as you say we don’t know the runtime properties (such as layering), that would require some input from the developer (if it is indeed possible to express).
> 
> I ask because there is a simpler way to express the current functionality, provide a method on ModuleEntry to obtain the LinkModule, rather than, or in addition to, the module name. Such functionality is much clearer regarding the scope of resolution.
> 
> Paul.
> 
> 
>> On 8 Jul 2016, at 17:53, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:
>> 
>> http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html
>> https://bugs.openjdk.java.net/browse/JDK-8161067
>> 
>