Hi Mandy,
On 04/13/2016 01:55 AM, Mandy Chung wrote:
On Apr 12, 2016, at 6:16 AM, Peter Levart <peter.lev...@gmail.com> wrote:
...
And there's also a question whether referenced types derived from method
signatures should be checked for visibility from the specified class loader (in
method validateProxyInterfaces). On one hand it is nice to ensure that later
usage of the proxy class will not encounter problems of visibility of types in
method signatures, but on the other, Java has been known to practice late
binding and a normal class implementing an interface is loaded without problems
although its method signatures reference types that are not visible from the
class' class loader. Only when such method is called does the resolving happen
and exception is thrown. So the question is whether such visibility checks are
actually beneficial. For example, one could successfully use a proxy class by
only invoking methods that reference visible types if this check was not
performed.
I noticed this missing visibility check when updating proxies to work with
modules. I don’t know the history why it only checks of proxy interfaces when
the API was defined. In typical cases, when a proxy interface is visible to
the specified class loader, the referenced types are likely visible. On the
other hand, I’m cautious of the compatibility risk if the visibility check
applies to referenced types as well. I don’t think this check has vast benefits
while past proxy changes broke existing libraries that show up the
incompatibility risk is somewhat hard to assess.
The problem is of course with the setup procedure of the dynamic module where
you have to add exports from modules/packages of those referenced types and
read edges to modules of those references types upfront. But this problem is
resolvable. If a type is not visible from the proxy class' class loader, then
we don't need an export from its module/package and we don't need a read edge
to its module, do we?
True. If the type is not visible, NCFE will be thrown and this read edge and
qualified exports would be redundant. Are you worrying the unused qualified
exports causing security concerns? The proxy classes in a dynamic module are
encapsulate and I’m not too concerned of the redundant ones.
No, not about security. Mainly about binary compatibility. For example:
- library A v1 defines an interface I with some methods
- library B creates a dynamic proxy implementing I. It depends on
library A and libraries defining types from method signatures of the
interface
- program P uses B and depends on the transitive closure
now comes new version of library A v2 which adds a default method to
interface I with signature that requires additional dependency which is
tagged as "optional". Program P does not need to call this new method on
the proxy created by B. Should we force P to bundle the new dependency
although it is not used?
Regards, Peter
