Hi,
it seems gradle 1.5 (and also 1.6) has problems with lombok’s eclipse integration:
Setup: - Gradle 1.5 - Eclipse Juno Service Release 1 - Lombok 0.11.8 (added to eclipse.ini via lombok installer) - Springsource STS (tried current release, milestone, nightly)
When importing a gradle project (via STS) it hangs during “Build Model”.
Works with 1.4 and also works when removing Lombok from the eclipse.ini.
Can you find any useful information in the Eclipse error log?
Nothing special there. It hangs with the “Build model” progress dialog at ~50%. After that I have to kill the process…
Here are parts of the thread dump: I have org.gradle.daemon=false, still it creates a ‘daemon’ dir in my gradle home and a gradle build daemon thread.
2013-04-30 12:26:48 Full thread dump Java HotSpot™ 64-Bit Server VM (23.5-b02 mixed mode):
“Run Gradle build daemon” prio=6 tid=0x000000001c62e800 nid=0x5dc waiting on condition [0x0000000020a7e000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
at java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:460)
at java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:359)
at java.util.concurrent.SynchronousQueue.poll(SynchronousQueue.java:942)
at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Locked ownable synchronizers:
“Connection worker” prio=6 tid=0x000000001457f800 nid=0x2a00 waiting on condition [0x000000002090e000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
at org.gradle.process.internal.DefaultExecHandle.start(DefaultExecHandle.java:236)
at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startProcess(DefaultDaemonStarter.java:104)
at org.gradle.launcher.daemon.client.DefaultDaemonStarter.startDaemon(DefaultDaemonStarter.java:90)
at org.gradle.launcher.daemon.client.DefaultDaemonConnector.createConnection(DefaultDaemonConnector.java:96)
at org.gradle.launcher.daemon.client.DefaultDaemonConnector.connect(DefaultDaemonConnector.java:73)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:147)
at org.gradle.launcher.daemon.client.DaemonClient.execute(DaemonClient.java:72)
at org.gradle.tooling.internal.provider.DaemonGradleLauncherActionExecuter.execute(DaemonGradleLauncherActionExecuter.java:42)
at org.gradle.tooling.internal.provider.DaemonGradleLauncherActionExecuter.execute(DaemonGradleLauncherActionExecuter.java:29)
at org.gradle.tooling.internal.provider.LoggingBridgingGradleLauncherActionExecuter.execute(LoggingBridgingGradleLauncherActionExecuter.java:53)
at org.gradle.tooling.internal.provider.LoggingBridgingGradleLauncherActionExecuter.execute(LoggingBridgingGradleLauncherActionExecuter.java:30)
at org.gradle.tooling.internal.provider.DefaultConnection.run(DefaultConnection.java:142)
at org.gradle.tooling.internal.provider.DefaultConnection.run(DefaultConnection.java:132)
at org.gradle.tooling.internal.provider.DefaultConnection.run(DefaultConnection.java:107)
at org.gradle.tooling.internal.consumer.connection.BuildActionRunnerBackedConsumerConnection.run(BuildActionRunnerBackedConsumerConnection.java:38)
at org.gradle.tooling.internal.consumer.ModelProvider.provide(ModelProvider.java:78)
at org.gradle.tooling.internal.consumer.connection.LazyConnection$1.run(LazyConnection.java:98)
at org.gradle.tooling.internal.consumer.connection.LazyConnection.withConnection(LazyConnection.java:106)
at org.gradle.tooling.internal.consumer.connection.LazyConnection.run(LazyConnection.java:96)
at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConnection$1.run(ProgressLoggingConnection.java:57)
at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConnection.run(ProgressLoggingConnection.java:71)
at org.gradle.tooling.internal.consumer.connection.ProgressLoggingConnection.run(ProgressLoggingConnection.java:55)
at org.gradle.tooling.internal.consumer.connection.LoggingInitializerConnection.run(LoggingInitializerConnection.java:52)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$1.run(DefaultAsyncConnection.java:51)
at org.gradle.tooling.internal.consumer.async.DefaultAsyncConnection$2.run(DefaultAsyncConnection.java:69)
at org.gradle.internal.concurrent.DefaultExecutorFactory$StoppableExecutorImpl$1.run(DefaultExecutorFactory.java:66)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Locked ownable synchronizers:
The tooling API, and therefore also IDE integration, always uses a Gradle daemon.
Any idea what change from 1.4 to 1.5 could cause this failure ?
Additional information on the issue is at https://issuetracker.springsource.com/browse/STS-3495. SpringSource is indicating it is not their issue.
I have the same issue. BTW, it occurs only on Windows. Mac and Linux Eclipses work just fine. SpringSource closed the issue on their side after isolating to Gradle Tooling API JAR. I just tested it after upgrade to Gradle 1.7 from 1.6 (Eclipse Preferences > Gradle points to system installation of Gradle).
Let me set straight that I cannot 100% say that the issue is not something in the Eclipse/STS tooling. Though it seems unlikely to me. In any case I don’t know enough about how the tooling API connects to the daemon to debug why it is failing and hanging in this instance.
I’m not opposed to reopening the STS issue and doing more work on it if more info comes to light pointing the finger at STS.
Maybe I, as one of the developers of Lombok, can be of assistance?
I’d be more than happy to have some help from you.
Let me give you a bit of background on the problem. When Lombok is installed in Eclipse on Windows, the Gradle tooling locks up when trying to spin up the Gradle daemon. If I uninstall Lombok from Eclipse, the Gradle tooling works fine.
Kris and I have done some debugging, and have localized where it occurs, but we haven’t been able to find out why it occurs or reproduce it outside of the Eclipse environment. See the STS tracker for details on our debugging: https://issuetracker.springsource.com/browse/STS-3495
The issue appears to happen across a range of versions, but for reference, my Gradle version is 1.6, the Lombok version is 0.12, the Gradle IDE is 3.3.0.201307040643-RELEASE org.springsource.ide.eclipse.gradle.feature.feature.group, and the Eclipse version is: Eclipse Java EE IDE for Web Developers.
Version: Juno Service Release 2 Build id: 20130225-0426
© Copyright Eclipse contributors and others 2005, 2013. All rights reserved. Visit http://www.eclipse.org/webtools
Lombok v0.12.0 “Angry Butterfy” is installed. http://projectlombok.org/
The comment threading doesn’t like me 
See the response below…
Hi Boyd,
Can you contact me directly? I do have a Gmail account and my username is is displayed as author of this post
Roel
After talking to Boyd, we are going to do some more investigation: - Boyd will try to use a renamed jar in Eclipse to see if using the same jar in Eclipse and in the project is problematic - Roel will try and set up an environment to reproduce the behavior.
Well, I can reproduce something:
In a clean workspace: - In Eclipse, choose [File/New/Project…] - In the [New Project] dialog, choose [Gradle/Gradle Project] - Press [Next] - Enter a project name - In [Sample project], select [Java Quickstart] - Press [Finish]
I got two separate results: the first time, the project was not created but some files were. Unfortunately, I didn’t make a copy of that result and I can no longer reproduce it.
Since then, all files are created, and so is the project. But building the project is always stuck at 15%.
Well, after disable pieces of lombok, I did found out that the problem goes away when we remove the code responsible for post-compilation bytecode manipulation. I don’t know exactly what’s going on though. If I replace the code with a no-op, the compiler still hangs. There might be a lock on the classloader, since this is the first time the PostCompiler class is accessed. A possible solution might involve loading the PostCompiler class during or just after instrumentation instead of on first use.
I suspect that the compilation takes place from a static initializer block or static field initializer that is loaded from a different thread, or that a classloader instance is used to synchronize on by a different thread. I’ll add this information to the SpringSource issue, and ask them to reinvestigate.
I’ve added the information above to https://issuetracker.springsource.com/browse/STS-3495
Unfortunately there isn’t really much new information here that I can do something with. The info stil points at some interaction between Gradle and Lombok being responsible for the hang.
Classloader locks are certainly not uncommon in Eclipse environment so its a fair guess, but tthe only stacktrace that I have seen of this problem so far has no obvious sign of a classloader being involved in the lockup.
So, I have the same issue. Clean installation of Eclipse, Gradle 1.8 and Lombok 0.12 on Windows XP and JDK 1.7.40
Eclipse IDE for Java Developers Kepler Service Release 1, Build id: 20130919-0819 * gradle plugin Gradle IDE 3.3.0.201307040643-RELEASE
Gradle 1.8 * Lombok 0.12 (added to eclipse.ini via lombok installer)
When I tried to create new gradle project, it hung like r.spilker has mentioned, with project files being generated (build.gradle and src contents ), when i ran the project in console it worked just fine. I recreated it in eclipse as regular java project with the same name and location, edited gradle.build to append gradle nature, ran ‘gradle cleanEclipse eclipse’ from console and refreshed workspace - all fine. Then I tried to create external tool configuration for this project, and it kept hanging on ‘building gradle model’ or something similar, operation could be stopped only by killing eclipse.
Then, when I disabled Lombok in Eclipse.ini, and ‘building gradle model’ completed without a hassle, after enabling Lombok it was working fine for this project, but when I created a new project, with different name, it failed as described in the beginning.
So, I guess the problem lies somewhere in project creation or initialization.
r.spilker did You try to create a new project with different name ?