Eclipse Gradle import error with Java 1.8: Unrecognized VM option 'MaxPermSize=256m'

[mrserverless]

I'm using:

• Mac OSX Yosemite
• Java 1.8_25
• Eclipse IDE for Java Developers 4.4.1.20140925-1820
• Gradle IDE 3.6.3.201411271013-RELEASE

My JAVA_HOME is set to 1.8. Downloaded Eclipse 4.4.1 and installed Gradle IDE. When importing a gradle project I get the following error:

!ENTRY org.springsource.ide.eclipse.gradle.core 4 0 2015-01-07 11:12:56.677
!MESSAGE Unable to start the daemon process.
This problem might be caused by incorrect configuration of the daemon.
For example, an unrecognized jvm option is used.
Please refer to the user guide chapter on the daemon at http://gradle.org/docs/2.2.1/userguide/gradle_daemon.html
Please read the following process output to find out more:
-----------------------
Unrecognized VM option 'MaxPermSize=256m'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

!STACK 0
java.lang.reflect.InvocationTargetException
    at org.springsource.ide.eclipse.gradle.core.util.GradleRunnable.run(GradleRunnable.java:112)
    at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Caused by: org.eclipse.core.runtime.CoreException: Unable to start the daemon process.

I tried various work arounds which didn't work:

• setting Java version to 1.7 in Eclipse preferences
• removing all references to MaxPermSize in eclipse.ini
• setting my JAVA_HOME environment variable to 1.7

In the end I had to hack the Info.plist file to force Java 1.7:

 <string>-vm</string><string>/Library/Java/JavaVirtualMachines/jdk1.7.0_55.jdk/Contents/Home/bin/java</string>

This isn't very elegant. The eclipse gradle plugin should support Java 1.8 out of the box.

[kdvolder]

Is that the entire stacktrace? I'd expect it to have more detailed location about exception origin as it most likely originates inside of Gradle tooling API implementation (when trying to start the daemon).

This is most likely a problem with tooling API implementation rather than STS tooling (STS itself doesn't start the daemon, it is the Gradle tooling API that does that. From what you are saying, it looks like Gradle Tooling API is trying to pass maxpermsize option to JDK 8 which no longer supports that option.

[mrserverless]

@kdvolder thanks for looking into this. Who should I raise the issue with for Gradle Tooling API?

[kdvolder]

Normally you start by asking a question on gradle forum and it then gets converted into an issue.

However, I'm not yet 100% sure this is a problem with gradle or with STS. Let me first try and reproduce the problem. I'll post back here later.

[kdvolder]

I tried reproducing the problem but cannot. For me stuff is running just fine with Java 8.

Maybe you are getting this vmarguments from somewhere else you customized long ago and forgot. Check the following in workspace preferences.

1. Any default VM arguments set in your JRE definiition?

Window >> Preferences >> Installed JREs. If you select a JRE and click 'Edit', theres a 'DefaultVM arguments section. Check what is in there.

2. VM arguments set by Gradle preferences?

Window >> Preferences >> Gradle >> Arguments

Check if maybe the permgen argument is being set there.

3. Launch configuration

Check if maybe you have existing Gradle launch configs that supply custom VM arguments:
External tools toolbar button menu (looks like a 'play icon' with suitcase) >> Run Configurations

Delete any old 'Gradle' launch configs you see there.

4. gradle.properties

See the docs here: http://www.gradle.org/docs/current/userguide/gradle_daemon.html
Section 19.4 says:

Some daemon settings, such as JVM arguments, memory settings or the Java home, can be configured. Please find more information in Section 20.1, “Configuring the build environment via gradle.properties”

Read that and check your gradle.properties (maybe in the project you are importing).

Hopefully in one of these places you will find who is supplying the 'bad' VM arguments.