Hello together,
I try to load vtk 9.4.1 into java. I have build with wrappings, vtk jar and wrappings dll are build.
I copied it al together and try to to call vtkNativeLibrary.LoadAllNativeLibraries();.
It fails. Several dlls cannot be loaded, e.g. vtkTestingRendering. DependencyWalker is green. I traced it down to vtkFiltersCellGrid. It cannot be loaded into java. What is going on here? Is this broken?
I now tested the standard example on several machines. The error is reproducable in both debug and release dlls. I don’t use jogl. I looks like the java wrapping is fundamental broken.
Are you using our maven published package? @vbolea
No, I need to build VTK manually with Java wrappings because my build process produces custom code in additional DLLs and includes patches to several VTK classes.
My current workflow is straightforward: I configure the build environment using CMake and Ninja, then execute the build. Although the build completes without errors, running the example results in crashes when loading multiple DLLs. I tried to disable some modules, but it seems that fundamental dlls cannot be loaded.
I tested that on several machines, always the same.
Hi @metamurk, I have been maintaining Java (Maven) builds in the release branch of VTK. You could try our latest release (9.4.2), in that release we include a few changes in the way that we build/run-time link VTK JAVA (Maven). Note all of this is WIP at the moment and we are currently only targeting MAVEN as the way for users to install VTK JAVA.
In addition to that, here are the flags that we use to build our MAVEN artifacts in our CI, you might not need all of this vars (since you are not using maven), but you definitely have to disable the modules below.
set(BUILD_TESTING OFF CACHE BOOL "" FORCE)
set(JOGL_VERSION "2.3.2" CACHE STRING "")
# Naming is <arch-platform-build_type> we avoid adding numbers in the arch
# such as 64/86 since some maven versions fail to properly parse it.
string(TOLOWER "${CMAKE_BUILD_TYPE}" build_type)
set(native_artifacts
darwin-amd-${build_type}
darwin-arm-${build_type}
linux-amd-${build_type}
windows-amd-${build_type}
)
set(MAVEN_NATIVE_ARTIFACTS "${native_artifacts}" CACHE STRING "" FORCE)
unset(build_type)
unset(native_artifacts)
set(MAVEN_VTK_ARTIFACT_SUFFIX "-java${VTK_JAVA_TARGET_VERSION}" CACHE STRING "")
# Disable snapshots for tag releases and also when the env variable
# VTK_JAVA_FORCE_RELEASE is defined through the Gitlab schedule pipeline UI.
# Note that VTK_JAVA_FORCE_RELEASE is used to create/override VTK java
# releases.
if (NOT DEFINED ENV{CI_COMMIT_TAG} AND NOT DEFINED ENV{VTK_JAVA_FORCE_RELEASE})
set(MAVEN_VTK_SNAPSHOT "-SNAPSHOT" CACHE STRING "")
endif()
set(VTK_BUILD_TESTING OFF CACHE BOOL "" FORCE)
set(VTK_CUSTOM_LIBRARY_SOVERSION "" CACHE STRING "")
set(VTK_CUSTOM_LIBRARY_VERSION "" CACHE STRING "")
set(VTK_DEBUG_LEAKS OFF CACHE BOOL "" FORCE)
set(VTK_GROUP_ENABLE_Rendering "YES" CACHE STRING "")
set(VTK_JAVA_JOGL_COMPONENT "YES" CACHE STRING "")
set(VTK_MODULE_ENABLE_VTK_RenderingOpenXR NO CACHE STRING "" FORCE)
set(VTK_MODULE_ENABLE_VTK_TestingCore NO CACHE STRING "")
set(VTK_MODULE_ENABLE_VTK_TestingDataModel NO CACHE STRING "")
set(VTK_MODULE_ENABLE_VTK_TestingGenericBridge NO STRING STRING "")
set(VTK_MODULE_ENABLE_VTK_TestingIOSQL NO CACHE STRING "")
set(VTK_MODULE_ENABLE_VTK_TestingRendering NO CACHE STRING "")
set(VTK_VERSIONED_INSTALL "OFF" CACHE BOOL "" FORCE)
set(VTK_MODULE_ENABLE_VTK_vtkvtkm NO CACHE STRING "") # Java Wrap errors in windows
Ok, thanks. I’ll tried that out and it does not work.
A documentation would help. The behavior is cryptic; you seem to run from one problem to the next and all you can do is try and error.
Just unpack it. Running the usual CMake setup and run ninja build results in linker crashes such as:
java.lang.UnsatisfiedLinkError: java.lang.UnsatisfiedLinkError: C:\HEAD\env\app\lib\vtkFiltersCellGridJava.dll: Eine DLL-Initialisierungsroutine ist fehlgeschlagen
Redist is installed, every depended DLL is available. Something in the dll seems to be disliked by the java vm when it is build in a certain way. I had a configuration which was loadable, but after a windows update it fails again with the same errors. The thing was that in every case it worked, the jaring failed and I had to jar it by hand.
It would be awesome if anybody had an idea what could cause the builded dll to be rejected by the jvm and which cmake flag is producing that.
The unloadable dlls are all java wrapping dlls:
vtkFiltersCellGridJava
vtkIOLegacyJava
vtkParallelCoreJava …
Ok, after many tries I figured out something:
So there is no way at the moment to build a vtk 9.4.2. release and load it into an actual JVM.
So there is no migration path for java products based on vtk at the moment.
Is there a ticket for this or anymore knowledge? Could we support somehow? For us this is a real major issue, cause we have several commerical products depending on these wrappings massivly . Migration is necessary, major feature are blocked…
Is this relevant?
Good morning Todd and thanks for getting in touch. Yes, this was the problem with java 9.4.0. The problem was ‘kind of solved’ in 9.4.1 in that the Debug was fine while the Release would not run after a clean build.
We seem to have the same problems with 9.4.2. The build is clean but neither the Debug nor the Release will run. David identified something which was put into 9.4.1 but may have been dropped again.
I have attached the run error log I am getting. My build system is CMake 4.0.0 and VS 2022- latest update. I have also attached, for confirmation, the directory listing showing the file the system can’t load as missing.
I shall be most grateful if you have any insight into this or tricks I can try to identify the solution. Thanks again and good luck.
ngwarai
runErrorLog.txt (9.51 KB)
dir.txt (15.2 KB)
Hi Todd, thank you.
I think the behavior is the same as in 9 4.1 . Debug runs but Release not. Without Release DLLs in Java, we cannot migrate anymore to higher vtk versions. Debug Dlls are significantly slower.
Did you try setting VTK_JAVA_RELEASE_VERSION in CMake? Otherwise it defaults to version 8
The only other thing I can suggest is to try VTK_BUILD_MAVEN_PKG=OFF and do a manual build of the JARs.
Good morning. No, I have not tried that one. I will give it a bash and report back. Thanks and happy Easter
I don’t think that Javaside flags like Release Version could have any influance on it.
JVM really rejects loading vtk Release DLLs in every newer version (so java Wrapping practically doesn’t work at all for newer vtk versions). This must have something to do with the dependcy hierachies of VTK and the JVM …
and you think the dependency changes between debug and release builds?
Yes. With the same Cmake config debug build can be loaded, while release builds are failing.
It’s not really the static depedency, they are all good. Also there is no dynamic loading. Something else must prevent the JVM from loading them. And it’s not all Dlls, but a subset which cannot be loaded.
Following this very keenly. I hope a solution can be found before 9.5.0 is out, else the problem will manifest itself again in the new release. Thanks very much and good luck.
Have you tried what I suggested?
Did you try setting VTK_JAVA_RELEASE_VERSION in CMake? Otherwise it defaults to version 1.8
Thanks Todd. No I haven’t yet. I was confused somewhat, because I have no alternative java version on my build machine, only the 1.8. I will have another go at it and report back. Thanks
ngwarai
I just tried it. Makes no difference…
Tried what? Setting VTK_JAVA_RELEASE_VERSION = x?
What about manually building the JARs?