On Feb 26, 2011, at 18:48, Bill Janssen <jans...@parc.com> wrote:
Andi Vajda <va...@apache.org> wrote:
On Sat, 26 Feb 2011, Bill Janssen wrote:
I'm seeing a lot of errors of the form:
build/_GoodStuff/__wrap07__.cpp:57522: error: ?class
com::parc::goodstuff::t_FooIterator? has no member named ?
parameters?
Apparently relating to code like this:
if (!parseArgs(args, ""))
{
OBJ_CALL(result = self->object.nextElement());
return self->parameters[0] != NULL ? \
wrapType(self->parameters[0], result.this$) : \
java::lang::t_Object::wrap_Object(result);
}
I look in the header files, and, sure enough, there's no
"parameters"
field to be found.
FooIterator is pretty complicated; it extends an abstract class, and
implements several interfaces as well. I wonder if something is
getting
mixed up about where the "parameters" member should be emitted.
Maybe you found an unrelated bug ?
It may be simplest if you can send me the source file for this class
as well as a small jar file I can use to reproduce this ?
Yes, that would be great, but it's part of a huge shaggy jarball I'm
trying to wrap. Don't know if it really has any significant relation
to the iteraction detection.
I'm guessing what's going on is that I actually have two huge shaggy
jar
files, goodstuff.jar and libstuff.jar. I'm using "--jar goodstuff.jar
--include libstuff.jar". The actual iterator class is in
libstuff.jar,
but the derived class is in goodstuff.jar. I thought that perhaps JCC
was thinking that the "parameters" member would be generated for the
class in libstuff.jar, but since that wasn't actually being processed,
the expected member variable wasn't there.
The parameters stuff is related to Java generics. It's represents the
type parameters for a generic class.
Andi..
I'll see what I can figure out.
Bill
