> On 11 Jul 2016, at 18:58, Jim Laskey (Oracle) wrote:
>
>> How about the following helper method on ModulePool:
>>
>> Optional findModule(ModuleEntry me);
>>
>> then the intent in code might be a littler clearer on the context.
>
> After thinking about this at bit: If we did that and then la
> How about the following helper method on ModulePool:
>
> Optional findModule(ModuleEntry me);
>
> then the intent in code might be a littler clearer on the context.
After thinking about this at bit: If we did that and then later worked out a
way to optimize across modules, we’d have to hunt
Sent from my iPhone
> On Jul 11, 2016, at 11:09 AM, Paul Sandoz wrote:
>
>
>> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle)
>> 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
> On 11 Jul 2016, at 14:17, Jim Laskey (Oracle) 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
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 c
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 a
http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html
https://bugs.openjdk.java.net/browse/JDK-8161067
