We Keep Coding

VSCode error 'Java Home is different' when trying to develope on Mac

I am trying to develope my java app on Mac usig Gradle + openjdk. I have installed the openjdk using homebrew.
When I open my workspace in VSCode, I get the following error...
Could not run phased build action using connection to Gradle distribution 'https://services.gradle.org/distributions/gradle-5.4.1-bin.zip'.
The newly created daemon process has a different context than expected.
It won't be possible to reconnect to this daemon. Context mismatch:
Java home is different.
Wanted: DefaultDaemonContext[uid=null,javaHome=/opt/homebrew/opt/openjdk#11,daemonRegistryDir=/Users/myusername/.gradle/daemon,pid=13909,idleTimeout=null,priority=NORMAL,daemonOpts=--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=utf8,-Duser.country=CA,-Duser.language=en,-Duser.variant]
Actual: DefaultDaemonContext[uid=2e7a0e3f-ef48-46c7-add0-0230d33c95eb,javaHome=/opt/homebrew/Cellar/openjdk#11/11.0.12/libexec/openjdk.jdk/Contents/Home,daemonRegistryDir=/Users/myusername/.gradle/daemon,pid=13916,idleTimeout=10800000,priority=NORMAL,daemonOpts=--add-opens,java.base/java.util=ALL-UNNAMED,--add-opens,java.base/java.lang=ALL-UNNAMED,--add-opens,java.base/java.lang.invoke=ALL-UNNAMED,--add-opens,java.prefs/java.util.prefs=ALL-UNNAMED,-XX:MaxMetaspaceSize=256m,-XX:+HeapDumpOnOutOfMemoryError,-Xms256m,-Xmx512m,-Dfile.encoding=utf8,-Duser.country=CA,-Duser.language=en,-Duser.variant]
When I run echo $JAVA_HOME I get the following output...
/opt/homebrew/opt/openjdk#11

Did you try to set the setting java.import.gradle.java.home in VS Code with your expected javaHome path?

Eclipse aarch64 and OpenJDK (ARM)

I'm trying out the Eclipse 4.20 builds available as Mac OSX (64 bit version for Arm64/AArch64) running under macOS 11 on Apple Silicon. This version doesn't seem to come with a jdk, so I've assumed I need to handle that myself. I installed 16.0.1-librca from Bellsoft with SDKman (Rosetta2 mode false).
I edited the info.plist file of Eclipse like this:
<key>Eclipse</key>
<array>
<string>-vm</string>
<string>~/.sdkman/candidates/java/16.0.1-librca/bin/java</string>
…(Other stuff here)
</array>
and Eclipse does indeed startup, but crashes right away. A while after this macOS claims I don't have the permissions to start the app. Results are identical with the Zulu AArch64.
I typically get
"Exception Type: EXC_BAD_ACCESS (SIGABRT) Exception Codes:
KERN_INVALID_ADDRESS at 0x000000000000000c"
and
"Application Specific Information: abort() called"
in libjvm.dylib.
This with some variations depending on the setup used.
Assuming these releases are supposed to work in macOS 11 on Apple Silicon, then it would seem likely this should be possible to get working. Or have I misunderstood the meaning of aarch64 here? Are these perhaps just versions for jdk developers? I looked over the "Target Environments" for Eclipse and feel unsure what other uses a version labelled as "Mac…for Arm64/AArch64" would have here.
libexec doesn't see the SDKman installed version. When I run java --version in the terminal it does show "openjdk 16.0.1 2021-04-20" and not my main Oracle JDK.
Any suggestions on how to set this up?

I have yet to investigate the actual reason, but after I had installed the "OpenJDK 64-Bit Server VM Zulu (build 11.0.11+9-LT)" and I had started to contemplate overriding eclipse.ini in order to avoid macOS preventing me from starting a modified app (recurrent issue. Note I didn't attempt overriding) I started Eclipse from the command line with the open command and Eclipse starts right up using
-vm
/Users/[user name]/.sdkman/candidates/java/11.0.11-zulu/zulu-11.jdk/Contents/Home/bin/`
At least this starts Eclipse. Double clicking the app renders the same results as before.
A theory is that since the open command runs in the terminal and java --version verifies the zulu jdk set there by sdkman, this is why. However JAVA_HOME is empty and the /usr/libexec/java_home -V command only lists the Oracle JDK.
Thank you #greg-449 and #howlger. I don't think I'd found this without your helpful suggestions.
To not have to be in the terminal just for starting Eclipse I made this little Applescript that opens Terminal (Just executing the command without it involved wouldn't supply the proper JVM):
on run {input, parameters}
tell application "Terminal"
activate
do script "open /Applications/Eclipse.app"
delay 1
close front window
end tell
Save that as an app and start with this instead of Eclipse.
If I could find out how the proper JVM in Terminal is supplied to Eclipse with the open command, maybe this can be used for modifying how Eclipse starts.

Using different JDK locations on different processes might cause Gradle to spawn multiple daemons. [Android Studio 4.1] [duplicate]

I was building my test app in Android Studio, then in the Event Log it said:
Android Studio is using this JDK location: C:\Program
Files\Android\Android Studio\jre which is different to what Gradle
uses by default: C:\Program Files (x86)\Java\jdk1.8.0_181 Using
different locations may spawn multiple Gradle daemons if Gradle
tasks are run from command line while using Android Studio.
Then gave these options:
More info...
Set Android Studio to use the same JDK as Gradle and sync
Do not show this warning again
I clicked on:
Set Android Studio to use the same JDK as Gradle and sync
then my app didn't want to build any more.
This is the error:
Gradle sync failed: 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 Manual chapter on the daemon at
https://docs.gradle.org/5.4.1/userguide/gradle_daemon.html
Process command line: C:\Program Files (x86)\Java\jdk1.8.0_181\bin\java.exe
-Xmx1536m -Dfile.encoding=windows-1252 -Duser.country=ZA -Duser.language=en -Duser.variant -cp C:\Users\{MyUserName}\.gradle\wrapper\dists\gradle-5.4.1-all\3221gyojl5jsh0helicew7rwx\gradle-5.4.1\lib\gradle-launcher-5.4.1.jar
org.gradle.launcher.daemon.bootstrap.GradleDaemon 5.4.1
Please read
the following process output to find out more:
Error occurred during initialization of
VM Could not reserve enough space for 1572864KB object heap
Consult IDE log for more details (Help | Show Log) (16 s 166 ms)
I checked the event logs:
I think previously it did this:
Instructing gradle to use java from C:/Program Files/Android/Android
Studio/jre
Now it says this:
Instructing gradle to use java from C:/Program Files
(x86)/Java/jdk1.8.0_181
How do I set it back to the way it was so my app can build again?
Any help / advice will be appreciated

Go to File, Project Structure, SDK location and change the JDK location dropdown to JAVA_HOME.

You need to change/add an environment variable.
Follow this link to know how to change/add environment variables.
Now add/modify the variable 'JAVA_HOME' and set the path to C:\Program Files\Android\Android Studio\jre
Note: When you are going to work on a different Java project later on in a different IDE, you might have to change this variable again to the default Java location (in this case perhaps C:/Program Files (x86)/Java/jdk1.8.0_181)

Ubuntu 16.04 LTS, Android Studio 3.6
That's how I got rid of the warning:
1) locate the AS launcher script studio.sh on your machine, mine is under: /opt/android-studio-3.x/bin
2) inside the script, you'll find the following lines:
# ---------------------------------------------------------------------
# Locate a JDK installation directory which will be used to run the IDE.
# Try (in order): STUDIO_JDK, studio.jdk, ./jre64, JDK_HOME, JAVA_HOME, "java" in PATH.
# ---------------------------------------------------------------------
if [ -n "$STUDIO_JDK" -a -x "$STUDIO_JDK/bin/java" ]; then
JDK="$STUDIO_JDK"
fi
if [ -z "$JDK" -a -s "$HOME/.AndroidStudio3.6/config/studio.jdk" ]; then
USER_JRE=`"$CAT" $HOME/.AndroidStudio3.6/config/studio.jdk`
...
3) if, for some reason, you're unable to export your environment variables to the launcher (like it happens to me from the xfce4 session), you can write the desired JAVA_HOME value inside the studio.jdk file whose location on my system, as per the script, is in $HOME/.AndroidStudio3.6/config/studio.jdk.
$ echo $JAVA_HOME > $HOME/.AndroidStudio3.6/config/studio.jdk
$ cat $HOME/.AndroidStudio3.6/config/studio.jdk
/usr/lib/jvm/java-8-oracle
4) lastly, by restarting AS from the DE session, you should see the JAVA_HOME under the File -> Project Structure -> SDK Location window set to the above value and both AS and gradle should use the same JRE:

On Android Studio I did:
File > Project Structure... > SDK Location (On the left pane)
Then at the bottom there is a drop down below: JDK location:
I then selected / browsed to this directory:
C:\Program Files\Java\jdk1.8.0_181
Gradle Sync worked again for me after that but I still get this warning:
Android Studio is using this JDK location: C:\Program
Files\Java\jdk1.8.0_181 which is different to what Gradle uses by
default: C:\Program Files (x86)\Java\jdk1.8.0_181. Using
different locations may spawn multiple Gradle daemons if Gradle tasks
are run from command line while using Android Studio.
More info...
Set Android Studio to use the same JDK as Gradle and sync project
Do not show this warning again

Gradle is clearly using my native java installation (from Oracle) whereas Android Studio is using its own version.
I have been ignoring this warning since the upgrade of Android Studio to 3.6.1.
No issue so far. Indeed, I have released new versions of my app without issues.
If this becomes annoying, and IF you have no other issues, you have an option to ignore future warnings: Just press the warning and select option to ignore future messages related to this warning.

Update for Android Studio "Artic Fox | 2020.3.1 Patch 4" running on Linux (5.3.0-62-generic #56~18.04.1-Ubuntu) using Xfce4 Desktop environment.
This way allows for using independent, i.e. not synchronized, JRE/JDK versions on system and Android Studio.
Changed: The Gradle settings have been moved to
File -> Settings -> Build, Execution, Deployment -> Build Tools -> Gradle
To use unique JRE/JDK for Gradle execution:
Open Gradle Settings and note the "Gradle JDK" Path.
Hint: To select
"Embedded JDK" first, if available, should be an appropriate choice.
Edit the properties of the Android Studio starter (on Start Menu, Desktop, system menu bar, ...) , which should look like
/home/USERNAME/android-studio/bin/studio.sh
and change to
/bin/bash -c "export JAVA_HOME=<GRRADLE JDK PATH FROM
1.>;/home/m/android-studio/bin/studio.sh"
Hint (untested): May be possible to insert the export JAVA_HOME=... statement into the studio.sh script, which may be overwritten on updates.
Check: After applying changes start Android Studio and execute Build -> Rebuild Project: The error message should have disappeared. Then check the same after File -> Invalidate Caches / Restart. Last, open the Android Studio embedded Terminal (bottom line click) and execute echo $JAVA_HOME. That should show the <GRADLE JDK PATH FROM 1.>, while a terminal opend from outside Android Studio should still show the (different) system's JAVA_HOME.

Eclipse (Java/SWT App): Reconfigure to run as 64-bit

I am trying to reconfigure my Java WindowBuilder SWT application to be 64-bit, not 32-bit.
My development machine is Windows (Win7, 64-bit), but the code needs to run on CENTOS too. Everything was working as 32-bit.
I cannot seem to shake this error. I did see the following articles here on StackOverflow.
issue 1, issue 2, issue 3
As per other developers recommendations, I did the following:
1. I went Window | Preferences and set the JRE to the 64-bit version
I then made absolutely sure to reference the 64-bit version of the SWT file. I even placed the 64-bit SWT in the project's /lib folder.
Steps: Right click project | Build Path | Configure Build Path... | Libraries
The run (project right click | Run As | Run Configuration...) and debug (project right click | Debug As | Debug Configuration...) configurations use the project environment JRE, which is what I set in step 1, or so I think.
I modified the eclipse.ini (with Eclipse closed) and added the following line to the end:
-vm "C:\Program Files\Java\jre7/bin/javaw.exe"
The 32-bit version is in "C:\Program Files (x86)".
I am still new to Java programming, so what step did I miss?
I am seeing the error if I run from the project folder in a command window or through Eclipse using the Debug configuration (F11 in Debug view).
Command Line Error:
Debugging Error:
UPDATE:
I might have answered my question, just not sure. I see at the bottom of this issue that the author said that he overlooked the Eclipse version. I see via the shortcut properties that I am using the 32-bit version (installed into the "C:\Program Files (x86)" folder). As there is no installatino program, I assume that I downloaded the 32-bit version. Could that be the problem? (I am trying the 64-bit version now.)
I would think that switching SWT over like I did would have solved the problem or can 32-bit Eclipse only produce 32-bit and not 64-bit?
That would seem to bring up another interesting question, although the other article answers this question too, that 64-bit Eclipse can build 64-bit and 32-bit Eclipse 32-bit, not mix and match like Visual Studio, even if you do set the libraries correctly. I will see.

I'm answering your "another interesting question".
In Eclipse there is a Feature called 'Delta Pack' which makes Eclipse able to export RCP applications into different platforms than the Eclipse you're looking at. It knows how to make 32/64 bits too.
But it has disadvantages:
1.) It's somewhat slow to export (a half minute maybe)
2.) You have to debug your application via Remote Java Application debugging (on localhost probably)
I'm not sure about the second point; I was fixing a UI bug which only appeared on Ubuntu exports so I had to debug it on a virtual-machine as a Remote app.

Eclipse switch workspace causes Failed to create the Java Virtual Machine

I'm using Eclipse juno and osx 10.8 . I have java 7 with eclipse setup by doing the trick here:
Eclipse 4.2, Mac OS X 10.8 (ML), and Java 6
sudo mkdir /System/Library/Java/JavaVirtualMachines
sudo su ln -s /Library/Java/JavaVirtualMachines/1.7.0.jdk /System/Library/Java/JavaVirtualMachines/1.6.0.jdk
When i go to switch workspaces I get a "Failed to create the Java Virtual Machine." alert. Then I can start eclipse the normal way and its in the different workspace i chose. On the command line i see:
./eclipse -clean
No binding table for org.eclipse.ui.contexts.dialog
requested Java version ((null)) not available. Using Java at "" instead.
JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
JavaVM FATAL: Failed to load the jvm library.
Any idea how to make switching workspaces not throw the error and perform normally yet still use java 7?
I tried adding to info.plist:
<string>-vm</string>
<string>/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java</string>
as shown on stack overflow here
But i still get the error.

It seems to work now. I'm not sure what I did to make it work. Maybe restarting the computer, but i think it went away once i put a project in the workspace.