apache / apache/netbeans

Uncompilable code - cannot find symbol appearing in maven tests in same package

Open
#5,934 4 comments 0 reactions 0 assignees View on GitHub
Java kind:bug Maven needs:triage
Dominant language
Java
Stars
3.1k
Forks
935
Avg merge
2d 3h
Merged PRs (30d)
17

Description

### Apache NetBeans version

Apache NetBeans 17

### What happened

Hello

This is an issue that I have experienced in all Netbeans Versions since ~12 but has gotten better with 17, still, it appears from time to time. So:

From time to time, in some of my Maven projects, it happens that Unit Tests do not find a class in the same package anymore. They show up marked as "red" and lines using them show up as "red" saying "missing symbol" and when running them via the IDE with the individual-file context menu fail with errors such as:
```
java.lang.RuntimeException
Uncompilable code - cannot find symbol
symbol: variable MyClass
location: class com.xyz.MyClassTest
at com.xyz.MyClassTest.test(MyClassTest.java:1)
```
Where MyClass is in the same package as the MyClassTest (com.xyz). It does not happen for classes in different packages (Test in one package, class to Test in another package).

When I run the same test via the more high-level "maven clean build" commands all works fine (in the IDE and also from the command line).

Change the Java Version does not help. Recompiling does not help. Restarting the IDE does not help. Change Maven Version or bundled vs external does not help.

The only thing to make this go away is go to the cache directory and remove the index directory (shutting down the IDE first and then starting again). Once I do this, it usually stays fine for a few days or weeks, and then randomly appears again. Also, it does not appear for all classes for that package or project, it is really quite random.

Another interesting twist: When I rename the class MyClass to MyClass2 the test works and the "red" marks disappear. When I then rename it back to MyClass the same issues reappear.

Any idea how to fix this? I'm also happy to enable debugging/logging and help reproduce this.

If it can't be fixed (soon), as a workaround, would it be possible to introduce a feature to purge/clean/rebuild the cache/index directory from inside of the IDE for specific classes/packages/projects?

Thanks, regards, Leo

### How to reproduce

I cannot hard-reproduce the problem.

I believe it happens more often the more "load" is on the IDE. So, if I only have one or two projects open in the IDE and they are not big the probability for this to happen is low.

But if I have more projects (say, 10-15 each with 100K lines of code) open and work on one of them, then it happens more frequently (say, once or twice per week).

Also to add, when I do a git checkout/switch from "underneath" the IDE via the command line I have the impression that the likelyhood for this to happen is increased - but I have also seen it happen just out of the blue by editing a class from the IDE.

Also, I think this was worse in previous versions of the IDE, it improved with Netbeans 17.

### Did this work correctly in an earlier version?

Apache NetBeans 12.6 or earlier

### Operating System

Windows 10

### JDK

8, 11, 17

### Apache NetBeans packaging

Apache NetBeans binary zip

### Anything else

_No response_

### Are you willing to submit a pull request?

Yes

Contributor guide

Open the contributing guide

Research direction

Start by reproducing the failure through the IDE's individual-file test action and compare it with a Maven clean build, while examining the cache/index behavior described in the report. Done means same-package Maven tests compile reliably in the IDE without manually deleting the index directory; reproduction and regression coverage would be needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
devtools, testing
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.