Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gradle+Lombok compile error on @Builder, works in Eclipse with Lombok #1646

Open
bvkatwijk opened this issue Apr 7, 2018 · 1 comment
Open

Gradle+Lombok compile error on @Builder, works in Eclipse with Lombok #1646

bvkatwijk opened this issue Apr 7, 2018 · 1 comment

Comments

@bvkatwijk
Copy link

@bvkatwijk bvkatwijk commented Apr 7, 2018

I'm running into a compilation error when compiling with Gradle using @Builder. Eclipse with Lombok installed does not raise a compilation error. The following is a minimal reproduction of the issue:

A.java:

import java.util.List;
import java.util.stream.Collectors;
import java.util.stream.IntStream;

import lombok.Builder;
import lombok.RequiredArgsConstructor;

@Builder
@RequiredArgsConstructor
public class A {

	private final List<Object> list;

	public static class ABuilder {

		private List<Object> list = IntStream.range(0, getInt())
				.mapToObj(i -> new Object())
				.collect(Collectors.toList()); 

		private int getInt() {
			return 10;
		}

	}

}

Running ./gradlew jar gives the following error:

A.java:10: error: incompatible types: no instance(s) of type variable(s) T exist so that Collector<T,?,List<T>> conforms to int
@Builder
^
  where T is a type-variable:
    T extends Object declared in method <T>toList()

Some remarks about this example:

  • Inlining the getInt method removes the compilation error
  • Replacing Collectors.toList() with Collectors.<Object>toList() removes the compilation error
  • Removing @Builder removes the compilation error

build.gradle:

plugins {
    id 'net.ltgt.apt' version '0.10'
}

apply plugin: 'java'
apply plugin: 'eclipse'

sourceCompatibility = 1.9

repositories {
    mavenCentral()
}

dependencies {
    compileOnly group: 'org.projectlombok', name: 'lombok', version: '1.16.20'
    apt "org.projectlombok:lombok:1.16.20"
}

Gradle Wrapper Version:

------------------------------------------------------------
Gradle 4.5.1
------------------------------------------------------------

Build time:   2018-02-05 13:22:49 UTC
Revision:     37007e1c012001ff09973e0bd095139239ecd3b3

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          9.0.4 (Oracle Corporation 9.0.4+11)
OS:           Mac OS X 10.13.3 x86_64
@wrprice
Copy link

@wrprice wrprice commented Apr 9, 2018

Maybe a javac bug in the improved type inference code? Compiling on Java 8 works for me, but 9 and 10 fail. Passing -Xdiags:verbose to javac provides additional details, note that the required/found actually match in spite of what the error says:

error: method range in interface IntStream cannot be applied to given types;
@Builder
^
  required: int,int
  found: int,int
  reason: argument mismatch; no instance(s) of type variable(s) T exist so that Collector<T,?,List<T>> conforms to int
  where T is a type-variable:
    T extends Object declared in method <T>toList()

Possibly related:

  • JDK-8178150: Regression in logic for handling inference stuck constraints
  • JDK-8189683: Non-deterministic solving order of inference variables

On that second one, note these comments:

The dependencies of an inference node are currently stored in a 'HashSet' that doesn't preserve insertion order . . . In addition to that, 'hashCode()' is inherited from 'Object' giving no guarantee of consistency between two compilations of the same code sample . . .

Tarjan's algorithm iterates on these dependencies to compute the acyclic graph determining the solving order which is then non-deterministic . . .

Picking a node to be solved from a stuck expression also iterates on those dependencies leading to a non-deterministic solving order too . . .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.