Bridge Module for Integrating Non-Module Code in Standard Systems

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current software development environments face challenges in integrating module systems and non-module systems, particularly due to the inability of standard modules to explicitly depend on non-module code, leading to difficulties in accessing and utilizing non-module code within module environments.

Innovation Solution

The generation of bridge modules that can explicitly depend on non-module code, allowing standard modules to access non-module code by modularizing the non-module code and creating a module descriptor that exposes packages and dependency paths, enabling indirect dependency on non-module code without modifying the non-module code itself.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If standard modules are restricted from explicitly depending on non-module code, then the module system maintains its integrity and structure, but the ability to access and utilize non-module code is lost

Engineering Contradiction:

Improvemodule system integrityVSAvoidaccess to non-module code

Core Design Contradiction:

ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent introduces bridge modules as intermediary components that standard modules can explicitly depend on. These bridge modules act as mediators that have access to both the module system and non-module code, allowing standard modules to indirectly access non-module code through the bridge module interface without violating the restriction on explicit dependencies.

Inventive Principle:

Principle #24Intermediary (Mediator)

2Adaptability or versatility

If non-module code is directly accessed by standard modules, then access to non-module code is enabled, but the module system structure is compromised

Engineering Contradiction:

Improveaccess to non-module codeVSAvoidmodule system integrity

Core Design Contradiction:

Adaptability or versatilityVSReliability

Solution Approach 1:

The patent segments the access path to non-module code by introducing bridge modules as separate, distinct components. Instead of allowing direct access from standard modules to non-module code, the access path is divided into two segments: standard modules depend on bridge modules, and bridge modules access non-module code. This segmentation preserves the module system structure while enabling the desired access.

Inventive Principle:

Principle #1Segmentation

3Adaptability or versatility

If bridge modules are introduced to enable access to non-module code, then adaptability is improved, but system complexity increases

Engineering Contradiction:

Improveintegration of module and non-module environmentsVSAvoidsystem structure

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent designs bridge modules to perform multiple functions: they serve as explicit dependency targets for standard modules, provide access interfaces to non-module code, and maintain the module system structure. By making bridge modules universal components that handle multiple responsibilities, the patent reduces the need for separate specialized components, thereby managing complexity while achieving integration.

Inventive Principle:

Principle #6Universality (Multi-functionality)

Data Source

PatentUS10078497B2Bridging a module system and a non-module system

Publication Date: 2018.09.18 ORACLE INT CORP

AI summary

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.