sdkman installed grails 4.0.4, now grails is broken and wont start - macos

Question

I have some older version of grails installed (3.3.8), and tried to use sdkman to install a newer version (4.0.4). The install worked, but grails is now completely broken. i also updated java to 14 from the dmg from the oracle website. Basically grails is now completely broken. Any ideas how to fix?
mac 10.14.4
$ sdk version
SDKMAN 5.7.3+337
$ sdk current java
Not using any version of java
$ java -version
java version "14.0.2" 2020-07-14
Java(TM) SE Runtime Environment (build 14.0.2+12-46)
Java HotSpot(TM) 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)
$ sdk current
Using:
groovy: 2.5.8
$ grails --version
| Grails Version: 3.3.8
| Groovy Version: 2.4.15
| JVM Version: 14.0.2
$ sdk install grails
Downloading: grails 4.0.4
In progress...
######################################################################## 100.0%
Installing: grails 4.0.4
Done installing!
Setting grails 4.0.4 as default.
$ sdk current
Using:
groovy: 2.5.8
$ grails --version
java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.vmplugin.v7.Java7
at org.codehaus.groovy.vmplugin.VMPluginFactory.<clinit>(VMPluginFactory.java:43)
at org.codehaus.groovy.reflection.GroovyClassValueFactory.<clinit>(GroovyClassValueFactory.java:35)
at org.codehaus.groovy.reflection.ClassInfo.<clinit>(ClassInfo.java:107)
at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:95)
at org.codehaus.groovy.reflection.ReflectionCache.<clinit>(ReflectionCache.java:39)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.registerMethods(MetaClassRegistryImpl.java:209)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:107)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:85)
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:86)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.bitwiseNegate(ScriptBytecodeAdapter.java:842)
at org.grails.config.NavigableMap.<clinit>(NavigableMap.groovy)
at org.grails.cli.GrailsCli.<clinit>(GrailsCli.groovy:77)
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.codehaus.groovy.reflection.ReflectionCache
at org.codehaus.groovy.runtime.dgmimpl.NumberNumberMetaMethod.<clinit>(NumberNumberMetaMethod.java:33)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
at java.base/java.lang.reflect.ReflectAccess.newInstance(ReflectAccess.java:124)
at java.base/jdk.internal.reflect.ReflectionFactory.newInstance(ReflectionFactory.java:346)
at java.base/java.lang.Class.newInstance(Class.java:604)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.createMetaMethodFromClass(MetaClassRegistryImpl.java:257)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:110)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.<init>(MetaClassRegistryImpl.java:85)
at groovy.lang.GroovySystem.<clinit>(GroovySystem.java:36)
at org.codehaus.groovy.runtime.InvokerHelper.<clinit>(InvokerHelper.java:86)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.bitwiseNegate(ScriptBytecodeAdapter.java:842)
at org.grails.config.NavigableMap.<clinit>(NavigableMap.groovy)
at org.grails.cli.GrailsCli.<clinit>(GrailsCli.groovy:77)
I dont see an easy way to uninstall java 14, or go back in time.
echo $PATH
/Users/xx/.sdkman/candidates/groovy/current/bin:/Users/xx/.sdkman/candidates/grails/current/bin:/Library/Frameworks/Python.framework/Versions/3.7/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Appz/apache-jmeter-5.3/bin:/usr/local/go/bin:/usr/local/share/dotnet:/opt/X11/bin:~/.dotnet/tools:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/xx/go/bin:/Users/xx/dev/grails-3.3.8/bin:/Users/xx/dev/flutter/bin:/Users/xx/dev/gradle-5.1.1/bin:/appz/cassandra/bin
I am guessing I can try to hack the path etc, to fix.
This is my current .bash_profile:
vi .bash_profile
export JAVA_HOME=`/usr/libexec/java_home`
export GRAILS_HOME=/Users/xx/dev/grails-3.3.8
export GOPATH=$HOME/go
export GOBIN=$GOPATH/bin
export PATH=$PATH:$GOBIN
export PATH=$PATH:$GRAILS_HOME/bin
# Setting PATH for Python 3.7
# The original version is saved in .bash_profile.pysave
export GRADLE_HOME=/Users/xx/dev/gradle-5.1.1
PATH="/Library/Frameworks/Python.framework/Versions/3.7/bin:${PATH}"
PATH="${PATH}:/Users/xx/dev/flutter/bin"
PATH=$PATH:$GRADLE_HOME/bin
# Cassandra
if [ -d "/appz/cassandra" ]; then
export PATH="$PATH:/appz/cassandra/bin"
fi
export PATH
#THIS MUST BE AT THE END OF THE FILE FOR SDKMAN TO WORK!!!
export SDKMAN_DIR="/Users/simonh/.sdkman"
[[ -s "/Users/xx/.sdkman/xx/sdkman-init.sh" ]] && source "/Users/xx/.sdkman/bin/sdkman-init.sh"
~
This is odd, why is grails home still 3.3.8, when sdkman installed and made 4.0.4 current? Why didnt it edit the path? What version should I set gradle to? How do I go back to java 8, as I think there are bugs in java 14 which is causing issues with grails?

Answer 1

OK, figured it out.
First, I had to manually fix the java version.
To do this go to
$ /usr/libexec
$ ./java_home -V
This outputs one or more versions:
14.0.2, x86_64: "Java SE 14.0.2" /Library/Java/JavaVirtualMachines/jdk-14.0.2.jdk/Contents/Home
1.8.0_131, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home
Now edit our .bash_profile and replace the JAVA_HOME line with the version you want, either the whole thing (1.8.0_131) or just the major (1.8) thusly:
export JAVA_HOME=`/usr/libexec/java_home -v 1.8`
Now when you open a new window, and do "java -version" you get 1.8, and when you do "grails -version" I finally get 4.0.4.
Yay!
The strange part is that just changing JAVA_HOME should not affect whats on the path, but it seems to. i.e. just setting JAVA_HOME should not affect what version of java is run when I type in "java", but it does. i.e. there is no line suchy as "PATH=$PATH:$JAVA_HOME/bin in muy bash_profile.