Restrictive access control for modular reflection

Abstract

The present disclosure relates to "restrictive access control for modular reflection". If a module element within a first module has not been exposed to a second module, access by the second module to a module element within a first module is prohibited. If a specific module element within a first module has been exposed to a second module, access by the second module to the specific module element may or may not be allowed, depending on: (a) whether the specific module element has been declared with a public access modifier or a non-public access modifier, (b) whether a second exposed module element that includes the specific module element has been declared with a public access modifier or a non-public access modifier, (c) the access level associated with an operation that attempts to access the specific module element of the first module, and / or (d) whether an accessibility override configuration for accessing the specific module element is set.

Description

[0001] This application is a divisional application of invention patent application 201680002642.2, filed on June 14, 2016, entitled “Restrictive Access Control for Modular Reflection”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of U.S. Application No. 14 / 847,800, filed September 8, 2015, which claims the benefit of U.S. Provisional Application No. 62 / 209,878, filed August 25, 2015; this application also claims the benefit of U.S. Application No. 14 / 847,833, filed September 8, 2015, which claims the benefit of U.S. Provisional Application No. 62 / 209,878, filed August 25, 2015; this application also claims the benefit of U.S. Provisional Application No. 62 / 209,878, filed August 25, 2015, and all of which are incorporated herein by reference. Priority is claimed to all applications to the extent appropriate. Technical Field

[0004] The present disclosure relates to module systems. In particular, the present disclosure relates to limiting access to unexposed module elements in a module system. Background Art

[0005] A module system allows a set of modules to be defined. Each module in a module system corresponds to a corresponding set of code. The module system specifies how a set of code corresponding to a particular module can access code corresponding to other modules. For a particular module, a module descriptor (interchangeably referred to as a "module interface") expresses other modules that the particular module may depend on. The declaration of a dependency on another module may be referred to as an explicit dependency. The module descriptor also expresses the elements of the particular module that are exposed by the particular module to other modules that declare an explicit dependency on the particular module. Other modules that do not declare an explicit dependency on the particular module are restricted from accessing such elements.

[0006] Conventionally, module systems are designed to allow certain access techniques and / or accessibility configurations to override access restrictions declared in module descriptors. In one example, a reflection application programming interface (API) (such as java.lang.reflect in Java SE) allows a test framework module to access module elements within a particular module, even if that module element has not been exposed to the test framework module by that particular module. In another example, the reflection API of the .NET platform allows access to the internals of any module.

[0007] The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The embodiments are shown in the figures of the accompanying drawings by way of example and not limitation. It should be noted that references to "one" or "an" embodiment in the present disclosure are not necessarily to the same embodiment, and they mean at least one embodiment. In the drawings:

[0009] Figure 1 An example computing architecture is shown in which the techniques described herein may be practiced.

[0010] Figure 2 is a block diagram illustrating one embodiment of a computer system suitable for implementing the methods and features described herein.

[0011] Figure 3 An example virtual machine memory layout in block diagram form is shown in accordance with an embodiment.

[0012] Figure 4 An example of modules in a Java module system is shown in accordance with one or more embodiments.

[0013] Figure 5 Operations according to one or more embodiments are shown.

[0014] Figure 6 A system according to one or more embodiments is shown. DETAILED DESCRIPTION

[0015] In the following description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding. One or more embodiments may be practiced without these specific details. Features described in one embodiment may be combined with features described in different embodiments. In some examples, well-known structures and devices are described with reference to block diagram form in order to avoid unnecessarily obscuring the present invention.

[0016] 1. General Overview

[0017] 2. System Architecture Overview

[0018] 2.1 Example class file structure

[0019] 2.2 Example Virtual Machine Architecture

[0020] 2.3 Loading, linking and initialization

[0021] 3. Module elements of modules in the module system

[0022] 4. Access types used to access module elements

[0023] 5. Controlling access to module elements

[0024] 6. Example Embodiments

[0025] 7. Other aspects; expansion

[0026] 8. Hardware Overview

[0027] 1. General Overview

[0028] One or more embodiments include strictly controlling access to modules in a module system.

[0029] In one embodiment, if a module element within a first module has not been exposed to a second module, access by the second module to the module element within the first module is strictly prohibited. Access by the second module to an unexposed module element of the first module is strictly prohibited, regardless of (a) whether the unexposed module element has been declared with a public access modifier or a non-public access modifier, (b) the access level associated with the operation that attempts to access the unexposed module element of the first module, and (c) whether an accessibility override configuration is set for the unexposed module element. In the example, access by a consumer module to the unexposed module element of a provider module is prohibited even when access is attempted using a reflection operation with an accessibility override configuration set for attempting to access the unexposed module element.

[0030] In the example, access by the second module to an unexposed module element within the first module is strictly prohibited even when access is attempted using a reflection operation with an accessibility override configuration that sets the unexposed module element to be publicly accessible.

[0031] In an embodiment, if a particular module element within a first module has been exposed to a second module, access by the second module to the particular module element may or may not be permitted. Permission to access the exposed particular module element may be determined based on one or more factors, including, but not limited to: (a) whether the particular module element has been declared with a public access modifier or a non-public access modifier, (b) whether a second exposed module element that includes the particular module element has been declared with a public access modifier or a non-public access modifier, (c) an access level associated with an operation that attempts to access an unexposed module element of the first module, and (d) whether an accessibility override configuration is set for the unexposed module element.

[0032] In the example, the module element in the first module is a field declaration with a non-public access modifier. The field declaration is within a class declaration with a public access modifier. By exposing the package that includes the class declaration (and therefore the field declaration), both the field declaration and the class declaration are exposed. If the second module attempts to access the field declaration (with a non-public access modifier) ​​using a reflection operation, access is allowed or prohibited based on whether the accessibility override configuration is set for the field declaration by the reflection operation. If the accessibility override configuration is not set, the non-public access modifier in the field declaration indicates that the second module is prohibited from accessing the field declaration. If the accessibility override configuration is set, the non-public access modifier in the field declaration is overridden and the second module is allowed to access the field declaration.

[0033] One or more embodiments described in this specification and / or described in the claims may not be included in this general overview section.

[0034] 2. System Architecture Overview

[0035] Figure 1 An example architecture in which the techniques described herein may be practiced is shown. The software and / or hardware components described with respect to the example architecture may be omitted or associated with a set of functions different from those described herein. According to one or more embodiments, software and / or hardware components not described herein may be used within the environment. Therefore, the example environment should not be considered to limit the scope of any claim.

[0036] like Figure 1 As shown, the computing architecture 100 includes source code files 101, which are compiled by a compiler 102 into class files 103 representing a program to be executed. The class files 103 are then loaded and executed by an execution platform 112, which includes a runtime environment 113, an operating system 111, and one or more application programming interfaces (APIs) 110 that enable communication between the runtime environment 113 and the operating system. The runtime environment 112 includes a virtual machine 104, which includes various components, such as a memory manager 105 (which may include a garbage collector), a class file validator 106 that checks the validity of the class files 103, a class loader 107 that locates and builds an in-memory representation of a class, an interpreter 108 for executing the virtual machine 104 code, and a just-in-time (JIT) compiler 109 for generating optimized machine-level code.

[0037] In an embodiment, computing architecture 100 includes source code files 101 that contain code written in a particular programming language, such as Java, C, C++, C#, Ruby, Perl, etc. Thus, source code files 101 follow a particular set of grammatical and / or semantic rules for the associated language. For example, code written in Java follows the Java language specification. However, because specifications are updated and revised over time, source code files 101 may be associated with a version number that indicates a revised version of the specification followed by source code files 101. The exact programming language used to write source code files 101 is generally not critical.

[0038] In various embodiments, compiler 102 converts source code written according to a specification convenient for a programmer into machine code or object code that can be directly executed by a specific machine environment, or an intermediate representation ("virtual machine code / instructions") such as bytecode that can be executed by a virtual machine 104 that can run on various specific machine environments. Virtual machine instructions can be executed by virtual machine 104 in a more direct and efficient manner than source code. Converting source code to virtual machine instructions includes mapping source code functions from a language to virtual machine functions that utilize underlying resources (such as data structures). Typically, functions presented in simple terms by a programmer via source code are converted into more complex steps that are more directly mapped to instruction sets supported by the underlying hardware on which virtual machine 104 resides.

[0039] Generally speaking, a program is executed as a compiled program or an interpreted program. When a program is compiled, the code is globally transformed from a first language to a second language before execution. Since the work of transforming the code is performed in advance, the compiled code often has excellent runtime performance. In addition, since the transformation occurs globally before execution, techniques such as constant folding, dead code elimination, inlining, etc. can be used to analyze and optimize the code. However, depending on the program being executed, the startup time may be very long. In addition, inserting new code will require the program to be offline, recompiled, and re-executed. For many dynamic languages ​​(such as Java) designed to allow code to be inserted during the execution of the program, a pure compilation method may be inappropriate. When the program is interpreted, the code of the program is read line by line and converted into machine-level instructions when the program is executed. Therefore, the program has a short startup time (can start execution almost immediately), but the runtime performance is reduced due to the on-the-fly execution transformation. In addition, since each instruction is analyzed separately, many optimizations that rely on a more global analysis of the program cannot be performed.

[0040] In some embodiments, virtual machine 104 includes interpreter 108 and JIT compiler 109 (or components implementing these two aspects), and uses a combination of interpretation technology and compilation technology to execute the program. For example, virtual machine 104 can initially start by interpreting the virtual machine instructions representing the program via interpreter 108, while tracking statistical information related to program behavior, such as how frequently different code parts or code blocks are executed by virtual machine 104. Once the code block exceeds the threshold (becomes "hot"), virtual machine 104 calls JIT compiler 109 to perform analysis of the block and generate optimized machine-level instructions, which replace the "hot" code block for future execution. Since programs often spend most of their time executing a small part of the entire code, only compiling the "hot" part of the program can provide performance similar to that of the fully compiled code, but without a startup penalty. In addition, although the optimization analysis is constrained to the "hot" block that is replaced, there is still a much greater optimization potential than converting each instruction separately. There are several variants for the above example, such as tiered compilation.

[0041] To provide a clear example, source code file 101 has been illustrated as a "top-level" representation of a program to be executed by execution platform 111. Although computing architecture 100 depicts source code file 101 as a "top-level" program representation, in other embodiments, source code file 101 may be an intermediate representation received via a "higher-level" compiler that processes code files in different languages ​​into the language of source code file 101. Some examples in the following disclosure assume that source code file 101 conforms to a class-based object-oriented programming language. However, this is not a requirement to utilize the features described herein.

[0042] In an embodiment, compiler 102 receives source code file 101 as input and converts source code file 101 into class file 103 in a format expected by virtual machine 104. For example, in the context of the JVM, the Java Virtual Machine Specification defines a specific class file format that class files 103 are expected to follow. In some embodiments, class file 103 contains virtual machine instructions that have been converted from source code file 101. However, in other embodiments, class file 103 may also contain other structures, such as tables identifying constant values ​​and / or metadata associated with various structures (classes, fields, methods, etc.).

[0043] The following discussion assumes that each of the class files 103 represents a corresponding "class" defined in the source code file 101 (or dynamically generated by the compiler 102 / virtual machine 104). However, the above assumption is not a strict requirement and will depend on the implementation of the virtual machine 104. Therefore, no matter how the exact format of the class file 103 is, the technology described herein can still be executed. In some embodiments, the class file 103 is divided into one or more "libraries" or "packages", each of which includes a collection of classes that provide related functions. For example, a library can contain one or more class files that implement input / output (I / O) operations, mathematical tools, cryptographic techniques, graphics utilities, etc. In addition, some classes (or fields / methods in those classes) can include access restrictions that limit the use of these classes (or fields / methods in those classes) to specific classes / libraries / packages or to classes with appropriate permissions.

[0044] 2.1 Example class file structure

[0045] Figure 2 An example structure of a class file 200 in block diagram form according to an embodiment is shown. To provide a clear example, the remainder of this disclosure assumes that the class file 103 of the computing architecture 100 follows the structure of the example class file 200 described in this section. However, in an actual environment, the structure of the class file 200 will depend on the implementation of the virtual machine 104. In addition, one or more features discussed herein may modify the structure of the class file 200, for example, to add additional structure types. Therefore, the exact structure of the class file 200 is not critical to the techniques described herein. For the purposes of Section 2.1, a "class" or "current class" refers to a class represented by a class file 200.

[0046] exist Figure 2 In the embodiment, class file 200 is composed of class members, which include but are not limited to constant table 201, field structure 208, class metadata 204 and method structure 209. In an embodiment, constant table 201 is a data structure that also serves as a symbol table of a class in addition to other functions. For example, constant table 201 can store data related to various identifiers used in source code file 101, such as type, range, content and / or position. Constant table 201 has entries for value structure 202 (constant values ​​representing types int, long, double, float, byte, string, etc.), class information structure 203, name and type information structure 205, field reference structure 206 and method reference structure 207 derived from source code file 101 by compiler 102. In an embodiment, constant table 201 is implemented as an array that maps index i to structure j. However, the exact implementation of constant table 201 is not critical.

[0047] In some embodiments, entries of constant table 201 include structures that index other entries of constant table 201. For example, an entry of one of value structures 202 used to represent a string may hold a tag identifying its "type" as a string, and may hold indexes to one or more other value structures 202 of constant table 201 that store char, byte, or int values ​​representing the ASCII characters of the string.

[0048] In an embodiment, a field reference structure 206 of a constant table 201 holds an index to one of the class information structures 203 representing a defined field in the constant table 201, and holds an index to one of the name and type information structures 205 providing the name and descriptor of the field in the constant table 201. A method reference structure 207 of the constant table 201 holds an index to one of the class information structures 203 representing a class defining a method in the constant table 201, and holds an index to one of the name and type information structures 205 providing the name and descriptor of the method in the constant table 201. A class information structure 203 holds an index to one of the value structures 202 holding the name of the associated class in the constant table 201.

[0049] The name and type information structure 205 holds a reference to one of the value structures 202 storing the name of the field / method in the constant table 201 and holds a reference to one of the value structures 202 storing the descriptor in the constant table 201 .

[0050] In an embodiment, the class metadata 204 includes metadata for the class, such as (one or more) version numbers, the number of entries in the constant pool, the number of fields, the number of methods, access flags (whether the class is public, non-public, final, abstract, etc.), an index in the constant table 201 to one of the class information structures 203 identifying the current class, an index in the constant table 201 to one of the class information structures 203 identifying the superclass (if any), and the like.

[0051] In an embodiment, field structure 208 represents a set of structures that identify the various fields of a class. Field structure 208 stores, for each field of the class, the field's accessor flag (whether the field is static, public, non-public, final, etc.), an index to one of the value structures 202 in constant table 201 that holds the field's name, and an index to one of the value structures 202 in constant table 201 that holds the field's descriptor.

[0052] In an embodiment, method structure 209 represents a set of structures that identify various methods of a class. Method structure 209 stores, for each method of the class, a method's accessor flag (e.g., whether the method is static, public, non-public, synchronized, etc.), an index to one of value structures 202 in constant table 201 that holds the name of the method, an index to one of value structures 202 in constant table 201 that holds the method's descriptor, and virtual machine instructions corresponding to the body of the method as defined in source code file 101.

[0053] In an embodiment, a descriptor represents the type of a field or method. For example, a descriptor can be implemented as a string that follows a specific syntax. Although the exact syntax is not important, several examples will be described below.

[0054] In the example where the descriptor represents the type of the field, the descriptor identifies the type of data held by the field. In an embodiment, a field can hold a basic type, an object, or an array. When a field holds a basic type, the descriptor is a string that identifies the basic type (e.g., "B" = byte, "C" = char, "D" = double, "F" = float, "I" = int, "J" = longint, etc.). When a field holds an object, the descriptor is a string that identifies the class name of the object (e.g., "L ClassName"). In this case, "L" indicates a reference, so "L ClassName" represents a reference to an object of class ClassName. When a field is an array, the descriptor identifies the type held by the array. For example, "[B" indicates an array of bytes, where "[" indicates an array and "B" indicates that the array holds the basic type byte. However, since arrays can be nested, the descriptor of an array can also indicate nesting. For example, "[[L ClassName" indicates an array, where each index array holds an object of class ClassName. In some embodiments, ClassName is fully qualified and includes the simple name of the class and the path name of the class. For example, ClassName may indicate where the file is stored in a package, library, or file system that manages class file 200 .

[0055] In the case of a method, the descriptor identifies the parameters of the method and the return type of the method. For example, a method descriptor can be in the general form "({Parameter Descriptor})ReturnDescriptor" where {ParameterDescriptor} is a list of field descriptors representing the parameters and ReturnDescriptor is a field descriptor identifying the return type. For example, the string "V" can be used to represent a void return type. Thus, a method defined in source code file 101 as "Object m(int I, double d, Thread t){...}" matches the descriptor "(ID LThread)L Object".

[0056] In an embodiment, the virtual machine instructions held in method structure 209 include operations that reference entries of constant table 201. Using Java as an example, consider the following class:

[0057] Class A

[0058] {

[0059] int addl2andl3(){

[0060] return B.addTwo(12,13);

[0061] }

[0062] }

[0063] In the above example, Java methods add12and13 are defined in class A, take no parameters, and return an integer. The body of method add12and13 calls static method addTwo of class B, which takes constant integer values ​​12 and 13 as parameters and returns a result. Therefore, in constant table 201, compiler 102 includes, in addition to other entries, a method reference structure corresponding to the call to method B.addTwo. In Java, calls to methods are compiled down to invoke commands in the bytecode of the JVM (invokestatic in this case, because addTwo is a static method of class B). The invoke command is provided with an index in constant table 201 corresponding to the method reference structure, which identifies the class "B" that defines addTwo, the name "addTwo" of addTwo, and the descriptor "(II)I" of addTwo. For example, assuming that the above method reference is stored at index 4, the bytecode instruction can be expressed as "invokestatic#4".

[0064] Since constant table 201 uses structures with identification information (rather than direct references to memory locations) to symbolically reference classes, methods, and fields, the entries of constant table 201 are called "symbolic references". One reason symbolic references are used for class files 103 is because in some embodiments compiler 102 does not know how and where the class will be stored once loaded into runtime environment 112. As will be described in Section 2.3, after the referenced class (and associated structure) has been loaded into the runtime environment and assigned a specific memory location, the runtime representation of the final symbolic reference is resolved by virtual machine 104 into an actual memory address.

[0065] 2.2 Example Virtual Machine Architecture

[0066] Figure 3 An example virtual machine memory layout 300 in block diagram form according to an embodiment is shown. To provide a clear example, the remaining discussion will assume that the virtual machine 104 follows Figure 3 . Furthermore, although components of virtual machine memory layout 300 may be referred to as memory "regions," there is no requirement that these memory regions be contiguous.

[0067] exist Figure 3 In the example shown, the virtual machine memory layout 300 is divided into a shared area 301 and a thread area 307. The shared area 301 represents an area in the memory in which structures shared between various threads executed on the virtual machine 104 are stored. The shared area 301 includes a heap 302 and a per-class area 303. In an embodiment, the heap 302 represents a runtime data area from which memory for class instances and arrays is allocated. In an embodiment, the per-class area 303 represents a memory area in which data related to each class is stored. In an embodiment, for each loaded class, the per-class area 303 includes a runtime constant pool 304 representing data from the constant table 201 of the class, field and method data 306 (for example, to hold static fields of the class), and method code 305 representing virtual machine instructions for methods of the class.

[0068] Thread area 307 represents a memory area in which structures specific to each thread are stored. Figure 3 , thread region 307 includes thread structure 308 and thread structure 311, which represent per-thread structures utilized by different threads. To provide a clear example, Figure 3 The thread region 307 depicted in FIG. 1 assumes that two threads are executing on the virtual machine 104. However, in a practical environment, the virtual machine 104 may execute any arbitrary number of threads, with the number of thread structures scaling accordingly.

[0069] In an embodiment, thread structure 308 includes program counter 309 and virtual machine stack 310. Similarly, thread structure 311 includes program counter 312 and virtual machine stack 313. In an embodiment, program counter 309 and program counter 312 store the current address of the virtual machine instruction executed by its corresponding thread.

[0070] Thus, as the thread steps through instructions, the program counter is updated to maintain an index to the current instruction.In an embodiment, virtual machine stack 310 and virtual machine stack 313 each store a frame for its respective thread that holds local variables and partial results and is also used for method calls and returns.

[0071] In an embodiment, a frame is a data structure used to store data and partial results, return method values, and perform dynamic linking. Each time a method is called, a new frame is created. When the method that generates the frame is completed, the frame is destroyed. Therefore, when a thread executes a method call, the virtual machine 104 generates a new frame and pushes the frame onto the virtual machine stack associated with the thread.

[0072] When the method call is completed, the virtual machine 104 passes the result of the method call back to the previous frame and pops the current frame from the stack. In an embodiment, for a given thread, there is a frame that is active at any point. This active frame is called the current frame, so that the method that generates the current frame is called the current method, and the class to which the current method belongs is called the current class.

[0073] 2.3 Loading, linking and initialization

[0074] In an embodiment, the virtual machine 104 dynamically loads, links, and initializes classes. Loading is the process of finding a class with a specific name and creating a representation from the associated class file 200 of that class within the memory of the runtime environment 112. For example, a runtime constant pool 304, method code 305, and field and method data 306 are created for the class within the per-class area 303 of the virtual machine memory layout 300. Linking is the process of taking the in-memory representation of the class and combining it with the runtime state of the virtual machine 104 so that the methods of the class can be executed. Initialization is the process of executing a class constructor to set the starting state of the fields and method data 306 of the class and / or creating a class instance on the heap 302 for the initialized class.

[0075] The following are examples of loading, linking, and initialization techniques that may be implemented by virtual machine 104. However, in many embodiments, these steps may be interleaved such that an initial class is loaded, and then during linking, a second class is loaded to resolve symbolic references found in the first class, which in turn causes a third class to be loaded, and so on. Thus, the progression through the loading, linking, and initialization phases may vary from class to class. In addition, some embodiments may delay ("lazy" execution) one or more functions in the loading, linking, and initialization process until the class is actually needed. For example, resolution of a method reference may be delayed until the virtual machine instructions that call the method are executed. Thus, the exact timing of the execution of the steps for various classes may vary greatly between various implementations.

[0076] To start the loading process, the virtual machine 104 is started by calling the class loader 107 that loads the initial class. The technology for specifying the initial class will be different between embodiments. For example, a technology can enable the virtual machine 104 to accept a command line parameter specifying the initial class when starting.

[0077] To load a class, the class loader 107 parses the class file 200 corresponding to the class and determines whether the class file 200 is well-formed (satisfies the grammatical expectations of the virtual machine 104). If the class file 200 is not well-formed, the class loader 107 generates an error. For example, in Java, an error may be generated in the form of an exception, which is thrown to an exception handler for processing. Otherwise, the class loader 107 generates an in-memory representation of the class by allocating a runtime constant pool 304, method code 305, and field and method data 306 for the class in the class area 303.

[0078] In some embodiments, when class loader 107 loads a class, class loader 107 also recursively loads the superclass of the loaded class. For example, virtual machine 104 can ensure that the superclass of a particular class is loaded, linked and / or initialized before continuing the loading, linking and initialization process of a particular class.

[0079] During linking, the virtual machine 104 validates the class, prepares the class, and performs resolution of symbolic references defined in the runtime constant pool 304 of the class.

[0080] To verify the class, the virtual machine 104 checks whether the in-memory representation of the class is structurally correct. For example, the virtual machine 104 may check that each class except the general class Object has a superclass, check that the final class has no subclasses and that the final method is not overridden, check whether the constant pool entries are consistent with each other, check whether the current class has the correct access permissions to the class / field / structure referenced in the constant pool 304, check that the virtual machine 104 code of the method will not cause unexpected behavior (e.g., ensure that the jump instruction will not send the virtual machine 104 beyond the end of the method), etc. The exact checks performed during verification depend on the implementation of the virtual machine 104. In some cases, verification may cause additional classes to be loaded, but it is not necessarily required that those classes are also linked before continuing. For example, suppose that class A contains a reference to a static field of class B. During verification, the virtual machine 104 may check class B to ensure that the referenced static field actually exists, which may result in the loading of class B, but not necessarily the linking or initialization of class B. However, in some embodiments, some verification checks may be delayed until a later stage, such as being checked during the resolution of symbolic references. For example, some embodiments may delay checking access permissions on symbolic references until those references are resolved.

[0081] To prepare the class, the virtual machine 104 initializes the static fields located within the field and method data 306 of the class to default values. In some cases, setting the static fields to default values ​​may be different from running the constructor of the class. For example, the verification process may clear the static fields to zero or set them to the values ​​that the constructor expects those fields to have during initialization.

[0082] During parsing, the virtual machine 104 dynamically determines the specific memory address from the symbolic reference included in the runtime constant pool 304 of the class. In order to resolve the symbolic reference, the virtual machine 104 uses the class loader 107 to load the class identified in the symbolic reference (if not already loaded). Once loaded, the virtual machine 104 knows the memory location of the referenced class and its fields / methods in the class area 303. Then, the virtual machine 104 replaces the symbolic reference with a reference to the specific memory location of the referenced class, field or method. In an embodiment, the virtual machine 104 caches the parsing to reuse it when the virtual machine 104 processes another class and encounters the same class / name / descriptor. For example, in some cases, class A and class B may call the same method of class C. Therefore, when parsing is performed on class A, the result can be cached and reused during parsing the same symbolic reference in class B to reduce overhead.

[0083] In some embodiments, the step of resolving symbol references during linking is optional. For example, an embodiment may perform symbol resolution in a "lazy" manner, thereby delaying the step of resolution until a virtual machine instruction requiring the referenced class / method / field is executed.

[0084] During initialization, the virtual machine 104 executes the constructor of the class to set the starting state of the class. For example, the initialization can initialize the field and method data 306 of the class and generate / initialize any class instances on the heap 302 created by the constructor. For example, the class file 200 for the class can specify that a particular method is a constructor for setting the starting state. Therefore, during initialization, the virtual machine 104 executes the instructions of the constructor.

[0085] In some embodiments, the virtual machine 104 performs resolution of field and method references by initially checking whether the field / method is defined in the referenced class. Otherwise, the virtual machine 104 recursively searches the superclasses of the referenced class for the referenced field / method until the field / method is located or the top-level superclass is reached, generating an error in the case of reaching the top-level superclass.

[0086] Module elements for modules in the module system

[0087] One or more embodiments may be applied to a module system. Each module in the module system corresponds to a corresponding set of codes (referred to as "module code"). Each module is associated with one or more module elements. A module element as referred to herein corresponds to a portion of a module code. A module element (a portion of a module code) itself may include additional module elements (sub-portions of a module code).

[0088] The module system implemented with different programming languages ​​can be defined with different types of module elements. For the purpose of explanation, some examples described herein refer to the specific module elements of the modules in the Java module system. However, the embodiment is equally applicable to different types of module elements in the module system implemented with other programming languages.

[0089] In the Java module system, each module includes one or more packages. Each package includes one or more classes. Each class includes one or more class members, such as fields and methods. Methods as referred to herein include constructors that can be called to create objects by instantiating classes. As mentioned herein with respect to the Java module system, module elements may include packages, classes, or class members.

[0090] Exposing module elements

[0091] In an embodiment, a module element of a module may or may not be exposed to another module. In the Java module system, a package may be exposed by a module when the module descriptor corresponding to the module includes an "exports" expression in which the package is identified as an argument. A package may be exported to a specified set of modules (referred to as "qualified exports") or to all other modules in the module system (referred to as "unqualified exports").

[0092] A module element of a provider module may be exposed by the provider module to a consumer module if any of a set of conditions are satisfied. The set of conditions may include, but are not limited to, (a) a declaration within the provider module's descriptor to expose the module element to the consumer module via a qualified or unqualified output, (b) a user instruction received via an interface (e.g., a command line interface), (c) a determination made by a runtime environment based on detection of a triggering event associated with permission to expose the module element, or (d) any other instruction instructing the module system to expose the module element.

[0093] A specific module element can be exposed by exposing the specific module element itself or by exposing another module element that includes the specific module element. In one example, a class can be exposed by exposing the package that includes the class. Class members of a class are also exposed by exposing the package that includes the class.

[0094] One or more embodiments relate to module elements of modules in access module systems. The module attempting to access is referred to as a consumer module herein, and the module being accessed is referred to as a provider module herein. For different access operations, a module can be used as a consumer module or as a provider module.

[0095] In an embodiment, determining whether a module element of a provider module can be accessed by a consumer module is based at least in part on whether the module element in the provider module has been exposed to the consumer module. Access control to determine whether a module element of a provider module can be accessed by a consumer module is further described in Section 5, "Controlling Access to Module Elements."

[0096] Access modifiers for module elements

[0097] In an embodiment, module elements are declared using access modifiers. Access modifiers identify the accessibility configuration of the module element. The accessibility configuration declares that the module element is (a) publicly accessible or (b) not publicly accessible. In one example, the modifier "public" indicates that the module element is publicly accessible, and the modifier "private" indicates that the module element is not publicly accessible. However, the declared access modifiers themselves do not control whether the module element is accessible or inaccessible from outside the module. Access control that determines whether a module element of a provider module can be accessed by a consumer module is further described in Section 5, "Controlling Access to Module Elements."

[0098] 4. Operations that may require access to module elements of the provider module by the consumer module

[0099] In an embodiment, different kinds of operations require access by consumer modules to module elements of a provider module.

[0100] Operations may be performed on the bytecode to enumerate, analyze, and / or classify portions of the bytecode.Some examples of operations for accessing module elements include reflection operations identified in the Java Reflection API.

[0101] In an embodiment, an operation includes getting or setting the value of a module element, where (a) the module element represents a field, (b) the get or set is performed relative to an object, and (c) the object is an instance of another module element (e.g., a class that includes the field). A set of example operations includes, but is not limited to:

[0102] (a) getField(String name): Returns a Field object that reflects the specified field of the class or interface represented by the Class object against which the command is executed.

[0103] (b) getFields(): Returns an array of Field objects reflecting all the fields of the class or interface represented by the Class object for which the command is executed.

[0104] (c) getDeclaredFields(): Returns an array of Field objects reflecting all the fields declared by the class or interface represented by the Class object for which the command is executed.

[0105] (d) getDeclaredMethods(): Returns an array of Method objects reflecting all methods declared by the class or interface represented by the Class object for which the command is executed.

[0106] (e) getSuperclass(): Returns the class that is the superclass of the entity (class, interface, primitive type, or void) represented by the class on which the command is executed.

[0107] (f) set(Object obj, Object value): Sets the value of the field represented by the Field object on the specified object parameter (where the command is executed on the Field object) to the specified new value.

[0108] (g) get(Object obj): Returns the value of the field represented by the Field on the specified object (where the command is executed for the Field).

[0109] In an embodiment, the operation includes a consumer module calling a module element of a provider module. The module element as a method can be called using reflection technology or not. An example command for calling a method using reflection includes java.lang.reflect.Method.invoke(). The first parameter is the object instance on which a specific method is to be called. If the method is static, the first parameter can be null. Subsequent parameters are parameters of the method.

[0110] In an embodiment, the operation includes a consumer module instantiating a module element of a provider module. A class (a first module element of a provider module) can be instantiated by a consumer module by calling a constructor of the class (a second module element of a provider module).

[0111] In the example, class Spaceship is a first module element in a provider module. Class Spaceship includes a second module element, which is a method declaration fireMissile(). A separate class CommandCenter is a module element in a consumer module. Class CommandCenter (a module element of the consumer module) may include operations to: (a) instantiate an object of type Spaceship (a module element of the provider module) and (b) call method fireMissile() on the instance of SpaceShip from (a).

[0112] 5. Controlling access to module elements

[0113] As described above, one or more operations require access to module elements of a provider module by a consumer module. One or more embodiments include controlling access to module elements of a provider module by a consumer module. Controlling access includes allowing access or prohibiting access. If access to module elements of a provider module by a consumer module is allowed, the operation is successfully compiled or executed. If access to module elements of a provider module by a consumer module is prohibited, the operation may not be successfully compiled and / or may not be successfully executed. As described herein, factors for controlling access to module elements of a particular type may be applied to controlling access to module elements of another type.

[0114] Figure 4 An example of a module in a Java module system according to one or more embodiments is shown. Other modules (defined using the Java module system or other module systems) may include Figure 4 408. A module (e.g., module 402) may include any number of packages. A package (e.g., package 404) may include any number of classes. A class (e.g., class 406) may include any number of class members (e.g., class members 408).

[0115] One or more embodiments include controlling access by a consumer module (e.g., module 430) to a module element (i.e., package 404, class 406, or class member 408) of a provider module (e.g., module 402). In order for module 430 to access class member 408 of module 402, module 430 may require access permissions to (a) class member 408 itself, (b) class 406 that includes class member 408, and (c) package 404 that includes class 406. Additionally, access controls applicable to module elements (e.g., class 406) may determine whether operations to access objects created by instantiating the module element are allowed or prohibited. In an example, access to obtain or modify the value of a field of an object is allowed or prohibited based on the access controls for the specific class that was instantiated to create the object.

[0116] Figure 5 A set of example steps for allowing or disabling access by a consumer module to a module element of a provider module is shown. Figure 5 The steps described may be performed before runtime and / or during runtime. A compiler, interpreter, and / or runtime environment may perform one or more of the steps described below.

[0117] Initially, an operation in which a consumer module attempts to access a module element of a provider module is identified (step 502). The operation may be identified by a compiler during the compilation process. The operation may be identified by a runtime environment when a request is made to perform the operation. Some examples of the types of operations that require access to module elements are indicated in Section 4 above entitled "Operations that may require access to module elements of a provider module by a consumer module".

[0118] In response to identifying an operation in which a consumer module attempts to access a module element of a provider module, a check is required to determine whether the consumer module has the necessary permissions to access the module element of the provider module. This check is a multi-step process as described below.

[0119] In an embodiment, a determination is made as to whether a module element of a provider module has been exposed to a consumer module (step 504). As mentioned above, a particular module element of a provider module may be exposed to a consumer module if (a) the particular module element itself has been exposed to a consumer module or (b) a second module element that includes the particular module element has been exposed to a consumer module. In the Java module system, if a package in a provider module has been exposed to a consumer module, all classes within the package and class members within the class have been exposed to the consumer module. Figure 4 In the example shown, exposing package 404 of module 402 to module 430 includes exposing class 406 and class 408 to module 430. Package 404 of module 402 may be exposed to module 430 using a qualified export that specifically identifies module 430. Package 404 of module 402 may be exposed to module 430 using a non-qualified export (not specifically identifying module 430) for all modules in the module system.

[0120] If the module elements of the provider module have not been exposed to the consumer module, the consumer module is strictly prohibited from accessing the module elements of the provider module (step 506). Access by the consumer module to the module elements of the provider module is strictly prohibited, regardless of (a) the access modifiers in the module element declaration, (b) the accessibility override configuration expressed for the module element (described below), or (c) the access level associated with the operation that attempts to access the module element (described below). Strictly prohibiting access can include generating a compile-time error and / or a runtime error (e.g., throwing an exception) that prevents the execution of the operation that attempts to access the module element.

[0121] exist Figure 4In the example shown in , if class member 408 has not been exposed to module 430, access to class member 408 by module 430 is strictly prohibited. The strict prohibition on unexposed class member 408 is applicable even if (a) class member 408 and class 406 are declared with public access modifiers, (b) the accessibility override configuration is set to override any non-public access modifiers, and (c) the attempt to access class member 408 relies on an operation with the highest possible access level. Similarly, if class 406 has not been exposed to module 430, access to class 406 by module 430 is strictly prohibited.

[0122] If a determination is made in operation 504 that a module element of a provider module has been exposed to a consumer module, access may or may not be allowed. In other words, exposing a module element of a provider module to a consumer module does not guarantee that the consumer module is allowed access to the module element. Allowing or disallowing access by a consumer module to an exposed module element of a provider module depends on a set of factors as described below.

[0123] In an embodiment, a determination is made as to whether the exposed module element is declared with a public access modifier (step 508). The module element declaration may be checked to determine whether a public access modifier or a non-public access modifier is configured for the exposed module element. Additionally, if the exposed module element is included within another parent module element having an access modifier, a check is performed to determine whether the declaration of the parent module element includes a public access modifier or a non-public access modifier. For example, if the exposed module element is a class member of a particular class, the access modifiers of each of the class member declaration and the class declaration are checked to determine whether both include a public access modifier.

[0124] If the module element (and any parent module elements with an access modifier) ​​is declared with a public access modifier, access by the consumer module to the module element of the provider module is allowed, step 514. Allowing access by the consumer module to the module element of the provider module allows successful compilation and / or execution of operations that attempt to access the module element.

[0125] If the exposed module element (or if any parent module element of the module element) is declared with a non-public access modifier, additional analysis is required to determine whether access to the exposed module element is allowed or prohibited. Access to an exposed module element with a non-public access modifier may depend on the access level associated with the operation attempting to access it. Figure 5An operation with a minimum access level required to access an exposed module element with a non-public modifier is defined as a reflective operation with an accessibility override configuration set for the exposed module element (described in detail below). However, other embodiments are equally applicable to any system in which different operations are associated with different access levels. For example, a first operation (in a consumer module) with a first access level is allowed to access non-public class members of a public class in an exposed package of a provider module. However, the first operation with the first access level is prohibited from accessing non-public class members of a non-public class in an exposed package of the provider module. A second operation (in the same consumer module) with a second access level (higher than the first access level) is allowed to access non-public class members of a non-public class in an exposed package of the provider module. Therefore, the following description Figure 5 The specific operations 510 and 512 should be understood as a set of example rules for determining access to exposed module elements with non-public modifiers. The specific operations 510 and 512 should not be interpreted as limiting the scope of other embodiments in which a set of different access levels are used to define operations.

[0126] continue Figure 5 In an embodiment, an exposed module element with a non-public access modifier may be accessed if (a) the operation is a reflective operation (step 510) and (b) an accessibility override configuration is set for the exposed module element being accessed (step 512). Therefore, if the operation is a reflective operation with an accessibility override configuration set for the accessed module element, access to the module element is allowed (step 514). In an embodiment, the accessibility override configuration is available to consumer modules for accessing module elements of a provider module. Even if the accessibility override configuration is set to access module elements of a provider module, the accessibility override configuration may be available to consumer modules independently of any configuration for the provider module.

[0127] In the example, reflective operations (from the Java reflection API) include get(Object obj), which returns the value of the field represented by the Field on the specified object (where the command is executed for the Field). Reflective operations also include setAccessible(), which sets the accessibility override configuration for an exposed module element with a non-public modifier. Reflective operations with accessibility override configuration are allowed to access exposed module elements with a non-public modifier. An exposed module element is an element of a provider module that is being accessed by a consumer module.

[0128] 6. Example Embodiments

[0129] One or more embodiments include a non-transitory computer-readable medium including instructions that, when executed by one or more hardware processors, cause a set of steps to be performed. The set of steps includes: identifying an operation expressed in a first set of module code that attempts to access a module element of a second set of module code; determining whether the module element has been exposed to the first set of module code by the second set of module code; and in response to determining that the module element has not been exposed to the first set of module code by the second set of module code: prohibiting the operation from attempting to access the module element even when the operation attempts to access the module element using an accessibility override configuration available to the first set of module code.

[0130] In one or more embodiments, the operation comprises a reflection operation, and wherein an accessibility override configuration is set for the module element.

[0131] In one or more embodiments, determining that the module element has not been exposed by the second set of module code to the first set of module code includes determining that the module element is not part of any set of code that has been exposed by the second set of module code to the first set of module code.

[0132] In one or more embodiments, the operation includes invoking a module element.

[0133] In one or more embodiments, the operation includes modifying a value of an object created by instantiating a module element.

[0134] In one or more embodiments, an operation includes obtaining a value of an object created by instantiating a module element.

[0135] In one or more embodiments, the operations include instantiating a module element.

[0136] In one or more embodiments, prohibiting an operation includes generating a runtime error associated with the operation.

[0137] In one or more embodiments, prohibiting an operation includes generating a compile-time error associated with the operation.

[0138] In one or more embodiments, the group of steps also includes: determining that the first group of module code expresses a second operation that requires access to a second module element of the third group of module code; determining that the second module element has been exposed to the first group of module code by the third group of module code; determining that the second module element is declared with a non-public modifier; and prohibiting compilation or execution of the second operation in response to determining one of the following: (a) a second accessibility override configuration for accessing the second module element has not been set or (b) the second operation does not have an access level sufficient to access any module element with the non-public modifier.

[0139] In one or more embodiments, the group of steps also includes: determining that the first group of module code expresses a second operation that requires access to a second module element of the third group of module code; determining that the second module element has been exposed to the first group of module code by the third group of module code; determining that the second module element is declared with a non-public modifier; and allowing compilation or execution of the second operation in response to determining both of the following: (a) a second accessibility override configuration has been set for accessing the second module element, and (b) the second operation is associated with an access level sufficient to access the module element with the non-public modifier.

[0140] One or more embodiments include a method performed by at least one device including a hardware processor. The method includes: identifying an operation expressed in a first set of module codes that attempts to access a module element of a second set of module codes; determining whether the module element has been exposed to the first set of module codes by the second set of module codes; and in response to determining that the module element has not been exposed to the first set of module codes by the second set of module codes: prohibiting the operation from attempting to access the module element even when the operation attempts to access the module element using an accessibility override configuration available to the first set of module codes.

[0141] In one or more embodiments, the operation comprises a reflection operation, and wherein an accessibility override configuration is set for the module element.

[0142] In one or more embodiments, determining that the module element has not been exposed by the second set of module code to the first set of module code includes determining that the module element is not part of any set of code that has been exposed by the second set of module code to the first set of module code.

[0143] In one or more embodiments, the operation includes invoking a module element.

[0144] In one or more embodiments, the operation includes modifying a value of an object created by instantiating a module element.

[0145] In one or more embodiments, an operation includes obtaining a value of an object created by instantiating a module element.

[0146] In one or more embodiments, the operations include instantiating a module element.

[0147] In one or more embodiments, prohibiting an operation includes generating a runtime error associated with the operation.

[0148] In one or more embodiments, prohibiting an operation includes generating a compile-time error associated with the operation.

[0149] In one or more embodiments, the method further includes: determining that the first set of module code expresses a second operation that requires access to a second module element of the third set of module code; determining that the second module element has been exposed to the first set of module code by the third set of module code; determining that the second module element is declared with a non-public modifier; and prohibiting compilation or execution of the second operation in response to determining one of the following: (a) a second accessibility override configuration for accessing the second module element has not been set or (b) the second operation does not have an access level sufficient to access any module element with the non-public modifier.

[0150] In one or more embodiments, the method further includes: determining that the first set of module code expresses a second operation that requires access to a second module element of the third set of module code; determining that the second module element has been exposed to the first set of module code by the third set of module code; determining that the second module element is declared with a non-public modifier; and allowing compilation or execution of the second operation in response to determining both of the following: (a) a second accessibility override configuration has been set for accessing the second module element, and (b) the second operation is associated with an access level sufficient to access the module element with the non-public modifier.

[0151] One or more embodiments include a system including at least one device including a hardware processor, the system configured to perform a set of steps. The set of steps includes: identifying an operation expressed in a first set of module code that attempts to access a module element of a second set of module code; determining whether the module element has been exposed to the first set of module code by the second set of module code; and in response to determining that the module element has not been exposed to the first set of module code by the second set of module code: prohibiting the operation from attempting to access the module element even when the operation attempts to access the module element using an accessibility override configuration available to the first set of module code.

[0152] One or more embodiments include a non-transitory computer-readable medium including instructions that, when executed by one or more hardware processors, cause a set of steps to be performed. The set of steps includes: identifying an operation expressed in a first set of module code that attempts to access a module element of a second set of module code, wherein the module element is declared with a non-public modifier. The set of steps also includes: determining whether the module element has been exposed to the first set of module code by the second set of module code; determining whether the operation attempts to access the module element using an accessibility override configuration available to the first set of module code; and in response to determining that (a) the module element has been exposed to the first set of module code by the second set of module code, and (b) the operation attempts to access the module element using an accessibility override configuration available to the first set of module code, and only if the module element has been exposed to the first set of module code by the second set of module code: allowing the operation to access the module element using the accessibility override configuration available to the first set of module code.

[0153] In one or more embodiments, determining whether to attempt to access the module element using an accessibility override configuration available to the first set of module code is performed in response to determining that the module element has been exposed to the first set of module code by the second set of module code.

[0154] In one or more embodiments, the operation comprises a reflective operation.

[0155] In one or more embodiments, the operation includes invoking a module element.

[0156] In one or more embodiments, the operation includes modifying a value of an object created by instantiating a module element.

[0157] In one or more embodiments, an operation includes obtaining a value of an object created by instantiating a module element.

[0158] In one or more embodiments, the operations include instantiating a module element.

[0159] One or more embodiments include a method performed by at least one device including a hardware processor. The method includes: identifying an operation expressed in a first set of module codes that attempts to access a module element of a second set of module codes, wherein the module element is declared with a non-public modifier. The method also includes: determining whether the module element has been exposed to the first set of module codes by the second set of module codes; determining whether the operation attempts to access the module element using an accessibility override configuration available to the first set of module codes; and in response to determining that (a) the module element has been exposed to the first set of module codes by the second set of module codes, and (b) the operation attempts to access the module element using an accessibility override configuration available to the first set of module codes, and only if the module element has been exposed to the first set of module codes by the second set of module codes: allowing the operation to access the module element using the accessibility override configuration available to the first set of module codes.

[0160] In one or more embodiments, determining whether to attempt to access the module element using an accessibility override configuration available to the first set of module code is performed in response to determining that the module element has been exposed to the first set of module code by the second set of module code.

[0161] In one or more embodiments, the operation comprises a reflective operation.

[0162] In one or more embodiments, the operation includes invoking the module element.

[0163] In one or more embodiments, the operation includes modifying a value of an object created by instantiating a module element.

[0164] In one or more embodiments, an operation includes obtaining a value of an object created by instantiating a module element.

[0165] In one or more embodiments, the operations include instantiating a module element.

[0166] One or more embodiments include a system comprising at least one device, the at least one device comprising a hardware processor, the system configured to perform a set of steps. The set of steps includes: identifying an operation expressed in a first set of module code that attempts to access a module element of a second set of module code, wherein the module element is declared with a non-public modifier. The set of steps also includes: determining whether the module element has been exposed to the first set of module code by the second set of module code; determining whether the operation attempts to access the module element using an accessibility override configuration available to the first set of module code; and in response to determining that (a) the module element has been exposed to the first set of module code by the second set of module code, and (b) the operation attempts to access the module element using an accessibility override configuration available to the first set of module code, and only if the module element has been exposed to the first set of module code by the second set of module code: allowing the operation to access the module element using the accessibility override configuration available to the first set of module code.

[0167] In one or more embodiments, determining whether to attempt to access the module element using an accessibility override configuration available to the first set of module code is performed in response to determining that the module element has been exposed to the first set of module code by the second set of module code.

[0168] In one or more embodiments, the operation comprises a reflective operation.

[0169] In one or more embodiments, the operation includes invoking a module element.

[0170] In one or more embodiments, the operation includes modifying a value of an object created by instantiating a module element.

[0171] In one or more embodiments, an operation includes obtaining a value of an object created by instantiating a module element.

[0172] In one or more embodiments, the operations include instantiating a module element.

[0173] 7. Other aspects; expansion

[0174] Embodiments are directed to a system having one or more devices including a hardware processor and configured to perform any of the operations described herein and / or recited in any of the following claims.

[0175] In an embodiment, a non-transitory computer-readable storage medium includes instructions that, when executed by one or more hardware processors, cause performance of any of the operations described herein and / or recited in any of the claims.

[0176] Any combination of the features and functions described herein may be used in accordance with one or more embodiments. In the foregoing description, various embodiments have been described with reference to many specific details, which may vary from one implementation to another. Therefore, the description and drawings should be considered in an illustrative rather than a restrictive sense. The sole and exclusive indication of the scope of the invention, and what the applicants intend to be the scope of the invention, is the literal and equivalent range of the set of claims arising from this application, in the specific form in which such claims arise, including any subsequent corrections.

[0177] 8. Hardware Overview

[0178] According to one embodiment, the technology described herein is implemented by one or more special-purpose computing devices. The special-purpose computing device can be hard-wired to perform these technologies, or can include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are permanently programmed to perform these technologies, or can include one or more general-purpose hardware processors that are programmed to perform these technologies according to program instructions in firmware, memory, other storage devices, or combinations thereof. Such special-purpose computing devices can also combine customized hard-wired logic, ASICs or FPGAs with customized programming to implement these technologies. The special-purpose computing device can be a desktop computer system, a portable computer system, a handheld device, a networking device, or any other device that combines hard-wiring and / or program logic to implement these technologies.

[0179] For example, Figure 6 6 is a block diagram illustrating a computer system 600 upon which embodiments of the present invention may be implemented. Computer system 600 includes a bus 602 or other communication mechanism for communicating information, and a hardware processor 604 coupled to bus 602 for processing information. Hardware processor 604 may be, for example, a general purpose microprocessor.

[0180] The computer system 600 also includes a main memory 606, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus 602 for storing information and instructions to be executed by the processor 604. The main memory 606 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 604. When stored in a non-transitory storage medium accessible to the processor 604, such instructions render the computer system 600 into a special-purpose machine customized to perform the operations specified in the instructions.

[0181] Computer system 600 also includes a read only memory (ROM) 608 or other static storage device coupled to bus 602 for storing static information and instructions for processor 604. A storage device 610, such as a magnetic or optical disk, is provided and coupled to bus 602 for storing information and instructions.

[0182] The computer system 600 may be coupled to a display 612, such as a cathode ray tube (CRT), via the bus 602 for displaying information to a computer user. An input device 614, including alphanumeric and other keys, is coupled to the bus 602 for communicating information and command selections to the processor 604. Another type of user input device is a cursor control 616, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 604 and for controlling cursor movement on the display 612. Such input devices typically have two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to be positioned in a plane.

[0183] The computer system 600 can implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that is combined with the computer system to make the computer system 600 a special purpose machine or program the computer system 600 to be a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 600 in response to the processor 604 executing one or more sequences of one or more instructions contained in the main memory 606. Such instructions may be read into the main memory 606 from another storage medium, such as the storage device 610. Execution of the sequences of instructions contained in the main memory 606 causes the processor 604 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0184] As used herein, the term "storage medium" refers to any non-temporary medium that stores data and / or instructions that cause a machine to operate in a specific manner. Such storage media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 610. Volatile media include dynamic memory, such as main memory 606. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tapes or any other magnetic data storage media, CD-ROMs, any other optical data storage media, any physical media with a pattern of holes, RAM, PROMs and EPROMs, FLASH-EPROMs, NVRAMs, any other memory chips or cassettes.

[0185] Storage media are distinct from but may be used in conjunction with transmission media. Transmission media participate in the transfer of information between storage media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the cables comprising bus 602. Transmission media may also take the form of acoustic or light waves, such as those generated in radio wave and infrared data communications.

[0186] Various forms of media may be involved in carrying one or more sequences of one or more instructions to the processor 604 for execution. For example, the instructions may initially be carried on a disk or solid-state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions via a telephone line using a modem. A modem located locally in the computer system 600 may receive the data on the telephone line and convert the data into an infrared signal using an infrared transmitter. An infrared detector may receive the data carried in the infrared signal and appropriate circuitry may place the data on the bus 602. The bus 602 carries the data to the main memory 606, from which the processor 604 retrieves and executes the instructions. The instructions received by the main memory 606 may optionally be stored on the storage device 610 before or after being executed by the processor 604.

[0187] Computer system 600 also includes a communication interface 618 coupled to bus 602. Communication interface 618 provides bidirectional data communication coupled to network link 620, wherein network link 620 is connected to local network 622. For example, communication interface 618 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem, or a modem that provides a data communication connection to a corresponding type of telephone line. As another example, communication interface 618 can be a LAN card that provides a data communication connection to a compatible local area network (LAN). Wireless links can also be implemented. In any such implementation, communication interface 618 sends and receives electrical signals, electromagnetic signals, or optical signals that carry digital data streams representing various types of information.

[0188] The network link 620 typically provides data communication to other data devices through one or more networks. For example, the network link 620 can provide a connection to a host computer 624 or to data equipment operated by an Internet Service Provider (ISP) 626 through a local network 622. The ISP 626 in turn provides data communication services through the global packet data communication network now commonly referred to as the "Internet" 628. Both the local network 622 and the Internet 628 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link 620 and through the communication interface 618 are example forms of transmission media, where these signals carry the digital data to or from the computer system 600.

[0189] Computer system 600 can send messages and receive data, including program code, through the network(s), network link 620, and communication interface 618. In the Internet example, server 630 can transmit the requested code for an application program through Internet 628, ISP 626, local network 622, and communication interface 618.

[0190] The received code may be executed by processor 604 as the code is received, and / or stored in storage device 610 or other non-volatile storage for later execution.

[0191] In the foregoing specification, embodiments of the present invention have been described with reference to numerous specific details, which may vary from one implementation to another. Accordingly, the specification and drawings should be considered in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what the applicants intend to be the scope of the invention, is the literal and equivalent range of the set of claims issuing from this application, in the specific form in which such claims are issued, including any subsequent corrections.

Claims

1. A non-transitory computer readable medium comprising instructions which, when executed by one or more hardware processors, result in the execution of steps comprising: identifying an operation expressed in a first module, wherein performance of the operation requires access to a module element of a second module; in, a module-non-specific accessibility configuration associated with the module element controlling access to the module element in the absence of any module boundary associated with the module element; wherein the non-module-specific accessibility configuration associated with the module element controls access to the module element if there is a module boundary associated with the module element and if the module boundary associated with the module element allows access to the module element; determining whether the module element is exposed to the first module by the second module based on a module boundary associated with the module element; In response to determining that the module element is not exposed to the first module by the second module based on a module boundary associated with the module element: disabling the operation.

2. The medium of claim 1, wherein: One or more of a compiler and a runtime environment implements control of access to the module element based on (a) any modularity boundaries associated with the module element and (b) the non-module-specific accessibility configuration associated with the module element.

3. The medium according to claim 1, wherein The prohibition steps include one or more of the following: Avoid compiling a set of codes including the first module and the second module; refrain from performing the actions described; Generates a compile-time error related to said operation; as well as Generates a runtime error related to the described operation.

4. The medium according to claim 1, wherein The steps also include: identifying a second operation expressed in the first module, wherein performance of the operation requires access to a second module element of a third module; determining whether the second module element is exposed to the first module by the third module based on a second module boundary associated with the second module element; In response to determining that the second module element is exposed to the first module by the third module based on a second module boundary associated with the second module element: allowing the second operation.

5. The medium of claim 1, wherein: The module element is associated with one or more of: an accessibility override configuration and a public modifier.

6. The medium of claim 1, wherein: Determining whether the module element is exposed by the second module to the first module based on a module boundary associated with the module element includes determining whether a declaration within a module descriptor associated with the second module exposes the module element to the first module.

7. The medium of claim 1, wherein: Access to the module elements is controlled based on at least a module descriptor associated with the second module.

8. A non-transitory computer readable medium comprising instructions that, when executed by one or more hardware processors, result in the execution of steps comprising: identifying an operation expressed in a first module, wherein performance of the operation requires access to a module element of a second module, and wherein access to the module element is controlled by: (a) a modular exposure of the module element, and (b) a non-modular accessibility configuration associated with the module element; determining whether the module element is exposed to the first module by the second module based on the modular exposure of the module element; In response to determining, based on the modular exposure of the module element, that the module element is not exposed to the first module by the second module: disabling the operation.

9. The medium of claim 8, wherein: One or more of a compiler and a runtime environment implements control of access to the module element based on (a) a modular exposure of the module element, and (b) a non-modular accessibility configuration associated with the module element.

10. The medium of claim 8, wherein: The prohibition steps include: Avoid compiling a set of codes including the first module and the second module; Avoid performing the described actions.

11. The medium of claim 8, wherein: The steps also include: identifying a second operation expressed in the first module, wherein performance of the second operation requires access to a second module element of a third module, and wherein access to the second module element is controlled by: (a) a second modular exposure of the second module element, and (b) a second non-modular accessibility configuration associated with the second module element; determining whether the second module element is exposed to the first module by the third module based on the second modular exposure of the second module element; In response to determining that the second module element is exposed to the first module by the third module based on the second modular exposure of the second module element: allowing the second operation.

12. The medium of claim 8, wherein: The operation is a reflective operation.

13. A system for managing access control in a module system, comprising: at least one device comprising a hardware processor; The system is configured to perform the steps of any one of claims 1-12.

14. A method for managing access control in a module system, comprising: The steps as claimed in any one of claims 1 to 12; The method is performed by one or more devices, each of which includes a hardware processor.

15. An apparatus comprising means for performing the method of claim 14.

Images