[vtk-developers] vtkJavaAwt.h and dependency issues

[Jeff Lee]

Hi (all interested),
There is a problem with the linking of libvtkRenderingJava.so which has 
long been a source of frustration to everyone using the java bindings in 
vtk.  It is a nasty chain of dependencies that come in due to the 
reference of one jni call, namely JAWT_GetAWT from vtkJavaAwt.h.  It 
basically causes us to do such nasty things as link 
libvtkRenderingJava.so with the base internal swing libraries in the jdk 
(libjawt.so, libmawt.so, libjvm.so).  This causes these dependencies to 
get built into ibvtkRenderingJava.so, and as such the lib has to be able 
to have all symbols referenced upon load into the jvm.  This is where 
the problems start.  It basically prevents us from being able to load 
libvtkRenderingJava.so in headless mode (when you want to do offscreen 
batch rendering) because java does a bunch of stuff at runtime to 
determine which libmawt.so to load.

The chain starts with the call to JAWT_GetAWT which causes us to link in 
libjawt.so.  libjawt.so contains unresolved references which get 
resolved by the jvm at runtime when it sees what kind of windowing 
system is being used (motif, x, headless).  This really means that we 
can't be linking in libjvm.so into libvtkRenderingJava.so because it 
will cause us to pick a libmawt.so(there are many of them) to resolve 
all of the symbols left hanging by libjawt.so.  This shouldn't be a 
compile-time decision, but a runtime one.

What I propose is to dynamically load libjvm.so and pull out the 
JAWT_GetAWT symbol at runtime (using our trusty vtkDynamicLoader), and 
not link libvtkRenderingJava.so with libjawt.so at all.  This gets rid 
of the chain of dependencies, lets us have a clean 
libvtkRenderingJava.so, and most importantly, it works in headless mode 
as well as in interactive mode.

Does anyone object to me making these changes to vtkJavaAwt.h?  There is 
also some CMakeList.txt logic which was introduced to add java libpaths 
that can be ripped out also.  I have this working on linux_32, linux_64, 
linux_ia64, win32, win64, aix5.3, sunos5.8, hpux_ia64, hpux_hppa.  I 
think it will be fine on osx, although I have no direct proof.  If 
anyone is interested, I can provide some more detail.
ugh,
Jeff