Abstract: 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.

Abstract: The disclosed embodiments provide a system that facilitates the development and compilation of a software program. During operation, the system obtains a set of compilation units to be used in the software program and a version order associated with a programming language of the compilation units. Next, for each compilation unit from the set of compilation units, the system uses the version order to select a version of the programming language that is compatible with the compilation unit. The system then uses the version to compile the compilation unit.

Abstract: A runtime environment identifies a request for a proxy object whose class implements a plurality of interfaces. Responsive to the request, the runtime object generates a class for the proxy object. Generating the class comprises determining that two or more interfaces, of the plurality of interfaces, define a respective method body with a same method signature. Responsive to determining that the two or more interfaces define a respective method body with a same method signature, the runtime environment may (a) omit a method body, in the class, for a particular method corresponding to the method signature, (b) include a method body that triggers a runtime error, or (c) include a method body that includes operations to select a default method declared in one of the two or more interfaces.

Abstract: Declarations of annotation types, which specify annotations, are themselves annotated by meta-annotations. Meta-annotations define constraints based on modular encapsulation.

Abstract: Declarations of annotation types, which specify annotations, are themselves annotated by meta-annotations. Meta-annotations define constraints based on modular dependencies.

Abstract: Metadata-driven dynamic specialization may include applying a type erasure operation to a set of instruction in a generic class or to a method declaration that includes typed variables using an encoded form of an instruction or an argument to an instruction. The instruction may operate on values of the reference types and the argument may be a signature that indicates the reference types. The encoded form may be annotated to include metadata indicating which type variables have been erased and which reference types are the erasures of type variables. Additionally, the metadata may indicate that the instruction operates on values of, and that the argument indicates reference types that are erasures of, the type variables of the class (or method) declaration. Moreover, the encoded form of the instruction or argument may be used directly without specialization or transformation.

Abstract: 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.

Abstract: The disclosed embodiments provide a system that facilitates the development and execution of a software program. During operation, the system provides a mechanism for restricting a variable to a runtime context in the software program. Next, the system identifies the runtime context during execution of the software program. Finally, the system uses the mechanism to prevent incorrect execution of the software program by ensuring that a closure capturing the variable executes within the identified runtime context.

Abstract: 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.

Abstract: The loading or operation of a specialized class may trigger the specialization of other classes. A compiler may be configured to recognize dependency relationships between generic classes and to describe the classes in terms of the type variables of the triggering types (e.g., the types and/or type parameterizations) that trigger the specialization of classes based on the specialization of a first class. A compiler may include information, such as structural references, indicating dependency relationships between classes when generating class files. Thus, the class file may include information indicating that a class extends a class resulting from applying a specialization code generator to an argument. Loading a first class may trigger the loading of a second class described by a structural description such that a specializer (and/or class loader) may apply the structural description to generate and load the second class for the particular parameterization.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: 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.

Abstract: The disclosed embodiments provide a system that encapsulates and manages diagnostic information. During operation, the system detects an event that generates diagnostic information, and stores this diagnostic information in a format that preserves semantic information associated with the event. The system also determines an output context (e.g., the intended target environment) for the diagnostic information, and then uses the preserved semantic information to output the diagnostic information in a context-sensitive format suited for the output context. Note that outputting customized diagnostic information that is adapted to a specific target environment facilitates improving the quality of diagnostic information presented to a user.

Abstract: 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.

Abstract: 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.

Abstract: Generic classes may have more than one specializable type parameter and it may be desirable to specialize one or more of the type variables while not specializing others. The result of partial specialization may be one or more additional generic classes that are further specializable on the remaining type parameters. A runtime specializer may partially specialize a generic class to produce a partially specialized class and may subsequently further specialize the partially specialized class to generate a fully specialized class. Thus, rather than performing the specialization of a generic class all at once, such as by specializing Map<K, V> into Map<int, int> or Map<long, int>, one type parameter may be partially specialized, such as resulting in Map<K, int>, and then at some later time the remaining type parameter(s) may be specialized, such as to generate Map<int, int> or Map<long, int>.

Abstract: The disclosed embodiments provide a system that facilitates the development and compilation of a software program. During operation, the system obtains a set of compilation units to be used in the software program and a version order associated with a programming language of the compilation units. Next, for each compilation unit from the set of compilation units, the system uses the version order to select a version of the programming language that is compatible with the compilation unit. The system then uses the version to compile the compilation unit.

Abstract: The disclosed embodiments provide a system that facilitates the development and compilation of a software program. During operation, the system obtains a set of compilation units to be used in the software program and a version order associated with a programming language of the compilation units. Next, for each compilation unit from the set of compilation units, the system uses the version order to select a version of the programming language that is compatible with the compilation unit. The system then uses the version to compile the compilation unit.