IntelliJ: Debugging/Running does not reflect current code state

Make sure Build step is included in Before Launch section of the run configuration.

Build with IntelliJ IDEA, not with Maven, they build into different output directories.

Verify .class files are updated after your perform Build | Build.

Do not delegate to Maven: https://i.imgur.com/HpeUaUE.png.

Update to the current release: https://www.jetbrains.com/idea/download/index.html.

I know this is old, but I'm stumbling across this issue right now in 2024.1 (Ultimate). When just playing around with some scratch files using WSL on Windows 11, Idea appears to not have support for detecting file changes. SO, if I try to run `main()` in the current class file, the file will be compiled and will run but then if I make changes and click on the Run button again, there will have been no build and the old code will run again and again.

One work around I've found, and this is pretty dumb, is that if I also open the project in VSCode and then leave that running in the background, any change I make in Idea is then applied during the next Run in Idea. I don't even have to open the file I'm working on explicitly in VSCode, just the project itself.

Simply touching the file from the terminal, in Ubuntu in WSL, makes no difference.

Hi Mark,

Do you also have this problem on Windows, outside of WSL?

Does the run configuration for your scratch file have a ‘Build’ step in the ‘Before Launch’ area?

Does it help if you do Build → Build Project manually before rerunning your code?

Hi all,

I'm now facing the same problem as Mark.

Run configuration has a build step, and doing Build → Build Project manually doesn't resolve an issues

Avtutueva Please contact support at https://intellij-support.jetbrains.com/hc/requests/new with the sample project and the exact steps to reproduce this issue. Also share the logs (Help | Collect Logs and Diagnostic Data).

This may not work in WSL, related issue: https://youtrack.jetbrains.com/issue/IDEA-341365 .

You can either open the project from \\wsl$ instead of \\wsl.localhost or try the EAP version: https://www.jetbrains.com/idea/nextversion/ .

If it still doesn't work, follow IJPL-149166 for updates.

Arina Efremova I don't have the problem in Windows (outside of WSL). In WSL, adding a “Build” step in “Before Launch” makes no difference. Doing a “Build → Build Project” makes no difference. I have to “Build → Rebuild Project” for changes to cause a difference.

But again, if I simultaneously open the directory in VSCode, launching VSCode from within WSL, and without actually opening any file with the directory, any changes I make from the editor inside of Intellij will immediately be seen when clicking the “Run” button or “Build → Run…”. No idea why that works.

@Mark Please refer to the comment above for possible root cause and solutions.

Serge Baranov That youtrack link is not accessible by the public. Arina Efremova The issue UPL-149166 looks like the behavior I see.

I fixed the link, see https://youtrack.jetbrains.com/issue/IDEA-341365 .

Serge Baranov  Yes, that issue does indeed look like the same thing. Thanks for fixing the link.

The issue is fixed in https://www.jetbrains.com/idea/nextversion/ and in 2024.1.x you can use a workaround (open the project from \\wsl$ path).

In IJ 2024.1, I have a similar issue, not on Windows, not involving a path \\wsl$ as follows:

1. Open IJ and build a very large project (which generates and compiles some code)
2. Modify some files that require regeneration
3. Start server with a run config that has an initial build step.
4. The start server fails because some necessary files are not rebuilt

I tried invalidating each cache, and it doesn't help. What does work is any  one of the following:

• File->Cache Recovery->Reopen Project
• Rebuild (full)
• Exit IJ and start it again

My project is quite extensive so I haven't found a simple way to reproduce this problem to submit to you.

I cannot “try it” with IJ 2024.2 because 2024.2 breaks my plugins completely – they no longer compile and the changes required will take months to work out.

Yes, this is stably reproduced with the same large project.

Here is one RunConfiguration that has a Build step.  The first time this is run, it works.  But if I change some files and run it again, the Build step before launch doesn't find all the changed files and thus doesn't regenerate/recompile them:

Doing any of the 3 things I mentioned (full rebuild, File->Cache Recovery->Reopen Project, or exit IJ and start it again) will fix the problem and this RunConfiguration then works fine.

So somehow the logic that decides what to incrementally build is not doing the correct thing.

This is a Java project, using a Gradle build.  The changed file is an xml file that is read by a code generator to produce Java source files.

Expected: Changing a file should cause the Build to redo all the code generators and compilation steps that depend on that file.

Actual: Changing the xml file causes the code generator to rerun and output a Java file that is then recompiled by the Java compiler as part of the incremental Build.

Upload ID: 2024_12_05_QpYv8DVu4NEJfiSeCQ8hkJ (files: idea-logs-20241205-10555011671060059116069334.zip, jetty-0_0_0_0-8480-webapp-_px-any-10088398745860435289.zip)

The previous upload was a different case.  Here is the upload from the exact same case as above:

Upload ID: 2024_12_06_oahspFU5h2aSrqHHigcG5u (file: idea-logs-20241205-1711572459333682169866700.zip)

Well, yes, Jerome, we have our own plugins that are involved.  Can you please tell me what error you found related to dropping an index due to some large file?  What was that error? What were the warnings?  What log file did you find this in?  Was it build.log?

Regarding “asking questions”, our plugins have been in use for 10 years now, and most of the changes have been to keep up with JetBrains refactoring and changing things. I am aware of this #intellij-platform channel, but since we aren't doing any new development (but rather using our plugins developed previously before IJ 2024.1) I have no idea what questions to ask.

Please understand that we have been using our plugins for 10 years.  We're not actively developing a new plugin.  The change is that we are using IJ 2024.1 instead of an older IJ version.

So if you could give me some “hints” about what you found, and where, so I can look at the errors and warnings you say you found, that would help me see what is going on.

Thanks!

Jerome Guan I would appreciate a response.  Thanks.

Hi Bob,

In my opinion, maybe adding a clean task before the build task might help. I'll asking our build team colleague to check if any hints.

Bob Goldberg In regards to the original issue with the Run Configuration failing after some of the Project's files have been changed: can you please confirm that IDEA is currently configured to delegate the builds to Gradle ("Build and run using" option in the Gradle Settings)?

A reproducer Project would also be massively helpful in discovering the root cause of the issue.

It does not have to be your entire Project, it can be a small Project with the minimal code that uses the same Annotation Processor / Code Generator as your actual Project does. As long as it exhibits the same behavior, that should be enough for us to work with.

Jacky Liu A full rebuild of the project takes 30 - 50 minutes. Doing a clean would presumably do something similar, and take similar time.  Only a small number of files have changed.

Roman Vatagin Yes, we build and run using Gradle.  As far as a simple example, that is difficult to do.  We have many many code generators, and many layers of build, and many languages involved.  I am working on a code change that was made recently where we used to close and reopen a view programmatically.  That caused problems when switching from IJ 2023.3.5 to IJ 2024.1.5, so that code was removed.  But it may be necessary to put it back under some circumstances.

Jerome Guan said above “We found when build process was initiated, there will be some warning caused by a customized plugin, which integrates with IJ related apis and components. And we can also found the index was dropped due to some large file.” It seems that someone already found that the index was dropped.  What index? Where can I see that? Which log file? With these details, I could make progress!

Bob Goldberg If the builds are delegated to Gradle, they should be processed by a Gradle Daemon and IDEA's involvement should be minimal. Does the issue persist if you run Gradle from OS Command Prompt?

If the issue does not persist when running Gradle from OS Command Prompt, could you please share the full output from IDEA's Build Tool Window?

You can share it privately using our upload service.

The problem does not occur from the command line Gradle build.

The files involved which are not recompiled by an incremental build are generated files, I believe. For some reason, either the code generators are not running on an incremental build (in only some cases) or the code they generate is not being marked as needing to be compiled.

I have found a change that was made to our XML editor code that may have caused the problem. The editor code uses your interface com.intellij.openapi.fileEditor.FileEditorProvider and it closes and reopens the file when it creates our editors.  With this close/reopen, our build worked in the past, but due to the changes JetBrains made to the dispose logic related to closing and reopening of the file,  someone here modified it to put that close/reopen under a “Run Once Per Project Per File” lambda block. So in our method createEditor(project, file), it now reads:

RunOnceUtil.runOnceForProject(project, file.getCanonicalPath(), () -> {
          if (!file.isValid()) {
            return;
          }
          FileEditorManager manager = FileEditorManager.getInstance(project);
          manager.closeFile(file);
          manager.openFile(file, false);
        });
      });

I highly suspect that this causes the problem.  The command line Gradle build does not involve the editor, or IJ's rebuild index, so it was not affected.

The reason the code was put under a Run Once lambda is that in IJ 2023/2024 it produces stack traces in the log with “already disposed” errors over and over.  This did not happen when our plugins were run under prior IJ major versions, e.g., IJ 2022.

I am going to try removing the Run Once to see if that fixes this problem.  If so, I'll need a fix to the “already disposed” errors stack traces happening over and over.  Stay tuned ….

Bob Goldberg Thank you for the update!

Since the issue does appear to be Plugin-related, the resources linked by my colleague may help you resolve it.

It turns out that the if (!file.isValid()) caused the problem because it was under runOnceForProject().  When the editor is first opened, it gets a dummy file, goes into this block, and the code is never executed because of the if condition.  Then, later, when the file is set to something valid, it thinks it has already run the code and skips it.  So I moved the if condition outside the runOnceForProject() and all now seems to work.

Sorry for bothering you.