On Tue, 7 May 2013, Barry Wark wrote:
I recently discovered JCC (awesome project!) and am attempting to use it to
wrap a Java API for Python users. It's been working great, with two
exceptions. I'd be grateful for any advice on the following:
1) Public methods from implemented interfaces are not wrapped
We have where (public) methods of interfaces are not wrapped. Here's a toy
example:
package us.physion.mixin;
public interface MixinA {
void mixinMethodA(String);
}
public interface MixinB {
void mixinMethodB(String);
}
package us.physion.domain;
public interface Entity extends us.physion.mixin.MixinA,
us.physion.mixin.MixinB
{
void entityMethod();
}
public interface MyClass extends Entity
package us.physion.domain.impl;
public class EnityBase implements us.physion.domain.Entity {
}
public class MyClass extends EntityBase implements
us.physion.domain.MyClass {
}
MyClass is wrapped correctly, and exposes entityMethod. However, the
mixinMethodA and mixinMethodB aren't exposed. We get an AttributeError when
calling mixinMethodA on a MyClass instance:
In [10]: myInstance = MyClass()
In [11]: myInstance.mixinMethodA()
---------------------------------------------------------------------------
AttributeError Traceback (most recent call last)
<ipython-input-10-51f1cf2e8c2d> in <module>()
----> 1 myInstance.mixinMethodA('foo')
AttributeError: 'MyClass' object has no attribute 'mixinMethodA'
The issue may or may not be related to the second issue of name collisions.
You can access these mixin methods by casting to the owning interface:
MixinA.cast_(myInstance).mixinMethodA('foo')
The cast_() here function rewraps your Java object with a wrapper for the
MixinA interface (also checking that the Java instance can be cast to it).
Note that we have an interface us.physion.domain.MyClass, and the
implementation us.physion.domain.impl.MyClass. JCC 2.15 sees these as a
name conflict, so we have
--rename us.physion.domain.impl.MyClass=us_physion_domain_impl_MyClass
in our wrapper invocation.
Can anyone guide me in the right direction?
2) Name collisions across packages
The same example above shows a name collision
between us.physion.domain.impl.MyClass and us.physion.domain.MyClass. We're
using
--rename us.physion.domain.impl.MyClass=us_physion_domain_impl_MyClass
in our wrapper invocation, but --rename is not well documented on the JCC
web site, so i'm not positive we're using it correctly. I saw a post from
Aug 29 to this list that says JCC 2.16 models the entire package structure,
avoiding these name collisions, but when running JCC from SVN trunk this
doesn't appear to be the case (we still get the name collision without the
--rename).
Are we using --rename correctly?
Looks correct to me but you should use JCC 2.16 instead and use its
--use_full_names command line flag instead so that the full package
hierarchy is reproduced as Python modules. JCC 2.16 is available from trunk
and its release is imminent (PyLucene 4.3.0 rc1 is up for release vote).
When using --use_full_names, you must first import your main Python
extension - which causes the java packages to be installed - then the java
hierarchy packages. For PyLucene, the main extension is called 'lucene', for
example:
>>> from lucene import initVM
>>> from org.apache.lucene.document import Document
>>> etc....
>>> initVM()
>>> d = Document()
Andi..
Thank you,
Barry
