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

James Laskey james.laskey at oracle.com
Mon Jul 11 14:15:22 UTC 2016



Sent from my iPhone

> On Jul 11, 2016, at 11:09 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
>> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:
>> 
>> 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.
> 
> Ok.
> 
> 
>> 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.
> 
> Ah, i see, so the rule being: go back to the pool to query for stuff.
> 
> How about the following helper method on ModulePool:
> 
>   Optional<LinkModule> findModule(ModuleEntry me);
> 
> then the intent in code might be a littler clearer on the context.
> 

Ok

> 
> ImagePluginStack
> 
> 407             return res.isPresent()? Optional.of(getUncompressed(res.get())) : Optional.empty();
> 
> You could do:
> 
>  return res.map(this::getUncompressed);
> 

Good


> 
> ClassForNamePLugin
> 
> 148             .filter(resource -> resource != null)
> 
> Can a resource ever be null?

I don't think it can. Just cloning JFs code. Might have true at some point. Will drop and see what falls out. 

> 
> Paul.



More information about the core-libs-dev mailing list