Runtime Module Loading for Application Customization
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for customizing computer-executable applications, such as testing harnesses, require specifying functionality at compile or link time using static or dynamic link libraries, leading to overhead and potential inclusion of proprietary information when releasing customized versions.
Innovation Solution
The technology allows for runtime customization by splitting applications into a core and modular components, enabling the dynamic loading of modules at runtime to add or remove functionality, including language-level features and constructs, without prior specification, thus isolating proprietary features and reducing overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If static or dynamic link libraries are used for customization, then functionality can be extended, but the functionality must be known at compile or link time and creates overhead when releasing customized versions
Solution Approach 1:
The patent implements runtime loading of language modules, allowing the application to dynamically load and unload language implementations without recompilation. The core application maintains a registry of available languages and can load specific language modules at runtime based on user needs, transforming the static linking approach into a dynamic one that adapts to runtime requirements.
Solution Approach 2:
The patent segments the application into a core component and separate language modules. Each language is implemented as an independent module that can be loaded separately. This segmentation allows the core application to remain lightweight while language-specific functionality is distributed across separate loadable modules, reducing the overhead of including all languages by default.
2Adaptability or versatility
If proprietary functionality is included in the testing harness, then developer-specific features are available, but releasing sanitized versions for third parties creates overhead and risk of accidental inclusion
Solution Approach 1:
The patent segments proprietary functionality into separate language modules that can be independently controlled. The core application contains only neutral, third-party-safe functionality, while proprietary features reside in optional language modules. This allows the distributor to release a sanitized core version to third parties while maintaining the ability to load proprietary language modules only when appropriate, eliminating the risk of accidental proprietary information leakage.
Solution Approach 2:
The patent introduces a module loading mechanism as an intermediary between the core application and language-specific functionality. This intermediary layer controls which modules are loaded and executed, providing a security boundary that prevents unauthorized access to proprietary functionality while still allowing it to be utilized when properly authorized.
3Adaptability or versatility
If all language functionalities are included in the application, then complete language support is available, but the application size and loading time increase
Solution Approach 1:
The patent implements dynamic module loading where language functionalities are loaded only when needed rather than being statically included. The core application starts with minimal dependencies and loads language modules on-demand based on user selection or system requirements, significantly reducing initial loading time while maintaining full language support coverage when required.
Solution Approach 2:
The patent loads only the necessary language modules required for the current task rather than loading all available language functionalities. This partial loading approach reduces memory consumption and loading time by loading exactly what is needed and leaving other language modules unloaded until they are required.
Data Source
AI summary
Disclosed is a method of automatically customizing a computer executable application, such as a test automation harness, based on currently installed modules. The functionality of the application can be split in multiple modules. At runtime, the application can automatically detect the presence or absence of a module. If a module is available, it can automatically be integrated with the application such that the functionality, such as language-level features and constructs, provided by the module is active and/or exposed. If the module is absent, the application can continue executing without the functionality provided by the module.