Review request for the incorrect check for "getClassLoader" permission

[Mandy Chung]

David,

On 6/25/2012 10:02 PM, David Holmes wrote:
>
> I think it is not unreasonable that our jigsaw sources and jsr166e 
> sources will naturally diverge for a while. This shouldn't be seen as 
> a "bad thing". We want to modularize as much as we can to gain 
> experience with the new architecture for classloading and the access 
> control aspects of that. Conversely Doug wants to continue with 
> functional updates targeted for 8 without needing to work around a 
> potentially fluctuating modularity API - and the need to work in 
> modular and non-modular versions of 8.
>
> So my take is that we modify the Atomic classes as needed and worry 
> about sync'ing with Doug at a much later date.

Sorry for  the late reply as I took a day off yesterday.  I don't see 
the jigsaw source and jsr166e diverging a bad thing.   As we want to 
keep jdk changes minimal in jigsaw repo and integrate jdk change to jdk8 
regularly, I was thinking of the steps to get the Atomic classes change 
into jigsaw.  Since this is not time critical, it may be best to follow 
the normal way to get the change in jsr166e first and then pulled down 
to openjdk.

The new needsPackageAccessCheck method in jigsaw repo will be the 
version to work in modular and non-modular versions.  The jdk8 version 
will be slightly different and that will not call any jigsaw API (just 
check class loader == null).   So I hope it shouldn't be an issue making 
such change in jsr166e.  BTW with the new needsPackageAccessCheck method 
you can remove the isAncestor method in all 3 atomic updater classes.

I'd like to push this changeset first and separate the j.u.c. change.  
If it's determined that jsr166e won't make such change for some reason, 
I can modify the Atomic classes and fix that in jigsaw repo.

Mandy