Abstract: Cross-compiling, by a multi-version compiler, may produce complied code targeted to a specified release version of a programming platform supported by the compiler. The specified version may be different from a default version of the programming platform targeted by the compiler. Thus, the multi-version compiler may cross-compile source code to generate compiled code for different versions of the programming platform. A developer may specify the target version using a single compiler option and the compiler may, in response, cross-compile for the target version without requiring any additional options to be configured by the user. The multi-version compiler may include library data regarding multiple versions of the programming platform, preventing a developer from having to locate and provide the necessary library data for each targeted version.

Abstract: Operations include determining a compile-time representation of a particular type. A request for the compile-time representation of the particular type comprises a source representation of the particular type. Based on and subsequent to receiving the request, a source representation of a source code file comprising the source representation of the particular type is generated. The source representation of the source code file is converted to a compile-time representation of the source code file. The compile-time representation of the particular type is derived from the source time representation of the source code file. The source code file may also be compiled to generate a set of compiled code. The set of compiled code may be loaded into a virtual machine for generating a runtime representation of the set of compiled code. A runtime representation of the particular type is derived from the runtime representation of the set of compiled 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: Annotation processors defined by a module of a module system are used for processing annotations. Annotation processors defined by a module of a module system may be used with annotation processors defined by non-module code. A predefined deterministic process is used to select annotation processors for processing annotations. The predefined deterministic process imposes an order for searching and/or using annotation processors.

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: Operations include determining a compile-time representation of a particular type. A request for the compile-time representation of the particular type comprises a source representation of the particular type. Based on and subsequent to receiving the request, a source representation of a source code file comprising the source representation of the particular type is generated. The source representation of the source code file is converted to a compile-time representation of the source code file. The compile-time representation of the particular type is derived from the source time representation of the source code file. The source code file may also be compiled to generate a set of compiled code. The set of compiled code may be loaded into a virtual machine for generating a runtime representation of the set of compiled code. A runtime representation of the particular type is derived from the runtime representation of the set of compiled code.

Abstract: Annotation processors defined by a module of a module system are used for processing annotations. Annotation processors defined by a module of a module system may be used with annotation processors defined by non-module code. A predefined deterministic process is used to select annotation processors for processing annotations. The predefined deterministic process imposes an order for searching and/or using annotation processors.

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: Cross-compiling, by a multi-version compiler, may produce complied code targeted to a specified release version of a programming platform supported by the compiler. The specified version may be different from a default version of the programming platform targeted by the compiler. Thus, the multi-version compiler may cross-compile source code to generate compiled code for different versions of the programming platform. A developer may specify the target version using a single compiler option and the compiler may, in response, cross-compile for the target version without requiring any additional options to be configured by the user. The multi-version compiler may include library data regarding multiple versions of the programming platform, preventing a developer from having to locate and provide the necessary library data for each targeted version.

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 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: The disclosed embodiments provide a system that facilitates the development and maintenance of a software program. This system includes a software development kit (SDK) and a runtime system for the software program. During operation, the system associates classes of the software program with module declarations for a set of modules and uses the module declarations to manage dependencies in the software program throughout the life cycle of the software program.

Abstract: Some embodiments provide a system that facilitates the development, maintenance, and execution of a software program. During operation, the system obtains a module declaration for a module to be used in the software program. Next, the system resolves one or more dependencies of the module using the module declaration and a list of available modules for the software program. Finally, the system uses the resolved dependencies to manage the software program throughout the life cycle of the software program.

Abstract: The disclosed embodiments provide a system that facilitates the compilation of a software program. During operation, the system uses a directory hierarchy for the software program to infer a compilation unit to be used in the software program as a member of a module. Next, the system obtains a module declaration for the module using the directory hierarchy. Finally, the system enables compilation of the software program by dynamically identifying and locating one or more dependencies of the module using the module declaration and the directory hierarchy.

Abstract: Some embodiments provide a system that facilitates the development, maintenance, and execution of a software program. During operation, the system obtains a module declaration for a module to be used in the software program. Next, the system resolves one or more dependencies of the module using the module declaration and a list of available modules for the software program. Finally, the system uses the resolved dependencies to manage the software program throughout the life cycle of the software program.

Abstract: The disclosed embodiments provide a system that facilitates the compilation of a software program. During operation, the system uses a directory hierarchy for the software program to infer a compilation unit to be used in the software program as a member of a module. Next, the system obtains a module declaration for the module using the directory hierarchy. Finally, the system enables compilation of the software program by dynamically identifying and locating one or more dependencies of the module using the module declaration and the directory hierarchy.

Abstract: The disclosed embodiments provide a system that facilitates the development and maintenance of a software program. This system includes a software development kit (SDK) and a runtime system for the software program. During operation, the system associates classes of the software program with module declarations for a set of modules and uses the module declarations to manage dependencies in the software program throughout the life cycle of the software program.

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.