[Insight-users] About pipeline in Java

[William A. Hoffman]

I have checked in the fix for CableSwig.cxx.

I now get this:

public class itkImageFileReaderUC2_Pointer {
....
  public itkImageUC2 GetOutput() {


-Bill

At 11:22 AM 3/9/2004, Pablo D. Burstein wrote:
>That's very encouraging news. Please, let me (us)  know as soon as it's checked in.
>
>Thanks a lot,
>Pablo
>
>William A. Hoffman wrote:
>
>>This is a bug in the wrapping.  It should not return a SWIGTYPE_p class, it should
>>return the image class.  I checked in a fix, but had to back it out because
>>it broke the tcl wrapping.  I will post when I have checked in the new fix.
>>
>>-Bill
>>
>>
>>At 10:54 AM 3/9/2004, Pablo D. Burstein wrote:
>> 
>>
>>>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 ______________________________________________________________________
>>>_______________________________________________
>>>Insight-users mailing list
>>>Insight-users at itk.org
>>>http://www.itk.org/mailman/listinfo/insight-users
>>>   
>
>______________________________________________________________________
>This email has been scanned by the MessageLabs Email Security System.
>For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
>_______________________________________________
>Insight-users mailing list
>Insight-users at itk.org
>http://www.itk.org/mailman/listinfo/insight-users