mplushnikov / lombok-intellij-plugin

Lombok Plugin for IntelliJ IDEA
Apache License 2.0
3.11k stars 635 forks source link

Library does not match the bytecode for class XXX #438

Open bironran opened 6 years ago

bironran commented 6 years ago

Short description

When using libraries built with lombok and attaching source with lombok annotations, IntelliJ complains about mismatch between source and class file.

Expected behavior

IntelliJ should not complain about mismatch since the source, when lombok-ed, will compile to the provided class.

Version information

Steps to reproduce

  1. In a source root run the following

mvn archetype:generate -DgroupId=com.test.rb.m1 -DartifactId=module1 -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

mvn archetype:generate -DgroupId=com.test.rb.m2 -DartifactId=module2 -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

  1. update module 1 pom.xml: 2.1 add lombok dependency
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.6</version>
            <scope>provided</scope>
        </dependency>

    2.2 add source plugin

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
  2. update module 1 App.java:

    @Setter
    @Getter
    public class App {
    private String myField;
    
    @SneakyThrows
    public void ex() {
        throw new Exception("ex");
    }
    
    public static void main(String[] args) {
        System.out.println("Hello World!");
    }
    }
  3. update module 2 pom.xml - add dependency on module 1:
        <dependency>
            <groupId>com.test.rb.m1</groupId>
            <artifactId>module1</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
  4. run "mvn install" on module 1
  5. open module 2 in IntelliJ, open class "com.test.rb.m1.App"

IntelliJ shows a red error "Library source does not match the bytecode for class App"

Sample project

Please provide a sample project that exhibits the problem. See lombok_bug.tar.gz](https://github.com/mplushnikov/lombok-intellij-plugin/files/1620326/lombok_bug.tar.gz) You should also include .idea folder so we can inspect the settings.

Additional information

no

Stacktrace

none

arikkfir commented 6 years ago

Yes this is sorely needed - we built all our reusable libraries with Lombok, only to discover that users have a hard time using them in their projects, since the library source code is not synchronized; it makes debugging that much harder...

wujun8 commented 6 years ago

@mplushnikov Any updates on this?

mjustin commented 5 years ago

I came up with a even simpler project to reproduce this issue when I was debugging this issue locally:


Create a Maven project from the pom below. Then open the org.springframework.data.convert.CustomConversions.java class (Navigate -> Class…). A red warning message appears at the top of the file, with the message "Library source does not match the bytecode for class CustomConversions". Clicking the "Show diff" link will show that it's comparing the pre-processed Java file with the post-processed .class file.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>test</groupId>
    <artifactId>idea-lombok-warning</artifactId>
    <version>1.0-SNAPSHOT</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.data</groupId>
            <artifactId>spring-data-commons</artifactId>
            <version>2.1.2.RELEASE</version>
        </dependency>
    </dependencies>
</project>
alexejk commented 5 years ago

This is the issue that you will have with Lombok itself and not this plugin specifically. Bytecode generated with lombok is going to differ from what you see in sources - thats the nature of Project Lombok.

You can generate sources explicitly with delombok step if you want and package it - but I'm not entirely sure what are you expecting this IntelliJ plugin to do.

FYI, at my workplace we are not having this issue when using Lombok Plugin for all developers in their IDE even if libraries are built with lombok - so I believe it's mainly an issue on the setup/user side or an issue of not understanding how things work behind the scenes.

wujun8 commented 5 years ago

@alexejk The fact that you are not having this issue when using Lombok Plugin probably is because of you don't download the source files for the jars, the bytecode has the whole code that Lombok generated, so no errors show. But normally, we're more likely interested in source files, you know the bytecode is really not for reading. Maybe, this IntelliJ plugin can adopt the feature that combining the source and bytecode, so we can achieve that:

  1. Still see the original source code with all comments
  2. Still can trace the stacktrace without errors

THX

alexejk commented 5 years ago

Well we are downloading sources for all of our JARs and also publishing them.

But either way, while cases and setups vary (which may lead to differences) I can only suggest that you change packaging sources with delomboked code, which is done with your build system (E.g maven/gradle). This will allow any IDE to see sources of getter and setters and match byte code even if they don't have Lombok support. Packaging is not responsibility of this plugin and as sources are unmodifiable it would be quite confusing for this plugin to modify those (if even possible to augment those to begin with - I wouldn't be surprised if the platform has restrictions on that)

maxidelo commented 5 years ago

I've done a work a round that helped me to solve this problem. Using this plugin (https://plugins.gradle.org/plugin/io.freefair.lombok) what I do is to delombok my files and use them to create the source. It's not the best solution but at least now the source is pure Java and it can be debugged.

build.gradle

plugins {
    id "io.freefair.lombok" version "3.2.1"
}

apply plugin: 'maven-publish'

task sourcesJar(type: Jar) {
    from 'build/delombok/main'
    archiveClassifier = 'sources'
}

publishing {
    ...
}

tasks.getByName("publish").dependsOn(delombok)
wujun8 commented 5 years ago

@mdelorenzo If you only want to achieve that

the source is pure Java and it can be debugged

It is already done by "Java Bytecode Decompiler" plugin which is bundled in IDE. The true desire is:

  1. Still see the original source code with all comments
  2. Still can trace the stacktrace without errors

Not sure which files do you use to delombok, source code, or bytecode?

maxidelo commented 5 years ago

@wujun8 the problem is when you use your library (that uses lombok) on other project. When you want to debug this library the bytecode is different, as they're lombok generated (you'll see an error on the IDE like library source does not match the bytecode). So the only approach to solve this that I found is to delombok your source files before publishing it on the repository.

shark300 commented 2 years ago

Happy birthday! 🎂 Aaaahhh, it is too late.

KyranRana commented 1 year ago

Any update on this?

alexejk commented 1 year ago

Given that this plugin is now bundled into IntelliJ since about 2 years ago - I do not believe there will be any movement on this front in this repository. From what I understand most of the updates are now done as part of the IntelliJ bundled plugin development.

@mplushnikov you might be able to provide more details and set expectations 😄

magicprinc commented 1 year ago

+1

gonkon commented 1 year ago

+1

nagkumar commented 1 year ago

+1