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.
Can I get confirmation of that statement - Java bindings are broken for Windows and Mac in vtk9.5???
If so, can information like this be placed prominently in the release notes? I’ve spent days trying to figure out why 9.5 doesn’t work (and yes, I am one of those people who has to custom build, since methods we need aren’t exposed to Java for whatever reason), and I wouldn’t have even started down this path if I knew things were so broken.
To that end, and following discussion in this thread, I would love to have a separate Java support category in this discourse that I could follow and keep up with. I tend to not pay attention to here until I need help, but if the devs were reaching out and telling us that things are broken in upcoming releases it sure would lessen the amount of headaches I encounter.
It also sounds like vtk9.4 seems to work ok with Java on all platforms?
Hi Josh and thanks very much for reaching out and sounding a note of hope. Technically, I am not a developer at all but I have used vtk in “hobby” development of Java 3D processing and viewing applications since vtk4.0.
Then, they did provide the dll’s and jar ready to use.
In my experience, Windows builds up to vtk 8.2.0 build clean and run. My problems started with vtk9.0. Up to vtk9.5.0, some of the intermediate releases run only in DEBUG. None of RELEASE versions even load into java. I have read comments about the system being broken but did not quite comprehend the SW technicalities involved.
My latest attempt was on vtk9.5.0. The RELEASE follows the said traits but the DEBUG builds with minor errors and basically runs. I would be thrilled to do trial builds and report back the errors encountered. My build system is on Windows 10, CMake 4.1.0, Visual Studio 22 - latest update and Netbeans 8.2. I have java installed on two machines. One is on java 8, which I am working to migrate to Java 24. The 2nd machine is also Windows 10 with Java 24 and Netbeans 25.
I commit these resources to anything I can do to sort out this broken system to enable us java users (lovers!} to migrate to vtk9.x.x without problems.
Good luck with this initiative Josh and I look forward to hearing from you soon. Thanks again.