-
Notifications
You must be signed in to change notification settings - Fork 4
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
Calljava doesn't appear to work with arguments when class accepts an interface #6
Comments
It seems that this can be resolved by working through permutations of the argument's base classes in the case of a NoSuchMethodException. This can explode exponentially in the performance impact (In the case of an actual missing method when using 3 arguments with 10 base classes each, it will incur 1000 lookups before actually giving up), but normal use shouldn't cause any of these kinds of issues. In any case memoization can curtail most expense in repeated calls. |
It's also notable that the JavaCallHelper won't work when a method is declared in an interface or superclass, because it uses getDeclaredMethod instead of getMethod. |
I think with the string arg you have to use -prim
As for getDeclaredMethod vs getMethod I'll have to look at that.
…On Thu, Dec 15, 2016 at 5:40 PM, Taylor C. Richberger < ***@***.***> wrote:
It's also notable that the JavaCallHelper won't work when a method is
declared in an interface or superclass, because it uses getDeclaredMethod
instead of getMethod.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEZAhM16b0ylokGa-G5q-AKu9E_qNVzXks5rId36gaJpZM4LOuBP>
.
--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021
NON-DISCLOSURE NOTICE: This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information. If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited. If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
|
prrimarg doesn't work, because it still manages it as a String, and doesn't find the method that takes a CharSequence, as String.contains requires (CharSequence is an interface that String implements). I can make these changes, I was just opening the issue somewhere so I wouldn't forget. |
The extensions are full of calljava instances if you need test code
…On Thu, Dec 15, 2016 at 11:35 PM, Taylor C. Richberger < ***@***.***> wrote:
prrimarg doesn't work, because it still manages it as a String, and
doesn't find the method that takes a CharSequence, as String.contains
requires (CharSequence is an interface that String implements). I can make
these changes, I was just opening the issue somewhere so I wouldn't forget.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEZAhFAQQhpxoGGs1EK15kylqxqH1hkZks5rIjEmgaJpZM4LOuBP>
.
--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021
NON-DISCLOSURE NOTICE: This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information. If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited. If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
|
Anyway, please fix calljava if you are inspired to do so and can do so without breaking existing code. Try to avoid a performance hit. I want to use calljava more and more to create extensions rather than expand the base system. |
It shouldn't break existing code. It should not cause a performance hit, because the classes will be checked as-is first before checking interfaces and superclasses, so if there is an exact match, it should operate in constant time as before. With memoization, the individual call worst-case is polynomial time, but the amortized time would reduce to constant, but this only really helps for long-running programs and in loops. Either way, existing working uses should continue to work as expected with no performance impact, and cases that returned a NoSuchMethodException will be fixed with a one-time performance impact per session. |
Marvellous, I'm delighted you are repairing these structural flaws in the
operation of our domain-specific language.
…On Fri, Dec 16, 2016 at 9:43 AM, Taylor C. Richberger < ***@***.***> wrote:
It shouldn't break existing code. It should not cause a performance hit,
because the classes will be checked as-is first before checking interfaces
and superclasses, so if there is an exact match, it should operate in
constant time as before. With memoization, the individual call worst-case
is exponential time, but the amortized time would reduce to constant, but
this only really helps for long-running programs and in loops.
Either way, existing working uses should continue to work as expected with
no performance impact, and cases that returned a NoSuchMethodException will
be fixed with a one-time performance impact per session.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#6 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AEZAhKWm1BTK0BgmMt8tAfb8rT9-LOSwks5rIr-kgaJpZM4LOuBP>
.
--
Absolute Performance, Inc.
12303 Airport Way, Suite 100
Broomfield, CO 80021
NON-DISCLOSURE NOTICE: This communication including any and all
attachments is for the intended recipient(s) only and may contain
confidential and privileged information. If you are not the intended
recipient of this communication, any disclosure, copying further
distribution or use of this communication is prohibited. If you received
this communication in error, please contact the sender and delete/destroy
all copies of this communication immediately.
|
This should work. I've noticed some similar issues using calljava to create and work with HashMaps.
The text was updated successfully, but these errors were encountered: