Code migration method and system based on holographic environment perception and dependent coevolution

Abstract

The invention provides a code migration method and system based on holographic environment perception and dependent coevolution, and relates to the technical field of code migration. Comprising the following steps: analyzing a Java source code and a configuration condition of the Java source code; determining a target JDK version, combining a JDK compatibility rule and a knowledge base, identifying a part needing to be modified in the Java source code based on a large language model, and generating a modified code; modifying the configuration condition of the Java source code to obtain a modified configuration condition; the modified codes and configuration conditions are applied and verified; generating a migration report based on the verification result; and obtaining feedback of the developer to the migration report, and circulating until the modified code and the configuration condition are confirmed by the developer to obtain the target Java item after code migration. According to the method, the JDK upgrading efficiency is improved, the upgrading success rate and quality are improved, and upgrading failures caused by configuration omission or dependency problems are reduced.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of artificial code migration, and particularly relates to a code migration method and system based on holographic environment perception and dependent co-evolution. BACKGROUND

[0002] With the rapid iteration of Java Development Kit (JDK), new versions bring performance improvement, security enhancement and language new features. However, for a large number of existing Java projects based on old JDK (such as JDK 8), upgrading to new JDK (such as JDK 21) is a complex and time-consuming task. The main challenges include: (1) Source code compatibility, there are API obsoletion, behavior change, modularization introduction and other problems between old and new JDK, which need to modify the source code a lot.

[0003] (2) External dependency compatibility, third-party libraries that the project depends on may not be compatible with the target JDK version, which needs to be researched, replaced or upgraded.

[0004] (3) Build environment adaptation, the plugins and configurations of Maven / Gradle and other build tools may need to be adjusted to adapt to the new JDK.

[0005] (4) Deployment environment adaptation, CI / CD pipeline, container image, application server configuration and other aspects may need to be updated.

[0006] (5) Test coverage and risk, after upgrading, sufficient regression testing is needed to ensure function correctness and performance, but manual testing is costly and there are still unknown risks.

[0007] (6) Knowledge barrier, developers need to master the differences between old and new JDK, the compatibility information of various libraries and the migration best practices.

[0008] Therefore, a system that takes into account the "environment" factor, accurately identifies the location of the java code that needs to be modified and generates code is needed to automate JDK code migration. SUMMARY

[0009] To overcome the shortcomings of the prior art, the present application provides a code migration method and system based on holographic environment perception and dependent co-evolution, which is suitable for the rapid iteration of Java Development Kit (JDK) new and old versions. When migrating code to the new version of JDK, the adaptability of the code environment is considered, the powerful understanding and generation capability of LLM is combined with the deep insight into the complete environment of the project, the JDK upgrade efficiency is greatly improved, the upgrade success rate and quality are improved, and the upgrade failure caused by missing configuration or dependency problem is reduced through comprehensive environment analysis.

[0010] To achieve the above object, one or more embodiments of the present application provide the following technical solutions: The first aspect of the present application provides a code migration method based on holographic environment perception and dependent co-evolution.

[0011] The code migration method based on holographic environment perception and dependent co-evolution comprises the following steps: Step one: obtain the target Java project, parse the Java source code in the target Java project and the configuration conditions of the Java source code; Step two: determine the target JDK version, combine the JDK compatibility rules and the knowledge base, identify the parts that need to be modified in the Java source code based on the large language model, generate the modified code or modification suggestions; at the same time, modify the configuration conditions of the Java source code to obtain the modified configuration conditions; Step three: apply and verify the modified code and configuration conditions; Step four: generate a migration report based on the verification result; Step five: obtain the feedback of the developer on the migration report, update the knowledge base and the large language model; Step six: based on the updated knowledge base and the large language model, cycle steps two to five until the modified code and configuration conditions are confirmed by the developer, and obtain the target Java project after code migration.

[0012] The second aspect of the present application provides a code migration system based on holographic environment perception and dependent co-evolution.

[0013] The code migration system based on holographic environment perception and dependent co-evolution comprises: The parsing module is configured to: obtain the target Java project, parse the Java source code in the target Java project and the configuration conditions of the Java source code; The large language model modification module is configured to: determine the target JDK version, combine the JDK compatibility rules and the knowledge base, identify the parts that need to be modified in the Java source code based on the large language model, generate the modified code or modification suggestions; at the same time, modify the configuration conditions of the Java source code to obtain the modified configuration conditions; The verification module is configured to: apply and verify the modified code and configuration conditions; The report generation module is configured to: generate a migration report based on the verification result; The feedback update module is configured to: obtain the feedback of the developer on the migration report, update the knowledge base and the large language model; The circulating module is configured to: based on the updated knowledge base and the large language model, circulate the process of the large language model modification module to the feedback updating module until the modified code and the configuration condition are confirmed by the developer, and obtain the target Java project after the code migration. The third aspect of the present application provides a computer readable storage medium having a program stored thereon, which, when executed by a processor, implements the steps in the code migration method based on holographic environment perception and dependent co-evolution of the first aspect of the present application.

[0014] The fourth aspect of the present application provides an electronic device comprising a memory, a processor, and a program stored on the memory and executable on the processor, wherein the processor implements the steps in the code migration method based on holographic environment perception and dependent co-evolution of the first aspect of the present application when executing the program.

[0015] The above one or more technical solutions have the following beneficial effects: The present application provides a code migration method and system based on holographic environment perception and dependent co-evolution, which considers the adaptability of the code environment when migrating the code to the new version of JDK, combines the powerful understanding and generation ability of LLM with the deep insight into the complete environment of the project, greatly improves the JDK upgrade efficiency, and improves the upgrade success rate and quality.

[0016] The present application comprehensively considers the dependent configuration, build script, CI / CD configuration and deployment configuration in the configuration condition of the Java source code, reduces the upgrade failure caused by missing configuration or dependency problem through comprehensive environment analysis.

[0017] LLM makes decisions based on a large amount of knowledge, avoids human negligence and common errors, reduces labor cost and skill threshold, reduces the dependence on tedious migration work of senior Java experts, and enables more developers to participate in or manage the upgrade process.

[0018] The present application enhances the controllability and traceability of code migration, and the detailed report and modification basis make the entire upgrade process transparent. Through the developer feedback loop, the intelligent level and knowledge base update of the system are improved.

[0019] The present application can help enterprises to adopt new version of JDK more quickly, enjoy the performance, security and language feature advantages brought by it, and maintain the technical competitiveness.

[0020] The advantages of the additional aspects of the present application will be partially given in the following description, partially will become obvious from the following description, or will be learned through the practice of the present application. BRIEF DESCRIPTION OF DRAWINGS

[0021] The accompanying drawings, which form a part of this specification, are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification. The embodiments of the application, and their

[0022] Figure 1 A method flowchart for example one.

[0023] Figure 2 An AST-level only analysis and conversion architecture diagram for example one source code.

[0024] Figure 3 An intelligent analysis and adaptation architecture diagram for example one build script.

[0025] Figure 4 An intelligent adaptation architecture diagram for example one CICD and containerization configuration. DETAILED DESCRIPTION

[0026] It should be noted that the following detailed description is exemplary in nature, intended to provide further description of the application. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs.

[0027] The embodiments in the present application and the features in the embodiments can be combined with each other without conflict.

[0028] Example one The present embodiment discloses a code migration method based on holographic environment perception and dependent co-evolution.

[0029] As shown in Figure 1 The code migration method based on holographic environment perception and dependent co-evolution includes the following steps: Step one: obtain the target Java project, parse the Java source code in the target Java project and the configuration conditions of the Java source code; Step two: determine the target JDK version, combine the JDK compatibility rules and knowledge base, identify the parts that need to be modified in the Java source code based on the large language model, generate the modified code or modification suggestions; at the same time, modify the configuration conditions of the Java source code to obtain the modified configuration conditions; Step three: apply and verify the modified code and configuration conditions; Step four: generate a migration report based on the verification result; Step five: obtain the developer's feedback on the migration report, update the knowledge base and the large language model; Step six: Based on the updated knowledge base and large language model, steps two to five are cycled until the modified code and configuration conditions are confirmed by the developer, and the target Java project after code migration is obtained.

[0030] It can be understood that the target Java project described in the embodiment specifically refers to a project to be upgraded to JDK.

[0031] The JDK compatibility rules are a comprehensive set of knowledge covering all technical points that may cause compilation errors, runtime exceptions or behavior changes when upgrading from one Java version to a higher version. They can be subdivided into the following levels: 1. Language syntax level: changes in the syntax of the java language itself; 2. Core API level: involves the addition, deletion, and modification of classes, methods, and fields in the JDK standard library; 3. JVM runtime level: changes in the behavior of the Java Virtual Machine, such as garbage collector default value, class loading mechanism, JNI changes, etc. 4. Security level: changes in security manager, default TLS protocol version, encryption algorithm strength, etc. 5. Tool level: changes in parameters and behavior of command-line tools such as javac and jar.

[0032] Based on the large language model, the parts of the Java source code that need to be modified are identified, and the modified code or modification suggestions are generated. The specific process includes: AST-level intelligent analysis and conversion of source code. The detailed data processing flowchart of this process is shown in Figure 2 .

[0033] Detailed data processing process at each stage: Stage one: Parsing and semantic enrichment (Parsing & Semantic Enrichment) Objective: Convert pure text Java code into structured data that contains complete type information and can perform accurate semantic analysis.

[0034] 1. Input: Single.java source file.

[0035] 2. Processing process: AST Parsing: The system invokes a mature Java AST parser (e.g., the widely-used JavaParser library in the community). This parser converts the source code files into a tree-like data structure - Abstract Syntax Tree (AST). Each node of the tree represents a syntax element, such as MethodDeclaration (method declaration), MethodCallExpr (method call), ImportDeclaration (import statement), etc.

[0036] Symbol Resolution / Type Enrichment: Having just the AST is not enough. We need to know what type a variable myVar is, and which class a method call myMethod() belongs to. Therefore, the system initiates a Symbol Solver. It traverses the entire AST, combining the classpath information of the project, and "injects" each node with its corresponding type information. For example, it can determine that the type referenced by the node new Date() is java.util.Date, not any other class named Date.

[0037] 3. Output: An Enriched AST. This is the foundation for all subsequent analyses, providing a complete syntactic and semantic view of the code.

[0038] Phase Two: Intelligent Analysis & Change Proposal Objective: The LLM plays the role of a "code review expert," identifying code points that need modification under the guidance of enriched context and rules, and generating precise, atomic modification schemes.

[0039] 1. Input: Enriched AST (from Phase One).

[0040] Relevant rules retrieved from the knowledge base, such as: "Rule ID: R-032, Description: The deprecated constructor Date(int, int, int) of java.util.Date should be replaced with java.time.LocalDate.of(int, int, int).atStartOfDay()".

[0041] Target JDK version.

[0042] 2. Processing: The system's AST traverser visits each node in the AST.

[0043] When a critical node (like a MethodCallExpr or ConstructorCallExpr) is accessed, the system checks its resolved type and method signature.

[0044] If the signature matches a certain incompatible rule in the knowledge base, the system does not immediately let the LLM analyze the entire file. Instead, it constructs a highly focused Prompt: Context: "A Java project is migrating from JDK 8 to 17. In a method call, we identified an incompatible usage." Question code point: Code snippet: Date myDate = new Date(123, 4, 5); (readable code generated from AST node backwards); Type information: "The invoked constructor is java.util.Date(int year, int month, int date)." Location information: "This code is located at line 42 in file com / mycorp / legacy / DateUtils.java." Guiding rule: "According to knowledge base rule R-032, this constructor is deprecated, and java.time.LocalDate is recommended." Task instruction: "Please generate a JSON-formatted Atomic ChangeProposal for this issue. The JSON must contain: target_node_id (a unique identifier to locate the AST node), new_code_snippet (new code to replace the current node), required_imports (an array of new import statements that the new code might need), reason (explain the modification reason, referencing rule R-032)." 3. Output: One or more structured Atomic ChangeProposals. The output of the LLM is structured data, not free code.

[0045] { "target_node_id": "ast-node-uuid-12345", "new_code_snippet":"Date.from(LocalDate.of(1900 + 123, 4, 5).atStartOfDay(ZoneId.systemDefault()).toInstant())", "required_imports": ["java.time.LocalDate", "java.time.ZoneId"], "reason": "Following JDK migration rule R-032, the deprecated Date constructor was replaced with a java.time API, and the year offset issue was resolved." } Phase Three: AST Deterministic Transformation Goal: Apply the "proposals" from LLM safely and without errors to the AST.

[0046] 1. Input: Type-rich AST (from Phase One).

[0047] List of atomic change proposals generated by LLM (from Phase Two).

[0048] 2. Processing: This is a purely deterministic, code-manipulation phase.

[0049] The system iterates over the list of change proposals. For each proposal, it uses the target_node_id to precisely find the node to be modified in the AST. It converts the new_code_snippet string in the proposal into a new AST subtree using the AST parser. Then, it replaces the old target node in the main AST with this new subtree. Finally, it checks the required_imports array and adds import statements that are not already present in the AST's root ImportDeclaration list.

[0050] 3. Output: A modified AST whose content has been updated, and whose structure is still intact.

[0051] Phase Four: Code Regeneration and Formatting Goal: Convert the modified AST back into a human-readable, well-formatted Java code file.

[0052] 1. Input: Modified AST (from Phase Three).

[0053] 2. Processing: System call AST library built-in code generator (also known as "Pretty Printer"). This tool will perform a depth-first traversal of the entire modified AST and print it as text-formatted Java code. A good Pretty Printer will try to preserve the original code's indentation, blank lines, and comments to ensure that the generated code is consistent with the original style and facilitates code comparison (Diff) by developers.

[0054] 3. Output: Final modified.java file.

[0055] Through this meticulous, phased pipeline, the system ensures that modifications to the source code both leverage the intelligence of the LLM and circumvent its uncertainties, enabling safe, reliable, and interpretable automation in complex software engineering tasks.

[0056] The configuration conditions of the Java source code include dependency configurations, build scripts, CI / CD configurations, and deployment configurations.

[0057] Further, the Java source code in the target Java project and the configuration conditions of the Java source code are parsed, specifically including: Parsing the Java source code to generate an AST; Parsing the pom.xml or build.gradle file in the dependency configuration to extract project dependencies and plugin information; Parsing custom logic in the build script; Parsing CI / CD configuration files to understand the build, test, and deployment processes; Parsing containerization configuration files to understand the code runtime environment.

[0058] Further, the configuration conditions of the Java source code are modified to obtain modified configuration conditions, specifically including: The large language model analyzes the existing dependency configuration of the Java source code and compares it with the compatibility information about third-party libraries and the target JDK version in the knowledge base to suggest the need to upgrade the dependency version or replace the library and automatically update the dependency configuration; The large language model analyzes the build script and proposes modifications based on the requirements of the target JDK version, including updating plugin versions and adjusting compilation parameters; this process specifically includes intelligent analysis and adaptation of the build script. The detailed data processing flowchart of this process is shown in Figure 3 .

[0059] Phase One: Holographic Analysis and Structured Modeling. The goal is to convert semi-structured build script files into deterministic data structures that machines can accurately understand and manipulate.

[0060] 1. Input: Raw build script file (pom.xml or build.gradle).

[0061] 2. Process: For pom.xml (Maven): The system does not treat it as normal text. Instead, it invokes a standard XML parser (such as JAXB or DOM4J) to parse it into a Java object tree (POJO) or a precise JSON object according to the Maven POM model definition. This object is called the Build Script Model. The model clearly contains <project> , <dependencies> , <build> , <plugins> , <plugin>and elements.

[0062] For build.gradle (Gradle): It is more complicated because it is essentially executable Groovy or Kotlin code. The system will use the Gradle Tooling API. This API allows to safely query the configuration model of a project, including all its tasks, dependencies and plugin configurations, without actually executing the build. Again, the query result is transformed into a standard build script model.

[0063] 3. Output: A structured, in-memory build script model. For example, a plugin's representation might look like this: { "groupId": "org.apache.maven.plugins", "artifactId": "maven-compiler-plugin", "version": "3.1", "configuration": { "source": "1.8", "target": "1.8" } } Value of this phase: Avoids the ambiguity of having the LLM directly deal with syntax, simplifying the problem from "understand a DSL" to "analyze a structured object", greatly improving the reliability of the subsequent analysis.

[0064] Phase two: Context Enhancement & Intelligent Analysis Goal: This is the phase where the LLM plays its core role, combining all information to reason and generate concrete, executable modification instructions.

[0065] 1. Input: The build script model (from phase one).

[0066] The target JDK version (e.g.: 17).

[0067] Relevant rules retrieved from the knowledge base, for example: Maven-Compiler-Plugin version compatibility matrix with JDK. Compilation parameter rule: "For JDK 9+, it is recommended to use the --release flag instead of -source and -target flags to ensure the code is compiled against the correct platform API." Compatibility rules for Maven-Surefire-Plugin (test plugin).

[0068] 2. Processing Process (Prompt Engineering): The system constructs a highly structured Prompt to submit to the LLM. This Prompt roughly contains: Role Setting: "You are a senior Java build engineer experienced in JDK version migration." Context Information: "The current project is migrating from Java 8 to Java 17. Below is the core model of its build script (provided in JSON format): [insert phase one output JSON]." Task Instruction: "Please analyze this build model. Based on the following rules: [insert relevant rules retrieved from the knowledge base], identify all plugin versions and compilation parameter configurations that are incompatible with the target JDK 17. For each issue found, return a modification instruction in the form of a JSON array. Each instruction should include element_path (the path of the element to modify), action (such as UPDATE_VERSION, REPLACE_CONFIGURATION), new_value (the new value), and reason (the reason for the modification, citing knowledge base rules)." Output: A structured list of modification instructions (JSON Array of Fixes). The LLM's output is strictly constrained, not free text. { "element_path": "build.plugins.maven-compiler-plugin.version", "action": "UPDATE_VERSION", "new_value": "3.10.1", "reason": "Version 3.1 is not fully compatible with Java 17. According to the knowledge base, 3.10.1 is the recommended stable version." }, { "element_path": "build.plugins.maven-compiler-plugin.configuration", "action": "REPLACE_CONFIGURATION", "new_value": { "release": "17" }, "reason": "Using the --release flag ensures that the code is compatible with the target JDK not only syntactically but also at the API level, which is a best practice for JDK 9+." } ] The value of this stage lies in guiding the powerful reasoning capabilities of LLM onto a controllable, predictable, and interpretable track through sophisticated hint engineering and constraints on the output format.

[0069] Phase Three: Application of Structured Modifications Objective: To safely and accurately apply the "instructions" generated by LLM to the in-memory model.

[0070] 1. Input: The original build script model (from Phase 1).

[0071] The list of modification instructions generated by LLM (from Phase 2).

[0072] 2. Processing Procedure: This is a deterministic, non-AI process. The system will write a simple piece of code to iterate through the list of modification instructions. For each instruction, it will: The node to be modified is located in the build script model based on the element_path.

[0073] Perform the corresponding modification operation based on the action and new_value (e.g., update a version number, replace the entire configuration block).

[0074] 3. Output: A build script model with updated content.

[0075] The value of this stage lies in separating the AI's "decision-making" from the actual "execution," ensuring 100% accuracy in the modification process and avoiding any errors that the AI ​​might introduce at the execution level.

[0076] Phase Four: Formatting & Write-back Objective: Convert the updated memory model back into a human-readable and well-formatted build script file.

[0077] 1. Input: Updated build script model (from Phase Three).

[0078] 2. Processing: The system calls an XML / code generator.

[0079] The generator converts the memory model back into a text format. The key is that it tries to maintain the original file's indentation and comments to generate a human-friendly file with minimal differences (Diff).

[0080] 3. Output: Final modified pom.xml or build.gradle file, ready for the next step of automated compilation and testing.

[0081] Through this rigorous pipeline, the system ensures that every step of the complex task of modifying build scripts using LLM is clear, controllable, and of high quality, which is the core of its innovative and engineering value.

[0082] The large language model analyzes CI / CD scripts and containerization deployment files, modifies base images, updates environment variables, and adjusts JVM parameters. The process specifically includes intelligent adaptation of CI / CD and containerization configurations. The detailed data processing flowchart of the process is shown in Figure 4 .

[0083] As shown in Figure 4 , the detailed data processing process of each stage is as follows: Phase One: Holographic Analysis and Structured Modeling Objective: Convert different formats of CI / CD and containerization configuration files into a unified, machine-readable memory object model.

[0084] 1. Input: CI / CD scripts:.gitlab-ci.yml, Jenkinsfile, GitHub Actions workflow, etc.

[0085] Containerization files: Dockerfile, Kubernetes deployment.yaml / pod.yaml, etc.

[0086] 2. Processing: For YAML files (GitLab CI, K8s, GitHub Actions): Use a robust YAML parser to fully parse their content into an object tree composed of Maps and Lists. The parser preserves all structural information.

[0087] For Dockerfile: Use a specialized Dockerfile parser. This parser can parse the file line by line into a list of instructions, each instruction being an object containing the instruction name (FROM, ENV, RUN, CMD, etc.) and its corresponding value.

[0088] For Jenkinsfile (Groovy DSL): Instead of trying to fully understand Groovy's logic, the system uses a pattern-based structured extraction approach. Through regular expressions and light syntax analysis, it extracts key blocks such as image names in agent { docker { image '...'}}, environment variables in environment {...}, and JVM startup commands contained in sh '...' or bat '...' steps.

[0089] 3. Output: A structured configuration object model (Deployment&CI Model). This model unifies configuration information from different sources.

[0090] Dockerfile model example: [ { "instruction": "FROM", "value": "openjdk:8-jdk-alpine"}, { "instruction": "ENV", "value": "JAVA_OPTS=\"-Xmx512m\""}, ... ] K8s Deployment model example (partial): { "spec": { "template": { "spec": { "containers": [ { "name": "my-app", "image": "my-registry / my-app:1.0-jdk8", "env": [ { "name":"JAVA_OPTIONS","value": "-XX:+UseConcMarkSweepGC" }] }] } } } } Phase Two: Context Enhancement and Intelligent Analysis Objective: Utilize LLM combined with context and knowledge base to reason and generate precise, atomic modification instructions.

[0091] 1. Input: Configuration object model (from Phase One).

[0092] Target JDK version (e.g.: 17).

[0093] Relevant rules retrieved from the knowledge base: Base image rule: "For JDK 17, the recommended base image is eclipse-temurin:17-jdk-jammy." "Alpine base images may lack certain native libraries and should be used with caution." JVM parameter rule: "JVM parameter -XX:+UseConcMarkSweepGC has been removed in JDK 14+, should be removed." "For container environments, use -XX:MaxRAMPercentage instead of -Xmx to set heap memory." Environment variable rule: "Ensure JAVA_HOME points to the correct JDK installation directory." 2. Processing process (Prompt engineering): The system constructs a highly structured Prompt, instructing the LLM to play the role of a DevOps specialist.

[0094] Context provision: "A Java application is migrating from JDK 8 to JDK 17. The following is its Dockerfile model: [insert Dockerfile model JSON]. The following is its Kubernetes deployment file model: [insert K8s model JSON]." Task instruction: "Please analyze the above configuration based on the target JDK 17 and the following rules: [insert relevant rules]. Identify the base image that needs modification, outdated environment variables, and incompatible JVM parameters. Return the modification instructions in JSON array format, each instruction containing file_type (e.g., DOCKERFILE, K8S_DEPLOYMENT), element_path, action (REPLACE_VALUE, DELETE_FLAG), new_value, and reason." 3. Output: A structured list of modification instructions. [ { "file_type": "DOCKERFILE", "element_path": "[0].value", / / Points to the value of the first element (FROM) in the instruction list "action": "REPLACE_VALUE", "new_value":"eclipse-temurin:17-jdk-jammy", "reason": "openjdk:8-jdk-alpine is a JDK 8 image. According to the knowledge base, eclipse-temurin:17-jdk-jammy is the recommended image for JDK 17." }, { "file_type":"K8S_DEPLOYMENT", "element_path":"spec.template.spec.containers[0].env[0].value", "action": "DELETE_FLAG", "flag_to_delete": "-XX:+UseConcMarkSweepGC", "reason": "The CMS garbage collector has been removed in JDK 14+, and this flag will cause the JVM to fail to start" } ] Phase Three: Application of Structured Modifications Objective: Apply the decisions of the LLM to the in-memory configuration model in a deterministic, error-free manner.

[0096] 1. Input: The original configuration object model and the list of modification instructions generated by the LLM.

[0097] 2. Processing: This is a simple, non-AI script. It iterates through the instruction list, selects the corresponding model based on file_type, and then precisely locates the attribute to be modified based on element_path. Finally, it executes the action (such as replacing values, deleting parts of strings, etc.).

[0098] 3. Output: The configuration object model has been updated.

[0099] Stage Four: File Regeneration and Rewriting Objective: Convert the updated model back into a properly formatted, human-friendly configuration file.

[0100] 1. Input: Updated configuration object model.

[0101] 2. Processing For YAML files: Use a YAML generation library that supports format preservation. This library will try to preserve the original comments, indentation style, and blank lines when writing back to the file, making the differences (Diff) in version control systems clear and readable.

[0102] For Dockerfile and Jenkinsfile: The system will reconstruct the file content line by line or block by block. Again, the goal is to minimize changes in format.

[0103] Through this complete pipeline, the system can turn the otherwise error-prone modification of CI / CD and containerized configuration files into a highly automated, reliable, and auditable process.

[0104] Further, the modified code and configuration conditions are applied and verified, including: Apply the modified code and configuration conditions to a new code branch. Automated verification of the modified code and configuration conditions on the new code branch, including static analysis, compilation, and automated testing: The static analysis includes using tools to perform static checks on the converted code, the compilation is to compile the modified project using the target JDK version, and the automated testing includes executing the original unit tests and integration tests of the project.

[0105] Further, the migration report includes: A differential view of all modified code snippets. The basis and explanation of each modification by the large language model. Modification details of dependencies, build, and configuration files. Test results and potential risk points.

[0106] Further, the target Java project after code migration is merged from the new code branch to the code trunk.

[0107] The embodiment of the application provides an end-to-end automated JDK upgrade solution, which performs automated Java migration design. Overall, first, the "holographic environment" of the target Java project is scanned and analyzed, including source code, dependency configuration (pom.xml, build.gradle), build script, CI / CD configuration and containerized deployment file (such as Dockerfile). Then, the large language model (LLM) engine loads the predefined JDK compatibility rules, API documents, migration guidelines, community experience and the context information parsed from the environment, performs AST (abstract syntax tree) level analysis and conversion on the source code, and proposes upgrade or modification suggestions for the dependency library, build script and deployment configuration. The modified code and configuration will be automatically analyzed, compiled and tested in an isolated environment. The system generates a detailed migration report, including code differences, modification basis and test results, for the developer to review. The feedback of the developer will be used to continuously optimize the LLM model and knowledge base, and finally obtain the target Java project after code migration.

[0108] The above-mentioned Java project JDK upgrade method based on large model holographic environment perception and dependency co-evolution provided by the embodiment combines the powerful understanding and generation ability of LLM with the deep insight into the complete environment of the project, greatly improves the JDK upgrade efficiency, improves the upgrade success rate and quality, and reduces the upgrade failure caused by missing configuration or dependency problems through comprehensive environment analysis.

[0109] LLM makes decisions based on a large amount of knowledge, avoiding human negligence and common errors. Reducing labor costs and skill threshold, reducing the dependence on senior Java experts to perform tedious migration work, allowing more developers to participate or manage the upgrade process. At the same time, controllability and traceability are enhanced, and detailed reports and modification basis make the entire upgrade process transparent. Help enterprises adopt new versions of JDK faster, enjoy the performance, security and language feature advantages brought by it, and maintain technical competitiveness. Through the developer feedback loop, the intelligence level and knowledge base of the system will continue to improve.

[0110] Next, the technical solutions of the embodiment will be explained and described in detail.

[0111] 1. Project access and holographic scanning User specifies the code repository address, the system clones the project and starts the "Project Holographic Scanning and Analysis Module", which parses: Java source code, generates AST. pom.xml or build.gradle file, extracts project dependencies, plugin information. Custom logic in build scripts. CI / CD configuration files, understand the build, test, deployment process. Dockerfile and other containerization configuration files, understand the runtime environment.

[0112] 2. LLM Intelligent Analysis and Conversion 1) Source Code Conversion: LLM engine combines AST, JDK compatibility rules and knowledge base to identify parts of the source code that need to be modified (such as deprecated APIs, incompatible syntax), and generates modified code or modification suggestions.

[0113] 2) Dependency Co-evolution: LLM analyzes existing dependencies and compares them with compatibility information about third-party libraries and target JDK versions in the knowledge base, suggesting the need to upgrade dependency versions or alternative libraries, and can try to automatically update pom.xml / build.gradle.

[0114] 3) Build Script Adaptation: LLM analyzes build scripts (such as Maven plugin configurations) and makes modification suggestions (such as updating plugin versions, adjusting compilation parameters) based on the requirements and best practices of the target JDK.

[0115] 4) CI / CD and Containerization Configuration Adaptation: LLM analyzes CI / CD scripts and Dockerfile, and suggests modifying the base image (such as using an image containing the target JDK), updating environment variables, adjusting JVM parameters, etc.

[0116] 3. Code and Configuration Application The system applies the modifications generated by LLM (code, dependency configuration, build script, CI / CD and containerization configuration) to a new code branch or temporary working area.

[0117] 4. Automatic Verification

[0118] 1) Static Analysis: Use tools such as Checkstyle, SpotBugs to perform static checks on the converted code.

[0119] 2) Compilation: Use the target JDK version to compile the modified project.

[0120] 3) Automated Testing: Execute the project's original unit tests and integration tests.

[0121] 5. Report Generation and Display The system aggregates static analysis results, compilation status, test coverage and pass rate to generate a detailed migration report. The report contains: 1) A diff view of all modified code snippets.

[0122] 2) The rationale and explanation of each modification made by LLM (from the knowledge base or the inference process of the model).

[0123] 3) Modification details of dependencies, build and configuration files.

[0124] 4) Test results and potential risk points.

[0125] 6. Developer review and feedback Developers review the report through the interface and can accept, reject or manually adjust the modifications made by LLM. The feedback of developers (such as which modifications are good and which are wrong, why) is collected: 1) To fine-tune the LLM model, improve its accuracy in subsequent analysis and conversion.

[0126] 2) To update and enrich the knowledge base.

[0127] 7. Iteration and confirmation After the developers confirm the modifications, they can merge the new branch into the main branch. If there are problems, they can go back to steps 2 or 3 for adjustment and re-verification.

[0128] The key technologies of this embodiment are as follows: 1. Holographic project environment analysis and modeling.

[0129] Develop a parser that can accurately parse configuration files of different formats (XML, YAML, Groovy DSL, Shell script, etc.). Build a unified model of the project environment, including code structure, dependency relationship diagram, build process, deployment topology, etc., as the context for LLM analysis.

[0130] 2. Application of LLM in code and configuration understanding and generation.

[0131] Multi-modal information fusion: LLM can understand structured AST, semi-structured configuration files and unstructured documents / community discussions.

[0132] Controlled generation and explainability: The code and configuration modifications generated by LLM need to strictly follow compatibility rules and provide clear reasons for making such modifications. Techniques such as Retrieval-Augmented Generation (RAG) can be used to ensure that the generated content is based on reliable knowledge.

[0133] Context awareness: The analysis and recommendations of the LLM need to fully consider the contextual information obtained from the "holistic environment scan", for example, the selection of a dependent library may be limited by other libraries or deployment environments that the project already has.

[0134] 3. Construction and maintenance of knowledge base.

[0135] Integrate official JDK migration documents, API change logs, compatibility matrices of mainstream frameworks and libraries, community best practices, Stack Overflow, and other sources of knowledge. Design an effective knowledge representation method to facilitate LLM retrieval and reasoning. Establish a mechanism for automatically updating the knowledge base from developer feedback and successful migration cases.

[0136] 4. Integration of automated testing and verification.

[0137] Seamless integration with the existing test framework of the project. Based on methods such as mutation testing, evaluate the coverage of test cases for changes in new JDK features. Use the LLM to analyze the reasons for test failures and assist in locating problems.

[0138] 5. Differentiated comparison and developer interaction, providing clear and intuitive views of code and configuration file differences. Efficient feedback collection mechanism, accurately conveying developer intentions to the LLM for learning.

[0139] 6. Security and stability, ensuring that the code generated by the LLM does not introduce new security vulnerabilities (SAST tools can be integrated to scan generated code). Strict version control and rollback mechanisms for modification operations.

[0140] Embodiment Two The embodiment discloses a code migration system based on holographic environment perception and dependent co-evolution.

[0141] The code migration system based on holographic environment perception and dependent co-evolution comprises: The parsing module is configured to obtain a target Java project, and parse Java source code in the target Java project and configuration conditions of the Java source code; The large language model modification module is configured to determine a target JDK version, combine JDK compatibility rules and a knowledge base, identify parts of the Java source code that need to be modified based on a large language model, and generate modified code or modification suggestions; and modify the configuration conditions of the Java source code to obtain modified configuration conditions; The verification module is configured to apply and verify the modified code and configuration conditions; The report generation module is configured to generate a migration report based on the verification result; The feedback updating module is configured to obtain feedback of the developer on the migration report, and update the knowledge base and the large language model. The circulation module is configured to circulate the process from the large language model modifying module to the feedback updating module based on the updated knowledge base and the large language model, until the modified code and the configuration condition are confirmed by the developer, and the target Java project after code migration is obtained. Embodiment three An object of this embodiment is to provide a computer-readable storage medium.

[0142] A computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the steps in the code migration method based on holographic environment perception and dependence co-evolution of embodiment 1 of the present disclosure.

[0143] Embodiment four An object of this embodiment is to provide an electronic device.

[0144] An electronic device comprising a memory, a processor, and a program stored on the memory and executable on the processor, wherein the processor implements the steps in the code migration method based on holographic environment perception and dependence co-evolution of embodiment 1 of the present disclosure when executing the program.

[0145] The steps and methods involved in the above embodiments two, three and four correspond to embodiment one, and the specific implementation can be referred to the relevant description part of embodiment one. The term "computer-readable storage medium" should be understood to include a single medium or multiple media of one or more instruction sets; it should also be understood to include any medium capable of storing, encoding or carrying a set of instructions for execution by a processor and causing the processor to perform any of the methods in the present invention.

[0146] Those skilled in the art should understand that each module or step of the present invention described above can be implemented by a general computer device, alternatively, they can be implemented by program code executable by a computing device, so that they can be stored in a storage device for execution by a computing device, or they can be made into individual integrated circuit modules, or a plurality of modules or steps among them can be made into a single integrated circuit module. The present invention is not limited to any specific combination of hardware and software.

[0147] Although the specific embodiments of the present invention are described above in combination with the accompanying drawings, it is not a limitation on the scope of protection of the present invention, and those skilled in the art should understand that various modifications or variations made by those skilled in the art on the basis of the technical solutions of the present invention without creative labor are still within the scope of protection of the present invention.< / plugin> < / plugins> < / build> < / dependencies> < / project>

Claims

1. A method for code migration based on holographic environment perception and dependent co-evolution, characterized in that, The method comprises the following steps: Step 1: Obtain the target Java project, parse the Java source code in the target Java project and the configuration conditions of the Java source code; Step 2: Determine the target JDK version, combine the JDK compatibility rules and knowledge base, identify the parts that need to be modified in the Java source code based on the large language model, and generate modified code or modification suggestions; at the same time, modify the configuration conditions of the Java source code to obtain the modified configuration conditions; Step 3: Apply and verify the modified code and configuration conditions; Step 4: Generate a migration report based on the verification results; Step 5: Obtain the developer's feedback on the migration report, update the knowledge base and the large language model; Step 6: Based on the updated knowledge base and the large language model, repeat steps 2 to 5 until the modified code and configuration conditions are confirmed by the developer, and obtain the target Java project after code migration.

2. The method for code migration based on holographic environment perception and dependency co-evolution of claim 1, wherein, The configuration conditions of the Java source code include dependency configuration, build script, CI / CD configuration and deployment configuration.

3. The method of claim 2, wherein, The Java source code in the target Java project and the configuration conditions of the Java source code are parsed, specifically including: Parse the Java source code to generate an AST; Parse the pom.xml or build.gradle file in the dependency configuration to extract project dependencies and plugin information; Parse the custom logic in the build script; Parse the CI / CD configuration file to understand the build, test and deployment process; Parse the containerization configuration file to understand the code runtime environment.

4. The method of claim 1, wherein, Modify the configuration conditions of the Java source code to obtain the modified configuration conditions, specifically including: The large language model analyzes the existing dependency configuration of the Java source code and compares it with the compatibility information of third-party libraries and the target JDK version in the knowledge base to suggest the dependency version that needs to be upgraded or the alternative library, and automatically update the dependency configuration; The large language model analyzes the build script and proposes modification suggestions based on the requirements of the target JDK version, including updating the plugin version and adjusting the compilation parameters; The large language model analyzes the CI / CD script and containerization deployment file, modifies the base image, updates the environment variables and adjusts the JVM parameters.

5. The method for code migration based on holographic environment perception and dependency co-evolution of claim 1, wherein, Apply and verify the modified code and configuration conditions, specifically including: Apply the modified code and configuration conditions to a new code branch; Automatically verify the modified code and configuration conditions on the new code branch, including static analysis, compilation and automated testing: The static analysis includes using tools to perform static checks on the converted code, the compilation is to use the target JDK version to compile the modified project, and the automated testing includes executing the original unit tests and integration tests of the project.

6. The method for code migration based on holographic environment perception and dependency co-evolution of claim 1, wherein, The migration report specifically includes: A differentiated view of all modified code snippets; The basis and explanation of each modification by the large language model; Modification details of dependencies, build and configuration files; Test results and potential risk points.

7. The method of claim 5, wherein the holographic environment perception and dependency co-evolution based code migration is characterized by, Merge the target Java project after code migration from the new code branch to the code trunk.

8. A code migration system based on holographic environment perception and dependent co-evolution, characterized in that, It includes: The analysis module is configured to: obtain a target Java project, and analyze Java source code in the target Java project and configuration conditions of the Java source code; The large language model modification module is configured to: determine a target JDK version, combine JDK compatibility rules and a knowledge base, identify parts that need to be modified in the Java source code based on a large language model, generate modified code or modification suggestions, and modify the configuration conditions of the Java source code to obtain modified configuration conditions; The verification module is configured to: apply and verify the modified code and the configuration conditions; The report generation module is configured to: generate a migration report based on a verification result; The feedback updating module is configured to: obtain feedback of a developer on the migration report, and update the knowledge base and the large language model; The loop module is configured to: based on the updated knowledge base and the large language model, cyclically execute the process from the large language model modification module to the feedback updating module until the modified code and the configuration conditions are confirmed by the developer, and obtain a target Java project after code migration.

9. A computer-readable storage medium having stored thereon a program, characterized in that, The program is executed by the processor to implement the steps in the code migration method based on holographic environment perception and dependent co-evolution of any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the steps in the code migration method based on holographic environment perception and dependent co-evolution of any one of claims 1-7.

Images