Thank you for the detailed description and code to reproduce. You may have found a bug here, I need to investigate.
To be continued...

Andi..

On Thu, 26 Nov 2020, Erik Groeneveld - Seecr wrote:

L.S.,

We use PyLucene and JCC from the beginning and are very satisfied with it
but we do have a problem. It appeared while using Lucene, but we brought it
down to the following.

(Everything is at https://github.com/ejgroene/jcc-howto.git, clone and run
go.sh.)

We have an extension pkg1 with:

package pkg1;

public class Wtf {}

and an second extension with that uses the first:

package pkg2;

import pkg1.Wtf;


public class MyWtf {

   public void f(Wtf a) {}

}

NB: pkg2 uses a class from pkg1 as method argument type.

The Python program is:

import pkg1

pkg1.initVM()


import pkg2

pkg2.initVM()


c = pkg1.Wtf()

s = pkg2.MyWtf()


# should work, but it gives InvalidArgs

s.f(c)

It will not call s.f because although c is an pkg1.Wtf, it is not the same
Java class (not ==).
It seems we have duplicate wrappers for the same class.

The build looks like:

python3 -m jcc \

       --shared \

       --jar build/pkg1.jar \

       --python pkg1 \

       --build \

       --install \

       --root dist


python3 -m jcc \

       --shared \

       --import pkg1 \

       --package pkg1 \

       --jar build/pkg2.jar \

       --python pkg2 \

       --build \

       --install \

       --root dist

The whole setup is available at https://github.com/ejgroene/jcc-howto.git.
Clone it and run go.sh.

It seems to me that there is a contradiction between --import, as it is
intended for sharing wrappers across extensions, as per

"When more than one JCC-built extension module is going to be used in the
same Python VM and these extension modules share Java classes, only one
extension module should be generated with wrappers for these shared
classes. The other extension modules must be built by importing the one
with the shared classes by using the --import command line parameter. This
ensures that only one copy of the wrappers for the shared classes are
generated and that they are compatible among all extension modules sharing
them."

however, we also need --package for JCC to recognize the type of the
argument and generate code for f as per

"JCC generates wrappers for all public classes that are requested by name
on the command line or via the --jar command line argument. It generates
wrapper methods for all public methods and fields on these classes whose
return type and parameter types are found in one of the following ways:

  - the type is one of the requested classes
  - the type is one of the requested classes' superclass or implemented
  interfaces
  - the type is available from one of the packages listed via the
--package command
  line argument"

(Originally MyWtf extended Wtf, making the wrapper generation for Wtf (in
pkg2) implicit, so we could do without --package.)

I looked at all the documentation as well as the (generated) source code,
but I could not find a solution.

What am I doing wrong?

Best regards,
Erik Groeneveld

--
Erik Groeneveld  ♦ seecr.nl ♦ +31 624 584 029

--
Seecr helpt informatieprofessionals met het consistent integreren en
verbinden van decentrale metadata zodat zij zich helemaal kunnen focussen
op de inhoud.
?? Meer weten? Kijk op seecr.nl <https://seecr.nl>.

Reply via email to