I am using VTK via the Java binding and I ran into a few oddities about the Java API.
For instance, I am trying to use a vtkHigherOrderCurve, and was expecting to access the ParametricCoords in Java.
The fact is, I could see only a « SetParametricCoords() » function in the Java generated class, not a getter — like a hypothetical GetParametricCoords() function.
Here is the public API from the vtkHigherOrderCurve from the Java class:
So, I kept searching about the *.java wrapping source automatic generation and finally understood it’s done with an intermediate C program named vtkWrapJava-xxx.exe, which compiled at first and then called at the right time thanks to the vtkCommonDataModelJava-java-sources project and vtkHigherOrderCurve.java.rule (pretty neat contraption by the way!).
A similar mechanism is used to generate the C++ intermediate JNI dynamic library source code (DLL in my case) with the vtkCommonDataModelJava project and vtkHigherOrderCurveJava.cxx.rule.
Now, for some reason, the vtkWrapJava-xxx.exe program outputs the SetParametricCoords() function in the Java file but it won’t write the GetParametricCoords() function?! (and maybe some others functions are missing as well, I haven’t checked it yet)
Now, I can’t fathom a genuine reason for the GetParametricCoords() for being skipped.
My understanding is that there might be a bug or limitation in the vtkWrapJava-xxx.exe program, and so I am about to trace its execution with the Visual Studio debugger to see what it really does when it comes to this GetParametricCoords function of the vtkHigherOrderCurve.h.
I would expect it to write something similar to this in the .java/.cxx it generates (I wrote the getter myself as an example) :
Now that I wrote it manually, I wonder if maybe it’s because it could not know the « double* » array size to allocate with newDoubleArray and so it skips it?
As I said, I am going to check what vtkWrapJava-xxx.exe actually does, but any help or explanation on this issue would be quite nice from someone who knows something about the whole process!
If I really have to add some JNI functions to the *.cxx and *.java I guess I will have to do it anyway, but I really would prefer I didn’t have to, and obviously I would need to do it in way so that it’s not overwritten at the next compilation ^^
Thanks in advance for any tips!
PS: sorry about the first post split, I had to do it because I am a newbie here and cannot post more than 4 media in a single post apparently.
Well … shucks! That’s unfortunate! Technically understandable of course, but unfortunate nonetheless!
Thank you very much for the infos! How are the java guys doing to use vtk? Do they stick by the implemented functionalities?
Do you have an idea of the ratio of the problematic functions versus the correct ones? I could add some log to vtkWrapJava-xxx.exe to compute this. I hope I won’t need too many of them …!
If there is a lot to write initially, couldn’t it be a community job to manually write the new functions? Then it would be simple to add the new ones along when they are added to the vtk core? (with some kind of diff/patch added to the generated sources?) I don’t know if there is an active community big enough to do this?
I suspect that this method is even missed in Python as it also needs to know how much to put into the returned list object. If it is dynamic, we’ll need some other way to communicate the size of this array.
A -Wunwrapped warning to the wrappers probably wouldn’t be the worst thing in the world. I don’t think we can enable it by default though.
It contains a size hint so it should work but I see it is a virtual function and the overrides are all missing that size information. Possibly a bug in the wrapper logic on the descendant methods.
Did I mention that I think public virtual methods are bad idea?
This method actually is available in Python, because the Python wrappers are able to utilize hints that involve function calls, like the GetNumberOfPoints() call here.
The Java wrappers lack this level of sophistication. They can only utilize size hints that are constants.
)
