I set it to 21.
I built jar by hand.
Same behaviour, the release build crashes with “A DLL initialization routine failed.” Debug build runs.
I don’t tink it’s solvable by CMake configurations at the moment. It looks really like it’s imposible to build vtk 9.x for java!.
The problem is not in class files, but in release dlls of java wrapping.
You see the error when you just load one of these dlls with system load. For example vtkIOParallelXMLJava. It’s only anout wrapping DLLs, like e.g. vtkIOIOSSJava.
I will now start to build older vtk versions and try to figure out when this was introduced.
Ok. After many builds and a lot of investigation I now know the following:
The last version which loads into Java was 9.0.0.
Every other version since that is broken. Release DLLs fail to load into java.
Maven is no complete build, it’s a vtk.jar at maven central without any native dependecies.
At the moment, there is no valid migration path: VTK java is dead!
On my point of view, features in a software project should never break - especially something as fundamental as a language binding. This is much more critical than a little bug in some modul - whole applications depend on that. Either it should be maintained or deleted, there is nothing in between.
Thanks very much Philipp for the in-depth analysis of this Java issue. I would agree that where the build loads (9.3.1 & 9.4.1) only the Debug does and not the Release. Of my builds, 9.4.1 did run while 9.3.1 did not. It seemed as if each time a problem was resolved, the solution disappeared in the subsequent release.
I have also worried that I may never be able to build and run a final 9.x.x release and in all likelihood, these problems are still inherent in the expected 9.5.0. It would be very sad and in cases (not least mine) tragic, if this marked the end of consistent Java support for vtk.
But, I am encouraged that you seem to have a handle on the problem. At least you have identified the root cause. May the force be with you in your efforts to build that java-migration path. We cross our fingers and wait for a breakthrough in good time for 9.5.x.
@metamurk I appreciate the detailed investigation and the time to report it in this thread.
The last version which loads into Java was 9.0.0
After the release of 9.4.0 we made some changes in the release branch that enabled us to build a maven package (Release build) that ran in our target machine.
Maven is no complete build, it’s a vtk.jar at maven central without any native dependecies.
The Maven central package is not working, some working (depending on platform) packages are available at Packages · Kitware, Inc. · GitHub.
You could download the native packages in the following manner (you might need to fix the URL):
At the moment, there is no valid migration path: VTK java is dead!
That is incorrect, we do test the Linux VTK java build in every commit and we did it for the latest release (v9.5.0-rc1). For Windows/Mac, VTK java is indeed currently broken, the reason of these failures is that we do not have CI coverage of these platforms in our merge-requests, meaning that every change to master can (and it did) potentially break these builds.
From the VTK dev team we have a strong interest for maintaining VTK Java bindings. Unfortunately we have not had the resources/personnel to successfully and long lasting achieving that. An important push was done to bring the VTK Java bindings from 2018 to 2024 which briefly yielded satisfactory functioning Java builds for some time.
The situation is unlikely to improve unless we can get our hands in extra CI resources (Java builds are resource intensive), otherwise, as much as put our effort into get master into a buildable/runnable state, it is at the risk to be broken in the next merge-request.
Good morning Vicente and thanks very much for the explanation. I am very much encouraged that the java migration problems are well known and are being worked on in on-going supports efforts of the central team. My personal fear had been that, on evidence available, java is being downgraded progressively as a medium of application for vtk. I am gratified that that this is not so.
Thanks very much and good luck with on-going efforts.
The version on works. But we need to replicate this in our build system due to patches and dependend native code. Can you tell me the exact commit of this snapshot? I’m not able to pinpoint it…
I just wanted to remind everyone that VTK is an Open Source project and if you like what it is doing for you, you can contribute back.
This could be done in the form of time, by improving documentation, code or anything else that is relevant to you and your capabilities. (i.e. fixing Java build for Windows)
Or, you can also involve Kitware by asking us to improve, develop or maintain specific features of VTK/ParaView/CMake/trame/etc by supporting us financially while we do so.
So if projects depends on VTK, then those projects should help supporting VTK. I understand why it is great to expect everything for free but in many ways, that is not realistic. So, while we do our best to do it for the greater good, sometime it won’t be enough. So help us do better!
@Sebastien_Jourdain
Can I just add to that. Whenever there is a request to JAVA developers for feedback about wrapped features that are liked, disliked, desired or how to handle things like passing method parameters by reference and unsigned integers there is zero response. It’s like talking to a vacuum.
Indeed, the VTK/Java community is not active on the forum, and within Kitware we do not have Java project that we maintain or develop. Hence the absence of comment from Kitware too. If we were getting involved in those projects, we could provide better help.
You’re absolutely right. But - whether the project is commercial or open-source, it’s best-practice to ensure nothing is left broken and no major branch of functionality falls outside the test suite’s reach. Open source, especially, carries an implicit promise of reliability and accountability: every public commit attests to that commitment - and that’s how it works and why these commits are made for it for free.
That’s also why we rely on these libraries—we expect them to do exactly what they claim. In this case the stakes are even higher, because it’s a full language binding that touches entire code bases. There are really only two responsible choices: maintain it properly or remove it entirely. There’s no middle ground. If you don’t want or can maintain something - what I understand - than delete it and comunicate it to the community because there are whole organizations with a lot of people who rely on it. Like that this just causes a lot of trouble, costs and problems in many organizations.
Can you imagine Torvals saying: I don’t maintain this anymore, but I ship a bunch of broken drivers and act like it works? I cannot…
I guess what fall under the test suite’s reach is just Linux right now for the Java build. If the community has interest to go beyond that, they can pitch in.