Having some problem with running a grails application in GGTS (eclipse) due to upgrade to Java 1.8.
The stack starts with:
Mar 05, 2015 3:51:31 PM org.springsource.loaded.jvm.JVM copyMethod
SEVERE: Problems copying method. Incompatible JVM?
java.lang.reflect.InvocationTargetException
at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springsource.loaded.jvm.JVM.copyMethod(JVM.java:134)
at org.springsource.loaded.ri.OriginalClassInvoker.createJavaMethod(OriginalClassInvoker.java:68)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlClassGetDeclaredMethods(ReflectiveInterceptor.java:151)
at org.codehaus.groovy.reflection.CachedClass$3$1.run(CachedClass.java:84)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.reflection.CachedClass$3.initValue(CachedClass.java:81)
...
at java.lang.reflect.Method.invoke(Method.java:497)
at org.springsource.loaded.ri.ReflectiveInterceptor.jlrMethodInvoke(ReflectiveInterceptor.java:1270)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.rootLoader(GrailsStarter.java:236)
at org.codehaus.groovy.grails.cli.support.GrailsStarter.main(GrailsStarter.java:264)
Caused by: java.lang.IllegalArgumentException: Can not copy a non-root Method
at java.lang.reflect.Method.copy(Method.java:151)
... 280 more
I used to run the same application in Java 1.7. My colleagues upgraded to 1.8 and no longer able to run it.
I tested with SUN JDK and now I am on OpenJDK again and that does not help
Current JDK openjdk version "1.8.0_40"
JAVA_HOME, JAVA_PATH and any other variable seems to point to the correct JDK installation. I have removed all the previous (JDK 1.6 & 1.7 from the OS to be sure that there is no reference to them).
For some reason GGTS still complains for a wrong JVM. I understand the error might be related to a compiler 1.7 trying to compile files in the 1.8, but I am not sure where this reference is comming from in eclipse.
My Eclipse installation information lists the following under Java:
-vm
/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
eclipse.home.location=file:/home/arb/dev/applications/ggts-3.6.3.SR1/
eclipse.launcher=/home/arb/dev/applications/ggts-3.6.3.SR1/GGTS
eclipse.launcher.name=GGTS
eclipse.p2.data.area=#config.dir/../p2
eclipse.p2.profile=DefaultProfile
eclipse.product=org.springsource.ggts.ide
eclipse.startTime=1425566898624
eclipse.stateSaveDelayInterval=30000
eclipse.vm=/usr/lib64/jvm/jre-1.8.0-openjdk/bin/java
eclipse.vmargs=-Dgrails.console.enable.interactive=false
-Dgrails.console.enable.terminal=false
-Djline.terminal=jline.UnsupportedTerminal
-Dgrails.console.class=grails.build.logging.GrailsEclipseConsole
-Dosgi.requiredJavaVersion=1.6
-Xms60m
-Xmx1024m
Version 1.8.0_40 and 1.8.0_45 has breaking updates with grails.
Spring can not copy non-Root methods.
Since the initial posting a workaround has been developed.
aclement commented on Mar 5
Here is the build:
http://repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.2.BUILD-SNAPSHOT/springloaded-1.2.2.BUILD-SNAPSHOT.jar
To test it under grails, what I do is go into the grails folder:
grails-2.5.0/lib/org.springframework/springloaded/jars
I then rename the spring loaded jar that is there and put in a symlink
to the jar above. It used to be that you could just modify the
startGrails script to point to the new version, but now due to the
forking I find you need to do the symlink thing. Or drop that jar into
this folder and rename it to match the expectations of grails (rename
it from springloaded-1.2.2.BUILD-SNAPSHOT.jar to
springloaded-1.2.0.RELEASE.jar)
If you want to rollback instead
Grails is natively supported in 1.8.0_25, 1.8.0_31
http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jdk-8u25-oth-JPR
Once you have a compatible java version clean your grails project.
Ensure that your java path variables are set to point to your expected version.
set JAVA_HOME=C:\java\jdk1.8.0_25
set PATH=%JAVA_HOME%\bin;%PATH%;
It's a problem related to jdk8u40, go back to jdku31. It works in that version.
I'm running into the same problem both in windows and linux environments.
I updated my springloaded jar to version 1.2.4.BUILD-SNAPSHOT (from 1.2.1) and that resolved the issue. (Latest version can be found in the Spring repo)
Go to your local Grails lib directory to find springloaded jar. For me that was /usr/local/Cellar/grails/2.4.4/libexec/lib/org.springframework/springloaded/jars/
remove existing 1.2.1 jars (I removed pom file, too, but not necessary)
download latest springloaded jar and place into the jars subdir:
wget http://repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.4.BUILD-SNAPSHOT/springloaded-1.2.4.BUILD-SNAPSHOT.jar
After doing that, everything works. (Clues used from previous answer: https://github.com/spring-projects/spring-loaded/issues/98)
Step 1 : Download this jar
step 2 : put it into the grails folder: grails-2.4.1/lib/org.springframework/springloaded/jars
should be enough , restart IDE
Root cause, work-arounds and news on fixes here: https://github.com/spring-projects/spring-loaded/issues/98
I am running Grails 2.4.3 and also had problems moving from jdk1.8.0_31 to jdk1.8.0_40 and had to go back to jdk1.8.0_31
Loading Grails 2.4.3
...
SEVERE: Problems copying method. Incompatible JVM?
java.lang.reflect.InvocationTargetException
...
Caused by: java.lang.IllegalArgumentException: Can not copy a non-root Method
at java.lang.reflect.Method.copy(Method.java:151)
From https://github.com/spring-projects/spring-loaded/issues/98 and worked to me
wget repo.spring.io/libs-snapshot-local/org/springframework/springloaded/1.2.3.BUILD-SNAPSHOT/springloaded-1.2.3.BUILD-SNAPSHOT.jar -O ~/.gvm/grails/2.4.4/lib/org.springframework/springloaded/jars/springloaded-1.2.1.RELEASE.jar
Two Step To Make it Work
1. Download JDK Lower Version:
Install jdk1.8.0_25 from link http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jdk-8u25-oth-JPR. It's the lower version of JDK as grails dont support higher version. Maybe They'll include this in latest version soon.
2. Set Up Environment Variables:
Don't forget to change the Enviromental variables for jdk, you have to just edit Path Variables and JavaHome Variable from "C:\Program Files\Java\jdk1.8.0_'LatestVersion'" to "C:\Program Files\Java\jdk1.8.0_25" .
Changing the springloaded version in my pom.xml did the trick.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>springloaded</artifactId>
<version>1.2.6.RELEASE</version>
</dependency>
When I was experiencing the issue my springloaded version was 1.2.1.RELEASE
I thought I should add my two pence worth on this topic. Recently I hit the same issue trying to upgrade an ancient app to 2.4.4. The reason for my post is because all of the above instructions are a little out of date and whilst in most cases it may appear to work. The moment you introduce mysql drivers all of the above mentioned versions of spring loaded hit a new issue around incompatibility and Non-root when attempting to trigger the database.
I got ggts fully working with JDK 1.8_065. To make it work get hold of springloaded-1.2.5.RELEASE.jar Put this into grails-2.4.4/lib/org.springframework/springloaded/jars/ folder.
When you install ggts inside the ggts-bundle folder is grails-2.4.4. So put the file in the above location within the ggts-bundle folder. Unless you have changed configuration.
Re-launch GGTS
I spent ages on it and thought I should update the instructions.
Also the other thing that I hit issues around was forking under grails 2.4.4 with my uprade and ended up setting
grails.project.fork = []
In my BuildConfig.groovy
Related
So this error is a weird one...
I'm using EXE4J 6 to build a .exe file for my JavaFX Application. This has worked with no issues through Java version 13.0.1. I recently upgraded my environment to use Java 14.0.1 and now I get the following stacktrace whenever I try to run my application through exe:
java.lang.RuntimeException: Exception in Application start method
at javafx.graphics/com.sun.javafx.application.LauncherImpl.launchApplication1(Unknown Source)
at javafx.graphics/com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.InternalError: platform encoding not initialized
at java.base/java.net.Inet6AddressImpl.getLocalHostName(Native Method)
at java.base/java.net.InetAddress.getLocalHost(Unknown Source)
at org.apache.logging.log4j.core.util.NetUtils.getLocalHostname(NetUtils.java:54)
at org.apache.logging.log4j.core.LoggerContext.setConfiguration(LoggerContext.java:612)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:691)
at org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:708)
at org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:263)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:243)
at org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:45)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:174)
at org.apache.logging.log4j.LogManager.getLogger(LogManager.java:669)
This error happens when trying to initialize my Log4J logging. however if I just made a direct call to InetAddress.getLocalHost() I can replicate this error out of .exe. Running my application directly out of my Eclipse (EE 06/2020) works just fine. After doing some debugging. I determined that removing Java from my PATH allowed the application to run. My .exe4j configuration file is set up so that the application should look for a separate Java 14 jre and not attempt to use my PATH for java.
<searchSequence>
<directory location="../java/jre64" />
</searchSequence>
The jre64 is built through ANT using the 14.0.1 jdk that I have and only importing the modules I need. Again, this all worked through 13.0.1 prior to my upgrade to 14.0.1
From research and testing on other computers, I think this boils down to an environment issue on my computer. However I've run out of places to look. Any thoughts or ideas would be much appreciated. Specifically why EXE4J would try to use the Java on my Path instead of the one in the search sequence.
Other Notes:
Running on Windows 10 Latest Updates
Path points to OpenJDK 14.0.1 (causes break) (java -version is correct in cmd)
I've confirmed that the working exe, after removing java from my Path, is still running on version 14.0.1 through the jre64
Application is built with and Eclipse Workspace/project JRE also points to same OpenJDK 14.0.1
Running on other computers with similar versions & environment works & doesn't cause this issue.
I was finally able to determine what the issue was.
I was using Exe4J 6.0 which was not compatible with Java versions 10+. I was surprised that I wasn't getting outright errors when trying to run exe4j to compile my executable, however it seems that exe4j was sucking in an older 1.8 java version from my registry and using a 1.8 jdk that I never cleaned out of my "C:/Program Files/Java" folder. When I deleted all my old JDKs, exe4j started complaining about missing a Java VM (even though 14.0.1 was set on path).
Upgrading to Exe4J 7.0 solved the issue for me.
In my case the problem was the PATH environment variable pointing to one jre directory.
I had 2 applications in different directories:
Application A had a jre directory included in the PATH environment variable and was working fine.
Application B had another jre directory NOT included in the PATH environment variable and was throwing this error.
After removing this jre directory from the PATH environment variable everything worked ok.
I have formatted my Mac due to some storage issues. Before this, I used Eclipse in a proper way. Now i have installed the JDK
Then, i have installed Java
Until now everything seems to be correct but when I open the Eclipse installer...
What can I do to fix this? I need to work with this the soon as possible.
Thanks
Eclipse on macOS will not start with Java 14 installed, this is being tracked in Eclipse bug 561273.
Installing Java 8 as well does not help. You need to remove the Java 14 install. You could use the Java 13.0.2 release instead.
Eclipse have determined that the root cause of this issue is a change in Java 14 which is described in this bug report JDK-8238225. The fix for this should be in Java 14.0.1
Update: Eclipse runs fine with Oracle Java 14.0.1 so the issue has been fixed.
I also asked this question which was closed, that's why I answer what I have found out: Eclipse will not install on Mac OS Catalina 10.15.4, saying the above error message
Failed to create the Java Virtual Machine.
Deinstalling jdk and install an older one wouldn't help on its own because Eclipse is refusing to install in the first place (as mentioned above). What I have done:
i´ve installed an JDK with boost (you can try several, mine worked with Version 13)
I edited the installer:
Download the dmg file
convert the dmg-file with "hdiutil convert /dev/disk3s1 -format UDRW -o devimage"
mount the converted dmg-file with: "hdiutil attach -owners on devimage.dmg -shadow"
Edit the /Volumes/Eclipse/Eclipse.app/Contents/Info.plist: there is a section which is commented and there you can try the jdk version. You have to give the full path to the java executable, for example:
<string>-vm</string><string>/Library/Java/JavaVirtualMachines/jdk-13.0.2.jdk/Contents/Home/bin/java</string>
Then my eclipse started from the (already) mounted Eclipse image without complaining
I had the same issue myself a while back. In your Eclipsepedia it provided an example of what the eclipse.ini file looks like when your trying to specify a JVM. So just change the eclipse.ini file and then make sure that you have all of the correct documents in that path to match the example.
I have been testing JavaFX 11 using Maven and cannot get it to work. I have Open JDK 11 installed and if adding jars to build path from downloadable .zip everything works just fine.
However when I use the recommended POM file from the javafx 11 site I get the following error.
Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: <init>
at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
at javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
This problem seems to have cropped up once here but none of the solutions in that thread have worked.
Does anyone have suggestions on how to go about diagnosing the problem? I am running in Eclipse 4.9 and have attached a screenshot of two projects which are identical other than one uses maven and the other has jars added to the build path. Any help much appreciated.
The solution to this problem is in comments (kleopatra). For quick reference you need to add
-Djava.library.path=C:/anywhere-outside-eclipse
(I tested using -Djava.library.path=C:/) to the VM arguments. This means javafx 11 works with Maven inside eclipse.
This is not Eclipse only problem. I have exactly the same issue when running OpenJFX app in Intellij IDEA 2018.3.2. If any other Java version specified in Windows %Path% env variable then forementioned exception will be thrown.
For instance I use Java 8 as default SDK and playing with Java 11. It's not working that way. It work only if I'll delete Java 8 bin directory from %Path%.
This is rather confusing (and I believe it's a bug) because I don't see any relations to Java 8 when I launch my project in IDE:
C:\Software\Java\openjdk-11\bin\java.exe -Dmaven.multiModuleProjectDirectory=C:\Project\helloworld -Dmaven.home=C:\Software\Maven\3.6.0 -Dclassworlds.conf=C:\Software\Maven\3.6.0\bin\m2.conf "-javaagent:C:\Software\IntelliJ IDEA\CE_2018.3.2\lib\idea_rt.jar=64808:C:\Software\IntelliJ IDEA\CE_2018.3.2\bin" -Dfile.encoding=UTF-8 -classpath C:\Software\Maven\3.6.0\boot\plexus-classworlds-2.5.2.jar org.codehaus.classworlds.Launcher -Didea.version=2018.3.2 -T 2 -DskipTests=true exec:java
As suggested in the post linked to by #kleopatra, the problem is that javafx11 is loading the wrong glass.dll file.
While the workaround suggested in other answers works, the OpenJFX tutorial suggests, when possible, to instruct eclipse to use the Java 11 VM to run, so that the correct dll is loaded.
You can modify your eclipse.ini file and (supposing your jdk11 is installed in C:\Program Files\Java\jdk-11.0.2) add the following lines:
-vm
C:\Progra~1\Java\jdk-11.0.2\bin\javaw.exe
Adding the following lines in the pom.xml file have resolved this issue for me.
In the POM file for the ArtifactID -- javafx-maven-plugin add the following lines in the configuration tag section.
<options> <option>-Djava.library.path=C:\tmp</option> </options>
<executable>C:\openjdk11\jdk-11\bin\java.exe</executable>
Create the tmp folder in advance before you make the change to pom.xml file. Also ensure that java11 is present in the path mentioned above. otherwise mention the path according to the java11 path in your system.
Context: NetBeans IDE 8 and 11 on Windows 10
I had the same problem, but my context was slightly different from the above. I do a lot of work switching between various versions of Java: supporting legacy applications in Java 8 and developing new applications in Java 11.
As it turned out, I had the Java 8 entry in the PATH while trying to develop and run a Java 11 application. The builds completed successfully but at runtime it was exceptions galore. All NB console logs and other logs indicated a Java 11 environment. I removed the Java entry from the PATH and then had to restart NB 11. Everything worked fine.
I can start Payara v5.192 with JDK11 via command line, but it breaks after trying to start it via IntelliJ with the following error:
-Xbootclasspath/p is no longer a supported option
And I can't even start it via terminal any longer.
This is part of the IntelliJ log:
C:\Program Files\Java\jdk-11.0.3\bin\java.exe
-cp
D:/Program Files/payara-5.192/glassfish/modules/glassfish.jar
-XX:+UnlockDiagnosticVMOptions
-XX:NewRatio=2
-Xbootclasspath/p:D:\Program Files\payara-5.192\glassfish/lib/grizzly-npn-bootstrap-1.8.1.jar
[...]
My project is configured to use JDK 11.0.3, what might the issue be?
EDIT: I'm using IntelliJ 2019.1.3 on Windows, I don't get this issue on Debian
EDIT2: apparently the configuration changes after starting the domain with IntelliJ, here's domain.xml respectively before and after: https://pastebin.com/HAzFgkGn -> https://pastebin.com/F3r3nWet
I've encountered the same error myself, on macOS High Sierra. The reason for me was a conflict between the JDK version I'm running asadmin by default (1.8), and what IntelliJ put in the domain.xml (11.0.1).
One workaround, besides updating your domain.xml, is to fix the JDK used by asadmin, e.g. by setting the AS_JAVA parameter in glassfish/config/asenv.conf.
EDIT: Since IntelliJ ships with a bundled JDK 1.8, I believe asadmin is run using that instead of the configured JDK 11 causing the conflict -- asadmin appears to check the JDK it was run with and make some (in this case) wrong assumptions.
EDIT 2: JB SDK is not related. The asadmin command is run using the JDK that's in path, instead of the one configured to the domain. You will get this error if your default (in path) JDK is <9, and your JDK configured to your domain is >=9, as the parameters for bootclasspath of npn are parameterized on the running JDK version.
EDIT 3: Reported and confirmed as a bug: https://github.com/payara/Payara/issues/4025
EDIT 4: The fix is merged to the repository, and is on track for the 5.193 release next month.
I have been testing JavaFX 11 using Maven and cannot get it to work. I have Open JDK 11 installed and if adding jars to build path from downloadable .zip everything works just fine.
However when I use the recommended POM file from the javafx 11 site I get the following error.
Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError: <init>
at javafx.graphics/com.sun.glass.ui.win.WinApplication.staticScreen_getScreens(Native Method)
at javafx.graphics/com.sun.glass.ui.Screen.initScreens(Screen.java:412)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:152)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
Exception in thread "JavaFX Application Thread" java.lang.NullPointerException
at javafx.graphics/com.sun.prism.d3d.D3DPipeline.getAdapterOrdinal(D3DPipeline.java:205)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.assignScreensAdapters(QuantumToolkit.java:695)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.runToolkit(QuantumToolkit.java:313)
at javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.lambda$startup$10(QuantumToolkit.java:258)
at javafx.graphics/com.sun.glass.ui.Application.lambda$run$1(Application.java:153)
at javafx.graphics/com.sun.glass.ui.win.WinApplication._runLoop(Native Method)
at javafx.graphics/com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(WinApplication.java:174)
at java.base/java.lang.Thread.run(Thread.java:834)
This problem seems to have cropped up once here but none of the solutions in that thread have worked.
Does anyone have suggestions on how to go about diagnosing the problem? I am running in Eclipse 4.9 and have attached a screenshot of two projects which are identical other than one uses maven and the other has jars added to the build path. Any help much appreciated.
The solution to this problem is in comments (kleopatra). For quick reference you need to add
-Djava.library.path=C:/anywhere-outside-eclipse
(I tested using -Djava.library.path=C:/) to the VM arguments. This means javafx 11 works with Maven inside eclipse.
This is not Eclipse only problem. I have exactly the same issue when running OpenJFX app in Intellij IDEA 2018.3.2. If any other Java version specified in Windows %Path% env variable then forementioned exception will be thrown.
For instance I use Java 8 as default SDK and playing with Java 11. It's not working that way. It work only if I'll delete Java 8 bin directory from %Path%.
This is rather confusing (and I believe it's a bug) because I don't see any relations to Java 8 when I launch my project in IDE:
C:\Software\Java\openjdk-11\bin\java.exe -Dmaven.multiModuleProjectDirectory=C:\Project\helloworld -Dmaven.home=C:\Software\Maven\3.6.0 -Dclassworlds.conf=C:\Software\Maven\3.6.0\bin\m2.conf "-javaagent:C:\Software\IntelliJ IDEA\CE_2018.3.2\lib\idea_rt.jar=64808:C:\Software\IntelliJ IDEA\CE_2018.3.2\bin" -Dfile.encoding=UTF-8 -classpath C:\Software\Maven\3.6.0\boot\plexus-classworlds-2.5.2.jar org.codehaus.classworlds.Launcher -Didea.version=2018.3.2 -T 2 -DskipTests=true exec:java
As suggested in the post linked to by #kleopatra, the problem is that javafx11 is loading the wrong glass.dll file.
While the workaround suggested in other answers works, the OpenJFX tutorial suggests, when possible, to instruct eclipse to use the Java 11 VM to run, so that the correct dll is loaded.
You can modify your eclipse.ini file and (supposing your jdk11 is installed in C:\Program Files\Java\jdk-11.0.2) add the following lines:
-vm
C:\Progra~1\Java\jdk-11.0.2\bin\javaw.exe
Adding the following lines in the pom.xml file have resolved this issue for me.
In the POM file for the ArtifactID -- javafx-maven-plugin add the following lines in the configuration tag section.
<options> <option>-Djava.library.path=C:\tmp</option> </options>
<executable>C:\openjdk11\jdk-11\bin\java.exe</executable>
Create the tmp folder in advance before you make the change to pom.xml file. Also ensure that java11 is present in the path mentioned above. otherwise mention the path according to the java11 path in your system.
Context: NetBeans IDE 8 and 11 on Windows 10
I had the same problem, but my context was slightly different from the above. I do a lot of work switching between various versions of Java: supporting legacy applications in Java 8 and developing new applications in Java 11.
As it turned out, I had the Java 8 entry in the PATH while trying to develop and run a Java 11 application. The builds completed successfully but at runtime it was exceptions galore. All NB console logs and other logs indicated a Java 11 environment. I removed the Java entry from the PATH and then had to restart NB 11. Everything worked fine.