I've been trying to create a modular JavaFX project with Excel-reporting capabilities. It turned out Apache POI doesn't yet support modular Java apps. Has anyone here tried any work-around on this matter?
I migrated a project initially developed in jdk8, which uses JavaFx to jdk13 using openJfx.
I had to modify the project.properties file quite extensively.
this was done as per openjfx website specifications
javac.modulepath=\
D:\\Libraries\\Java9\\openjfx-13.0.2_windows-x64_bin-sdk\\javafx-sdk-13.0.2\\lib
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 \
added these in run.jvmargs using trial and error in the sense that the build breaks when it tries to instantiate things...
--add-exports=javafx.graphics/com.sun.javafx.application=ALL-UNNAMED \
--add-exports=javafx.web/com.sun.webkit.network=ALL-UNNAMED \
--add-exports=javafx.web/com.sun.webkit.dom=ALL-UNNAMED \
--add-exports=javafx.graphics/com.sun.scenario.animation.shared=ALL-UNNAMED \
--add-exports=javafx.graphics/com.sun.javafx.tk.quantum=ALL-UNNAMED
and these are some of the libs it's using
javac.classpath=\
${libs.JAVAFX13.classpath}:\
${libs.jsch.classpath}:\
${libs.poi.classpath}:\
JAVAFX, poi and jsch are plain libraries. NO extra work was needed here.
apart from the trial and error exports, i essentially followed stuff from this link:
https://openjfx.io/openjfx-docs/#IDE-NetBeans
Related
VSCode, Java 11 JavaFX 18.0.2
I am trying to package my code up for distribution as a desktop app. In my case I want a fully self-contained app because of my target user's profile.
I have been through Jenkov add the Oracle docs here and here which suggest I need ant-javafx.jar. That jar file seems to have been dropped from the standard Java SDK some time around Java 7 and put into the regular JavaFX install lib folder.
It's not there in the build I have.
JavaFX seems to have gone to openjfx.io and nowhere in there can I see support for the ant packaging jar. In fact I see openjfx as a retrograde step as they are increasingly forcing everyone into paid plans (try going round and round the loop of downloading anything that doesn't require an LTS payment).
I have a suspicion that there is some silent assumption that everyone will use something from maven or gradle, and maybe the packaging tools are buried away in one of those build tools. For historical reasons I don't use either and it should be possible to do this packaging without one of them.
So where do I get the JavaFX Ant build tasks from without having to pay someone?
I have found that the following works as an alternative with Java 19 and OpenJFX 19. I use the maven-dependency-plugin to copy all the dependency jars (excluding JavaFX, which I use as modules from a "full" JDK [one that includes JavaFX)] into the target/lib directory.
#!/bin/bash
set -o errexit
set -o noclobber
set -o xtrace
# find dependency modules of required modules
DEP_MODS=$(jdeps -quiet --class-path "target/lib/*" --add-modules java.base,java.logging,java.sql,javafx.controls,javafx.fxml --multi-release base --ignore-missing-deps --print-module-deps target/myapp-4.0-beta.jar)
# create a modular runtime image
jlink --compress=1 --no-header-files --no-man-pages --add-modules "java.logging,java.sql,javafx.controls,javafx.fxml,$DEP_MODS" --output target/myapp-4.0-beta
# Example of running it out of the runtime image
# TEST target/myapp-4.0-beta/bin/java -cp "../../myapp-4.0-beta.jar:../../lib/*" org.myapp.App
# symlink to the artifact jar from the lib directory
$(cd target/lib && ln -s ../myapp-4.0-beta.jar)
# use the lib directory and modular runtime image as input to jpackage
jpackage --input target/lib --runtime-image target/myapp-4.0-beta --main-jar myapp-4.0-beta.jar --main-class org.myapp.App --type app-image --app-version 4.0 --name app --dest target/dist/bundle --mac-entitlements src/dist/mac/entitlements.plist
Here's what I need: A working OpenJFX 14 environment with hardware acceleration.
I have a i.MX 8M ARMv8 embedded system for which I'm trying to get OpenJFX 14 or latest running. The chipset has a Vivante GC7000UL GPU. The current Yocto build I did has galcore module loaded. The X window environment works fine and it has libEGL.so, libGLESv2.so and libGL.so in /usr/lib. I am a java engineer, not an OpenGL expert so I don't know if anymore libraries are needed for OpenGL APIs.
I have looked at the prebuilt versions from LibericaFX and Azul zulu. The latter does not have a ARM build. The former has aarch64 build but it is does not have monocle implementation. They have the prism ES2 implementation but unfortunately it needs GLX v1.3 or higher which I don't seem to have.
I tried to compile OpenJFX myself for ARMv8 using a Yocto recipe based on armv6hf.gradle. I managed to compile successfully and able to run it. But it does not render using the hardware pipeline.
Prism pipeline init order: es2 sw
Using Double Precision Marlin Rasterizer
Using dirty region optimizations
Not using texture mask for primitives
Not forcing power of 2 sizes for textures
Using hardware CLAMP_TO_ZERO mode
Opting in for HiDPI pixel scaling
Prism pipeline name = com.sun.prism.es2.ES2Pipeline
Loading ES2 native library ... prism_es2_monocle
GraphicsPipeline.createPipeline failed for com.sun.prism.es2.ES2Pipeline
java.lang.UnsatisfiedLinkError: /usr/lib/jni/libprism_es2_monocle.so: /usr/lib/jni/libprism_es2_monocle.so: undefined symbol: getNativeDisplayType
at java.base/java.lang.ClassLoader$NativeLibrary.load0(Native Method)
...
at java.base/java.lang.Thread.run(Thread.java:832)
*** Fallback to Prism SW pipeline
Prism pipeline name = com.sun.prism.sw.SWPipeline
(X) Got class = class com.sun.prism.sw.SWPipeline
Initialized prism pipeline: com.sun.prism.sw.SWPipeline
Which makes sense because getNativeDisplayType() method is defined in eglWrapper.c which is not included as a part of prism_es2_monocle linking.
Ok. Cool. Let me add that file to the compilation step.
Now the compilation fails with this error.
jfx-14.0.2.1-1/modules/javafx.graphics/src/main/native-prism-es2/eglWrapper/eglWrapper
.c:71:1: error: unknown type name 'PrismNativePort'
71 | PrismNativePort prismPort;
| ^~~~~~~~~~~~~~~
This is where my journey ends. I cannot find PrismNativePort mentioned anywhere other than this file (I've searched entire internet with Google).
Has anybody tried to compile OpenJFX other than Android or Linux x86? Can anyone tell me if I can try anything to make it work with hardware acceleration? Thank you.
This is what I use to start the sample application.
java --module-path /opt/openjfx/jfx-14 \
--add-modules javafx.controls \
-Djava.library.path=/usr/lib/jni \
-Dembedded=monocle \
-Dprism.verbose=true \
ColorfulCircles
Update: I found the PrismNativePort defined in a very old version of JFX code from 2016. Looks like a component called LensPort was decommissioned but eglWrapper still has links to the deleted code.
Not a real answer, but just an idea. OpenJFX 16-ea has more improvements for Raspberry Pi, so maybe also for your use-case. I'm starting my app with following commands on the Raspberry Pi 3 B (gtk instead of monocle):
java -Dglass.platform=gtk \
-Dprism.verbose=true \
-Djavafx.verbose=true \
-p /opt/arm32fb-sdk/lib \
--add-modules javafx.controls \
-jar /home/pi/APP.jar
You have to tell Glass to use monocle :
-Dglass.platform=Monocle
Here is my full command line to start app :
java --module-path ./dist/libARMv8/ --add-modules javafx.controls,javafx.fxml \
-Dembedded=monocle \
-Dglass.platform=Monocle \
-Dmonocle.platform=MX8 \
-Dprism.order=es2 \
-Dprism.verbose=true \
-Djavafx.verbose=true \
-Dcom.sun.javafx.isEmbedded=true -Dcom.sun.javafx.touch=true -Dcom.sun.javafx.virtualKeyboard=javafx \
-jar ./dist/JavaFXTestApp4.jar
I made a build of javaFX for iMX8. The hardware acceleration work but there is some blinking issue : for example, when I click in textField to show the virtual keyboard the display start blinking. Same issues with comboBox.
This blinking issue does not happen in software rendering mode.
I'm not an openGL expert either, so no more ideas for now.... It is maybe an issue with the Vivante openGL driver.
I can share my build script and give more details if someone is interested in it.
edit : to avoid blinking issue with hardware acceleration, add this to the command line :
-Dprism.forceUploadingPainter=true
Best regards,
I want to use openvino-opencv for my Qt (Qt5.7.1) based project. I have downloaded and installed openvino411 (corresponding to opencv411) following the instructions here in windows10 https://docs.openvinotoolkit.org/latest/_docs_install_guides_installing_openvino_windows.html#Configure_MO. I write a .pri file to demploy the opencv in Qt:
INCLUDEPATH += C:/openvino-411/openvino_2019.2.275/opencv/include
CONFIG(release, debug|release):{
LIBS += -LC:/openvino-411/openvino_2019.2.275/opencv/lib \
-lopencv_core411 -lopencv_highgui411 -lopencv_imgproc411 -lopencv_imgcodecs411 -lopencv_features2d411 -lopencv_ml411 -lopencv_objdetect411 -lopencv_dnn411
}
CONFIG(debug, debug|release):{
LIBS += -LC:/openvino-411/openvino_2019.2.275/opencv/lib \
-lopencv_core411d -lopencv_highgui411d -lopencv_imgproc411d -lopencv_imgcodecs411d -lopencv_features2d411d -lopencv_ml411d -lopencv_objdetect411d -lopencv_dnn411d
}
But it seeems opencv canot be run in Qt, since I tried running the qt program. The popping up cmd window goes directly to "Press <RETURN> to close this window..." without doing any actually.
First of all, keep in mind that OpenVINO for windows is compiled against MSBUILD instead of MinGW, so if your Qt project is compiled using MinGW, OpenVINO pre-built libraries will likely fail during linking
That said, I managed to integrate OpenVINO Inference Engine with OpenCV succesfully in a big and already existent Qt based project (QT 5.13.1), under LINUX (Ubuntu 16.04), it apperas that under Windows the dependencies fragmentation makes it harder
This configuration is quite tricky and also is a work in progress (to me), I am trying to completely isolate OpenVINO dependencies aiming to deploy them completely embedded in our app, anyway like this it works:
First I installed OpenVINO (https://docs.openvinotoolkit.org/latest/_docs_install_guides_installing_openvino_linux.html) paying particular attention in following each step precisely as it is described,
also DON'T MISS TO RUN the two examples demo_security_barrier_camera and demo_squeezenet_download_convert_run, they will produce two libraries libcpu_extension.so and libgflags_nothreads.a WITHOUT WHICH OpenVINO WILL NOT WORK UNDER YOUR PROJECT, the reason why it was made this way is unknown to me
I copied the following libraries under a subfolder of my project (ThirdPartyLibraries/OpenVINOInferenceEngine):
libinference_engine.so (found in OpenVINO installation folder: /opt/intel/openvino/inference_engine/lib/intel64/libinference_engine.so)
libtbb.so (found in OpenVINO installation folder: /opt/intel/openvino/inference_engine/external/tbb/lib/intel64/libtbb.so)
for the two "cpu extension" libraries, I created a subfolder named "extension", so:
extension/libgflags_nothreads.a (found in OpenVINO Inference Engine Demo BUILD FOLDER, for me it is /home/myuser/inference_engine_demos_build/Release/lib/libgflags_nothreads.a)
extension/libcpu_extensio.so (found in OpenVINO Inference Engine Demo BUILD FOLDER, for me it is /home/myuser/inference_engine_demos_build/Release/lib/libcpu_extensio.so)
Then I also copied the includes of Inference Engine and Lib Cpu Extension from their respective installation folders to my ThirdPartyLibraries:
All the content found under /opt/intel/openvino/inference_engine/include/ goes under /ThirdPartyLibraries/OpenVINOInferenceEngine/include
All the content found under /opt/intel/openvino/deployment_toos/inference_engine/src/extension/ goes under /ThirdPartyLibraries/OpenVINOInferenceEngine/extension/include
Finally here's my .pri file for Qt:
OPENVINODIR = /home/myuser/code_qt5_HG/Libraries/ThirdPartyLibraries/OpenVINOInferenceEngine
LIBS_OPENVINO += -L$$OPENVINODIR \
-linference_engine \
-ltbb \
-L$$OPENVINODIR/extension \
-lcpu_extension
INCLUDES_OPENVINO += $$OPENVINODIR/include \
+= $$OPENVINODIR/extension/include
LIBS += $$LIBS_OPENVINO
INCLUDEEPATH += $$INCLUDES_OPENVINO
That's it, doing so allows me to reference and use Inference Engine in my project like this:
#include <ie_core.hpp>
#include <ie_plugin_config.hpp>
#include <cpp/ie_cnn_net_reader.h>
#include <ext_list.hpp>
.....
InferenceEngine::Core ie;
ie.AddExtension(std::make_shared<InferenceEngine::Extensions::Cpu::CpuExtensions>(), "CPU");
InferenceEngine::CNNNetReader netReader;
netReader.ReadNetwork(detectorXmlPath);
netReader.getNetwork().setBatchSize(1);
netReader.ReadWeights(detectorBinPath);
InferenceEngine::InputsDataMap inputInfo(netReader.getNetwork().getInputsInfo());
.....
to deploy my App to a third party machine I need to install OpenVINO on the machine following the regular procedure (https://docs.openvinotoolkit.org/latest/_docs_install_guides_installing_openvino_linux.html) and to deploy my App as I usually do, the dependencies are then correctly resolved.
My last two cents: I am in direct contact with Intel, which is supporting me with the OpenVINO integration, according to them "all the .so files in in /deployment_tools/inference_engine/lib/intel64, from /deployment_tools/inference_engine/external/mkltiny_lnx/lib, and /deployment_tools/inference_engine/external/tbb/lib are pretty much all the dependencies required", I still didn't have the time to confirm that yet
I am using javafxpackager to deploy a javaFX application, but it only generates a deb package, the command line I am using is this:
javafxpackager -deploy -native -outdir packages -outfile DebtRegister -srcdir out/artifacts/DebtRegister2_jar -srcfiles DebtRegister2.jar -appclass application.Main
I am using ubuntu and I do not wish to use windows for packaging.
Where is the mistake in my command?
First please note that the javafxpackager has been renamed to javapackager.
Regarding your question, please see the documentation:
all: Runs all of the installers for the platform on which it is
running, and creates a disk image for the application.
You will have to run javapackager on every supported platform.
I am writing c++ program using poco c++ library and execute in PC environment successfully. But how to cross compile into ARM-Linux .
I am following from the poco GMakeBuildNotes, but I do not know where I made mistakes. Can anybody help me how to cross compile step by step. Here are the steps I am currently following:
./configure --config=ARM-Linux --no-samples --no-tests
make
cross compile in QT framework
Any suggestions to improve these steps, please?
This post is old and you didn't really stated what's the problem, but still I'll share. I'm getting started with poco for our embedded systems and this is how I compiled it for ARM linux:
If you download and unpack the poco package, you'll find a directory: build/config
Here you can find various preset configs for poco builds. I made a copy of 'ARM-linux' and edited it to suit my needs (these are only the changes):
LINKMODE ?= STATIC # since we are statically linking poco...
...
TOOL = arm-none-linux-gnueabi # this is the compiler we use
The rest was okay for me!
Then I compile poco like this:
$ ./configure --config=MY_OWN_CONFIG --prefix=/absolute/path/to/target/dir --no-samples --no-tests
$ make (compiles without a problem for me)
$ make install
after 'make install' (if everything is fine) the compiled libs will be in the directory specified by the '--prefix' option, and they are ready to be linked to your ARM applications.
I hope it helps!