phantom "ambiguous method" errors when using Lombok

[Alvin Thompson <al...@thompsonlogic.com>]

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.

Re: phantom "ambiguous method" errors when using Lombok

[Mario Schroeder <ma...@gmail.com>]

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 <
alvin@thompsonlogic.com>:

> Bump. Anyone, any suggestions?
>
> > On 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.
> >
> >
> > <Screen Shot 2019-07-25 at 4.14.03 PM.png>
>
>

Re: phantom "ambiguous method" errors when using Lombok

[Alvin Thompson <al...@thompsonlogic.com>]

Bump. Anyone, any suggestions?

> On 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.
> 
> 
> <Screen Shot 2019-07-25 at 4.14.03 PM.png>

Re: phantom "ambiguous method" errors when using Lombok

[Alvin Thompson <al...@thompsonlogic.com>]

> On Dec 10, 2019, at 2:56 PM, Tim Boudreau <ni...@gmail.com> wrote:
> 
> 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.

I hear you and agree (to some degree). Entire classes of problems magically go away when everything is immutable. But it’s way too late to consider that for this project.

Re: phantom "ambiguous method" errors when using Lombok

[Alvin Thompson <al...@thompsonlogic.com>]

Yep, deleting the cache fixes it in this case as well, but it’s only temporary.


> On Dec 10, 2019, at 2:56 PM, Tim Boudreau <ni...@gmail.com> wrote:
> 
> 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.

Re: phantom "ambiguous method" errors when using Lombok

[Tim Boudreau <ni...@gmail.com>]

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