I'm new in Apache Netbeans 11 with JDK11, however i've been programming in jdk1.8 (netbeans 8.2) for a while but for school purposes i'm forced to use jdk11 this year, the problem is that I dont know, how to create new JavaFX FXML project. I've done some research and found out, that jfx is not a part of standard jdk anymore.
Then I found some tutorials how to run a javafx 11 project with adding the libraries, however it doesn't tell how to create a new project.
Is there any simple way how to add JavaFX 11 to my netbeans so the netbeans can use JavaFX 11 natively (I mean for example create new JavaFX 11 project with jdk11)
And if there isn't and I will have to use jdk 1.8, do I also need to install older Scene Builder or the SB11 will do the work (even for older javafx/jdk?
Ok, SOLVED:
As you can read in https://openjfx.io/openjfx-docs/#IDE-NetBeans OpenJFK docs, there are basicly many options to create openJFX project (either with FXML)
From IDE: That means that you have to add libraries, VM options, etc yourself for each project (As I mentioned in my question, not much user friendly solution I was looking for)
Create Maven Project
Create Gradle Project
I chose the Maven, yet I have had an errors telling me Unrecognized option: --module-path Command execution failed., altho I have had java_home set up on jdk11 and project on jdk11 as well. However, i needed to add system enviromental variable %JAVA_HOME% with jdk with higher priority then the old one. After that it still didnt run! BUT... Then I deleted the old system EV refferencing on jdk1.8. Since then the project runs with no errors. I tried to create EV refferencing the old jdk1.8 at the end of that Path list and it still run. (So there was a bug with prioritising the Paths I guess) Thank you all, espcly #JoséPereda
Sum – all steps I've done to solve Unrecognized option: --module-path Command execution failed.
Set Apache NetBeans etc/netbeans.conf -> netbeans_jdkhome=/path/to/jdk-11
Create a new System Enviromental Variable called JAVA_HOME with value of path to new jdk (jdk11 in my case)
Edit System Enviromental Variable Path -> New -> %JAVA_HOME%\bin and move it above your old jdk path (yet my Maven project didn't run after this step)
Remove the old jdk path (jdk1.8 in my case)
Restart Apache NetBeans 11 -> Run Project -> It runs with no erros
I tried to add my old System Enviromental Varible Path (refferencing jdk1.8) and it still works.
Related
I am have this Exception please help me!
"Error occurred during initialization of boot layer
java.lang.module.Find Exception: Module test not found"
But i write VM option "--module-path "D:\UT java\javafx-sdk-17.0.1\lib" --add-modules javafx.controls,javafx.fxml"
and i have module-info.java "
requires javafx.fxml;
requires javafx.controls;
requires javafx.graphics;
requires java.sql;
requires java.desktop;
requires jdk.jfr;"
i add my sdk. And if i create javafx demo project and execute him it work. and if i start change fxml file and change controller i have this exception.
I have IntellIJIdea 2021, javafx-sdk-17.0.1, jdbc jr 8,11,16
Steps to fix:
Delete the JavaFX sdk (you don’t need it).
Delete old Java versions (they are obsolete).
Update your IntelliJ IDE and IDE plugins to the most recent release, 2021.3.2+.
Create a new JavaFX project using JDK and JavaFX 17.0.2+.
Select Maven for the build system unless you know and prefer Gradle.
Do not set VM arguments, you don’t need them.
Adding modules via the --add-modules VM arguments is unnecessary when you have a valid module-info.java file.
The --module-path is still required so that the modules can be found, but Idea will provide the correct path for your modules automatically when it recognizes the modules through your Maven dependencies.
So you don't need to explicitly define the --module-path VM argument yourself for a Maven based build (that would be difficult to do anyway because the modules are all downloaded to different directories in your local maven repository).
Test it works following the Idea create new JavaFX project execution instructions.
Add additional modules one at a time by adding their maven dependency to pom.xml and the requires clause to module-info.java.
Ensure you synchronize the Maven and Idea projects between each
addition.
See, for example, this question on correctly adding the javafx.media module.
Adding other modules such as javafx.web, javafx.fxml or javafx.swing follows a similar pattern.
Test between each addition by building and running the project, to ensure you haven’t broken anything.
Copy your original source code into the appropriate package directories under the new project source directory:
src/main/java
Place resources in:
src/main/resources
following the Eden resource location guide.
Fix any errors, ensure everything compiles and runs, then test it.
It's been a few days since I've been trying to export a very simple project made in JavaFX but I have a very frustrating problem: To run the jar I need to open cmd navigate to the jdk folder and execute the following code java --module-path %path_to_JavaFX_on_my_pc% --add modules=javafx.controls,javafx.fxml,javafx.graphics -jar %path_to_jar% where I point to the jfx folder on the pc and add the necessary modules to run the jar.
run the jar using java java -jar %path_to_jar% results in the following error: Error: JavaFX runtime components are missing, and are required to run this application
The project is modular, having declared module-info.java with the following code:
module Timer {
requires java.prefs;
requires com.jfoenix;
requires javafx.base;
requires javafx.controls;
requires javafx.fxml;
requires javafx.graphics;
requires javafx.media;
requires javafx.web;
requires javafx.swing;
opens main;
exports main;
}
when exporting the artifact I include all the .jar contained in the javafx, so why should I point to it externally?
The app runs well when I run it through the IDE, I didn't even have to add VM options.
My goal is to create an application that can actually be distributed, without the user needing to have any knowledge beyond the basics to run it, no jre, jdk, jfx, cmd code, etc... just click twice and done.
The question is: How do I generate an executable file that can be opened with 2 clicks like any other application on the pc on *any pc?
finally I got a solution to my problem.
1 ° - It was necessary to solve the problem when generating a java artifact using javaFx in intelliJ: In JDK 13 the IDE threw the following error
Can't build artifact - fx: deploy is not available in this JDK
the easiest solution for that was to return on JDK 9 ond the javaFx was still built in and everything worked fine. Having done that, I was able to generate .jar artifacts that worked without the need to use command line tools.
2 ° -So I needed to generate a native executable for my application: In this topic there is an excellent list of tools that create launchers for java artifacts (Ideal was to convert but there gets a little complicated). What worked best for me was Jsmooth where I was able to set up a launcher that built in my .jar and where I could also attach a copy of the JRE for distribution on computers without Java
It is worth noting that I develop desktop applications just for my use and that of some friends, they do not work with sensitive data and do not require a high level of security and therefore there is no problem using an old version of jdk, in any other case, no recommend this approach.
Thank you all for your help.
I ran into the same problem with JavaFX 11. The way I did it, to be able to generate the jar artifact, I set the Project Settings - Artifacts - Type to JAR rather than JavaFX Application. That enabled me to create a jar in the out directory of my project. Afterwards, I wrote a batch file that created a custom jre for my app (as small as ~40 MB for a small app), including JavaFX. I called that bat file create.bat and placed that bat file in the same folder as my jar artifact.
Now, provided
my jar artifact is called app.jar,
path to JDK is D:\jdks\jdk11,
path to JFX mods is D:\jdks\jfx11\jmods,
module name is com.epsilon, and
path to Main class is com.epsilon.Main,
below is the contents of the bat file to create a custom JRE, including JavaFX. It created a custom JRE in the folder dist, the launch file is in the dist\bin directory called run.bat.
rem This sets the variable DIR to the current directory with the jar artifact
set DIR=%~dp0
rem This creates a temporary mod file
D:\jdks\jdk11\bin\jmod create --class-path %DIR%app.jar %DIR%temp.mod
rem This creates distributable JRE
D:\jdks\jdk11\bin\jlink ^
--compress=2 ^
--strip-debug ^
--no-man-pages ^
--launcher run=com.epsilon/com.epsilon.Main ^
--module-path D:\jdks\jdk11\jmods;D:\jdks\jfx11\jmods;%DIR% ^
--add-modules com.epsilon ^
--output %DIR%dist
rem This command deletes the temporary mod file
del %DIR%temp.mod
rem You can create a shortcut to your app above the "dist" folder and enter the below line to the shortcut's target property
rem %windir%\system32\cmd.exe /c start "" "%CD%\dist\bin\javaw.exe" -m com.epsilon/com.epsilon.Main
So, this has enabled me to create a working distributable without downgrading Java.
I am running XUbuntu x64 14.04.4 LTS on my PC, with eclipse Mars.2 Release (4.5.2) and JDK 8 properly linked up to my eclipse (via ini file).
So basically, I "upgradet" to e(fx)clipse. Then I crated a new "JavaFX project". When I tried to run it, I got the error The import javafx.application cannot be resolved.
A quick google search brought up, that I need to add the jfxwt.jar from my java 1.8 directory (in my case /opt/Oracle_Java/jdk1.8.0_91/jre/lib/).
But the error didn't went away. I also tried the build options but nothing seemed to change anything.
First of all, I included the wrong jar. whoops. thanks to #DVarga for the tip.
But that wasn't the problem. So here are all the steps I took, to create a working e(fx)clipse environment:
Download the latest eclipse version and add the e(fx)clipse package.
Update to the latest JDK and reference that in the eclipse.ini file (1)
Tell ecplipse the path for the latest JDK. Although this tutorial is for MACs, it works pretty much the same in linux. There are a few differences tho:
The preferences menu is in window > preferences
The JRE type is not MacOS X VM but rather Standard VM
The JRE home path is the jdk1.8.0_VERSION folder (in my case /opt/Oracle_Java/jdk1.8.0_91)
I didn't need to add any other jar for javaFX to work properly.
(1) How to add the Java 1.8 path to eclipse
if you get the error "JavaFX was disabled because your java version is to old" (or something like this) you need to update to at least Java 1.8 and edit the eclipse.ini file in the eclipse folder.
There you have to look for the line -vm. In the next line is a path to an old Java version. Change that to the new path. It should look like this: /path/to/jdk1.8.0_VERSION/jre/bin/ in my case it is /opt/Oracle_Java/jdk1.8.0_91/jre/bin/
This should be easy, but I can't figure out how.
Is there any way to find out which JavaFX version is installed. And I DON'T mean programmatically via System.getProperty("javafx.runtime.version") , which returns an empty string on my computer, although JavaFX is installed.
I would rather like to have something like java -version on console, but in order to get the JavaFX version.
Alternatively it would be sufficient to know if JavaFX is installed at all. I just have some customers who can't run my swing/javaFX app and would like to tell them to check whether JavaFX is installed.
You can't really do this the same way you do with the Java runtime. The difference is that java is a machine executable that launches the JVM. JavaFX is just a set of library classes; it's not really an executable in the same sense.
It looks like the System property that you can read at runtime is kept in jre/lib/javafx.properties, so you can do something like
cat $JAVA_HOME/jre/lib/javafx.properties
or whatever the Windows equivalent is, if you're running on Windows. However, if the System property you get at runtime is blank, then I suspect this file doesn't exist. As dfeuer commented, it would help to know your JRE version.
Update:
The relationship between JDK/JRE version and JavaFX version is as follows.
Beginning with JRE 1.7.0 update 6, JavaFX was included with the JRE, but was not on the classpath. So for JRE 1.7.0, update 6 and later, the jfxrt.jar file is included in JAVA_HOME/jre/lib. The javafx.properties file which contains the JavaFX version information is in the same directory, though in theory at least the JRE version will determine the JavaFX version (since they were shipped together).
Just inspecting the JDK 1.7.0 versions I have installed on my machine, the mapping from JDK version to JavaFX version is:
/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk javafx.runtime.version=2.2.0
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk javafx.runtime.version=2.2.4
/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk javafx.runtime.version=2.2.4
/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk javafx.runtime.version=2.2.5
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk javafx.runtime.version=2.2.7
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk javafx.runtime.version=2.2.21
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk javafx.runtime.version=2.2.25
/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk javafx.runtime.version=2.2.40
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk javafx.runtime.version=2.2.45
Beginning with JRE 1.8.0, JavaFX was included with the JRE and was placed on the classpath; so it's effectively a full part of the core libraries. In version 1.8.0, the jfxrt.jar file is in JAVA_HOME/jre/lib/ext (which automatically makes it part of the classpath). The javafx.properties file which contains the JavaFX version information is still in JAVA_HOME/jre/lib. The version numbering for JavaFX in version 1.8.0 (appears to) simply mimic the JRE version:
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk javafx.runtime.version=8.0.0
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk javafx.runtime.version=8.0.5
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk javafx.runtime.version=8.0.20
So with your customers, you can simply ask them to do java -version and for the most part, you'll be able to deduce the JavaFX version. On some rare occasions you may need to dig a little deeper.
A sort-of-related note: if you are shipping an application to customers and you need to determine a specific version, consider using a self contained application, in which you include a JRE (and JavaFX runtime) with the application.
For Ubuntu 18.04 the JavaFX version can be found in /usr/share/openjfx/lib/javafx.properties. A simple command should show you the version you have.
$ cat /usr/share/openjfx/lib/javafx.properties
javafx.version=11.0.2-internal
javafx.runtime.version=11.0.2-internal+0-2019-02-19-093139
javafx.runtime.build=0
Perhaps your installation has something similar?
If you are using Netbeans 15 on Windows 10, look in the file:
C:\Program Files\NetBeans-15\netbeans\javafx\VERSION.txt
On my machine, it contains 11
My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.