search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.61k stars 836 forks source link

AnnotationProcessor crashes with Lombok #7111

Closed realulim closed 5 months ago

realulim commented 5 months ago

Apache NetBeans version

Apache NetBeans 21

What happened

If you open the enclosed minimal example project, you can compile and run it just fine. However, the IDE cannot process the Lombok annotations (in this example project there is just one @Getter annotation, but it happens with all Lombok annotations) and there is a popup message under the cursor, which states as much. However, I did not catch the message, because it disappeard quickly again.

But you can easily see in the IDE, if you open the App.java file, that the line accessing the Lombok generated getter method is underlined with a red squiggly line, indicating that this getter method is not found by the IDE (although the compiler finds it just fine).

This is a Java 17 project. The latest Netbeans version that I have found that does not exhibit this problem is NB 18.

Language / Project Type / NetBeans Component

Gradle Project as generated by the IDE

How to reproduce

Open the attached example project.

Did this work correctly in an earlier version?

Apache NetBeans 18

Operating System

Fedora 38

JDK

OpenJDK 64-Bit Server VM (Red_Hat-17.0.9.0.9-4) (build 17.0.9+9, mixed mode, sharing)

Apache NetBeans packaging

Apache NetBeans binary zip

Anything else

TestProject.tar.gz

Are you willing to submit a pull request?

No

matthiasblaesing commented 5 months ago

The comment from @neilcsmith-net in #6937 - you are using lombok and you are not up-to-date. You depend on lombok 1.18.26, 1.18.30 is the fixed version. lombok messes with the compiler internals and thus is tightly coupled with it.

realulim commented 5 months ago

Thank you very much for providing the solution to this problem and clearly specifying the needed version.

However, I should like to mention that it did work with the exact same compiler version and other environment details in NB 18. Therefore it is a change in the IDE that triggered this bug and as such it is a breaking change.

Breaking changes cannot and should not be avoided, but they should be explained more prominently in the release notes. Users should be told that upgrading NB could mean that some of their older projects won't work anymore (and preferably what they could do about it). This would also avoid a large number of duplicate issues being raised.

neilcsmith-net commented 5 months ago

@realulim this is not to do with the version of the compiler used by the project, but the version of the compiler used inside the IDE to support NetBeans' Java editing. That is always based on the latest JDK. This is one of the key benefits of NetBeans, but occasionally is a source of problems like this. You can either switch off annotation processing in the editor, or make sure to use a version of Lombok that supports the latest compiler.

matthiasblaesing commented 5 months ago

However, I should like to mention that it did work with the exact same compiler version and other environment details in NB 18. Therefore it is a change in the IDE that triggered this bug and as such it is a breaking change.

You are confusing cause and effect. The issue is not that the java compiler changed. It is clearly spelled out, that the compiler internals are subject to change and exposed API can change at anytime. You can hook into the compilation process, but you are responsible to follow all changes of the compiler. The problem is lombok in this case. You chose to use lombok, you also chose to live with the breakage it causes.

realulim commented 5 months ago

If it is an internal implementation detail and it can change anytime - don't expose it. If you expose it, you are creating a public API and assume the responsibility for maintaining it.

NB 18 worked. NB 20+ doesn't. That is the definition of a breaking change. My suggestion merely was to better communicate breaking changes.

Of course it is the NB community's prerogative to deny that this was a breaking change or that breaking changes do not have to be communicated. You make your own image.

matthiasblaesing commented 5 months ago

The point is: NetBeans has nothing done here. We upgraded the compiler and the tool you chose to use broke it. I bet there are dozens of compiler plugins. We can't check all these. You now know, that lombok is fragile. You can now decide whether or not you want to use it.

realulim commented 5 months ago

Is Lombok breaking all IDEs or just NB?

Clearly, a user's expectation would be that the Java version specified in the project settings would have to match the Lombok version specified in the project settings. I find it a surprising requirement that I have to match project dependencies to undocumented internal IDE dependencies. The NB documentation states that the IDE runs with the JDK I specify in the netbeans.conf file.

matthiasblaesing commented 5 months ago

Is Lombok breaking all IDEs or just NB?

Don't know. Eclipse might or might not have been affected as they have their own javac, where I don't know how lombok hooks into that.

Clearly, a user's expectation would be that the Java version specified in the project settings would have to match the Lombok version specified in the project settings. I find it a surprising requirement that I have to match project dependencies to undocumented internal IDE dependencies. The NB documentation states that the IDE runs with the JDK I specify in the netbeans.conf file.

NetBeans uses a copy of the javac to parse java code and handle annotation processing, class parsing and such. That javac needs to be current to support new features. In the past NetBeans used the javac of the JDK it was running on, but reality is, that the javac API changes often enough, that this causes major overhead and was not stable. The error you saw is caused by the fact, that the javac in NetBeans is to new to use the old lombok version. You would have seen the same problem if you had tried to compile your code on an up-to-date JDK (aka 21).

For me the discussion ends at this point.

realulim commented 5 months ago

Thank you for your explanations. I appreciate the effort that goes into maintaining a project like Netbeans.

Lombok is an important tool for software quality. It helps enormously with removing some glaring drawbacks of generated code, while still retaining its benefits.

neilcsmith-net commented 5 months ago

@realulim maybe also read this https://github.com/oracle/javavscode/issues/83#issuecomment-1824893786 Lombok is a hack that uses internal APIs, hardly a great idea for software quality. There's not a lot that NetBeans can, or should, do about this. Take it up with the Lombok project.