> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup 
> caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy 
> class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is 
> defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open 
> unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request incrementally with one additional 
commit since the last revision:

  Performance improvement contributed by plevart

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/8352a20b..d443f10e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=04-05

  Stats: 24 lines in 4 files changed: 7 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

Reply via email to