-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delay resolving super classes until referenced #146
Delay resolving super classes until referenced #146
Conversation
We should attempt to add a unit test for this. If we understand have a deep enough understanding of the underlying problem, I expect we could have simple fixture classes to demonstrate it. |
Worth noting that we don't run jpy tests at this time as part of CI or releases, they don't consistently pass enough to be useful. Deephaven-core has its own modified suite that we run instead. |
b625a98
to
48aee74
Compare
f6f680b
to
b50f206
Compare
8b27378
to
50d9dce
Compare
src/main/c/jpy_jtype.c
Outdated
} | ||
|
||
JPy_DIAG_PRINT(JPy_DIAG_F_TYPE, "JType_GetType: javaName=\"%s\", found=%d, resolve=%d, resolved=%d, type=%p\n", type->javaName, found, resolve, type->isResolved, type); | ||
|
||
if (!type->isResolved && resolve) { | ||
if (JType_ResolveType(jenv, type) < 0) { | ||
JPy_DECREF(type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need an error log?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably not b/c the functions that resolves the members (methods, fields, etc.) log the specific errors. That said it wouldn't hurt to log it at this level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first, I thought "resolve" was a proxy to java Class.forName
"initialize" param, but that is not the case. "resolve" here is jpy-logic for "have I reflected over the class type so I can know all the methods I can call".
It is user accessible via jpy.get_type("SomeClass", resolve=...)
. We might want to add some tests around this:
AClass = jpy.get_type("AClass", resolve=False)
BClass = jpy.get_type("BClass", resolve=False) # extends AClass
CClass = jpy.get_type("CClass", resolve=False) # extends BClass
# tests to show the above classes are not resolved
jpy.get_type("BClass")
# tests to show that AClass and BClass are resolved; and CClass is still not resolved
jpy.get_type("CClass")
# tests to show that AClass, BClass, CClass are resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also noticing we may be overcounting in JType_InitComponentType
and JType_InitSuperType
:
if (superClassRef != NULL) {
type->superType = JType_GetType(jenv, superClassRef, resolve);
if (type->superType == NULL) {
return -1;
}
JPy_INCREF(type->superType);
JPy_DELETE_LOCAL_REF(superClassRef);
}
JType_GetType
should be incrementing the ref count for us, so we shouldn't need to increment it again, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Jianfeng and I went over this and improved the reference counting logic, which I think is more correct now. Practically speaking though, once a type is successfully resolved into the jpy type ref dict, there is no (official) way to remove it, so it should stay referenced forever.
Fixes #142