Hello GroupDocs Support Team,
I am writing to report a critical issue encountered while testing GroupDocs.Total for Java for integration into our product. We are currently experiencing severe performance issues specifically within the Eclipse IDE environment.
Current Environment & Setup:
- Product: GroupDocs.Total for Java (specifically using
groupdocs-conversion)
- Build Tool: Gradle
- IDE: Eclipse IDE
- IDE Setting: “Download repository index updates on startup” is enabled in Maven settings.
Issue Description: I have added the groupdocs-conversion dependency via Gradle. The problem occurs when I trigger Auto Import (Content Assist) while editing code, following a Gradle Refresh and Project Clean Build.
At this point, the Eclipse IDE starts indexing to scan the added JAR file. However, the scanning process takes an excessively long time. Even if I attempt to cancel the operation, the indexing process breaks, and the IDE becomes completely unresponsive (freezes/hangs).
This situation repeats every time I clean and build the project, making it impossible to proceed with development tasks.
Question:
Is there a recommended workaround or configuration to prevent this indexing freeze in Eclipse? Since this issue is blocking our development workflow, we urgently need a solution.
Thank you.
I tried disabling the ‘Download repository index updates on startup’ option, but the problem remains the same.
Hello @dreamsoftware ,
We’re sorry to hear that you’ve encountered this issue while working with our GroupDocs.Total for Java library.
To better understand the situation, could you please clarify whether you are referencing GroupDocs.Conversion for Java directly in your Gradle file, or if you are using GroupDocs.Total for Java instead?
Additionally, could you let us know what heap space limit is configured for your IDE? We recommend setting it to at least -Xmx2048m.
If possible, please also share a small sample project that reproduces the issue. This would help us investigate your use case more efficiently and provide you with a solution sooner.
To provide more context on my environment, my local IDE heap memory is currently configured with -Xmx8192m -Xms8192m.
Regarding the dependencies, I specifically configured conversion (not total) as shown below: -> implementation group: 'com.groupdocs', name: 'groupdocs-conversion', version: '25.12'
I have also attempted to test using the total dependency, but the result was the same: -> implementation group: 'com.groupdocs', name: 'groupdocs-total', version: '25.12'
I have tried every troubleshooting step available to me, including testing with older library versions, using the latest Eclipse IDE version, and changing Java versions, but the issue persists.
I have attached a Sample Project below for your reference.
demo.zip (137.2 KB)
Environment:
- Project Type: Spring Boot Project - gradle
- Java Version: Java 17
- Gradle Version: 8.14.3
Added Dependency:
implementation group: 'com.groupdocs', name: 'groupdocs-conversion', version: '25.12'
Steps to Reproduce:
- Import the Gradle project into Eclipse.
- Refresh the Gradle project.
- Perform a Project Clean and Build.
- Open the
DemoApplication.java file.
- Delete all import statements in the code.
- Press
Ctrl + Shift + O to execute Organize Imports.
- Result: The problem occurs at this stage.
Detailed Symptoms:
-
At step 7, the ‘Organize Imports’ operation triggers a background indexing process to scan project files. This indexing process takes more than 20 minutes to complete.
-
If I forcibly cancel this indexing task, the IDE appears to function normally. However, the project index becomes corrupted. Consequently, even if there are syntax errors in the source code, the IDE fails to detect them, and no project errors are reported.
Hello @dreamsoftware ,
Thank you for providing such a detailed description of your use case and for sharing the sample application. I have registered your request in our tracking system under ID CONVERSIONJAVA-3054 and forwarded it to our development team. As soon as I receive feedback from them regarding the investigation of your use case, I will get back to you with an update.