Quantcast

JD 9 RFR: JDK-8177311: Denied access when named module accesses unreferences package from the unnamed module

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

JD 9 RFR: JDK-8177311: Denied access when named module accesses unreferences package from the unnamed module

Jan Lahoda
Hi,

I'd like to ask for a review for:
Bug: https://bugs.openjdk.java.net/browse/JDK-8177311
   http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005672.html

Webrev: http://cr.openjdk.java.net/~jlahoda/8177311/webrev.00/

The problem is this: in Resolve.isAccessible when checks if a module can
access types from other modules does:
currModule.visiblePackages.get(p.fullname) == p

But if "p" is from an unnamed module, then it may or may not be in the
visiblePackages (depending on whether Symtab.lookupPackage was called on
the given package in the context of currModule), as unnamed module
packages are computed lazily. So this check may fail incorrectly.

The proposal here is to add one more check for the dependency on the
unnamed module.

How does this look?

Thanks,
     Jan
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: JD 9 RFR: JDK-8177311: Denied access when named module accesses unreferences package from the unnamed module

Jonathan Gibbons
Looks good to me.

-- Jon

On 03/21/2017 02:51 AM, Jan Lahoda wrote:

> Hi,
>
> I'd like to ask for a review for:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8177311
> http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-March/005672.html
>
> Webrev: http://cr.openjdk.java.net/~jlahoda/8177311/webrev.00/
>
> The problem is this: in Resolve.isAccessible when checks if a module
> can access types from other modules does:
> currModule.visiblePackages.get(p.fullname) == p
>
> But if "p" is from an unnamed module, then it may or may not be in the
> visiblePackages (depending on whether Symtab.lookupPackage was called
> on the given package in the context of currModule), as unnamed module
> packages are computed lazily. So this check may fail incorrectly.
>
> The proposal here is to add one more check for the dependency on the
> unnamed module.
>
> How does this look?
>
> Thanks,
>     Jan

Loading...