Grails Plugin: Run Config: Grails compiles app with project JDK 1.7 - but runs it with JDK 8 - causing class not found

After upgrading to Intellij 16, my grails run configurations don't work anymore.

As you can see below from the "Run dialog box", It compiles the grails app using jdk1.7 which is correct, but then it runs the application using jdk 1.8 - which fails : Caused by ClassNotFoundException: java.util.HashMap$Entry

I'm pretty sure a run config shouldn't compile with one JDK and run the application with a different JDK - Intellij Only runs on 1.8 so I can't change the ide to use 1.7.

If I run the grails command from right clicking on the application Grails-> Run Grails Command -> run-app - it compiles with 1.7 and runs with 1.7 - so the problem seems to be with the run configuration feature

/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java -Dgrails.home=/Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4 -Dtools.jar=/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/lib/tools.jar -Dgroovy.starter.conf=/Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4/conf/groovy-starter.conf -Xms4g -Xmx4g -XX:MaxPermSize=1g -javaagent:/Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4/lib/org.springframework/springloaded/jars/springloaded-1.2.4.RELEASE.jar -noverify -Dspringloaded=profile=grails;cacheDir=. -Dbase.dir=/Users/<hidden-personal-data>/source/umbrella/umbrella -Dfile.encoding=UTF-8 -classpath /Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4/lib/org.codehaus.groovy/groovy-all/jars/groovy-all-2.3.7.jar:/Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4/dist/grails-bootstrap-2.4.4.jar org.codehaus.groovy.grails.cli.support.GrailsStarter –main org.codehaus.groovy.grails.cli.GrailsScriptRunner –conf /Users/<hidden-personal-data>/.sdkman/candidates/grails/2.4.4/conf/groovy-starter.conf "run-app -plain-output"
objc[14294]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java (0x10e04f4c0) and /Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10e1114e0). One of the two will be used. Which one is undefined.
|Loading Grails 2.4.4
|Configuring classpath
.
|Environment set to development
.................................
|Packaging Grails application
......
|Compiling 2 source files
................................................................................................
|Running Grails application
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=1024m; support was removed in 8.0
objc[14318]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java (0x10c0384c0) and /Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/jre/lib/libinstrument.dylib (0x10c1004e0). One of the two will be used. Which one is undefined.
...
| Error 2016-11-11 16:14:14,451 [localhost-startStop-1] ERROR context.GrailsContextLoaderListener - Error initializing the application: java/util/HashMap$Entry

Ok I figured out the issue. The grails plugin no longer respects the project JDK when running in forked mode. I added JAVA_HOME to the run config environment variables to force the forked process to respect the correct java. This wasn’t an issue in 15 so something might have regressed either in the core or in the plugin. This workaround is fine for now.

The IDE terminal window doesn’t load my shell environment properly so it tries to run the project in 1.8. If i run grails from my mac’s terminal, it runs fine because grails recognizes my shell environment.

Also if I alt-command-G and run the grails command run-app – it works.

---

*Imported from [IDEA-164172](https://youtrack.jetbrains.com/issue/IDEA-164172) · Type: Bug · Votes: 0*
*Comments, attachments, dates and reporter are not part of the export — follow the link above for the full history.*

Start by comparing the Grails run configuration's forked-mode launch with the working Grails run-app command, using the reported Java 1.7/1.8 output and JAVA_HOME workaround as the reproduction. Trace how the run configuration selects Java, then verify that compilation and application startup use the project JDK without requiring an environment-variable override.

Written by the indexing model from the issue text.