# How to extend the Java wrapper API?
**URL:** https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970
**Category:** Development
**Created:** [April 6, 2020, 12:53pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970 "2020-04-06T12:53:20Z")
**Posts on this page:** 8
**Page:** 1
### Author:  [@mat127](https://discourse.vtk.org/u/mat127)
#### Post date: [April 6, 2020, 12:53pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/1 "2020-04-06T12:53:20Z")
Hello,
I have realized that VTK Java wrapper API is a _subset_ of the full VTK API. How is the wrapper generated and how is the selection of what will be available in the Java wrapper done?
Is it possible to add a particular method that is missing?
What I need is the `vtkHardwareSelector::GetPixelInformation()` method(s). I understand that there is probably an issue with returning the inner class `PixelInformation` instance by a value. So I tried to add a method returning just the vtkProp\* which is sufficient for me. But still not able to get it into the Java wrapper API. How can I do it?
Petr
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 6, 2020, 2:27pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/2 "2020-04-06T14:27:26Z")
The Java wrappers “see” that they don’t know how to generate code for some function signatures and skip them silently. I’d look at the `Wrapping/Tools/vtk*Java.*` files for how Java and JNI code get generated and see if the skipped method patterns can’t be implemented.
Cc: @dgobbi
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [April 6, 2020, 3:02pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/3 "2020-04-06T15:02:41Z")
Hi Petr, you are correct that structs like `PixelInformation` aren’t wrapped. My best guess is that the `GetPixelInformation()` method was only meant for internal use (i.e. for use by other VTK classes, not by application code). Are you sure that you can’t solve your problem by using vtkScenePicker instead of vtkHardwareSelector?
For extending the wrappers, adding a method that returns a `vtkProp*` should work, as long as you re-compile the wrappers afterwards.
---
### Author:  [@mat127](https://discourse.vtk.org/u/mat127)
#### Post date: [April 7, 2020, 8:16am UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/4 "2020-04-07T08:16:00Z")
Hello Ben and David,
thank you both very much for your answers.
I have already tried the `vtkScenePicker` but with no success. The problem is that its API does not allow to control the cached pixel information invalidation and update. In my case after opening the window containing the `vtkRenderWindowPanel` the `vtkScenePicker` starts to periodically call the `vtkScenePicker::PickRender` even there is no interaction or renders happening. The whole application is stuck and no responding to any user interaction. As the purpose of using the `vtkScenePicker` was optimization this result in unacceptable.
That is why I decided to build a custom picker around the `vtkHardwareSelector` with respect to my custom interactor style. So I added a public method declaration:
` vtkProp* GetPixelProp(const unsigned int display_position[2]);`
into the `vtkHardwareSelector.h` file and its implementation into the `vtkHardwareSelector.cxx`. Then `cmake` on a fresh empty build directory and `make` but the introduced method did not appear in the generated `vtkHardwareSelectorJava.cxx`. So its also missing in the resulting vtk.jar. What could by wrong here?
Petr
---
### Author:  [@mat127](https://discourse.vtk.org/u/mat127)
#### Post date: [April 7, 2020, 10:55am UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/5 "2020-04-07T10:55:16Z")
To answer my own question myself if someone is interested:
The problem was the int array parameter. Changing the method signature to:
`vtkProp* GetPixelProp(unsigned int display_x, unsigned int display_y);`
solved the problem and such method appeared in the Java wrapper API.
As far as I know floating point arrays as method parameters are allowed. I did not try it yet but at least I know about several methods presented in the Java wrapper having such kind of parameters. Maybe because they are used for returning values from the method.
---
### Author:  [@ben.boeckel](https://discourse.vtk.org/u/ben.boeckel)
#### Post date: [April 7, 2020, 12:26pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/6 "2020-04-07T12:26:42Z")
> [@mat127](#):
>
> I did not try it yet but at least I know about several methods presented in the Java wrapper having such kind of parameters. Maybe because they are used for returning values from the method.
This is likely the reason here.
> [@mat127](#):
>
> I have already tried the `vtkScenePicker` but with no success. The problem is that its API does not allow to control the cached pixel information invalidation and update. In my case after opening the window containing the `vtkRenderWindowPanel` the `vtkScenePicker` starts to periodically call the `vtkScenePicker::PickRender` even there is no interaction or renders happening. The whole application is stuck and no responding to any user interaction. As the purpose of using the `vtkScenePicker` was optimization this result in unacceptable.
@ken-martin?
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [April 7, 2020, 4:31pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/7 "2020-04-07T16:31:33Z")
> [@mat127](#):
>
> vtkProp\* GetPixelProp(const unsigned int display\_position[2]);
Interestingly enough, if the “unsigned” is removed, this will wrap. I’ll have to check the wrappers to see if there is a valid reason why arrays of “int” are wrapped but not arrays of “unsigned int”.
---
### Author:  [@dgobbi](https://discourse.vtk.org/u/dgobbi)
#### Post date: [April 7, 2020, 5:08pm UTC](https://discourse.vtk.org/t/how-to-extend-the-java-wrapper-api/2970/8 "2020-04-07T17:08:03Z")
Java doesn’t have unsigned integer types, and after inspecting the VTK Java wrappers, I found:
- they silently do bitwise casting between C “unsigned int” and Java “int”
- they ignore any methods that use C “unsigned int[]”
So the behavior is inconsistent, and there is a trade off between functionality and safety. I’ll leave it to the Java experts to decide what behavior is most desirable.