Oracle International Corporation

Alan Bateman

Alexander R Buckley

Mark B Reinhold

Chris Hegarty

Mandy Chung

Jonathan J Gibbons

Paul Sandoz

Lai Hung Mandy Chung

Brian Goetz

John Robert Rose

Stuart Warren Marks

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.

Generating dynamic modular proxies

A module (m) is allowed to gain private reflective access to any class in any module (Cin m), if and only if mgrants to mdeep reflective access for C. A caller class may invoke a method to generate a second lookup object associated with a second principal class based on a first lookup object associated with a first principal class. The method is successfully executed only if (a) an access mode of the first lookup object allows for teleporting with private reflective access and (b) a module including the second principal class grants to a module including the first principal class deep reflective access for the second principal class. The second lookup object drops the access mode allowing for teleporting with private reflective access. Hence reflective access is confined within the limits imposed by module boundaries, as relaxed by access agreements between pairs of modules. The bilateral agreements are not transferable to other modules.

Confining reflective access based on module boundaries

Techniques for performing constructor accessibility checks during deserialization are disclosed. A system receives a command that requires deserializing a serialized object of a target type. The system determines an ancestor type of the target type. Without calling any constructors and regardless of whether the ancestor type is serializable, the system determines whether a constructor of the ancestor type is accessible to the target type. The system deserializes the serialized object only after determining that the constructor of the ancestor type is accessible to the target type.

Constructor accessibility checks for deserialization

Techniques for identifying permitted illegal access operations in a module system are disclosed. An operation, expressed in a first module, that attempts to access a module element of a second module is identified. Based on a module declaration associated with the second module, the module element is determined inaccessible to the first module. Additionally or alternatively, based on an access modifier associated with the module element, the module element is determined inaccessible to the operation. The operation is determined as an illegal access operation. The illegal access operation is permitted to access the module element. A warning corresponding to the illegal access operation is generated.

Identifying permitted illegal access operations in a module system

A bridge module is generated to bridge standard modules in a module system and non-module code in a non-module system. The bridge module includes explicit dependencies associated with a namespace, such as a dependency path corresponding to the non-module code. The bridge module exposes packages of the non-module code at least to the standard modules. Operations are performed on a code base that uses standard modules, bridge modules, and non-module code.

Composing a module system and a non-module system

Techniques for managing split packages in a module system are disclosed. A code conflict exists between two packages, in different modules, based at least in part on the packages being named identically and including executable code. No code conflict exists between two other identically-named packages, in different modules, based at least in part on the packages not including any executable code. Managing split packages may be based, at least in part, on module membership records associated with the modules.

Managing split packages in a module system

Access to a module element within a first module by a second module is prohibited if the module element within the first module has not been exposed to the second module. If a particular module element within a first module has been exposed to a second module, then access to the particular module element by the second module may or may not be allowed depending on: (a) whether the particular module element has been declared with a public or non-public access modifier, (b) whether a second exposed module element, which includes the particular module element, has been declared with a public or non-public access modifier, (c) a level of access associated with the operation that attempts to access the particular module element of the first module, and/or (d) whether an accessibility override configuration is set for accessing the particular module element.

Restrictive access control for modular reflection

Techniques for renaming a module in a module system are disclosed. It is determined that a first module is declared with a corresponding first module name. It is determined that the first module is associated with a second module name. Responsive to determining that the first module is associated with the second module name: a second module declared with the second module name is synthesized, and a dependency of the second module, with the second module name, is declared on the first module with the first module name.

Synthesized modules for module renaming

Permissive access control for modular reflection

A serial form of a serializable exposed first module element of a module in a module system is analyzed. An unexposed and/or inaccessible second module element expressed in the serial form is identified as a potential error condition. A corrective execution is executed and/or a warning is presented.

Modular serialization

Techniques for remediating serialization incompatibilities are disclosed. A runtime environment of a module system identifies a first serializable runtime object comprising a reference to a second serializable runtime object. The first serializable runtime object is an instantiation of a first element in a first package of the module system. The first package is open to one or more reflective operations. Based on determining that (a) the second serializable runtime object is an instantiation of a second element in a second package of the module system and (b) the second element is not open to the one or more reflective operations, a remedial operation, associated with the first serializable runtime object, is executed.

Growing community of inventors

Dublin, Ireland

Alan Bateman