Intellij recently very slow to run a Java project/test.

Hi Cgithub 

Thanks for contacting us, according to the description the problem looks related to a certain component or files in the projects. Could you please share more details about the projects that are not working properly, like if they are running some specific framework, or using maybe a particular java library or maven artifact, are they opening any connection to external services or connecting through authentication?

Also, please let me know if the slow projects are locally stored or are them in a remote server, a virtual machine or something similar. Verify that the IDE has enough permissions to access the project folder and its content.

As a first step to troubleshooting this issue, I would suggest disabling the custom plugins and seeing how it behaves. Since a couple of previous versions, GitHub Copilot has been presenting issues; we need to verify this is not the root cause. If this is not the origin of the problem then collect the logs by going to Help | Collect Logs and Diagnostic Data, attaching the zip file here or through our safe upload site https://uploads.jetbrains.com/, and sharing the uploadID.

Inside the logs folder there will be thread dumps if the app is stuck at some point, and it will give us more clues. Please share the timeframe when you noticed the issue.

Hi Monica - thanks for the reply. The projects are all standalone projects. They exist on my local HDD. They are all Springboot /Maven projects. They all use the SpringBoot starter parent. They don't need to connect to any external resources to run the unit tests. 

I've been playing around to try to find a pattern. This very simple stub project (https://github.com/XcrigX/springboot-rest-stub) exhibits the problem, but less dramatically. It will ‘pause’ for about 22 seconds if I click ‘Run All Tests’ on the project before actually starting the tests then takes another ~5s to run the tests, whereas “mvn test” from the command line takes ~7s. 

If I add more dependencies to the POM (just random extra dependencies for things like spring-jdbc, spring-batch, commons-io, database drivers, etc.) the pause time does increase. So perhaps the project complexity and number of dependencies is affecting it? 

I understand the IDE is doing useful things for me and I don't expect it to match a command line run exactly, but these pauses are very noticeable and definitely something recent as I've been developing on these affected projects for many months. 

Anyway, I disabled the two downloaded plugins (did not disable any of the default plugins that come with IJ), and it didn't change anything. I'll see about collecting the full logs tomorrow. 

Hello 

Thanks for the details and the sample project. 

So perhaps the project complexity and number of dependencies is affecting it?

Could be, but I need to investigate it further on my end to find a reported bug or reproduce the same behavior and be able to send it to developers. I'll come back with an update as soon as possible.

Monica  I closed IJ, cleaned out the logs folder, then restarted IJ at approximately 2025-10-13 12:04. 

I waited about 30s, then hit the run button on my unit test at 12:05. IJ displayed the ‘Starting <projectname>’ text at the bottom for 71s before actually starting the test, which then completed in ~7s. 

Immediately after I captured the logs - Upload ID: 2025_10_13_ZNgYGjS6P3ubhoapw3ZDAV

NOTE  - I pulled some of the affected projects to a different machine (that don't have corporate security software) and they ran instantly. So I suspect some interaction there is causing the delay - I just don't know what. When this pause is occurring, I see in task mgr that “Avecto Defendpoint Service/Beyond Trust Privilege Mgr” run at about 8-10% CPU, then drop back down once the run is complete. That CPU usage doesn't look too alarming, but could be something? 

Thanks for the help. 

Hi Cgithub 

Thanks for the test, logs and this new information about “Avecto Defendpoint Service/Beyond Trust Privilege Mgr” according to all the information and description of your issue, most likely Avecto is the root cause if policies are not defined correctly. This is what could be happening when you run JUnit tests, that trigger BeyondTrust scanning:

1. The test is executed
2. IntelliJ spawns a new JVM process to run tests
3. It checks if the Java executable is allowed to run with specific parameters
4. JUnit loads test classes, dependencies, and frameworks
5. Heavy file I/O + process are created. Each .class file is read from disk
6. BeyondTrust intercepts and validates this process launch and every file
7. Application control policies evaluate the new process and files
8. An overhead is caused resulting in a slowdown.

Basically this software can slow down processes if, as mentioned before, policies are not defined correctly, if there's some conflict with other security software, or simply and overhead if the software has to scan all the files. Some actions that can trigger the software to scan the files are the process creation and execution, the class loading, the test frameworks creating temp files, dynamic code generation, build tool integration, among others.

Then the 8-10% CPU spike that you saw during test execution from BeyondTrust should correspond to:

• Scanning newly loaded JAR files
• Validating the test runner JVM process
• Monitoring file operations in build directories
• Checking temp file writes

So please contact your IT team to check if you can run a quick test where temporarily they can disable BeyondTrust on your machine, run your tests and compare timing. This will definitively prove the impact. If you see the tests are running without delay please ask your IT team to modify the policies to exclude the next:

• Build output directories: /target/, /build/ Dependency
• caches: ~/.m2/repository/, ~/.gradle/caches/
• Java processes launched by IntelliJ IDEA

Hi @Monica - much of what you describe would also be an issue manually running a Java project. I can run ‘mvn clean verify’ which has to recompile all class files, run all tests, etc. and there are no delays. 

I can also ask IJ to rebuild my project, sync with maven, import a brand new project - all tasks that would need to scan/index/create a lot of files and it's quick to do all those things. So I don't think it's just a case that all file I/O is delayed. 

I can see at the bottom of the screen when it's parsing/building project changes. AFTER it does that, it gives me the ‘starting <projectname>’ background task message, and that is where it hangs. What is it doing there? 

I agree there's a decent chance the security software is interfering. I was hoping there were some IJ logger settings I could turn up to see what IJ is doing to give me a clue. I've tried from the other side to see the logs from the security SW, but that's a harder problem much more out of my control. 

Hi there,

Thanks for pointing out these processes that are working. 

This could still be related to BeyondTrust, but now I think it could be delaying in terms of inter-process communication and/or agent loading, because in the starting phase is when these actions are run. Below is a general list of what IntelliJ does during the starting:

1. Launches the test JVM with a specific configuration
2. Attaches debugger/monitoring agents
3. Establishes communication channels between IDE and the test process
4. Loads IntelliJ's test runner libraries into the test JVM
5. Initializes classpath and test framework detection

So, BeyondTrust could be interfering with the network socket creation, the dynamic library loading, the process memory inspection, and/or JAR verification of IntelliJ's bundled test runner JARs. This would also explain why mvn clean verify doesn't show any slowness, as it doesn't attach any IDE agents or establish IDE-JVM communication channels. To get more information that can confirm if this idea is correct, please enable the test runner debug logs by:

1. Going to Help | Diagnostic Tools | Debug Log Settings

2. Add the next log categories (each on a new line):

   #com.intellij.execution
   #com.intellij.execution.runners
   #com.intellij.execution.testframework
   #com.intellij.rt.execution
   #com.intellij.junit
   #com.intellij.maven.testRunning
   com.intellij.execution.process:all
   com.intellij.execution.junit:trace
   com.intellij.execution.runners:trace

3. Click Ok

Then run your test again and collect the logs following the same steps you did before, and share them as well as the timeframe during which the issue happens for further analysis. This should give us more info, mainly identifying gaps or messages that could indicate where exactly the delay is occurring. 

Monica 

Upload id: 2025_10_15_zr8dZmUQHuHQHTsAXPgMR2

Similar process, I closed IJ, deleted everything in the logs folder, and fired it back up (with the added loggers). 

I started IJ at 14:19, and waiting a minute, at 14:21 I fired off the unit test again. 

You'll see in the idea.log and build.log a time gap after 2025-10-15 14:21:11 until 14:22:22-35. 

That's the minute+ pause I'm seeing. There's nothing obvious in there to me on what's happening, hopefully you can spot something. 

Thanks very much for your help!

Hi Cgithub 

I did a deeper analysis of the log, specifically the gap you pointed when the hang happens. Basically these are the series of events :

14:21:04,100  - Previous build completed ("No changes found")
14:21:11,139  - NEW JPS process starts (7 seconds later)
14:21:11,899  - JPS "Pre-loaded process ready in 774 ms" ✅ FAST!
14:22:22,742  - Test process FINALLY starts

As we can see the test starts 71 seconds AFTER JPS was ready. So, it looks like the actual problem is in the Test Classpath Assembly, if we look at your launch command it has a MASSIVE classpath: -classpath "C:\Users\craig.mcclendon\.m2\repository\org\junit\platform\junit-platform-launcher\1.11.4\...[173 libraries]..." and also because the below message appears immediately when the test process starts at 14:21:11, but the test doesn't actually start running until 14:22:22. This is because Java is loading the classpath during the gap, and most likely a scanning is happening for each JAR as it's accessed.

Unable to make field private static java.util.IdentityHashMap 
java.lang.ApplicationShutdownHooks.hooks accessible

That's why in the log it is shown at 14:21:11,613 - "Project has 1 modules, 173 libraries"  ← JPS knows the libraries, all is good until this point, but for the test to start Java has to load the classpath, then 70 secs after, at 14:22:22,742 - Test launches test starts with all 173 libraries in the classpath.

As mentioned before and in some previous comments, the most probable root cause is corporate security. However, we still have to contemplate two more areas: Slow disk I/O reading, or Network path or slow storage. To validate which is the reason in your case, you'll have to:

1. Verify that the next paths are under exclusion in your antivirus software and/or corporate security software:

   • C:\Users\craig.mcclendon\.m2\repository
   • C:\Program Files\Java\jdk-21
   • C:\Users\craig.mcclendon\aaMyStuff\dev\git-aha\batch-fhir-ingest
   • C:\Program Files\JetBrains
   • C:\Users\craig.mcclendon\AppData\Local\JetBrains
   • C:\Users\craig.mcclendon\AppData\Roaming\JetBrains

   If these are not excluded from scans please add them to the exclusion list and test again. This should drop the time immediately.

2. Check your storage location and verify where C:\Users\craig.mcclendon\.m2\repository\ is on, it could be a network drive, OneDrive/Cloud storage, an encrypted volume or a slow HDD (not SSD) that could lead to slow reading. Depending on this you'll have to take the necessary actions within your company.
3. Also, if you can debug your classpath and remove the unnecessary jars, some improvement should be seen.

I hope this helps to go through the issue with your security team. Please let me know the results.

Not sure if it was already mentioned, I found a big improvement in the startup of the unit tests by simply adding “shorten command line” option to the junit configuration template. I used @argfile option. BeyondTrust also runs on my machine and, I am sure, it slows me down.

Hope that helps you too.

Michael Goldverg - you beauty, you!   That changed the delay on the project I'm working on currently from ~90 seconds to ~7 seconds. Thank you so much, I can regain a small modicum of sanity. 

That explains why some projects I had that seemed equally large/complex were quick to run and others painfully slow - as some projects refuse to run without this option and it pops up a dialog asking to change it. 

Monica - FYI - Looks like you had noticed the very long launch command in your last analysis so were close to honing in here. I compared the two and the shortened command is 876 chars, the unshortened is 24k chars.  Presumable the @argsfile would be equally as large as the command line - but for whatever reason this makes it behave nicely. Thanks again for your time looking into this as well.