Java file automatic compiling and uploading method and device

Abstract

The application discloses a kind of java file automatic compilation upload method and device, the method includes: through IDE multiple entry interactive mode receives the file set selected by user and completes java source file and the classification identification of non-java file;Java source file is constructed to simulate compilation context Trigger Incremental Compilation, project module structure is dynamically calculated bytecode file path in combination and is supplemented with cache optimization and path verification;Build the file list to be uploaded, upload the source file and bytecode file of java file simultaneously, only upload itself to non-java file;According to the server information of preconfiguration, file is uploaded to remote server.The device includes file processing module, compilation control module, upload execution module and man-machine interaction and feedback module, for synergistically implement the method.The scheme realizes the automation, integrated processing of java file compilation and upload, improves development deployment efficiency, optimizes user interaction experience, applicable to various IDE-based java project development scenarios.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a method and apparatus for automatically compiling and uploading Java files based on the IntelliJ platform. Background Technology

[0002] During software development, developers often need to upload locally written code files or compiled bytecode files to test or deployment servers. This process typically involves multiple steps, such as file compilation, server connection, and file transfer. Relying on external tools or manual operation is not only cumbersome but also prone to errors that could lead to missing files or incompatible file versions.

[0003] Currently, the same issue exists in the IntelliJ IDEA Community Edition. Developers typically need to manually perform the compilation operation first, and then use third-party FTP / SFTP tools (such as Xftp) or command-line tools to upload files. This method has problems such as multiple operation steps, low efficiency, inability to automatically associate compilation status, and lack of support for unified processing of mixed file types. Especially in multi-module microservice projects, it is difficult to quickly locate and upload the compilation output files of the corresponding module.

[0004] While some general-purpose FTP / SFTP client tools exist in the current technology, none of them are deeply integrated with IDEs and cannot automatically trigger compilation operations before file upload. Furthermore, these tools typically require users to manually configure server information and select upload paths, failing to achieve one-click uploads, and they do not provide auxiliary functions such as upload logs, error feedback, and file navigation within the IDE.

[0005] Therefore, existing technologies suffer from problems such as cumbersome operation, low efficiency, and lack of a compilation and upload linkage mechanism. There is an urgent need for a file upload method that can be deeply integrated with IDEs, support automatic upload after compilation, and provide a good user interaction experience. Summary of the Invention

[0006] To address the problems of cumbersome operation, low efficiency, and lack of compilation and upload linkage mechanism in existing technologies, this invention provides a method and device for automatic compilation and upload of Java files. It is mainly used in the software development process to help developers quickly and conveniently upload local files to remote servers, and is especially suitable for scenarios in Java project development where source files and compilation artifacts need to be uploaded frequently.

[0007] In a first aspect, this invention provides a method for automatically compiling and uploading Java files, integrated into an integrated development environment (IDE), comprising the following steps:

[0008] S1: File Selection and Type Recognition

[0009] The IDE receives the user-selected file set through a multi-entry interaction mechanism, which includes right-click menu items in the IDE project structure view, right-click menu in the editor, and main toolbar buttons.

[0010] It receives a collection of VirtualFile[] objects from the IDE event system, identifies file types using the getExtension() method, and supports simultaneous selection of Java source files and non-Java files with automatic classification and processing.

[0011] Use ApplicationManager.getApplication().executeOnPooledThread() to start a background thread for asynchronous preprocessing to avoid UI blocking;

[0012] S2: Automatic compilation of Java files and bytecode path location:

[0013] When a Java source file is identified, the compilation action is obtained through ActionManager.getInstance().getAction(Compile), and the AnActionEvent event mechanism is used to construct a simulated compilation context containing only the selected Java source file, triggering incremental compilation.

[0014] During compilation, ModuleUtilCore.findModuleForFile(virtualFile,project) is called to locate the module to which the file belongs. ModuleRootManager.getContentEntries() is used to parse the Maven / Gradle project output path or read the module's custom output path. Combined with ProjectRootManager.getSourceRoots(), the relative path of the source file is calculated. The .java extension is replaced with .class and concatenated with the module's output directory to generate the complete storage path of the bytecode file.

[0015] S3: Generating a mixed file list:

[0016] Construct a unified list of files to be uploaded, design the UploadItem data structure to uniformly encapsulate file information, and for Java source files, include both the source file path and the corresponding bytecode file path;

[0017] For non-Java files, only their own paths are included to form a structured upload list;

[0018] S4: Server connection and file transfer:

[0019] By implementing the PersistentStateComponent interface, FTP / SFTP server configuration information is persistently stored at the application level in XML format, enabling cross-project sharing.

[0020] The upload interface displays a list of stored servers. By default, the server configuration that the user last successfully used is selected. Based on the selected server protocol type, the corresponding library is used to establish a connection and complete identity authentication. The list of files to be uploaded is traversed and all files are transferred to the specified directory on the server. The connection is automatically disconnected after the transfer is completed.

[0021] S5: Upload Result Feedback:

[0022] By implementing ToolWindowFactory to create an IDE-specific console tool window, and using TextConsoleBuilder to build the console view, a structured upload log containing timestamps, file paths, and transfer status is output in real time. The file paths in the log are formatted as clickable hyperlinks, and success and failure information are highlighted with different colors.

[0023] As a further aspect of the present invention, S2 also includes establishing a module output directory caching mechanism: using a key-value pair data structure to cache the mapping relationship between module objects and their compilation output directories, so that when performing path calculations on Java source files within the same module, the output directory can be read directly from the cache to avoid repeated queries.

[0024] As a further aspect of the present invention, S2 also includes a path pre-calculation and verification step: before triggering compilation, the expected bytecode file paths corresponding to all Java source files are pre-calculated; after compilation, the existence of the expected paths is verified, and if the verification fails, error information is output to the console and interactive processing options are provided.

[0025] As a further aspect of the present invention, the method also includes persistent management of server configuration: by implementing the persistent state component interface provided by the IDE, the server configuration information is stored in an application-level manner, supporting sharing across all projects; the stored server list is automatically loaded in the upload interface, and the server configuration last successfully used by the user is selected by default.

[0026] As a further aspect of the present invention, the method further includes a server connection test function before file transfer: a connection test entry is provided in the server configuration interface, and the connection test is performed using the corresponding authentication method according to the selected protocol type to verify the validity of the configuration.

[0027] Secondly, this invention provides a Java file automatic compilation and uploading device, integrated into an integrated development environment (IDE), comprising:

[0028] The file processing module includes:

[0029] Configuration Management Unit: Used to receive and persistently store server connection parameters configured by the user, and provide functions for adding, deleting, modifying, querying server configurations and connection testing; File Selection and Type Recognition Unit: Used to receive the set of files selected by the user through multiple interactive methods such as the IDE's project structure view and editor menu, and to identify Java source files and non-Java files based on file extensions;

[0030] The compilation control module includes:

[0031] Compilation triggering unit: When a Java source file is identified, it obtains the compilation action by calling the IDE's ActionManager interface, constructs a simulated compilation context containing only the selected Java source file, and triggers an incremental compilation operation for the Java source file; Path positioning unit: After compilation is completed, it obtains the compilation output directory of the module to which the Java source file belongs by querying the IDE's module management API, calculates the target bytecode file path based on the relative path of the Java source file relative to the source code root directory, and concatenates the module output directory with the relative path to generate the complete absolute path of the bytecode file;

[0032] The upload execution module includes:

[0033] Upload list construction unit: used to construct a unified list of uploaded files based on the file recognition results. For Java source files, it includes both the source file path and the corresponding bytecode file path. For non-Java files, it only includes their own path. File transfer unit: used to establish a network connection with a remote FTP or SFTP server based on the server configuration selected by the user, and transfer all files in the upload file list to the specified directory on the remote server.

[0034] The human-computer interaction and feedback module includes:

[0035] Upload Interface Unit: Provides a graphical upload interface, displaying the user's configured server list and the information of the last selected server; Log Feedback Unit: Creates a dedicated view in the IDE's console, outputting upload logs in real time, including timestamps and file status, and formatting file paths in the logs into interactive hyperlinks, allowing users to click to jump to the source file for editing or re-uploading.

[0036] As a further aspect of the present invention, the device also includes a state management module: used to store server configuration information and the user's last operation selection in an application-level persistent manner by implementing the IDE's PersistentStateComponent interface, thereby realizing cross-project sharing and memory functions of configuration.

[0037] As a further embodiment of the present invention, the path location unit further includes: a cache subunit: used to establish and maintain a cache table of the module compilation output directory. When the output directory of the same module needs to be obtained multiple times, it can be read directly from the cache to reduce the performance overhead caused by repeated API calls.

[0038] As a further aspect of the present invention, the file transfer unit supports multiple authentication methods: for the SFTP protocol, SSH key authentication is used; for the FTP protocol, username and password authentication and anonymous login are supported.

[0039] The Java file automatic compilation and upload method provided in this application addresses the core pain points of traditional code deployment processes, such as cumbersome operations, low efficiency, and error-proneness. By deeply integrating IDE underlying capabilities and building an automated pipeline, it achieves a series of interconnected and progressively improving technical effects. Its inherent logic and consistency are reflected in the following aspects:

[0040] Technical benefit 1: Enables incremental compilation of Java files and precise bytecode path location, significantly improving compilation and uploading efficiency and accuracy.

[0041] Existing IDE plugins or external tools generally lack the ability to incrementally compile selected Java files, and mostly rely on full project compilation or manual compilation, resulting in long compilation times and wasted resources. At the same time, existing technologies cannot automatically and accurately locate the compilation output bytecode file path corresponding to the selected Java source file after compilation, which is especially prone to file misalignment or omission in multi-module and complex build systems.

[0042] This application constructs a complete compilation-location closed loop through three layers of technical means. First, at the compilation triggering level, a precise event simulation mechanism is adopted—the underlying compilation actions of the IDE are obtained through `ActionManager.getInstance().getAction(Compile)`, and a simulated compilation context (DataContext) containing only the selected Java file is constructed using the `AnActionEvent` event mechanism. This design directly interfaces with the IDE's native compilation system, realizing true incremental compilation: the system only compiles the .java files selected by the user, avoiding the resource consumption of compiling the entire project, and shortening the traditional full compilation that takes several minutes to complete within seconds. The core logic of this mechanism lies in precise triggering. By simulating the user's behavior in performing compilation operations, it causes the IDE's compilation engine to process only the target file and its minimal dependencies, rather than the entire module or project, thereby significantly improving compilation efficiency at the source.

[0043] Secondly, at the path location level, a multi-level mapping system from source files to bytecode files is established. During execution, the system precisely locates the module to which each source file belongs using `ModuleUtilCore.findModuleForFile(virtualFile, project)`, a crucial first step in avoiding path confusion in multi-module projects. Then, for projects using different build tools such as Maven and Gradle, the system dynamically resolves the module's compilation output directory (e.g., `target / classes`, `build / classes / java / main`) using `ModuleRootManager.getContentEntries()`. This process takes into account the differences in output directories between different build tools and the possibility of user-defined configurations. After determining the module's output directory, the system calculates the relative path of the source file to the source code root directory, replaces the `.java` suffix in the path with `.class`, and finally concatenates it with the module's output directory to form the complete target bytecode path. The brilliance of this path calculation logic lies in its universality and accuracy: it does not rely on fixed directory structure assumptions but dynamically adapts to the actual project configuration, ensuring that even in complex multi-module projects with mixed build tools, the correct compilation output for each Java file can be found.

[0044] Third, regarding performance optimization, this application incorporates an intelligent caching and pre-verification mechanism. The system uses ConcurrentHashMap.<Module,VirtualFile> The cached module output directory avoids repeatedly querying the IDE API for the same module during the same operation. Simultaneously, the expected paths of all target bytecode files are pre-calculated before compilation begins. After compilation, the existence of files under these paths is directly verified via VirtualFileManager, rather than traversing the entire output directory. This optimization significantly reduces file system operations and API call overhead, especially when handling a large number of files. This entire mechanism forms a closed technical loop of event-triggered compilation -> dynamic path calculation -> cached optimization verification, ultimately achieving a substantial improvement in overall efficiency from compilation to location while maintaining high accuracy.

[0045] Compared to traditional methods that require developers to manually perform compilation (potentially a full compilation) and then manually search for or guess the location of the corresponding bytecode file in a complex project output directory structure, this method achieves full automation and high precision in compilation triggering and path location. It not only frees users from tedious manual searching, but more importantly, it fundamentally eliminates problems caused by human error, such as uploading incorrect versions of bytecode files or omitting key bytecode files. This provides a reliable file foundation for subsequent testing and deployment, making it particularly suitable for agile development or microservice debugging scenarios that require frequent incremental code updates and deployments.

[0046] Technical benefit 2: Supports integrated processing and unified uploading of mixed file types, simplifying operations in multi-technology stack projects.

[0047] In modern projects that contain various file types, including Java files, configuration files, and front-end resources, existing tools lack a unified processing mechanism. Developers need to adopt different operation processes for Java files and non-Java files (e.g., Java files need to be compiled and then transferred as bytecode, while resource configuration files are directly transferred as source files), or use multiple tools to handle them separately, resulting in fragmented processes and cumbersome operations.

[0048] This application constructs a unified file processing pipeline that can intelligently identify and differentiate the processing of various file types. Technically, the system first receives the files selected by the user through the IDE's VirtualFile[] object collection and uses the getExtension() method to quickly identify the type of each file. This initial classification forms the basis of the entire mixed processing flow. Internally, the system designs a dedicated UploadItem data structure to establish a unified information encapsulation model for each file to be processed. This model includes key information such as local path, remote relative path, and file type identifier, as well as a bytecode file reference field specifically for Java files.

[0049] In terms of processing logic, the system implements a differentiated strategy based on file type: For files identified as .java, the system automatically triggers the aforementioned incremental compilation mechanism and performs precise bytecode path location after successful compilation. It's worth noting that the system creates two independent UploadItem objects for the source file path and corresponding bytecode file path of the same Java file, but ensures their order and correspondence during upload through an internal association mechanism. For non-Java files (such as .xml, .properties, .html, .js, etc.), the system adopts a direct upload strategy—directly creating an UploadItem from the file's own path, without additional compilation or conversion processing. After all processing is complete, the system integrates all UploadItems into a unified upload list, processed by a single upload execution engine.

[0050] The logical advantage of this technical approach lies in its unified front-end, intelligent back-end routing, and final aggregation architecture. From the user's perspective, the entire operation is completely consistent: select a batch of files -> click upload -> wait for completion. Internally, the system handles complex type identification, branching, and resource integration. Especially when dealing with scenarios involving a mix of Java and non-Java files, the system can correctly distinguish which files require compilation and which can be uploaded directly, ensuring that the compiled bytecode files maintain the correct correspondence with their source files. This intelligent processing capability is particularly well-suited to the diverse file types common in modern microservice architectures and full-stack projects. Developers no longer need to pre-classify files or perform multiple upload operations; the system automatically completes all necessary processing steps.

[0051] Traditional methods require developers to mentally and operationally distinguish file types, potentially switching between different tools or executing different commands. This method, through automated classification and process integration, achieves "what you see is what you upload." After a user selects a batch of files, whether they are pure Java files, pure resource files, or mixed files, all necessary files can be uploaded through a single operation, greatly simplifying file deployment operations in full-stack or microservice projects that contain multiple elements such as web resources, configurations, and Java code.

[0052] Technical benefit three: Provides deeply integrated visual feedback and console interaction, enhancing operational traceability and debugging convenience.

[0053] When using external FTP / SFTP tools for uploading, the operation process and result feedback are detached from the IDE, and the log information is scattered. When the upload fails or needs to be reviewed, it is difficult to quickly locate the specific local source file, resulting in low debugging efficiency.

[0054] This application constructs a visual feedback system deeply integrated into the IDE environment. This system not only provides real-time display of upload status but also establishes a direct operational link from feedback information to source code editing. Technically, the system implements the ToolWindowFactory interface to create a dedicated file upload console view in the bottom toolbar of the IDE. This console is not a simple text output area but a complete IDE tool window, supporting standard operations such as docking, hiding, and filtering, maintaining a consistent interactive experience with other development tools in the IDE (such as the terminal and run console).

[0055] In terms of log output, the system uses TextConsoleBuilder to build a structured log view. Each record contains a precise timestamp, a clear status indicator, and complete file path information. The status display uses a color-coding strategy: successfully uploaded files are marked in green (INFO level), and failed files are marked in red (ERROR level). This visual distinction allows users to instantly identify the operation result without having to read the text description carefully. More importantly, the system uses the printHyperlink() method to convert the file path in each log into a clickable hyperlink—this technical detail is based on the view-model binding mechanism in IDE plugin development. When a user clicks the hyperlink, the system can parse the corresponding local file path and call the IDE's editor API to open the file in the appropriate editor.

[0056] The core technical logic of this feedback system is operational transparency and problem traceability. The system outputs progress information in real time throughout the entire upload process: from connecting to the server, starting to transfer each file, completing the transfer, to finally disconnecting, each stage has corresponding log records. When a file upload fails, relevant error information (such as insufficient permissions, non-existent path, network timeout, etc.) is recorded in detail in the corresponding log entry. At this point, the user doesn't need to leave their current working environment; simply clicking the file hyperlink in the red error log will automatically navigate the IDE to the editor containing that file. Developers can immediately check the file content, correct the problem, and then re-execute the upload operation. This closed-loop feedback-correction process greatly shortens the problem-solving cycle, simplifying the debugging process that previously required repeatedly switching between the IDE and external tools into continuous operation within a single environment.

[0057] Compared to external tools that only provide simple success / failure messages or require opening separate log files for troubleshooting, this method offers immersive, interactive, and traceable feedback. When a file upload fails, developers don't need to leave the IDE or manually navigate through the project directory. They can simply click the file link in the corresponding red error log in the console to immediately jump to the problematic file for inspection and modification. They can then easily re-upload the file, forming a smooth closed loop of upload -> feedback -> location -> correction -> re-upload, greatly improving the efficiency of problem investigation and iteration.

[0058] Technical benefit 4: Enables persistent management and intelligent reuse of server configurations, reducing the cost of repetitive configuration.

[0059] Traditional methods require reconfiguring server connection information for each new project or environment, or rely on local configuration files that are not easy for teams to share, resulting in high management and maintenance costs.

[0060] The technical means and effects of this application are as follows: This application designs a layered configuration management system, which is optimized at the storage, management, and application levels. At the storage level, the system implements the PersistentStateComponent interface to store server configuration information at the IDE application level rather than the project level. The key logic behind this design decision is that, for most development scenarios, developers connect to relatively fixed test servers, pre-release environments, or production environments. These configurations are not related to specific projects but are related to the developer's work environment or team infrastructure. Application-level storage means that configuration information is persistently saved even after the IDE is closed and is shared and available in all open projects, avoiding the tedious operation of repeatedly configuring the same server for each project.

[0061] At the management level, the system provides a professional configuration management interface, built on DialogWrapper and Kotlin UIDSL. This interface is divided into a server list display area and a detailed configuration editing area. The list display area uses the ListModelEditor component encapsulated in the IDESDK, supporting CRUD operations on server configurations. The detailed editing area dynamically displays the corresponding configuration fields (such as host, port, authentication method, remote path, etc.) based on the selected protocol type (FTP / SFTP). Crucially, the system integrates a connection test function into the configuration interface. After a user creates or modifies a server configuration, they can immediately click the "Test Connection" button. The system will attempt to establish a connection based on the configuration information and return the connection result. The technical logic behind this function is to identify and resolve issues early in the configuration phase (such as network inaccessibility, authentication failure, insufficient path permissions, etc.), preventing configuration errors from being carried over to the actual upload operation and avoiding the need for retrospective troubleshooting after an operation fails.

[0062] At the application level, the system features an intelligent configuration reuse mechanism. Each time a user selects a server on the upload interface and successfully completes the upload, the system automatically records the last used server identifier. The next time the upload interface is opened, the system automatically selects this server as the default option. Behind this seemingly simple function lies a carefully designed user experience logic: developers typically connect to the same server repeatedly for multiple uploads within a work session, and automatically remembering the last selection reduces repetitive interface operations. Furthermore, the system also supports configuration import and export functions, facilitating the sharing of server configurations among team members or the migration of configurations between different development environments.

[0063] Compared to the need to maintain a separate .ftp configuration file for each project or repeatedly enter server information into external tools, this method achieves "configure once, use everywhere." For developers who frequently need to connect to fixed test servers or deployment environments, this avoids a significant amount of repetitive work. Simultaneously, application-level storage facilitates maintaining server environment consistency across multiple projects, reducing the risk of configuration errors. The connection testing function identifies problems early in the configuration phase, preventing failures due to configuration errors during uploads.

[0064] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0066] Figure 1 This is a flowchart of the method of the present invention;

[0067] Figure 2 This is a schematic diagram of the upload interface.

[0068] Figure 3 This is a diagram of the log upload console.

[0069] Figure 4 This is a schematic diagram of the principle of the device of the present invention.

[0070] Figure 5 This is a diagram of the server configuration interface. Detailed Implementation

[0071] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0072] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0073] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0074] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0075] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0076] This invention essentially provides an FTP / SFTP file upload plugin based on IntelliJPlatform, aiming to solve the technical problem that developers in the community edition of IntelliJ IDEA need to manually compile and use external tools to upload files to a remote server, and realize an automated pipeline operation of compilation, location and upload.

[0077] See Figure 1 This application provides a method for automatically compiling and uploading Java files. The core process of this method includes: file selection and recognition, automatic compilation and path location, upload list construction, server connection and transmission, and result feedback.

[0078] S1: File Selection and Type Recognition

[0079] This step utilizes the multi-entry interaction mechanism of the Integrated Development Environment (IDE) to achieve file selection and type identification, specifically including:

[0080] Interaction entry point:

[0081] Right-click menu items in the IDE project structure view;

[0082] Right-click menu within the editor (supports operations on the currently open file or multiple selected files);

[0083] Main toolbar button (supports one-click upload of recently modified or selected files).

[0084] File object parsing: Receives a collection of VirtualFile[] objects passed by the IDE event system and quickly identifies the file type using the getExtension() method.

[0085] Mixed selection support: Supports simultaneous selection of Java source files (.java) and non-Java files (such as .xml, .properties, .html, etc.), with automatic categorization and processing by the system.

[0086] Asynchronous preprocessing: To prevent UI blocking, after receiving the file collection, ApplicationManager.getApplication().executeOnPooledThread() is used to start a background thread for preliminary screening and identification.

[0087] S2: Automatic compilation of Java files and bytecode path location

[0088] This step performs incremental compilation of the selected Java file and precisely locates the path of the generated bytecode file:

[0089] 1. Incremental compilation triggered:

[0090] The compilation action can be obtained through ActionManager.getInstance().getAction(Compile).

[0091] By using the AnActionEvent mechanism, a simulated compilation context (DataContext) is constructed, which triggers incremental compilation only for the selected Java files, avoiding full project compilation and improving efficiency.

[0092] 2. Precise bytecode path location:

[0093] Module location: Call ModuleUtilCore.findModuleForFile(virtualFile,project) to accurately obtain the module to which the file belongs.

[0094] Output directory retrieval:

[0095] For Maven / Gradle projects, the output path (such as target / classes, build / classes / java / main) is resolved using ModuleRootManager.getContentEntries().

[0096] Supports custom output path configuration (read via module settings).

[0097] Relative path calculation:

[0098] Get the absolute path of the source file using VirtualFile.getPath().

[0099] Use ProjectRootManager.getSourceRoots() to match the source code root directory and calculate the relative path.

[0100] Execution path conversion: Replace .java with .class and concatenate it with the module output directory to generate the absolute path of the final bytecode file.

[0101] 3. Performance and fault tolerance optimization:

[0102] Module-level caching: Designing ConcurrentHashMap<Module,VirtualFile> The cache module output directory is used to avoid duplicate queries.

[0103] Path pre-computation: Calculate possible target paths before compilation and verify them directly after compilation, reducing I / O wait.

[0104] Fault tolerance:

[0105] If compilation fails, detailed error information (such as syntax errors or missing dependencies) will be output to the log console.

[0106] If the .class file is not generated, interactive options are provided to retry compilation or skip the file.

[0107] S3: Hybrid Upload List Construction

[0108] Based on the file recognition results, a final upload list is constructed, ensuring that Java files and their bytecode files, as well as non-Java files, are included:

[0109] List building strategy:

[0110] For Java files: add their source file path and the calculated bytecode file path to the list.

[0111] For non-Java files (such as .xml, .html, configuration files, etc.): only their own paths are added to the list.

[0112] Structured upload list:

[0113] Design an internal data structure, UploadItem, to uniformly encapsulate uploaded file information:

[0114] Java

[0115] public class UploadItem{

[0116] VirtualFilesourceFile; / / Source file (required)

[0117] String localPath; / / Local absolute path

[0118] String remoteRelativePath; / / Remote relative path (calculated based on configuration)

[0119] boolean asjavaFile; / / Whether it is a Java file

[0120] VirtualFileclassFile; / / Bytecode file (only present in Java files)

[0121] }

[0122] This will eventually result in a list containing all the files that need to be uploaded.

[0123] S4: Server Connection and File Transfer

[0124] This step establishes a connection and completes the file upload based on the user's preset server configuration:

[0125] 1. Configuration Persistence: The FTP / SFTP server parameters (protocol, host, port, authentication information, remote path, etc.) set by the user through the configuration interface are persistently stored at the application level in XML format by implementing the PersistentStateComponent interface, enabling cross-project sharing.

[0126] 2. Connection and Upload:

[0127] The upload interface displays a list of stored servers, with the last server used by the user selected by default.

[0128] After user confirmation, the plugin selects the appropriate library (such as JSchforSFTP or ApacheCommonsNetforFTP) to establish a connection and perform authentication (supporting SSH key, password, and anonymous login) based on the protocol type of the selected server.

[0129] Iterate through the upload list and transfer files to the specified remote directory. The connection will automatically disconnect upon completion of the transfer.

[0130] Upload interface design (e.g.) Figure 2 (as shown)

[0131] The interface is a modal dialog box, which is simple and clear.

[0132] The top section is a server selection dropdown (comboBox) that displays a list of all configured servers and allows selection.

[0133] The display area below shows the main configuration information of the currently selected server (such as host address and remote path) in read-only text boxes for confirmation purposes.

[0134] The bottom contains operation buttons (upload, cancel).

[0135] This design greatly simplifies the user experience.

[0136] S5: Feedback on Upload Results

[0137] The upload process and results are output in real time to a dedicated console tool window within the IDE, providing clear interactive feedback:

[0138] Console creation: Create a dedicated console tool window by implementing ToolWindowFactory.

[0139] Log output:

[0140] Use TextConsoleBuilder to create a console view.

[0141] Each log entry includes the time, file path, and status (success / failure).

[0142] The file path is formatted as a clickable hyperlink using printHyperlink(), allowing users to quickly open the corresponding file in the editor after clicking, facilitating review or re-uploading.

[0143] Success and failure messages are highlighted in different colors (such as green INFO and red ERROR) for easy and quick identification.

[0144] Screenshot of the log upload console (e.g.) Figure 3 (as shown)

[0145] The console is embedded in the tool window bar at the bottom of the IDE.

[0146] Logs are line-by-line, and each record includes a timestamp, status icon (or colored background), and file path.

[0147] File paths are displayed as clickable blue hyperlinks.

[0148] Successful messages are displayed in green font or with an icon, while failed messages are displayed in red font or with an icon. This clear hierarchy makes it easy for users to quickly obtain upload results and perform interactive operations.

[0149] 1. Evolution and Implementation of Configuration File Persistence Schemes

[0150] In the early stages of plugin design, it was planned to generate a separate configuration file (e.g., .ftp or .uploadsettings file) for each project to achieve project-level storage of server connection information. This approach facilitates configuration management along with project versioning and is suitable for scenarios with high requirements for configuration isolation.

[0151] However, requirements analysis revealed that developers often need to reuse the same server configurations across different projects. Configuring each project separately would lead to repetitive operations and reduced efficiency. Therefore, an application-level persistent storage solution was ultimately adopted. By implementing the PersistentStateComponent interface, server configurations are stored in XML format within the IDE's application-level settings, enabling cross-project sharing and unified maintenance of configurations.

[0152] To accommodate specific project configuration needs, the plugin retains the ability to detect and create project-level configuration files. The specific implementation is as follows:

[0153] 1) Configuration file path construction

[0154] The project root directory path is obtained through the Project object and concatenated with a preset configuration file name (such as .ftp) to generate the complete path of the configuration file.

[0155] 2) Verification of the existence of configuration files

[0156] Use the LocalFileSystem.getInstance().findFileByIoFile() method to check if the configuration file exists in the project structure.

[0157] 3) Configuration files are generated on demand.

[0158] If the configuration file does not exist, the `FileTemplateUtil.createFromTemplate()` method is called to dynamically generate a configuration file based on a predefined template. This method relies on the IntelliJ platform's file template mechanism to quickly create structured configuration files, simplifying the user initialization process.

[0159] This design supports unified management and sharing of application-level configurations while retaining the flexible expansion capabilities of project-level configurations, adapting to the diverse configuration management needs of different teams and projects.

[0160] 2. Server Configuration Management Interface Design and Implementation

[0161] This plugin provides two independent server configuration management interfaces: an upload interface and a configuration management interface. Both are built as modal dialogs based on DialogWrapper and use declarative components provided by KotlinUIDSLSDK to build the user interface.

[0162] Upload interface example:

[0163] The upload interface is designed to be simple and practical. Its main function is to quickly select the configured server and display its key information, so that users can confirm and then perform the upload operation.

[0164] Server selection: Displays a list of all persistent server configurations via the comboBox component, with the server last used by the user selected by default.

[0165] Configuration information display: The textField component is used to display the upload target address (remote path) of the currently selected server and set it to read-only to prevent accidental operation.

[0166] Interface layout: It adopts a vertical stacked layout, with a server selection box at the top, a read-only information display area at the bottom, and "upload" and "cancel" operation buttons at the bottom.

[0167] Example of configuration management interface:

[0168] The configuration management interface is divided into two main functional areas, supporting centralized management and detailed editing of the server list.

[0169] Server list display area: The ListModelEditor component, which is encapsulated in the SDK, displays a list of stored server configurations. It supports operations such as adding, deleting, and sorting list items and provides a clear list view.

[0170] Configuration editing area: A form-based editing interface is built using various input components provided by KotlinUIDSLSDK. It supports editing the connection parameters of the currently selected server item, including: protocol type (FTP / SFTP); host address; port; authentication method (username / password, SSH key, anonymous login, etc.); remote path.

[0171] Connection test function: A "Connection Test" button is integrated into the editing area to verify whether the currently configured server connection is valid.

[0172] SFTP protocol: Implemented based on SSH secure channels, using the JSch library to establish session connections. During testing, the host key is automatically accepted upon the first connection (for development and testing environments only, not applicable to production servers). Authentication methods support both passwords and SSH keys, without requiring SSL / TLS.

[0173] FTP protocol: Supports anonymous login (no username and password required), and can also be authenticated using a username / password. During testing, establish an FTP connection and attempt to access the specified path to verify the configuration's validity.

[0174] Test results are displayed instantly via pop-up windows, helping users quickly troubleshoot configuration issues.

[0175] Both interfaces utilize DialogWrapper to implement modal behavior, ensuring a clear interaction flow that conforms to IDE operating habits. The adoption of KotlinUIDSL makes interface construction concise and efficient, while maintaining good maintainability and extensibility. Configuration data reading and writing are implemented through persistent components, ensuring that user settings are retained across different sessions.

[0176] To ensure user convenience, the upload interface features persistent storage of server selection status. After a user selects a server and performs an upload, the plugin automatically records this selection and restores the previously selected server upon subsequent access to the upload interface, preventing duplicate selections.

[0177] 3. Persistent storage of plugins

[0178] The plugin's persistent storage adopts a state management model, divided into two levels: project-level and application-level. This invention uses an application-level persistence scheme to ensure that the server's selected state remains consistent across different projects, improving configuration reusability and user experience.

[0179] Application-level service registration and lifecycle:

[0180] Service registration: Register application-level persistent services in the extension node of the plugin.xml core file and declare components that implement the PersistentStateComponent interface.

[0181] Lifecycle: This service persists while the IDE is running, and its lifecycle is consistent with the application's. Persistent data is automatically loaded upon service startup and automatically saved upon shutdown, ensuring that state information remains valid across sessions.

[0182] State preservation mechanism implementation:

[0183] When a user selects a server and clicks the "Upload" button on the upload interface, the plugin triggers a state saving process:

[0184] 1) Call the registered application-level persistence service to obtain the current state object.

[0185] 2) Write the unique identifier (such as configuration name or ID) of the server selected by the user into the status object.

[0186] 3) The state information is persistently stored in the IDE configuration file through the state serialization mechanism provided by PersistentStateComponent.

[0187] State recovery mechanism:

[0188] The plugin automatically performs the following actions each time the upload interface is opened:

[0189] 1) Read the saved state information from the application-level persistence service.

[0190] 2) Parse out the server identifier selected by the user last time.

[0191] 3) Automatically select the corresponding item in the server selection box (comboBox) to achieve automatic status recovery.

[0192] This mechanism significantly reduces user steps and improves the consistency and efficiency of the upload process through transparent state management. Meanwhile, application-level persistence strategies ensure the consistency and availability of configuration information across multiple projects.

[0193] 4. Java file automatic compilation and bytecode path location mechanism

[0194] To enable automatic compilation of Java files before upload and subsequent bytecode file upload, this method automatically triggers the compilation process before the upload interface starts, ensuring that the source file and the compiled bytecode file are ready synchronously.

[0195] Compilation triggering mechanism:

[0196] After the user selects multiple files, the system first identifies the file types. If the selected files contain Java source files (.java), the compilation process is automatically invoked:

[0197] Compilation action acquisition: Obtain the compilation action instance through ActionManager.getInstance().getAction("CompileFile").

[0198] Compilation trigger: Construct a simulated AnActionEvent, pass in the currently selected collection of Java files as the context, trigger incremental compilation operation, avoid compiling the entire project, and improve compilation efficiency.

[0199] File Temporary Storage: After compilation, the system temporarily stores the source file to be uploaded and its corresponding bytecode file path in the upload list for subsequent transmission.

[0200] Bytecode file path location method:

[0201] To accurately obtain the path of the compiled bytecode file, this method uses the following steps for path calculation and verification:

[0202] Obtaining the module output directory: Use the ModuleAPI provided by IntelliJPlatform to call ModuleRootManager.getModuleOutputDirectory() to obtain the compilation output directory of the current module (such as target / classes or bin / classes).

[0203] Relative path calculation:

[0204] Extract the relative path of the selected Java source file to the source code root directory (e.g., src / main / java).

[0205] Replace the file extension from .java to .class while preserving the package path structure.

[0206] Complete bytecode path synthesis: Concatenate the module output directory, relative path, and class name to generate the complete local path of the bytecode file, in the format: output directory + relative path + class name.class.

[0207] File existence verification: Use platform APIs such as VirtualFileManager to query the virtual file system to see if the .class file exists, ensuring that the file has been successfully compiled and generated.

[0208] Performance optimization measures:

[0209] To reduce the system overhead of repeatedly querying the module's output directory, this method introduces an output directory caching mechanism:

[0210] Use ConcurrentHashMap<Module,VirtualFile> Establish a mapping cache table between modules and output directories.

[0211] After the output directory of a module is queried for the first time, it is cached in the mapping table.

[0212] Subsequent path queries for the same module are retrieved directly from the cache, avoiding repeated calls to compileContext.getModuleOutputDirectory(), significantly reducing system resource consumption and improving path location efficiency.

[0213] This mechanism ensures performance stability when frequently locating bytecode paths in multi-module projects, while also guaranteeing the accuracy and real-time performance of path calculation.

[0214] 5. Multi-type file mixed upload mechanism

[0215] To enable unified uploading of Java files and non-Java resource files, this method supports mixed selection of multiple files in the interface and adopts differentiated upload strategies for different file types, making it particularly suitable for file deployment scenarios in multi-module microservice projects.

[0216] Document selection and classification:

[0217] Multiple file selection: Users can select multiple files through the IDE project view or the right-click menu of the editor. The system receives a collection of VirtualFile[] objects as input.

[0218] File type identification and classification: Quickly classify selected files based on their file extensions: Java source files (.java); resource files (such as .xml, .properties, .html, configuration files, etc.).

[0219] Differentiated upload strategy:

[0220] Implement differentiated file processing logic using a custom upload utility class, UploadHandler:

[0221] Java file upload:

[0222] Automatically trigger compilation and obtain the bytecode file path.

[0223] Upload both the source file (.java) and the compiled bytecode file (.class).

[0224] Non-Java file upload:

[0225] Upload the source file directly; no compilation or preprocessing is required.

[0226] It supports direct transfer of various configuration files, static resources, etc.

[0227] Server connection and resource management:

[0228] Connection establishment: Before the upload operation begins, an FTP / SFTP connection is established based on the selected server configuration to complete identity authentication.

[0229] File transfer: Iterate through the upload list and perform file transfers according to the predefined strategy.

[0230] Connection release: The server connection is automatically disconnected after all file transfers are completed, releasing network and session resources and ensuring efficient use of system resources.

[0231] Given the characteristics of microservice projects with multiple modules and multiple output paths, this method has the following processing capabilities:

[0232] Modular path location: The module to which each file belongs is accurately located by ModuleUtilCore.findModuleForFile(), and the compilation output directory of the corresponding module is obtained (such as moduleA / target / classes, moduleB / build / classes).

[0233] Unified processing of mixed files: In the same upload task, Java files, resource configuration files, front-end static files, etc. from different modules can be processed simultaneously. The system automatically identifies the module to which they belong and adapts the corresponding output path.

[0234] Efficiency Improvement: It avoids the need to manually switch directories and repeatedly select files in multi-module projects, and enables batch compilation, path resolution and one-click upload of cross-module files, which significantly improves the file deployment efficiency in microservice projects.

[0235] This method enables efficient uploading of mixed files of multiple types and modules through a unified processing flow and module awareness, adapting to the deployment needs of projects under modern microservice architecture.

[0236] 6. Log upload console display mechanism

[0237] To provide visual feedback and convenient operation during the upload process, this method integrates a dedicated upload log console into the IDE, supporting features such as hierarchical log display and hyperlink navigation to file paths.

[0238] Console window construction:

[0239] Tool window creation: By inheriting the ToolWindowFactory interface and implementing the createToolWindowContent() method, a dedicated tool window embedded in the IDE sidebar is constructed.

[0240] Console initialization: After obtaining the toolWindow instance, call TextConsoleBuilderFactory.getInstance().createBuilder(project) to create a console builder, which in turn generates an interactive console view.

[0241] Log content display and formatting:

[0242] Log output: After the console is created, the upload process log is output using the console.print() method. Each log entry includes information such as timestamp, file path, and upload status.

[0243] File path hyperlinking: For source file paths mentioned in the log, the `printHyperlink()` method is used to format them into clickable hyperlinks. Users can click the links to directly open the corresponding files in the editor, facilitating quick location and secondary uploading.

[0244] Log classification by color:

[0245] Successful upload logs are marked as INFO and displayed in green font.

[0246] Upload failure logs are marked as ERROR and displayed in red.

[0247] Visual differentiation enhances log readability, making it easier for users to quickly identify uploaded results.

[0248] Interaction and operation support:

[0249] This console not only provides real-time feedback on the upload process, but also supports the following interactive features:

[0250] Log filtering: Users can filter and view logs based on their level (INFO / ERROR).

[0251] File navigation: Directly navigate to the corresponding source file via hyperlinks, supporting quick modification and re-uploading.

[0252] Log cleanup: Provides a button to clear console content, keeping the interface clean.

[0253] This mechanism significantly improves the traceability and ease of operation of the upload process through integrated log display and interactive support, making it suitable for complex multi-file upload scenarios.

[0254] Application Scenarios and Value of Integrated Java Compilation and Upload Operation

[0255] The integrated process proposed in this method is particularly suitable for scenarios where multiple types of files coexist, such as continuous integration / continuous deployment (CI / CD) pipelines and microservice projects, and can effectively ensure the quality of uploaded artifacts and the stability of the deployment environment.

[0256] Quality Assurance Mechanism:

[0257] This method forces a Java file compilation status check before performing the upload operation:

[0258] The system will only trigger the subsequent FTP / SFTP upload process after the Java file is successfully compiled.

[0259] If compilation fails, the upload will be interrupted and an error message will be displayed to prevent incomplete or incorrect .class files and resource files from being transmitted to the remote server.

[0260] This mechanism ensures the validity of uploaded artifacts from the source, improving the consistency and reliability of testing and production environment deployment.

[0261] Typical application scenarios:

[0262] Remote service debugging scenario: In a development and testing environment that only supports remote debugging, developers can compile the code locally and then deploy the bytecode file directly to the remote server with one click. This reduces manual transfer steps, improves the accuracy of resource placement, and provides convenience for subsequent testing and verification.

[0263] Microservice multi-module projects: Supports simultaneous processing of various file types such as Java files, configuration files, and static resources, and automatically identifies the output paths of each module, enabling mixed compilation and unified uploading of cross-module files, adapting to the complex deployment needs of modern microservice architectures.

[0264] Upload time comparison (traditional tools vs. this method):

[0265]

[0266] Secondly, this invention provides a Java file automatic compilation and uploading device, integrated into an integrated development environment (IDE), the structure of which can be found in the attached diagram. Figure 4 .

[0267] This device is the specific implementation of the aforementioned method, and the two are completely corresponding in function and logic: the file processing module in the device corresponds to the user interaction and file filtering steps in the method, the compilation control module corresponds to the incremental compilation and path calculation steps, the upload execution module corresponds to the server connection and file transfer steps, and the human-computer interaction and feedback module corresponds to the operation interface and progress feedback steps. Through modular design, the device integrates each step of the method into an IDE extension, allowing users to trigger and execute the complete "identification-compilation-location-upload" process through a graphical interface within the IDE environment. This transforms the automated operations described in the method into a practically usable integrated tool.

[0268] 1. File processing module

[0269] This module is responsible for receiving user input, identifying file types, and managing server configuration, specifically including:

[0270] File selection and type identification unit: Through multiple interactive methods such as the IDE's project structure view and the editor's right-click menu, it listens for and obtains the set of files selected by the user; it identifies and classifies files based on file extensions, distinguishing between Java source files and non-Java files.

[0271] Configuration Management Unit: Provides a graphical configuration interface (such as...) Figure 5 As shown, this interface (using KotlinUIDSL, inheriting from DialogWrapper) is used to manage server connection parameters. It internally uses the ListModelEditor component to manage the server list and provides detailed form fields for editing each configuration's protocol type (FTP / SFTP), host address, port, username, authentication method, and remote path. This unit supports adding, deleting, modifying, querying, sorting, and connection testing of server configurations. In SFTP scenarios, it establishes a session using an SSH key based on the JSch library to verify the configuration's validity.

[0272] like Figure 5 As shown, the configuration interface is divided into two parts: the upper part is a server list, which supports centralized management of configurations for multiple environments (development, testing, and production); the lower part is a detailed form of the currently selected server, and has a "Test Connection" button to facilitate users to quickly verify the configuration.

[0273] 2. Compilation control module

[0274] This module is the core of the automatic compilation function, including:

[0275] Compilation trigger unit: After identifying Java source files, this unit obtains the compilation action by calling the IDE's ActionManager interface, constructs a simulated compilation context containing only the selected Java source files, and triggers incremental compilation operations for the batch of files.

[0276] Path location unit: After compilation, the compilation output directory of the module to which the Java source file belongs is obtained by querying the IDE's module management API (such as ModuleRootManager); based on the relative path of the source file relative to the source code root directory, the path of the target bytecode file is calculated, and the module output directory is concatenated with the relative path to generate the complete absolute path of the bytecode file.

[0277] This unit also has a cache subunit, which is used to establish and maintain a cache mapping of the module compilation output directory. When the same module output directory is retrieved multiple times, it is read directly from the cache, avoiding repeated API calls and improving performance.

[0278] 3. Upload Execution Module

[0279] This module is responsible for building the upload list and performing file transfers, specifically including:

[0280] Upload list construction unit: Constructs a unified list of uploaded files based on the file recognition results. For Java source files, both the source file path and the corresponding bytecode file path are recorded; for non-Java files, only their own path is recorded.

[0281] File transfer unit: Based on the user-selected server configuration, establishes a connection with a remote FTP or SFTP server and transfers all files in the upload list to a specified directory on the remote server. This unit supports multiple authentication methods: for the SFTP protocol, SSH key authentication is used; for the FTP protocol, username / password authentication and anonymous login are supported. The transfer process is implemented based on appropriate client libraries (such as JSch and CommonsNet) and includes an exception handling mechanism.

[0282] 4. Human-computer interaction and feedback module

[0283] This module provides a graphical user interface and real-time operation feedback, including:

[0284] Upload Interface Unit: Provides a simple upload dialog box, displays a list of configured servers through a ComboBox component, and displays detailed information of the currently selected server using a read-only text box. Users only need to select the target server and click upload to trigger the operation.

[0285] Log Feedback Unit: Create a dedicated view in the IDE console to output upload logs with timestamps and file status in real time; format the file paths in the logs into interactive hyperlinks, allowing users to quickly jump to the corresponding source file for editing or re-uploading after clicking.

[0286] As a further aspect of the present invention, the device further includes:

[0287] State Management Module: By implementing the IDE's PersistentStateComponent interface, server configuration information and the user's last operation selection are stored in an application-level persistent manner, enabling cross-project sharing and memory of configurations.

[0288] Example:

[0289] Scenario: Developer Zhang is using IntelliJ IDEA Community Edition to develop a microservice project containing two modules: userservice and orderservice. He has just modified the UserController.java file in userservice and the application.yml configuration file in orderservice, and needs to immediately update them to the test server for verification.

[0290] Implementation process:

[0291] 1. Trigger: Zhang selects both UserController.java and application.yml files in the project view, right-clicks them, and selects "Upload via FTP / SFTP" from the context menu.

[0292] 2. Automatic processing:

[0293] The plugin recognizes UserController.java as a Java file and automatically triggers compilation. After successful compilation, the module API locates its bytecode file at userservice / target / classes / com / example / controller / UserController.class.

[0294] application.yml was recognized as a non-Java file.

[0295] The upload list built by the plugin consists of three files: a Java source file, its corresponding bytecode file, and a YAML configuration file.

[0296] 3. Upload: An upload interface will pop up ( Figure 2 The dropdown menu already had the TestServerSFTP configuration that Zhang had used previously selected by default. He clicked the upload button.

[0297] 4. Connection and transmission: The plugin uses the JSch library to connect to the test server via a pre-stored SSH key and uploads the three files to the corresponding directories on the remote server (such as / app / userservice / and / app / orderservice / ).

[0298] 5. Feedback: After uploading, the plugin console at the bottom of the IDE will display:

[0299] [INFO][Success]~ / project / userservice / src / ... / UserController.java

[0300] [INFO][Success]~ / project / userservice / target / ... / UserController.class

[0301] [INFO][Success]~ / project / orderservice / src / ... / application.yml

[0302] All paths are clickable hyperlinks. The entire process requires no manual compilation by Zhang, nor does it require opening any external FTP tools.

[0303] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0304] Although the present invention has been described in detail in the specification, drawings and embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention; and all technical solutions and improvements that do not depart from the spirit and scope of the present invention are covered within the protection scope of the patent of the present invention.

Claims

1. A method for automatically compiling and uploading Java files, integrated into an integrated development environment (IDE), characterized in that: Includes the following steps: S1: File Selection and Type Recognition: Receives a set of files selected by the user through the IDE's multi-entry interactive method, and identifies Java source files and non-Java files based on their file extensions; S2: Automatic compilation and output path location of Java files: When a Java source file is identified, the AnActionEvent mechanism constructs a simulated compilation context containing only the selected Java source file, triggers incremental compilation, and dynamically generates the complete storage path of the corresponding bytecode file based on the modular project structure after compilation is completed. S3: Mixed file list generation: Construct a unified list of files to be uploaded. For Java source files, it includes both the source file path and the corresponding bytecode file path; for non-Java files, it only includes their own path. S4: Server connection and file transfer: Establish a connection with the remote server based on the persistently stored server configuration information, and transfer all files in the list of files to be uploaded to the specified directory of the server; S5: Upload Result Feedback: Create a dedicated console in the IDE to output structured upload logs in real time, and format the file paths in the logs as clickable hyperlinks.

2. The method for automatically compiling and uploading Java files according to claim 1, characterized in that, The specific implementation method of S1 is as follows: The IDE receives the user-selected file set through a multi-entry interaction mechanism, which includes right-click menu items in the IDE project structure view, right-click menu in the editor, and main toolbar buttons. It receives a collection of VirtualFile[] objects from the IDE event system, identifies the file type through the getExtension() method, and supports simultaneous selection of Java source files and non-Java files and automatic classification and processing.

3. The method for automatically compiling and uploading Java files according to claim 1, characterized in that, S1 also includes: Use ApplicationManager.getApplication().executeOnPooledThread() to start a background thread for asynchronous preprocessing.

4. The method for automatically compiling and uploading Java files according to claim 1, characterized in that, The specific implementation method of S2 is as follows: When a Java source file is identified, the compilation action is obtained through ActionManager.getInstance().getAction(Compile), and the AnActionEvent event mechanism is used to construct a simulated compilation context containing only the selected Java source file, triggering incremental compilation. During compilation, ModuleUtilCore.findModuleForFile(virtualFile,project) is called to locate the module to which the file belongs. ModuleRootManager.getContentEntries() is used to parse the Maven / Gradle project output path or read the module's custom output path. Combined with ProjectRootManager.getSourceRoots(), the relative path of the source file is calculated. The .java extension is replaced with .class and concatenated with the module's output directory to generate the complete storage path of the bytecode file.

5. The method for automatically compiling and uploading Java files according to claim 1, characterized in that, S2 also includes path pre-calculation and verification: before triggering compilation, the expected bytecode file paths corresponding to all Java source files are pre-calculated, and the existence of the expected paths is verified after compilation; if compilation fails or bytecode is not generated, detailed error information is output and retry or skip options are provided.

6. The method for automatically compiling and uploading Java files according to claim 1, characterized in that, It also includes a server connection test function: a connection test entry is provided in the server configuration interface, and the connection test is performed using the corresponding authentication method according to the selected protocol type.

7. A Java file automatic compilation and upload device, characterized in that, The apparatus is used to implement the method of claim 1, and the apparatus comprises: The file processing module includes a configuration management unit and a file selection and type identification unit, which are used to receive and persist the storage server configuration, and to identify Java source files and non-Java files in the user-selected files; The compilation control module includes a compilation triggering unit and a path positioning unit, which are used to trigger incremental compilation of Java source files and locate the path of the generated bytecode file; The upload execution module includes an upload list construction unit and a file transfer unit, which are used to build a unified upload list and execute file transfer according to the server configuration; The human-computer interaction and feedback module includes an upload interface unit and a log feedback unit, which are used to provide an upload operation interface and interactive upload log output.

8. The Java file automatic compilation and upload device according to claim 7, characterized in that, The path location unit also includes a cache subunit, which is used to establish and maintain a cache table of the module compilation output directory.

9. The Java file automatic compilation and upload device according to claim 7, characterized in that, The device also includes a state management module for storing server configurations and user operation selections in an application-level manner via the IDE's persistent components.

10. The Java file automatic compilation and upload device according to claim 7, characterized in that, The file transfer unit supports multiple authentication methods: SSH key authentication is used for the SFTP protocol, and username / password authentication and anonymous login are supported for the FTP protocol.

Images