I downloaded and installed JDK8u33 for ARM on my beaglebone black, and according to this documentation (http://docs.oracle.com/javase/8/embedded/jdk-arm-8u6/index.html) javafx is included and supported.
However, I can not find jfxrt.jar anywhere in the JRE or JDK, and using javac on a simple javafx program yields "javafx.application" is not a package.
What gives?
As #eckig says, since the 8u33 for ARM version, Oracle has removed JavaFX from the ARM distribution.
To run any JavaFX application you can downgrade your version to the last JDK8u6 that supported JavaFX, or you can provide a valid jfxrt.jar.
And you can do it following this tutorial, cross building OpenJFX for ARM, or just using some already built distribution like this one hosted on the JavaFXPorts project.
Once you have downloaded armv6hf-sdk.zip, unzip it and you need to add this command line option to attach this external source to the classpath, with the extension mechanism:
-Djava.ext.dirs=<path to armv6hf-sdk>/rt/lib/ext
For instance, you need this to run one of the JavaFX old samples from its actual path:
sudo /opt/jdk1.8.0_33/bin/java -Djava.ext.dirs=<path to armv6hf-sdk>/rt/lib/ext -jar BrickBreaker.jar
The latest version of the Java Development Kit for ARM processors (JDK 8u33 for ARM) no longer supports JavaFX Embedded, it has been all of the tech news, for example here: http://jaxenter.com/jdk-arm-without-javafx-end-javafx-embedded-114212.html
Related
I can't get JavaFX working with NetBeans 11.3.
The NetBeans documentation says:
If you install JavaFX 2.1 to Windows manually, consider installing the JavaFX 2.1 libraries and runtime to the default location (C:/Program Files/Oracle/). NetBeans IDE checks the default locations for the JavaFX. If JavaFX 2 is in the default locations the IDE can automatically create a JavaFX-enabled Java platform.
I've put the Gluon SDK there, though the number is 11.0.2. NetBeans does not automatically create a JavaFX enabled platform.
This StackOverflow answer suggests cleaning the cache. That didn't help.
If I try to create a new JavaFX project from the IDE, I get the message:
Failed to automatically set-up a JavaFX Platform. Please go to Platform Manager, create a non-default Java SE platform, then go to the JavaFX tab, enable JavaFX and fill in the paths to valid JavaFX SDK and JavaFX Runtime. Note: JavaFX SDK can be downloaded from JavaFX website.
But there is no "JavaFX" tab on the platform manager. The NetBeans release notes way back in version 8.0.2 say:
Unlike previous versions of NetBeans IDE, NetBeans IDE 8.0.2 does not require that you set up an "FX-enabled" Java platform in order to utilize JavaFX support in the IDE. You can develop JavaFX projects in the IDE if you install any standard Java platform that is JDK 7 Update 6 or newer (JDK 7 Update 10 or newer is strongly recommended).
But presumably that is from when JavaFX was bundled in the JDK.
So how do I get NetBeans to recognise the Gluon JavaFX?
Manual workaround:
/nbproject/project.properties file
run.jvmargs=--module-path "D:\\Libraries\\Java9\\openjfx-13.0.2_windows-x64_bin-sdk\\javafx-sdk-13.0.2\\lib" \
--add-modules=javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web \
--add-exports=javafx.graphics/com.sun.javafx.application=ALL-UNNAMED \
// you may need to add more --ad-exports arguments based on the errors that will crop up during the run phase. this stuff basically removes package access limiters at runtime so be careful.
then there's the compiler arguments
javac.modulepath=\
D:\\Libraries\\Java9\\openjfx-13.0.2_windows-x64_bin-sdk\\javafx-sdk-13.0.2\\lib
and i'm pretty sure you need this too
javac.classpath=\
${libs.JAVAFX13.classpath}:\
I am trying to run a simple GRPC client-server code in raspberri Pi running Raspbian os.
Language that i am using -C# dotnet core (2.1)
I downloaded a sample project from here.
This is a dotnet core project . I am able to run it in Windows environment, i am also able to modify .proto file in this code and run successfully.
I published the solution as it is with command
{ dotnet publish -r linux-arm }
When tried running same on Rpi, i am getting exception. Attached screenshot has the details of it.
Any help to get through this would be of great use
tl;dr The problem is the libgrpc_csharp_ext native library which currently does not get compiled and built for the arm7 processor. I've compiled it (on a pi) for arm7 and released a nuget package to bridge the gap until they support it all the way: https://www.nuget.org/packages/libgrpc_csharp_ext.arm7/
I'll update with a link to a blog post when I finish getting the rest of the tooling and template finished I'm working on.
fuller explanation: the Grpc.Core nuget package contains the native libgrpc_csharp_ext library that the dotnet implementation of grpc loads in NativeExtensions.cs then maps with PInvoke in NativeMethods.Generated.cs. Inspecting that package, you'll see a version of that library in each /runtimes/[win, osx, linux]/native folder. Unfortunately, no linux-arm version of the library is included. However, in the code, if the platform is linux, it will try to load the static library using the name as formatted here. Dissect that a little and you'll see that as of right now, any 'linux' platform that isn't '64bit' (which despite the proc on the pi being 64 bit, the distro of linux you're using on there, including raspbian, likely isn't) will look for libgrpc_csharp_ext.x86.so. When you dotnet publish -r linux-arm, you'll see that library there in the build output, but unfortunately, it's the wrong one (I think publish just grabs 'the closest one' when it can't find a specific library in the runtimes folder).
The nuget package I created above is compiled for arm7 - I actually cloned the grpc repo onto a pi and peeled away enough of the /csharp build to just cmake the libgrpc_csharp_ext. The 'trick' the package uses is to put the library in runtimes/linux-arm/native folder within the package, which dotnet core recognizes when publishing and pulls into the build output - but the library is still named libgrpc_csharp_ext.x86.so because of the way NativeMethods.cs formats the library name.
I'm trying to replicate an application that we currently have running on a physical Ubuntu server using an Ubuntu machine in Virtual Box. It is a QT application but on the server we are running it using pm2 from NPM. After installing QT, and installing drivers needed for the application i've tried to run it but keep coming across this error:
Cannot mix incompatible Qt library (version 0x50701) with this library (version 0x50905)
I've inherited the code from someone else and don't want to change the project to QT5.9.5, so i'm trying to run with 5.7.1, I've followed instructions on other questions in order to change the QT version to 5.7.1 but still get the same error when running it.
I followed the instructions here:
https://unix.stackexchange.com/questions/116254/how-do-i-change-which-version-of-qt-is-used-for-qmake
When checking the QT version using "qmake -v" in the console I get the following output:
QMake version 3.0 Using Qt version 5.7.1 in /home/sam/Qt5.7.1/5.7/gcc_64/lib
So although it looks to me like i'm using the desired version of Qt (5.7.1), i'm still getting the incompatible library issue, i'm very new to all of this so apologies if this is a stupid question. If anyone could tell me what to do in order to use the compatible library that'd be great, thanks.
I will try to explain this in steps!
Each complete set of Qt libraries is called a Qt "distribution". You can get Qt distributions from a variety of sources:
Installed from the package manager of your OS (.deb/.rpm).
From a downloaded zip file on http://qt.io
As a cloned repo from git
etc..
Some of the available Qt distributions will come pre-built, and some will need to be built from sources. In either case they will all have a qmake program that is specific to that particular Qt distribution. This program is responsible for building programs so that they link to the particular Qt distribution that the qmake is part of. qmake is also used when building with QtCreator.
If you have a binary built with one qmake and you try to run it on another computer, it might find the wrong Qt libraries during dynamic linking and spit out errors of "incompatible version of Qt".
There are many solutions to this problem;
Collect all the Qt libraries (Mine are in /home/myusername/Qt/5.version/gcc_64/lib/*.so) in the same folder as your program executable. This will make sure they are prefered to any other version of Qt that may be in your dynamic linker's path.
Uninstall the OS supplied Qt version(s). This may not be advisable especially if other programs use them.
Rebuilt your program from source using the correct qmake.
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
I have made an application using QtWebKit, Qt4. I have the binary generated in Fedora 16. Now, I want to run that application on another PC (running some other Fedora version), where Qt is not installed. How can I package my Qt application so that it can run on a platform where Qt is not installed? Is there any command line utility as well as QtCreator utility to do so. I have tried "deploy all" command, but it didn't have any affect.
Create an Installer with the Qt Installer Framework and just supply all needed shared libraries (Win/OSX) or compile statically. Under Linux there is always the problem between system-wide libraries or bundled libraries. The documentation https://qt-project.org/doc/qt-5.0/qtdoc/deployment.html should give you a good start
Obviously, you need to have access to the qt libraries, which are exactly the same version that you used to compile your application.
There are two options :
link qt libraries statically
create a RPM package (see this how)
Also check Deploying Qt Applications.
Since you're deploying using rpm, to systems where Qt 4 rpms are available, you don't need to do anything besides simply adding a dependency on the qt to your rpm's specfile. The user installing your package using yum localinstall will get the Qt dependencies automatically installed. That's the correct way of doing it - it will keep your package size small.
Of course you need a separate rpm build for every fedora/centos major version out there, but that's almost always a requirement.
If your package needs newer Qt version than the one provided by the platform packages, you can still make a specific version dependency (say qt >= 4.7.0) and have a readme that indicates that newer packages can be obtained from a 3rd party repository (epel etc.)
For deployment under Linux I've used Bitrock Installer Tool.
The main thing before deploying is to check your dependencies. You can do that by using command:
ldd appName | grep libQt
After that you'll see list of dependencies. You'll have to set environment variable LD_LIBRARY_PATH to let linker know where're your libraries. To do that:
export LD_LIBRARY_PATH=.
. means current directory
And after that:
./appName $*
After that you'll be able to use your executable with Bitrock Installer Tool.