[ https://issues.apache.org/jira/browse/PYLUCENE-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17182184#comment-17182184 ]
Andreas Vajda commented on PYLUCENE-55: --------------------------------------- All right, I wrote JCC a long time ago so it takes a bit of time to page its inner workings back in. The issue is that JCC tries really hard not to generate wrappers for the entire universe of Java classes reachable, transitively, from your requested set of wrappers. This process is recursive and order dependent, thus bugs in it can be tricky to reproduce as we just saw. The issue that triggered this bug is that you have some generics on classes or methods you want wrapped but with generic parameters that were not in the set of things to be wrapped either directly (via --jar or a direct classname) or indirectly (via --package). These missing dependencies cause JCC to drop methods using them. This is an important feature as it gives you control over the the amount of wrappers generated. The situation here is a mix or found dependency (a generic class) and not found dependency (a parameter to that generic class). I made it an error to be in that situation and this new error can be remedied via additions of --package parameters. In your case, you are missing --package java.util and --package it.uniroma1.lcl.jlt.util. Once these two package flags are added to the JCC invocation the BabelNet class gets all its 28 getSynsets() methods wrapped. This also explains why you didn't see any of your mappings since java.util defines a lot of that. The fix is checked into the PyLucene trunk svn repository at apache: https://svn.apache.org/viewvc/lucene/pylucene/trunk/jcc/ Please, try this out and let me know how it works for you. Thanks ! > JCC creates the classes in non-deterministic order > -------------------------------------------------- > > Key: PYLUCENE-55 > URL: https://issues.apache.org/jira/browse/PYLUCENE-55 > Project: PyLucene > Issue Type: Bug > Reporter: Andrea Sterbini > Priority: Major > > I am trying to wrap the BabelNet API code. > The resulting module is non-deterministically not-working (once every 5 I get > it OK). > This seems to be related to the order the classes are handled, because they > are kept in a set, which has nondeterministic order. > By changing cpp.py at line 696 to sort the class names I get a working module. > {code:java} > // changed from > for cls in todo: > {code} > {code:java} > // to > for cls in sorted(todo, key=lambda c: c.getName()):{code} > I have been luky with this way to order the classes. Possibly a better > algorithm exists to fix this bug. -- This message was sent by Atlassian Jira (v8.3.4#803005)