This might not help you for now, but I also came across issues in my project which uses lombok. However it was not NetBeans specific. I wanted to upgrade to a new JDK, but a lot of tests were failing, upgrading lombok itself didn't resolve it. So I decided to take the long way and delomboked my source code.
Am Mo., 16. Dez. 2019 um 15:11 Uhr schrieb Alvin Thompson < [email protected]>: > Bump. Anyone, any suggestions? > > > On Dec 10, 2019, at 12:29 PM, Alvin Thompson <[email protected]> > 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. > > > > > > <Screen Shot 2019-07-25 at 4.14.03 PM.png> > >
