Library source does not match the bytecode for class

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.

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.

I just copied the contents of the file and deleted it. Later I just created a new file with same name as the older one and pasted the code in it. It worked for me.

For me just recreating the file has worked.

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..

I had this problem and to my knowledge, I know two solutions to solve this:

1. click "build" on top of your IntellIj windows, then "Build project"

and/or

2. on the right side, you click on "maeven projects"(vertically written in small), then "clean"

In my case helped the next steps:

1. remove the library from local repository
2. rebuild the project

Just now I had this problem,

What helped me:

I've found .ideaLibSources folder, by selecting 'Copy path' in context menu after right-clicking on jar file (You could find jar-file link in upper region of idea, when file is opened in editor and it is in focus) then just removed unwonted-sources.jar from this folder. aaand redownload.

btw invalidate/restart didn't help

It is caused by old-compiled version of the package that relies in .m2/repository.

 All you need to do is
-> Find the package in m2 folder and delete it
-> Rebuild the required package or re-download from the repository
-> Reimport all packages in the project

Check for multiple sources attached to lib

It could be due to multiple sources defined in Libraries. Check and remove multiple sources under File > Project Structure > Libraries > lib with issue > Sources

e.g. File > Project Structure > Libraries > Maven: com.rohit:example:1.0.0 > Sources --> remove multiple sources

Here's what I did :

1. Invalidate caches and restart.
2. Rebuild the project (Build->Rebuild).
3. Rebuild with your build system (ex. mvn clean install).

Worked for me.

I had this problem after migrating an oldish app to Androidx. The issue turned out to be a problem with the ActionBar using an AppTheme style not compatible with Androidx. This was not picked up by the debugger. I fixed the issue by

1. changing the AppTheme setting in the res/values/styles.xml file to:

<style name="AppBaseTheme" parent="Base.Theme.AppCompat.Light.DarkActionBar">
</style>

2. followed by gradlew clean

The following worked in my case:

1. Locate the dependency in the project structure.
2. Right click on the dependency and Open Library settings.
3. Right click and delete the dependency.
4. Re-import all dependencies again.

In my case I got a secondary pom.xml in my project used for backup (pom.xml.versionBackup) which was causing this "Library source does not match the bytecode for class" nightmare. Nothing else worked (clean library cache, remote the .idea folder, remove the ~/.m2 folder, remove the *.iml files, remote the target folders, ...)

Usually invalidate caches & "gradle clean build" works but this time it didn't for some reason. After trying all the answers I decided just to close the project window, delete the .idea folder in the project folder, and open again the project with IntelliJ (it recreates the .idea folder once opening it as project). Worked flawlessly.

There is another reason. This class depends on other libraries, but the dependency is not managed by maven. Try to add this dependency in your Maven pom.xml.

This can happen when the library maintainer

• obfuscates the jar with e.g. proguard, e.g. to reduce the jar size
• but also publishes the source which is not obfuscated and, thus, differs from the byte code

You could build the jar yourself without obfuscation and use this as dependency.

• checkout the source code from github if the project is open source
• comment out the obfuscation tasks in the build.gradle file
• publish the jar to your local repository gradle publishToMavenLocal
• add mavenLocal() to the beginning of the repositories section of your project's build.gradle
• reference this jar version from your own project and rebuild your project

This happened to me while using a dependency management (azure bom) - the bom has a different version than what i explicitly have in the pom - resolution was to delete the other dependency and rely on the dependencies from the bom.