A Code-Server-based Java online remote debugging method and system

Abstract

The application provides a Code-Server-based Java online remote debugging method and system, and belongs to the technical field of distributed software development environment. The method comprises the following steps: loading a Java debugging extension package in a Code-Server; in response to a debugging request from a browser end, starting a Debug Adapter process through the Java debugging extension package, requesting and obtaining session information from a Session-Broker service; based on an authentication Token, the Debug Adapter process establishes a secure JDWP connection with a target JVM, and sends bytecode hot replacement instructions and debugging data to the Session-Broker service through the JDWP connection, so as to synchronously transmit the debugging data to each browser client in real time based on a session identifier. The application realizes safe, collaborative and installation-free Java remote debugging through a cloud architecture.

Description

Technical Field

[0001] This application belongs to the field of distributed software development environment technology, specifically relating to a Java online remote debugging method and system based on Code-Server. Background Technology

[0002] aPaaS is short for Application Platform as a Service.

[0003] JDWP is short for Java Debug Wire Protocol.

[0004] IDE is short for Integrated Development Environment.

[0005] JVM is short for Java Virtual Machine.

[0006] JDK is short for Java Development Kit, a Java development toolkit.

[0007] SSH is short for Secure Shell, a secure shell protocol.

[0008] With the development of low-code and aPaaS platforms, cloud-based online open models are becoming increasingly popular, creating an urgent need for efficient and secure remote Java debugging in a browser environment. Existing Java remote debugging solutions primarily rely on JDWP, requiring developers to install a complete IDE locally and connect to the target JVM over a network.

[0009] However, this traditional debugging mode has the following technical drawbacks: First, there is a strong dependence on the local environment. Developers need to configure a complete development environment locally, including specific versions of JDK, IDEs, and various plugins, increasing the complexity and maintenance costs of environment configuration and making it impossible to achieve a pure browser-based development experience with zero local dependencies. Second, there are high security risks. For remote debugging, it is usually necessary to develop a debug port for the target JVM (such as the default port 5005) and perform port mapping through a network firewall or complex SSH tunnel. This method is not only cumbersome to configure, but also exposes the debug port directly to the network. Since the JDWP protocol itself lacks authentication and encryption mechanisms, it is highly vulnerable to security vulnerabilities that can be exploited by unauthorized third parties. Third, collaborative debugging capabilities are insufficient. Traditional debugging sessions are private and isolated. When multiple developers need to jointly locate a complex problem, they can often only do so through screen sharing or remote control software, which cannot achieve real-time sharing and synchronization of debugging context such as breakpoints, variables, and call stacks, resulting in low collaborative efficiency. Finally, the debugging experience is limited. In high-latency network environments, existing solutions exhibit significant delays in operations such as breakpoint hitting and variable viewing. Meanwhile, the HotSwap code hot swapping function is limited by its underlying implementation, resulting in low success rate and efficiency, making it difficult to meet the needs of agile development.

[0010] Therefore, there is an urgent need for a Java online remote debugging method and system that can overcome the above-mentioned defects and achieve safe, efficient, and collaborative debugging. Summary of the Invention

[0011] In a first aspect, embodiments of this application provide a Java online remote debugging method based on a Code-Server, comprising the following steps: S1. Load the Java debugging extension package containing the Debug Adapter startup module in the Code-Server environment; S2. In response to a debugging request from the browser, the Debug Adapter process is started by calling the Debug Adapter startup module through the Java Debug Extension Package; The S3.Debug Adapter process requests and obtains session information, including the session identifier and authentication token, from the Session-Broker service. S4. Based on the authentication token, the Debug Adapter process establishes a secure JDWP connection with the target JVM that has preloaded the Java debugging agent through the JDWP-Secure-Gateway reverse proxy, and sends bytecode hot-swap instructions to the Java debugging agent through the JDWP connection; The S5.Debug Adapter process sends the debug data obtained through the JDWP connection to the Session-Broker service; The S6.Session-Broker service synchronizes debug data in real time to various browser clients participating in the same debug session based on session identifiers.

[0012] Furthermore, the specific steps of step S1 are as follows: S11. Build the Java debugging extension package into a VSIX package, wherein the VSIX package includes the java-debugger-core module, the java-hotswap-agent module, and the java-session-share module; S12. When the Code-Server environment starts, install the VSIX package using the --install-extension command; S13. After installation, the VSIX package injects the functionality of the java-debugger-core module, java-hotswap-agent module, and java-session-share module into the debugging environment of the Code-Server environment. Among them, the java-debugger-core module is used by the Debug Adapter process to start.

[0013] Furthermore, the specific steps of step S2 are as follows: S21. After startup, the Debug Adapter process establishes communication with the Code-Server environment through the standard input / output stdio channel; S22. The Debug Adapter process receives debugging commands from the Code-Server environment according to the Debug Adapter Protocol; S23. The Debug Adapter process converts received debug commands from the Debug Adapter Protocol into JDWP protocol commands.

[0014] Furthermore, the specific steps of step S3 are as follows: S31. The Debug Adapter process sends a session creation request to the Session-Broker service. The session request includes the user ID, the session expiration time expireSec, and the initial role mapping initialRoleMap. The S32.Session-Broker service generates a unique session identifier (sessionID) and a random authentication token based on the session request, and determines the following fields: `owner` takes the value of the user ID, which represents the session owner. `createAt` takes the current system timestamp, indicating the session creation time. roleMap takes the value of initialRoleMap, which represents the role mapping; if initialRoleMap is not provided, a default role mapping is generated, which at least contains an entry that maps the session owner to the owner role; The algorithm for generating the authentication token is as follows: Token=Base64URL(SHA256(sessionID||userID||timestamp||random_nonce)) Where sessionID is the session identifier, userID is the user identifier, timestamp is the current timestamp, random_nonce is a random number of a specified number of bytes generated by a secure random number generator, and || represents the string concatenation operation; The S33.Session-Broker service stores session information, including session ID, owner, createAt, authentication token, and role map, in a Redis database. The S34.Session-Broker service returns the generated session ID and authentication token to the DebugAdapter process.

[0015] Furthermore, the specific steps of step S4 are as follows: S41. The JDWP-Secure-Gateway reverse proxy receives connection requests from the Debug Adapter process, and the connection requests carry an authentication token. S42. The JDWP-Secure-Gateway reverse proxy calls the TokenValidator interface of the Session-Broker service to verify the validity of the authentication token; S43. After successful verification, the JDWP-Secure-Gateway reverse proxy establishes a TLS encrypted channel with the Debug Adapter process and forwards the JDWP data stream sent by the Debug Adapter process to the debug port of the target JVM through the TLS encrypted channel; The S44.Debug Adapter process sends bytecode hot-swap instructions to the Java debug agent of the target JVM through the established JDWP connection; S45. After the debug session ends, the JDWP-Secure-Gateway reverse proxy notifies the Session-Broker service to invalidate the authentication token used in this session.

[0016] Furthermore, step S44 is detailed as follows: S441. In response to the user saving the modified Java class file on the browser, the Code-Server environment sends the compiled bytecode data to the Debug Adapter process; The S442.Debug Adapter process sends a class redefinition request to the target JVM via the JDWP protocol. The class redefinition request contains the class name to be replaced and the corresponding new bytecode. S443. After receiving the request, the Java debugging agent of the target JVM calls the redefineClasses function of the target JVM to perform hot replacement of bytecode and returns the replacement result to the Debug Adapter process; The S444.Debug Adapter process sends the hot-swap results to the Session-Broker service for synchronization.

[0017] Furthermore, the specific steps of step S5 are as follows: The S51.Debug Adapter process obtains debugging data of the target JVM through JDWP connection. The debugging data includes at least one of breakpoint events, variable values, and call stack information. The S52.Debug Adapter process encapsulates the acquired debug data into a format conforming to the Debug Adapter Protocol. The S53.Debug Adapter process sends the encapsulated debug data to the Session-Broker service.

[0018] Furthermore, the specific steps of step S6 are as follows: The S61.Session-Broker service receives WebSocket connection requests initiated by participant browsers by accessing a URL containing the session ID; The S62.Session-Broker service queries session information from the Redis database based on the session identifier (sessionID) to verify whether the session exists and is valid. S63. After successful verification, the Session-Broker service will reverse proxy the WebSocket connection to the stdio port of the corresponding DebugAdapter process; The S64.Session-Broker service pushes the debug data received in step S5 to the browsers of all connected participants in real time via a WebSocket connection.

[0019] Furthermore, it also includes the following steps: The S7 Debug Adapter process performs debugging operations; S8. Debug Adapter process execution log replay; The specific steps of step S7 are as follows: S71. In response to the user's breakpoint setting operation on the browser, the Debug Adapter process sends a breakpoint setting request to the target JVM via the JDWP protocol; S72. When the target JVM hits a breakpoint, the Debug Adapter process receives the breakpoint event sent by the target JVM via the JDWP protocol and converts it into a DAP protocol breakpoint event; S73. The Debug Adapter process sends the converted DAP protocol breakpoint events to the Session-Broker service so that they can be synchronized to various browser clients via step S6. S74. In response to the user's variable viewing operation on the browser, the Debug Adapter process sends a stack frame variable request to the target JVM through the JDWP protocol, receives the variable value returned by the target JVM, and then sends the variable value to the Session-Broker service for synchronization. The specific steps of step S8 are as follows: S81. In response to a user's time-travel-style history breakpoint replay request, the Debug Adapter process requests historical debug data at the specified breakpoint from the Session-Broker service; The S82.Session-Broker service queries the Redis database for the historical debug event stream associated with the current session identifier (sessionID). The historical debug event stream includes the thread context, variable snapshot, and call stack information at the time the breakpoint was hit. The S83.Session-Broker service returns the retrieved historical debug data to the Debug Adapter process; The S84.Debug Adapter process pushes historical debug data to the browser client for display via a WebSocket connection.

[0020] Secondly, embodiments of this application also provide a Java online remote debugging system based on Code-Server, comprising: The Code-Server environment is used to load Java debugging extension packages that include the Debug Adapter startup module; A browser client used to send debugging requests to the Code-Server environment; The Debug Adapter process is started by the Java Debug Extension Package in response to a debug request; The Session-Broker service communicates with the Debug Adapter process to receive session creation requests and return session information containing the session identifier and authentication token. JDWP-Secure-Gateway reverse proxy communicates with the Debug Adapter process and the target JVM that has a preloaded Java debug agent to establish a secure JDWP connection with the target JVM based on an authentication token; The Debug Adapter process is also used to send bytecode hot-swap instructions to the Java debugging agent via JDWP connection, and to obtain debugging data via JDWP connection and send it to the Session-Broker service; The Session-Broker service is also used to synchronize debugging data in real time to various browser clients participating in the same debugging session based on the session identifier.

[0021] As can be seen from the above technical solutions, this application has the following advantages: The Java online remote debugging method and system provided in this application, based on Code-Server, deploys a modular Java debugging extension package and Debug Adapter process in the Code-Server environment. Combined with a JDWP security gateway based on dynamic authentication tokens and TLS encryption, and using the Session-Broker service for session state management and WebSocket real-time data distribution, it enables Java online remote debugging. This allows debugging to be performed on the browser without installing any local development environment, achieving enterprise-level security protection, and enabling real-time collaborative operation by multiple users and hot replacement of bytecode. This completely solves the technical problems of complex environment configuration, high port exposure risk, and low team collaboration efficiency in traditional remote debugging. Attached Figure Description

[0022] To more clearly illustrate the technical solution of this application, the accompanying drawings used in the description will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating the Java online remote debugging method based on Code-Server of the present invention.

[0024] Figure 2 This is a schematic diagram of the Java online remote debugging system based on Code-Server according to the present invention. Detailed Implementation

[0025] The various embodiments of this disclosure will be described more fully in the following detailed steps of the Java online remote debugging method based on Code-Server. This disclosure may have various embodiments, and adjustments and changes may be made therein. However, it should be understood that there is no intention to limit the various embodiments of this disclosure to the specific embodiments disclosed herein, but rather this disclosure should be understood to cover all adjustments, equivalents, and / or alternatives falling within the spirit and scope of the various embodiments of this disclosure.

[0026] For example, with the evolution of low-code development and aPaaS cloud-native architecture, development models are rapidly shifting towards an online form where the browser is the IDE. This places stringent requirements on Java remote debugging, including zero client dependency, high security and compliance, and strong collaborative interaction. However, current mainstream solutions still adhere to the traditional local debugging paradigm based on the JDWP protocol, and their technical bottlenecks are becoming increasingly apparent. First, the environment is highly coupled, resulting in a fragmented delivery experience. Developers are forced to build their development stacks locally (specific JDKs, heavy-duty IDEs, and plugins), leading to cumbersome initial configurations, high maintenance costs, and failing to achieve the out-of-the-box, ubiquitous access convenience of cloud development. Second, the security baseline is weak, exposing the attack surface. Traditional solutions require exposing unauthenticated, plaintext JDWP ports (such as 5005) to the public internet through firewalls. This type of port mapping is highly susceptible to high-risk attacks such as Remote Code Execution (RCE) and lacks fine-grained access control and session auditing mechanisms. Third, collaboration is limited, information synchronization is lagging, and debugging sessions are isolated, lacking native multi-device state synchronization mechanisms. Team collaboration relies solely on inefficient screen sharing, failing to achieve real-time sharing of breakpoint hits, variable snapshots, and call stack information, or multi-view concurrent operations. Finally, the interactive performance is limited and the agile response is insufficient. Due to network latency and the limitations of the underlying HotSwap implementation, the existing solution is slow to operate in weak network environments, and the success rate of hot code replacement is low and the effect is slow, making it difficult to support the high-frequency iterative development pace.

[0027] In conclusion, building a new Java cloud debugging system that is delocalized, has an embedded security gateway, and supports real-time multi-party collaboration has become an inevitable choice to break through current technical bottlenecks.

[0028] To address the aforementioned issues, this embodiment provides a Java online remote debugging method based on Code-Server. Through Code-Server and a security gateway, it enables Java online debugging with zero dependencies, high security, and multi-user collaboration.

[0029] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0030] Please see Figure 1 The diagram shows a flowchart of a Java online remote debugging method based on a Code-Server in a specific embodiment. The method includes the following steps: S1. Load the Java debugging extension package containing the Debug Adapter startup module in the Code-Server environment; It should be noted that by preloading the Java debugging extension package containing the Debug Adapter startup module in the Code-Server environment, the cloud environment has native Java debugging capabilities, thus achieving zero local dependencies without requiring users to install or configure any additional plugins on the browser side. S2. In response to a debugging request from the browser, the Debug Adapter process is started by calling the Debug Adapter startup module through the Java Debug Extension Package; It should be noted that dynamically starting the Debug Adapter process in response to browser requests enables on-demand allocation and isolation of debugging resources. This allows the Debug Adapter process to act as middleware, bridging the browser's DAP protocol with the backend's JDWP protocol, thus ensuring the correct parsing and forwarding of debugging commands. The S3.Debug Adapter process requests and obtains session information, including the session identifier and authentication token, from the Session-Broker service. It should be noted that by requesting session information containing session identifier and authentication token from the Session-Broker service, an identity authentication mechanism for the debugging session is established. This is a prerequisite for subsequent secure connections, ensuring that only legitimate debugging requests can enter the system and preventing unauthorized access. S4. Based on the authentication token, the Debug Adapter process establishes a secure JDWP connection with the target JVM that has preloaded the Java debugging agent through the JDWP-Secure-Gateway reverse proxy, and sends bytecode hot-swap instructions to the Java debugging agent through the JDWP connection; It should be noted that by establishing a secure TLS encrypted connection through JDWP-Secure-Gateway based on the authentication token, the serious security risks caused by the traditional JDWP port exposure are resolved. At the same time, a channel for sending bytecode hot replacement instructions to the target JVM is established, realizing hot deployment. Code modifications can be verified without restarting the service, thus improving deployment efficiency. The S5.Debug Adapter process sends the debug data obtained through the JDWP connection to the Session-Broker service; It should be noted that by reporting the acquired underlying debugging data to the Session-Broker service, centralized aggregation and management of debugging data are achieved. This provides a data source for data distribution, historical record storage, and multi-device synchronization, breaking through the data silos of single-point debugging. The S6.Session-Broker service synchronizes debug data in real time to various browser clients participating in the same debug session based on session identifiers. It should be noted that by pushing debugging data to all participating browser clients in real time based on session identifiers, true multi-person collaborative debugging is achieved. This allows all participants to see breakpoint hits and variable changes simultaneously, improving the efficiency of team collaboration in troubleshooting and replacing the inefficient screen sharing mode.

[0031] This embodiment completely eliminates local environment dependencies and JDWP security risks through modular VSIX deployment, dynamic token authentication, and TLS encrypted proxy, realizing an enterprise-level Java online collaborative debugging system that supports millisecond-level hot replacement, historical playback, and real-time status synchronization across multiple browsers.

[0032] Furthermore, as a refinement and extension of the specific implementation of the above embodiments, in order to fully illustrate the specific implementation process of this embodiment, another Java online remote debugging method based on Code-Server is provided, which includes the following steps: S1. Load the Java debugging extension package containing the Debug Adapter startup module in the Code-Server environment; the Java debugging extension package is a VSIX package containing three core modules. The specific steps of step S1 are as follows: S11. Build the Java debugging extension package into a VSIX package, wherein the VSIX package includes the java-debugger-core module, the java-hotswap-agent module, and the java-session-share module; S12. When the Code-Server environment starts, install the VSIX package using the --install-extension command; S13. After installation, the VSIX package injects the functionality of the java-debugger-core module, java-hotswap-agent module, and java-session-share module into the debugging environment of the Code-Server environment. Among them, the java-debugger-core module is used by the Debug Adapter process to start. Specifically, the java-debugger-core module is responsible for the complete lifecycle management of the Debug Adapter process. It registers the Java debugging type in the debugging configuration of the Code-Server environment and specifies the entry script of the Debug Adapter to provide support for subsequent startup. The java-hotswap-agent module contains a built-in hotswap agent hotswap-helper.jar and a corresponding startup configuration template, which is used to implement hot bytecode replacement in the target JVM. The java-session-share module registers the Share Debug Session command in the Code-Server environment status bar, which is used to generate shared links for collaborative debugging. Through the specific steps in step S1, the Code-Server environment gains complete Java remote debugging capabilities. All functions are encapsulated through extension packages, without the need to modify the Code-Server kernel. S2. In response to the browser's debugging request, the Debug Adapter process is started by calling the Debug Adapter startup module through the Java Debug Extension Package; the specific steps of step S2 are as follows: S21. After startup, the Debug Adapter process establishes communication with the Code-Server environment through the standard input / output stdio channel; S22. The Debug Adapter process receives debugging commands from the Code-Server environment according to the Debug Adapter Protocol; S23. The Debug Adapter process converts received debug commands from the Debug Adapter Protocol into JDWP protocol commands; Through the stdio channel, the Debug Adapter process and the Code-Server frontend achieve bidirectional communication. The DAP commands sent by the frontend (such as setting breakpoints and single-stepping) are converted into JDWP instructions and prepared to be sent to the target JVM. S3. The Debug Adapter process requests and obtains session information, including the session identifier and authentication token, from the Session-Broker service. The Session-Broker service, as an independent session management service, is responsible for generating session credentials and storing session state. The specific steps in step S3 are as follows: S31. The Debug Adapter process sends a session creation request to the Session-Broker service. The session request includes the user ID, the session expiration time expireSec, and the initial role mapping initialRoleMap. The S32.Session-Broker service generates a unique session identifier (sessionID) and a random authentication token based on the session request, and determines the following fields: `owner` takes the value of the user ID, which represents the session owner. `createAt` takes the current system timestamp, indicating the session creation time. roleMap takes the value of initialRoleMap, which represents the role mapping; if initialRoleMap is not provided, a default role mapping is generated, which at least contains an entry that maps the session owner to the owner role; The algorithm for generating the authentication token is as follows: Token=Base64URL(SHA256(sessionID||userID||timestamp||random_nonce)) Where sessionID is the session identifier, userID is the user identifier, timestamp is the current timestamp, random_nonce is a random number of a specified number of bytes generated by a secure random number generator, and || represents the string concatenation operation; The S33.Session-Broker service stores session information, including session ID, owner, createAt, authentication token, and role map, in a Redis database. The S34.Session-Broker service returns the generated session ID and authentication token to the DebugAdapter process; S4. Based on the authentication token, the Debug Adapter process establishes a secure JDWP connection with the target JVM that has preloaded the Java debugging agent through the JDWP-Secure-Gateway reverse proxy, and sends bytecode hot-swap instructions to the Java debugging agent through the JDWP connection; JDWP-Secure-Gateway reverse proxy acts as a security proxy, responsible for encryption and authentication; The specific steps of step S4 are as follows: S41. The JDWP-Secure-Gateway reverse proxy receives connection requests from the Debug Adapter process, and the connection requests carry an authentication token. S42. The JDWP-Secure-Gateway reverse proxy calls the TokenValidator interface of the Session-Broker service to verify the validity of the authentication token; S43. After successful verification, the JDWP-Secure-Gateway reverse proxy establishes a TLS encrypted channel with the Debug Adapter process and forwards the JDWP data stream sent by the Debug Adapter process to the debug port of the target JVM through the TLS encrypted channel; S44. The Debug Adapter process sends a bytecode hot-swap instruction to the Java debug agent of the target JVM through the established JDWP connection; the specific steps of step S44 are as follows: S441. In response to the user saving the modified Java class file on the browser, the Code-Server environment sends the compiled bytecode data to the Debug Adapter process; The S442.Debug Adapter process sends a class redefinition request to the target JVM via the JDWP protocol. The class redefinition request contains the class name to be replaced and the corresponding new bytecode. S443. After receiving the request, the Java debugging agent of the target JVM calls the redefineClasses function of the target JVM to perform hot replacement of bytecode and returns the replacement result to the Debug Adapter process; The S444.Debug Adapter process sends the hot-swap results to the Session-Broker service for synchronization; S45. After the debug session ends, the JDWP-Secure-Gateway reverse proxy notifies the Session-Broker service to invalidate the authentication token used in this session. The S5.Debug Adapter process sends the debug data obtained through the JDWP connection to the Session-Broker service; Debugging data includes breakpoint events, variable values, call stacks, etc. The specific steps of step S5 are as follows: The S51.Debug Adapter process obtains debugging data of the target JVM through JDWP connection. The debugging data includes at least one of breakpoint events, variable values, and call stack information. The S52.Debug Adapter process encapsulates the acquired debug data into a format conforming to the Debug Adapter Protocol. The S53.Debug Adapter process sends the encapsulated debug data to the Session-Broker service; The S6 Session-Broker service synchronizes debug data in real time to all browser clients participating in the same debug session based on session identifiers; the specific steps of step S6 are as follows: The S61.Session-Broker service receives WebSocket connection requests initiated by participant browsers by accessing a URL containing the session ID; The S62.Session-Broker service queries session information from the Redis database based on the session identifier (sessionID) to verify whether the session exists and is valid. S63. After successful verification, the Session-Broker service will reverse proxy the WebSocket connection to the stdio port of the corresponding DebugAdapter process; S64. The Session-Broker service pushes the debug data received in step S5 to the browsers of all connected participants in real time via a WebSocket connection; Through role-based access control, the Session-Broker service can restrict the operational permissions of different participants. For example, read-only observers cannot send debugging commands, while collaborative debuggers can perform all operations except inviting / removing participants. The owner has full control, ensuring the orderliness and security of collaborative debugging. It also includes the following steps: The S7 Debug Adapter process performs debugging operations; S8. Debug Adapter process execution log replay; The specific steps of step S7 are as follows: S71. In response to the user's breakpoint setting operation on the browser, the Debug Adapter process sends a breakpoint setting request to the target JVM via the JDWP protocol; S72. When the target JVM hits a breakpoint, the Debug Adapter process receives the breakpoint event sent by the target JVM via the JDWP protocol and converts it into a DAP protocol breakpoint event; S73. The Debug Adapter process sends the converted DAP protocol breakpoint events to the Session-Broker service so that they can be synchronized to various browser clients via step S6. S74. In response to the user's variable viewing operation on the browser, the Debug Adapter process sends a stack frame variable request to the target JVM through the JDWP protocol, receives the variable value returned by the target JVM, and then sends the variable value to the Session-Broker service for synchronization. The above operations are broadcast via Session-Broker, enabling all participants to share debugging progress in real time and achieving a collaborative experience similar to a local IDE; Step S8 supports time-travel debugging, which means replaying the historical breakpoint. The specific steps are as follows: S81. In response to a user's time-travel-style history breakpoint replay request, the Debug Adapter process requests historical debug data at the specified breakpoint from the Session-Broker service; The S82.Session-Broker service queries the Redis database for the historical debug event stream associated with the current session identifier (sessionID). The historical debug event stream includes the thread context, variable snapshot, and call stack information at the time the breakpoint was hit. The S83.Session-Broker service returns the retrieved historical debug data to the Debug Adapter process; The S84.Debug Adapter process pushes historical debug data to the browser client for display via a WebSocket connection; For example, suppose developer xxx needs to debug a Java application deployed in the cloud, and he accesses the Code-Server's web interface through a browser; Start a debug session: xxx opens the project, sets a breakpoint at the line number, and then clicks "Start Debugging"; the Code-Server environment starts the Debug Adapter process according to the launch configuration (such as mainClass); the Debug Adapter process first sends a session creation request (gRPC call) to the Session-Broker service, which includes xxx's user ID xxx@company.com, the session validity period of 3600 seconds, and the initial role mapping (for example, setting Alice as the owner); the Session-Broker service returns the session identifier sessionID and authentication token; Establish a secure JDWP connection: The Debug Adapter process initiates a TLS connection to the JDWP-Secure-Gateway reverse proxy, carrying the authentication token. Upon receiving the connection request, the gateway parses the authentication token and calls the TokenValidator of the Session-Broker service to verify its validity. After successful verification, a TLS encrypted channel is established between the gateway and the Debug Adapter process, while a plaintext JDWP connection is established between the gateway and port 5005 of the target JVM. Thereafter, all JDWP communication between the Debug Adapter process and the target JVM passes through this encrypted tunnel. Debugging operations and data synchronization: When xxx performs a single-step skip operation in the browser, the Code-Server environment sends a next request to the Debug Adapter process via the DAP protocol. The Debug Adapter process converts this into a JDWP Step command and sends it to the target JVM. After the target JVM executes the command, it returns the call stack and variable information of the current thread. The Debug Adapter process encapsulates this information into a DAP stopped event and broadcasts it to all browser clients participating in the current session via the Session-Broker service. At this time, the browser interface of another collaborator (who has joined the session via a shared URL) will also synchronously display the paused status and variable values. Detailed process of bytecode hot replacement: When a user modifies and saves a Java source file in their browser, the Code-Server environment automatically triggers compilation, generating new bytecode. Subsequently, the frontend sends a custom hotswap request to the Debug Adapter process via the DAP protocol. The request body contains the fully qualified name of the class to be replaced and its new bytecode (Base64 encoded). Upon receiving the request, the Debug Adapter process converts it into a JDWP RedefineClasses command package and sends it to the target JVM through an established encrypted channel. The hotswap-helper.jar proxy in the target JVM listens for this command and calls the Instrumentation.redefineClasses() method to complete the hot replacement of the class. The replacement result (success or specific exception) is returned along the original path and finally broadcast to all participating browsers by the Session-Broker service, and the user is prompted in the interface. The implementation mechanism of log replay (time travel debugging): If the system has enabled the historical debugging data recording function, the Session-Broker service will serialize key debugging events (such as breakpoint hits, variable snapshots, and call stack changes) and append them to the Redis Stream. Each event carries a timestamp and breakpoint identifier. When a user requests to replay a historical breakpoint, the Debug Adapter process sends a replay request to the Session-Broker service, carrying the target breakpoint identifier. The Session-Broker service queries the Redis Stream for the complete context events before and after the breakpoint, assembles them into a historical event stream, and returns it to the Debug Adapter process. The Debug Adapter process converts these events into DAP protocol format and pushes them to the browser requesting replay via WebSocket. The front end restores the state at that time in the debug view, including source code location, variable values, call stack, etc., realizing time travel debugging. Detailed implementation of multi-user collaboration: When xxx clicks the Share Debug Session button, the Code-Server environment calls the java-session-share module, which creates a session through the CreateSession interface of the Session-Broker service and generates a URL containing a session identifier (sessionID); xxx then sends this URL to another browser. When another user opens the URL in their browser, the front-end code in the Code-Server environment initiates a WebSocket connection request to the Session-Broker service. The URL contains the session identifier (sessionID). The Session-Broker service retrieves session information from Redis based on the session identifier (sessionID), verifies that the session is valid and that the other user has the appropriate permissions (e.g., the role of collaborator). After successful verification, the Session-Broker service reverse proxies the WebSocket connection to the stdio port of the Debug Adapter process. Subsequently, the other user's browser and the Debug Adapter process communicate bidirectionally via this WebSocket connection to achieve real-time synchronization of debug data. Role-based access control: During collaborative debugging, the Session-Broker service controls participant permissions based on role mapping; roles are divided into three levels: Owner: Has full control, can set / clear breakpoints, modify variable values, perform hot swaps, and invite / remove participants; Collaborative debugger: Can perform all debugging operations except inviting / removing participants, and its operations will be synchronized to all participants; Read-only observers can only view the debug environment (breakpoint locations, variable values, console output) and cannot execute any debug commands; When a participant joins via a shared URL, the Session-Broker service queries the roleMap based on the session ID in the URL to determine the user's role and embeds the role information into the WebSocket connection context. Before forwarding user operation commands, the Debug Adapter process verifies whether the user has the corresponding permissions. If the permissions are insufficient, it refuses to execute the command and returns an error message. Exception handling and session cleanup: When a debug session ends (e.g., xxx actively disconnects or times out), the Debug Adapter process terminates; the JDWP-Secure-Gateway reverse proxy detects the connection closure and notifies the Session-Broker service to immediately invalidate the authentication token for that session; the Session-Broker service updates the state of the session in Redis and closes all associated WebSocket connections; after receiving the disconnection notification, the participant's browser prompts the user that the session has ended.

[0033] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0034] like Figure 2 As shown, the following are embodiments of the Java online remote debugging system based on Code-Server provided in this disclosure. This system and the Java online remote debugging methods based on Code-Server in the above embodiments belong to the same inventive concept. For details not described in detail in the embodiments of the Java online remote debugging system based on Code-Server, please refer to the embodiments of the Java online remote debugging methods based on Code-Server described above.

[0035] The system includes: The Code-Server environment is used to load Java debugging extension packages that include the Debug Adapter startup module; A browser client used to send debugging requests to the Code-Server environment; The Debug Adapter process is started by the Java Debug Extension Package in response to a debug request; The Session-Broker service communicates with the Debug Adapter process to receive session creation requests and return session information containing the session identifier and authentication token. JDWP-Secure-Gateway reverse proxy communicates with the Debug Adapter process and the target JVM that has a preloaded Java debug agent to establish a secure JDWP connection with the target JVM based on an authentication token; The Debug Adapter process is also used to send bytecode hot-swap instructions to the Java debugging agent via JDWP connection, and to obtain debugging data via JDWP connection and send it to the Session-Broker service; The Session-Broker service is also used to synchronize debugging data in real time to various browser clients participating in the same debugging session based on the session identifier.

[0036] This embodiment achieves efficient remote Java debugging with zero local dependencies, protection against port exposure risks, support for hot bytecode replacement, and real-time collaboration across multiple devices through the interactive collaboration of the Code-Server environment, browser client, Debug Adapter process, Session-Broker service, and JDWP-Secure-Gateway reverse proxy. By building a Code-Server debugging ecosystem and security gateway, it enables real-time collaboration across multiple devices.

[0037] Furthermore, as a refinement and extension of the specific implementation methods described above, and to fully illustrate the specific implementation process in this embodiment, another Java online remote debugging system based on Code-Server is provided. This system includes: The Code-Server environment is used to load Java debugging extension packages that include the Debug Adapter startup module; The Code-Server environment, as a web-based version of VS Code, runs on a cloud server (such as a Pod in a Kubernetes cluster) and provides a browser-based code editing and debugging interface. When it starts up, it loads the Java debugging extension package (VSIX format) via the --install-extension command, enabling the Code-Server environment to have Java debugging capabilities. The Java Debugging Extension Package contains three core modules: The java-debugger-core module is responsible for starting and managing the Debug Adapter process. This module registers the Java debugging type in the Code-Server's debugging configuration and specifies the entry script for the Debug Adapter. When a user starts debugging, this module starts the Debug Adapter as an independent child process and communicates with it through the standard input / output stdio channel. The java-hotswap-agent module includes a built-in hot-swap agent, hotswap-helper.jar, and corresponding startup configuration templates. This module injects the agent via the -javaagent parameter when the target JVM starts, enabling interaction with the Debug Adapter and supporting millisecond-level class redefinition. The java-session-share module registers the Share Debug Session command in the Code-Server environment status bar. When a user clicks this command, the module calls the Session-Broker service's session creation interface to generate a shared link and provides a session role management interface, supporting setting participants as collaborative debuggers or read-only observers. A browser client used to send debugging requests to the Code-Server environment; The Debug Adapter process is started by the Java Debug Extension Package in response to a debug request; The Session-Broker service communicates with the Debug Adapter process to receive session creation requests and return session information containing the session identifier and authentication token. The Session-Broker service is implemented in Go and relies on Redis as session storage and event streaming channel; its core services include: The SessionManager sub-service handles the CreateSession call; input parameters include userID, session expiration time (expireSec), and initialRoleMap; the service internally generates a globally unique session identifier (sessionID), such as a UUID, and an authentication token; the authentication token generation algorithm is as follows: Token=Base64URL(SHA256(sessionID||userID||timestamp|| random_nonce ) ) Here, timestamp is the current Unix timestamp, and random_nonce is a 32-byte safe random number; then, {sessionID,owner,createAt,token,roleMap} is stored in Redis as a hash table with the key session:{sessionID} and the expiration time is set to expireSec; finally, the sessionID and token are returned to the caller. The TokenValidator sub-service provides the ValidateToken interface, which accepts the authentication token as input, queries Redis by parsing the sessionID in the authentication token, and verifies whether the authentication token exists, whether it matches the stored value, and whether it has not expired; the verification result returns a boolean value. In addition, the Session-Broker service has a built-in WebSocket proxy function to distribute debug data to multiple participants in real time; JDWP-Secure-Gateway reverse proxy communicates with the Debug Adapter process and the target JVM that has a preloaded Java debug agent to establish a secure JDWP connection with the target JVM based on an authentication token; JDWP-Secure-Gateway, as a standalone reverse proxy service, is deployed between the Debug Adapter process and the target JVM; its core responsibilities are as follows: TLS encryption establishes a TLS encrypted channel with the Debug Adapter to ensure that JDWP data streams are not eavesdropped on or tampered with during transmission; Token authentication extracts the authentication token from the first data packet sent by the Debug Adapter process during the connection establishment phase and calls the TokenValidator interface of the Session-Broker service to verify its validity; only connections that pass the verification are allowed to forward subsequent data. Data forwarding decrypts encrypted data from the TLS encrypted channel and forwards it in plaintext to the target JVM's debug port (default 5005) using the JDWP protocol; reverse forwarding works similarly. When the Debug Adapter process terminates, disconnects, or the debug session times out, it actively notifies the Session-Broker service to invalidate the corresponding authentication token and clean up resources. In this way, the traditional unprotected JDWP port is completely hidden, and all debugging traffic must be encrypted and authenticated, fundamentally eliminating the security risks caused by port exposure. The Debug Adapter process is also used to send bytecode hot-swap instructions to the Java debugging agent via JDWP connection, and to obtain debugging data via JDWP connection and send it to the Session-Broker service; The Session-Broker service is also used to synchronize debugging data in real time to various browser clients participating in the same debugging session based on the session identifier; The following JVM parameters need to be added when the target JVM starts to enable the JDWP debugging service and load the hot-swap agent: -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005: Enables the JDWP debugging port; -javaagent: / path / to / hotswap-helper.jar: Loads the hot swap agent, which implements the ClassFileTransformer interface to receive and execute class redefinition instructions.

[0038] The above description of the disclosed embodiments enables those skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A Java online remote debugging method based on Code-Server, characterized in that, Includes the following steps: S1. Load the Java debugging extension package containing the Debug Adapter startup module in the Code-Server environment; S2. In response to a debugging request from the browser, the Debug Adapter process is started by calling the Debug Adapter startup module through the Java Debug Extension Package; The S3.Debug Adapter process requests and obtains session information, including the session identifier and authentication token, from the Session-Broker service. S4. Based on the authentication token, the Debug Adapter process establishes a secure JDWP connection with the target JVM that has preloaded the Java debugging agent through the JDWP-Secure-Gateway reverse proxy, and sends bytecode hot-swap instructions to the Java debugging agent through the JDWP connection; The S5.Debug Adapter process sends the debug data obtained through the JDWP connection to the Session-Broker service; The S6.Session-Broker service synchronizes debug data in real time to various browser clients participating in the same debug session based on session identifiers.

2. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, The specific steps of step S1 are as follows: S11. Build the Java debugging extension package into a VSIX package, wherein the VSIX package includes the java-debugger-core module, the java-hotswap-agent module, and the java-session-share module; S12. When the Code-Server environment starts, install the VSIX package using the --install-extension command; S13. After installation, the VSIX package injects the functionality of the java-debugger-core module, java-hotswap-agent module, and java-session-share module into the debugging environment of the Code-Server environment. Among them, the java-debugger-core module is used by the Debug Adapter process to start.

3. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, The specific steps of step S2 are as follows: S21. After startup, the Debug Adapter process establishes communication with the Code-Server environment through the standard input / output stdio channel; S22. The Debug Adapter process receives debugging commands from the Code-Server environment according to the Debug Adapter Protocol; S23. The Debug Adapter process converts received debug commands from the Debug Adapter Protocol into JDWP protocol commands.

4. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, The specific steps of step S3 are as follows: S31. The Debug Adapter process sends a session creation request to the Session-Broker service. The session request includes the user ID, the session expiration time expireSec, and the initial role mapping initialRoleMap. The S32.Session-Broker service generates a unique session identifier (sessionID) and a random authentication token based on the session request, and determines the following fields: `owner` takes the value of the user ID, which represents the session owner. `createAt` takes the current system timestamp, indicating the session creation time. roleMap takes the value initialRoleMap, which represents the role mapping; If the initial role map (initialRoleMap) is not provided, a default role map is generated, which contains at least an entry that maps the session owner to the owner role. The algorithm for generating the authentication token is as follows: Token=Base64URL(SHA256(sessionID||userID||timestamp||random_nonce)) Where sessionID is the session identifier, userID is the user identifier, timestamp is the current timestamp, random_nonce is a random number of a specified number of bytes generated by a secure random number generator, and || represents a string concatenation operation; The S33.Session-Broker service stores session information, including session ID, owner, createAt, authentication token, and role map, in a Redis database. The S34.Session-Broker service returns the generated session ID and authentication token to the DebugAdapter process.

5. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, The specific steps of step S4 are as follows: S41. The JDWP-Secure-Gateway reverse proxy receives connection requests from the Debug Adapter process, and the connection requests carry an authentication token. S42. The JDWP-Secure-Gateway reverse proxy calls the TokenValidator interface of the Session-Broker service to verify the validity of the authentication token; S43. After successful verification, the JDWP-Secure-Gateway reverse proxy establishes a TLS encrypted channel with the Debug Adapter process and forwards the JDWP data stream sent by the Debug Adapter process to the debug port of the target JVM through the TLS encrypted channel; The S44.Debug Adapter process sends bytecode hot-swap instructions to the Java debug agent of the target JVM through the established JDWP connection; S45. After the debug session ends, the JDWP-Secure-Gateway reverse proxy notifies the Session-Broker service to invalidate the authentication token used in this session.

6. The Java online remote debugging method based on Code-Server according to claim 5, characterized in that, The specific steps of step S44 are as follows: S441. In response to the user saving the modified Java class file on the browser, the Code-Server environment sends the compiled bytecode data to the Debug Adapter process; The S442.Debug Adapter process sends a class redefinition request to the target JVM via the JDWP protocol. The class redefinition request contains the class name to be replaced and the corresponding new bytecode. S443. After receiving the request, the Java debugging agent of the target JVM calls the redefineClasses function of the target JVM to perform hot replacement of bytecode and returns the replacement result to the Debug Adapter process; The S444.Debug Adapter process sends the hot-swap results to the Session-Broker service for synchronization.

7. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, The specific steps of step S5 are as follows: The S51.Debug Adapter process obtains debugging data of the target JVM through JDWP connection. The debugging data includes at least one of breakpoint events, variable values, and call stack information. The S52.Debug Adapter process encapsulates the acquired debug data into a format conforming to the Debug Adapter Protocol. The S53.Debug Adapter process sends the encapsulated debug data to the Session-Broker service.

8. The Java online remote debugging method based on Code-Server according to claim 4, characterized in that, The specific steps of step S6 are as follows: The S61.Session-Broker service receives WebSocket connection requests initiated by participant browsers by accessing a URL containing the session ID; The S62.Session-Broker service queries session information from the Redis database based on the session identifier (sessionID) to verify whether the session exists and is valid. S63. After successful verification, the Session-Broker service will reverse proxy the WebSocket connection to the stdio port of the corresponding DebugAdapter process; The S64.Session-Broker service pushes the debug data received in step S5 to the browsers of all connected participants in real time via a WebSocket connection.

9. The Java online remote debugging method based on Code-Server according to claim 1, characterized in that, It also includes the following steps: The S7.Debug Adapter process performs debugging operations; S8. Debug Adapter process execution log replay; The specific steps of step S7 are as follows: S71. In response to the user's breakpoint setting operation on the browser, the Debug Adapter process sends a breakpoint setting request to the target JVM via the JDWP protocol; S72. When the target JVM hits a breakpoint, the Debug Adapter process receives the breakpoint event sent by the target JVM via the JDWP protocol and converts it into a DAP protocol breakpoint event; S73. The Debug Adapter process sends the converted DAP protocol breakpoint events to the Session-Broker service so that they can be synchronized to various browser clients via step S6. S74. In response to the user's variable viewing operation on the browser, the Debug Adapter process sends a stack frame variable request to the target JVM through the JDWP protocol, receives the variable value returned by the target JVM, and then sends the variable value to the Session-Broker service for synchronization. The specific steps of step S8 are as follows: S81. In response to a user's time-travel-style history breakpoint replay request, the Debug Adapter process requests historical debug data at the specified breakpoint from the Session-Broker service; The S82.Session-Broker service queries the Redis database for the historical debug event stream associated with the current session identifier (sessionID). The historical debug event stream includes the thread context, variable snapshot, and call stack information at the time the breakpoint was hit. The S83.Session-Broker service returns the retrieved historical debug data to the Debug Adapter process; The S84.Debug Adapter process pushes historical debug data to the browser client for display via a WebSocket connection.

10. A Java online remote debugging system based on Code-Server, characterized in that, include: The Code-Server environment is used to load Java debugging extension packages that include the Debug Adapter startup module; A browser client used to send debugging requests to the Code-Server environment; The Debug Adapter process is started by the Java Debug Extension Package in response to a debug request; The Session-Broker service communicates with the Debug Adapter process to receive session creation requests and return session information containing the session identifier and authentication token. JDWP-Secure-Gateway reverse proxy communicates with the Debug Adapter process and the target JVM that has a preloaded Java debug agent to establish a secure JDWP connection with the target JVM based on an authentication token; The Debug Adapter process is also used to send bytecode hot-swap instructions to the Java debugging agent via JDWP connection, and to obtain debugging data via JDWP connection and send it to the Session-Broker service; The Session-Broker service is also used to synchronize debugging data in real time to various browser clients participating in the same debugging session based on the session identifier.

Images