Problem with java bindings in VTK 9

That is AWESOME! Thank you so much!!!

This actually allowed me to find a similar (but less pervasive) bug in the Python wrappers.

@dgobbi Thanks a lot! I’ve tested release branch and it works now - at least my brief tests.

I also noticed that I cannot compile with OSMESA:

vtk/vtk-release/ThirdParty/glew/vtkglew/src/glew.c:41:12: fatal error: GL/osmesa.h: No such file or directory
   41 | #  include <GL/osmesa.h>
      |            ^~~~~~~~~~~~~

I do set OSMESA_INCLUDE_DIR and OSMESA_LIBRARY variables in cmake, and I set VTK_OPENGL_HAS_OSMESA to on. When I manually add -I<path to include> to CXX flags, then things compile better, but linker fails. The same trick with adding -L<path to lib> did not work - something always fails to link.

Any ideas? Do I do something wrong?

Can you show the values that you used for OSMESA_INCLUDE_DIR and OSMESA_LIBRARY?

I set the following values

OSMESA_INCLUDE_DIR               /home/angainor/mesa/install/include
OSMESA_LIBRARY                   /home/angainor/mesa/install/lib/x86_64-linux-gnu/

When I run make VERBOSE=1, the include path is not seen on the command line when compiling ThirdParty/glew/. That’s why I tried to add it explicitly to compile flags. I looks like CMake is not using those variables, or at least not everywhere where it should.

I suspect that you are right that those cmake variables are not being used, but unfortunately I’m not very familiar with OSMesa. Can you start a new discussion thread for your question?

Of course, thanks a lot for your help!

Could someone actually using Java bindings please confirm that works for them?

Attempting to do this now, assuming I checked out the right branch, etc. Will let you know what I end up. Basically you’re looking for what ends up in the install dir for java related items, @ben.boeckel??

I’d like to know whether what is there is sufficient for you to get what you need from an install tree. If not, a list of what is missing would be very helpful (and its location in the build tree if you can find it).

Will do.

Just to keep you posted, I had some issues building last night (it seemed to have trouble finding the jogl/gluegen jars, even though they were specified via cmake), so I am trying again with my custom build script to see what happens.

Ah, I don’t think I tested with JOGL here. Trying it out.

I was able to get it to recognize the JOGL stuff with my custom build script (instead of going through ccmake) I’m just not sure why it was any different. I’m going to try to get a build done with my script, and then go back through doing it with ccmake to see if certain flags aren’t getting set (which I think is the case). A few to make sure:

JOGL_GLUE = <Your glugen-rt.jar file here>
JOGL_LIB = <Your jogl-all.jar file here>

I haven’t totally confirmed yet, but I’m pretty sure some of those weren’t getting set via ccmake once VTK_JAVA_INSTALL got set to ON. At a minimum, VTK_WRAP_JAVA should get enabled at that point, and the JOGL ones should get exposed; when JOGL_COMPONENT is turned to ON, the last 2 should get enabled and prompted for. Does that make sense? I’m not a cmake expert by any means, but that sounds like the series of updates via ccmake that need to take place. Like I said, I’ll try to confirm that later.

This variable no longer exists; if Java is enabled, it gets installed (controllable via install components).

They’re advanced variables, but they are there.

OK. Let me know what you get with the JOGL stuff enabled - for some reason now I’m having problems again, like the jars aren’t getting recognized. shrug emoji

I think that target_link_libraries with Java jar files doesn’t work as I thought it did. Seems I have to manually build up the -classpath argument.

I’ve successfully built with JOGL using the current state of the MR. If we need other paths added to FindJOGL to make finding it more automatic, please let me know.

Was the MR updated to recognize the class path? If not, were any special cmake fields besides what I mentioned above set?

Yeah, it just builds up a class path flag now.

OK copy that, let me pull and rebuild