Library source does not match the bytecode for class

In solving this, I had no need to mess around with Maven, and dealt with IntelliJ IDEA alone.

For me this problem arose out of confusion between three concepts in the IntelliJ IDEA: modules, libraries and dependencies. I had different projects, using different packages, some of which were referring to each other in inconsistent ways. I was also being inconsistent about how to refer to downloaded third-party packages.

It was easy once I distinguished the three concepts of modules, libraries and dependencies. How I clarified them in my mind:

1) Libraries refer to code (compiled or not) which is not going to change.

2) Modules refer to parts of the project (yours if you are working alone) where the code is subject to change.

3) A dependency (for this conversation) is a library or other module which a particular module will use.

I got the error from adding the code of an ongoing project, which was originally created by another IDE, as a dependency in the IntelliJ IDEA. In theory this should work, and it does, but like you I can't ignore a big red banner across the top of my development environment!

To solve the problem:

Modules Open File>Project Structure>Modules, and using the top left green plus sign (not the one to the right) added other projects where the code is likely to change. This makes them 'alive' to IntelliJ, and not a dusty old immutable library which, if changed, might cause the alarm banner to shout at you. At this stage, only use the big panel taking up most of the dialog for checking the imported jars, source code, etc., to verify what you want has arrived.

Libraries Open File>Project Structure>Libraries, and again using the top left green plus sign add the folder containing the code that will not change. The other green plus sign to the right allows you to add internal folders to an already added library, but IntelliJ is good at finding these in different project structures, so consider starting from scratch adding a new library, rather than adding specific folders that you think are missing and causing multiple copies to exist, another thing which causes confusion (understandably) to IntelliJ.

Dependencies Now everything should be ready for you to return to File>Project Structure>Modules. This time go to the large panel taking up most of the dialog and change to the 'Dependencies' tab. My preferred way of working at this stage (particularly when the project is large and complex) is to work my way down the listed modules, adding the libraries and module dependencies for each module as I go. This time for each module use the green plus sign to the right to add each library or module that you need, and these should be offered to you from the ones added in the last step.

WARNING There are two important steps which you should be careful of when finishing the process:

1. Make sure that each dependency you added for each module has scope 'Compile' in the dependencies tab.

2. When you are finished, click the Apply button at the bottom of the Project Structures dialog before clicking OK. It seems like it should be automatic, like so much else in IntelliJ, but I do not think it is. I have lost changes I have made to the Project Structure by not clicking Apply before exiting the dialog.

Had same problem - did a gradlew clean from the command line, then went into Android Studio and did a File -> Invalidate Caches and Restart and all was well again..

There's nothing wrong with IDEA, nor your dependencies or local maven caches, it's correctly identifying the mismatch.

Here's how to check:

• Open class in question
• Click "Show diff"
• Choose "Ignore whitespaces and empty lines"

You can clearly see (ignoring JavaDoc and FQCNs) that the class file has extra checks included for the @NonNull annotated arguments. The import says lombok.NonNull, and the documentation shows this transformation will happen.

I guess the best course of action is either to ignore this warning or ask the project's maintainers to build the sources.jar from the lombok-processed source code if that's possible. I think they'll need to employ delomboking and this Maven plugin, but never built lombok code myself.