I compiled the 9.0.0-rc1 with Java bindings. It seems that the bindings generator skips some functions, which were otherwise available in the VTK8.2 bindings. One particular example is vtkScalarBarRepresentation.java. The following functions were generated in 8.2
private native long GetScalarBarActor_2();
public vtkScalarBarActor GetScalarBarActor() {
long temp = GetScalarBarActor_2();
if (temp == 0) return null;
return (vtkScalarBarActor)vtkObjectBase.JAVA_OBJECT_MANAGER.getJavaObject(temp);
}
private native void SetScalarBarActor_3(vtkScalarBarActor id0);
public void SetScalarBarActor(vtkScalarBarActor id0)
{ SetScalarBarActor_3(id0); }
But they are not available in 9.0 bindings.
I’m guessing this is not the intended behavior. Any ideas of what could have gone wrong?
I’ve seen this problem when trying to compile master for quite some time. Not sure if the cause but definitely need to not lose any previous capability
I checked vtkInteractionWidgets-hierarchy.txt, and it does not contain vtkScalarBarActor. This suggests that the wrappers don’t recognize the fact that the InteractionWidgets module depends on the RenderingAnnotation module.
So perhaps the cmake wrapping rules are just using the module DEPENDS section and not the PRIVATE_DEPENDS when they build the hierarchy.txt files?
Well, that indicates that something that is a private dep is not actually. PRIVATE_DEPENDS things should not show up in public headers (and wrappers should not be looking at private headers).
The wrappers cannot wrap a method that uses vtkScalarBarActor as a parameter unless they can trace the hierarchy of the vtkScalarBarActor class. Forward declarations are a C++-ism.
So maybe our current PRIVATE_DEPENDS needs to be split in two? That way we could distinguish between entities that only appear within the .cxx files, and entities that appear in the .h files via forward declarations?
Hmm, I actually suspect the problem is not with how the hierarchy.txt files are built, but with how they are used. For each module in PRIVATE_DEPENDS that has a hierarchy file, that hierarchy file could be sent to the wrapper tools along with the main hierarchy file.
The other thing to note here if it wasn’t obvious - the Java sample code - in particular JoglConeRendering.java depends on the scalar bar actor mentioned above, so it fails, and the whole process fails about 36% in, so being able to test the Java wrapping for RC1 is impossible without some modifications (which I’ve had to do in the past when trying to compile master). I think if memory serves that you can build again on top of the initial attempt (without cleaning/removing files) and it will get further and maybe finish, but this shouldn’t be necessary…
I’m going to see if there’s a simple solution that can be applied for VTK 9. The cmake rules are already correctly dealing with the dependencies when they build the list of include directories that the wrapper tools need.
It also goes without saying that it would be great if someone could volunteer to maintain the Java wrappers.
I’ve merged in the latest from master with my fork (which has some custom changes on it, including the workarounds for the java issues with the scalar bar actor), and am running a build now, we’ll see how it goes.
Can confirm the vtk.jar and jnilibs weren’t copied over to the install directory. Hand copied them from the build tree, we’ll see if I can get the app running with it
No joy. The JoglConeRendering sample code shows a blank screen. (Using the libs in our main project also just shows a blank, sometimes all blue, renderer). This is using GLCanvas.
The jar is now installed with https://gitlab.kitware.com/vtk/vtk/-/merge_requests/6629. The JNI libraries aren’t installed, but we can look at how to get them in there. Do you happen to know of docs for the .jar layout with native libraries?
OK, I’ll do lib/java/vtk.jar and lib/java/vtk-$os-$arch until we have a better layout. Eventually, we can look at doing the fully packaged .jar with the native libraries in it (like we do for wheels).