Dynamic Class Loader for Software Compatibility Verification
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional software development systems face compatibility issues when testing applications across multiple platforms due to differences in underlying classes and revisions, leading to false incompatibility results, even if the application is functionally correct.
Innovation Solution
A dynamic class loader examines class inheritance during testing, using the same version of inherited secondary APIs in the reference implementation as the application under test, and a custom class loader generates and compares signatures to ensure accurate compatibility verification.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a conventional test suite examines the entire interface including all classes in the inheritance chain, then comprehensive compatibility verification is achieved, but false incompatibility results occur due to differences in underlying inherited classes
Solution Approach 1:
The patent segments the inheritance chain into two distinct parts: the target API classes under test and the inherited secondary API classes. The test suite selectively applies different version matching strategies to each segment - strict version matching for target API classes and flexible version matching for inherited classes. This segmentation resolves the contradiction by allowing comprehensive verification of the target API while preventing false failures from inherited class differences.
Solution Approach 2:
The patent applies different quality standards to different parts of the inheritance chain. For the target API classes (local to the test), strict version matching is enforced to ensure compatibility. For the inherited secondary API classes (peripheral to the test), flexible version matching is applied to tolerate legitimate variations. This local differentiation resolves the contradiction between comprehensive verification and avoiding false positives.
2Measurement precision
If the same version of inherited classes is enforced in both application under test and reference implementation, then false incompatibility results are avoided, but flexibility to use different valid API versions is lost
Solution Approach 1:
The patent introduces dynamic version matching behavior that adapts based on the role of the class in the inheritance chain. For target API classes, static strict version matching is applied. For inherited secondary API classes, dynamic flexible version matching is applied that allows different valid versions. This dynamic approach resolves the contradiction by being strict where needed and flexible where appropriate.
Solution Approach 2:
The patent changes the version matching parameter (strictness) based on the class type. For inherited secondary API classes, the version matching parameter is relaxed to allow variations, while for target API classes it remains strict. This parameter change resolves the contradiction between measurement precision and adaptability by adjusting the strictness level according to the specific context.
3Reliability
If comprehensive inheritance chain traversal is performed to verify all API calls, then complete compliance checking is achieved, but test complexity and execution time increase
Solution Approach 1:
The patent extracts the inherited secondary API classes from the comprehensive inheritance chain and handles them separately. Instead of applying the same complex verification logic to all classes, the inherited classes are extracted and processed with simplified flexible version matching. This reduces test suite complexity while maintaining complete compliance checking for the target API classes.
Solution Approach 2:
The patent applies partial verification action - full strict verification for target API classes and reduced flexible verification for inherited classes. This partial approach maintains reliability for the critical target API while reducing overall test complexity by not applying the same level of strict verification to all classes in the inheritance chain.
Data Source
AI summary
A software compliance test is typically directed only at particular classes in the inheritance hierarchy. Inherited APIs (classes), which are not the focus of the test, may cause the application under test (AUT) to fail the compliance test since some of the underlying classes differ from a reference implementation. Accordingly, a verification tool employs the same version and implementation of inherited APIs in the reference implementation of these inherited APIs as the application under test. A dynamic class loader examines class inheritance references made by the application under test to determine if the class is included in the API to be tested, or if the class is outside the scope of the API to be tested. If the class corresponds to the API to be tested, then the dynamic loader uses the reference implementation of the API for comparison. Otherwise, the reference implementation employs the same inherited class references as the application under test. Therefore, for the underlying inherited or secondary class references, the dynamic loader employs the same classes in the reference implementation as the AUT inherits.