Dynamic Modular Proxy Interface Access via Qualified Exports
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In module systems, generating dynamic proxies to implement non-exposed interfaces across different modules is challenging due to access restrictions and the inability of proxy classes to implement interfaces from modules they are not explicitly exposed to.
Innovation Solution
A runtime environment generates or selects a proxy class within a module and exposes necessary interfaces using a qualified export, allowing the proxy class to implement interfaces from other modules without exposing it to other modules, thereby enabling testing of methods through reflective operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a proxy class is located in a same module as a first non-exposed publicly accessible interface, then the proxy class may implement the first non-exposed publicly accessible interface, but the proxy class cannot implement a second non-exposed publicly accessible interface within a second different module than the proxy class
Solution Approach 1:
The patent introduces a module descriptor as an intermediary that manages and controls access between modules. The module descriptor maintains exposure information that tracks which interfaces are exposed to which modules, allowing the proxy class to access non-exposed interfaces through this intermediary mechanism without violating module encapsulation principles
Solution Approach 2:
The patent implements dynamic exposure information that can be modified at runtime. The module descriptor's exposure information is not static but can be updated to reflect changing access requirements, allowing interfaces to be dynamically exposed to proxy classes based on testing needs while maintaining security for production code
2Adaptability or versatility
If interfaces are exposed to multiple modules using traditional export mechanisms, then more modules can access the interfaces, but interfaces become accessible to modules that should not have access
Solution Approach 1:
The patent applies local quality by making exposure information module-specific and interface-specific. Each module descriptor contains exposure information tailored to particular interfaces and particular consuming modules, allowing precise control over which modules can access which interfaces, rather than using coarse-grained export mechanisms
Solution Approach 2:
The module descriptor maintains exposure information that provides feedback about access permissions. This exposure information is consulted during runtime to determine whether a proxy class in one module can access an interface in another module, creating a feedback loop that enforces access control policies
3Reliability
If proxy classes are restricted to implementing only interfaces from explicitly exposed modules, then module encapsulation is maintained, but comprehensive testing of interfaces across modules becomes impossible
Solution Approach 1:
The patent performs preliminary action by pre-configuring exposure information in module descriptors before runtime execution. The exposure information is prepared in advance to include test modules in the list of modules that can access specific interfaces, allowing comprehensive testing to occur without violating encapsulation principles during normal operation
Data Source
AI summary
A runtime environment generates a proxy class in response to detecting a request for a proxy object. The proxy class implements a set of interfaces specified by the request for the proxy object. The runtime environment selects or generates a proxy module, in a module system, to include the proxy class. The runtime environment exposes interfaces from other modules to the proxy module using a qualified export that does not expose the interfaces to modules other than the proxy module. The runtime environment does not expose the proxy class, of the proxy module, to other modules in the module system.