FWIW, I have had similar problems when developing modules referencing code generated by the annotation processors for Antlr - doesn't happen often for me, but it does happen. Deleting the cache from the userdir fixes it (nothing else does) - it seems like the indexing plumbing gets something stuck in its craw that stays there forever.
What would be really useful is a command-line tool to view/query data from the index files - when its working correctly, print the output of searching on the class in question, and then do so again once it's broken - get the query right, and the difference in the data will point to the culprit. P.S. Don't use beans, for anything. I'd highly recommend finding a framework that encourages absolutely everything that possibly can be to be immutable - the final keyword in Java is one of the powerful bug-prevention tools in the language, because it turns what would be runtime bugs into compile-time bugs. One of these days I'm going to write a politically incorrect blog with a title something like *Java: Nice language. Too bad about the cult of mediocrity it comes with*. The fixation on beans is the root cause of that cult of mediocrity. -Tim On Tue, Dec 10, 2019 at 12:29 PM Alvin Thompson <al...@thompsonlogic.com> wrote: > Hi, > > I’ve been having a problem where in one of my projects, NetBeans is > constantly highlighting references to methods generated by Lombok as an > error. However, it’s not a "method not found error" as you’d expect, but > rather the opposite—it claims that the method is ambiguous because there > are two methods that match. The odd thing is that the methods mentioned are > both the same—it’s just the method generated by Lombok—and the code > compiles fine without warnings. See the picture at the bottom for an > example. > > There’s nothing special about the code that uses Lombok; they’re just > simple beans that use Lombok annotations to generate things like getters, > setters, equals, hashcode, etc. Strangely, the issue doesn’t show up for > *all* Lombok-annotated beans—just some of them. It seems random which > beans are affected; with two seemingly semantically identical beans in the > same package, one may be affected while the other may not. > > This makes working with this project in NetBeans unpleasant to say the > least, because this project relies heavily on Lombok and many of the java > files are filled with dozens of spurious error highlights. This issue has > actually been happening since NetBeans 9. I believe I filed an issue for > this in the old issue tracker, but I don’t see it here so I guess it didn’t > get migrated. However, someone also created an issue for this in the new > tracker (NETBEANS-1842), and it has several votes, so I guess others also > have this issue. > > For more than a year, I’ve tried many things to isolate this issue without > success. Any help with this issue would be appreciated. Below is > information I’ve gleaned which may be useful to identify the problem, in no > particular order: > > - This issue started with NetBeans 9. NetBeans 8 worked fine. > - This is a Maven project, which uses generated code from both Lombok > and Mapstruct. > - I have not proven that Mapstruct has anything to do with the > issue. I just mention it here as a potentially relevant piece of > information. > - I’ve tried using all Lombok versions since the issue started, > several Mapstruct versions, and various combinations. > - This issue affects all generated methods (setters, getters, > toString, etc). > - The project uses a custom source path instead of src/main/java. > Again, I’m not sure this is relevant. > - The project platform is JDK 8, while NetBeans runs on JDK 13. > - I’ve tried running NetBeans with JDK 10,11, and 12 as well. > - I’ve tried a clean install of NetBeans without importing preferences. > - I’ve tried NetBeans on several different computers (all my computers > are macOS, but the reporter of the issue reported it against Windows). > - I’ve tried many NetBeans-javac versions. > - I’ve tried a clean install without installing nb-javac at all. > - Editing and saving the Lombok-annotated bean will make the error > highlights in the files that reference the bean go away temporarily, but > they will eventually come back. > - This is not scalable because project has hundreds of beans, and > as I progress down the list of beans the error will eventually pop back > up > in the beans I already edited. > - Stopping NetBeans, removing its cache, and restarting temporarily > fixes the problem, but it eventually comes back. > - I haven’t figured out what sequence of events causes the error to > show up again, but it’s common enough that the problem resurfaces within > the day (often within minutes). > - Since it takes a long time to scan this project, and since it > takes a long time to rebuild other stuff in the cache, this is not > viable. > > > The last two points (and since the issue seems to be independent of > nb-javac) leads me to believe this is a caching issue of some type. > > Thanks, > Alvin > > P.S. - My apologies to Geertjan for tweeting this instead of bringing it > up here first. > > > -- http://timboudreau.com
