[Insight-users] About pipeline in Java

[Pablo D. Burstein]

Hi,

	I have a problem understanding how the pipeline, used from Java-wrapped 
ITK, works. Specifically, when I used my own wrapping (and wrote a C++ 
pipeline), I could have an ImageFileReader connecting to an 
Image::Pointer and then access the Image's methods. Opposedly, when I 
use ImageFileReader from java, GetOutput() returns a 
SWIGTYPE_p_itk_ImageTunsigned_short_2_t (for example). How does this 
relates to ITK's Image now? What should I do if I want to call, for 
instance, GetBufferPointer() or have any similar access to the data?
And in general, is there any doc explaining the Java-wrapped ITK 
architecture?

Thanks,
Pablo


Brad King wrote:

> Pablo D. Burstein wrote:
>
>> Hi Brad,
>>
>> I caanot find itkbase.java anywhere (I wanted to take a look).
>
>
> It is in the ITK build tree under 
> Wrapping/CSwig/Java/{Debug,Release}/InsightToolkit, and is configured 
> by the build process from a source tree file under Wrapping/CSwig/Java 
> called itkbase.java.in.
>
> > I put InsigtToolkit.jar in the classpath but it didn't help. From my 
> JNI
>
>> experience, the Java class accessing native methods should load the 
>> dlls using the name of the library, no path or extensions allowed.
>
>
> The jar that is created by ITK now is designed to run from the build 
> tree only.  No installable version has been created.  The idea of 
> encoding the paths to the libraries is that one may use the jar by 
> simply adding it to the classpath (right from the build tree, not 
> copying it to somewhere else).  There is no need for adding the DLL 
> locations to the PATH environment variable.
>
>> I tried to look for System.loadLibrary in the wrapped code; haven't 
>> found anything of the kind. How do libs get loaded then?
>
>
> If you find the code in itkbase.java, it should be clear how it works. 
> All the wrapper code in java starts by calling a method in 
> itkbase.java to find and load the native DLLs.  The whole idea is to 
> work around what seems to be an inherent Java/Windows design flaw.  No 
> one should ever have to add entries to both the CLASSPATH and the PATH 
> variables just to load a package.  What if a user points the PATH to 
> the wrong DLL versions for the jar to which they pointed the CLASSPATH?
>
> -Brad




______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________