[Swig-user] Problems with Java typemaps to replace an input object parameter with a different type

[Juan H. <jhe...@la...>]

Dear all,

I'm trying to wrap different C++ namespaces into different Java packages 
with SWIG 1.3.36 and so far I've been able to work out all the details 
except one.

Suppose I have two namespaces A and B that map to Java packages A and B. 
In both namespaces there is an homonym class Foo which we don't want to 
rename (actually renaming would solve much of the problems but that's 
inconvenient from the user perspective).
In A there is a class like this:
class Problematic
{
     void f(Foo &x);
     void f(B::Foo &x);
};
As the documentation says this type of code causes name clashes in the 
target language because namespaces are flattened. I could rename one of 
the overloads but then the C++ code and Java code wouldn't be the same 
and I want to avoid that.

So, the solution seems to be providing a typemap for B::Foo &, but I'm 
not able to get it right.

First I define a typemap for jstype
%typemap(jstype) B::Foo & "B.Foo"
so the Java code looks like this:
...
     public void f(B.Foo x) {
     ModuleAJNI.f__SWIG_1(swigCPtr, this, B.getCPtr(x), x);
     }
...
The Java interface is exactly what I want but it doesn't work for 2 
reasons. First getCPtr is called on the wrong class, so I have to 
provide a typemap for javain. And then, premature garbage collection 
parameter doesn't match the type in ModuleAJNI.f__SWIG_1 because I 
haven't changed jstype. I've tried many possible combinations but 
without success. The key points are that there is no way to override the 
type of the permature garbage collection parameter (and I don't want to 
get rid of it) and that the JNI type is unique so I can't do tricks with 
the argument list without affecting other points of the C++ code. The 
closer I got was working fine but since I changed the jni type it 
affected wrapping of Foo & as a return type.

Passing the object directly instead of the pointer seems to be a 
possible solution but that involves direct access to fields in the C++ 
side, which is cumbersome and not less efficient that getCPtr.
I'd appreciate very much any idea about how to solve this problem neatly?

Thanks for your time
Best regards,
Juan