Calljava doesn't appear to work with arguments when class accepts an interface

[Taywee]

> put -to @string ${ this is a test }$
> put -to @test test
> calljava -obj @string -method contains -arg @test
Ublu:1:UbluInterpreter.Thread[main,5,main]:SEVERE:ublu.command.CmdCallJava.cmdCallJava():Error looking up method in calljava/0 [-to @datasink] [-new ~@{classname}] [--,-obj ~@object] [-method ~@{methodname}] [-arg ~@argobj [-arg ..]] [-primarg ~@argobj [-primarg ..]] : call Java method
java.lang.String.contains(java.lang.String)
java.lang.NoSuchMethodException: java.lang.String.contains(java.lang.String)
	at java.lang.Class.getDeclaredMethod(Class.java:2130)
	at ublu.util.JavaCallHelper.<init>(JavaCallHelper.java:70)
	at ublu.command.CmdCallJava.cmdCallJava(CmdCallJava.java:118)
	at ublu.command.CmdCallJava.cmd(CmdCallJava.java:173)
	at ublu.util.Interpreter.loop(Interpreter.java:1140)
	at ublu.util.Interpreter.interpret(Interpreter.java:1317)
	at ublu.Ublu.runMainInterpreter(Ublu.java:194)
	at ublu.Ublu.niam(Ublu.java:249)
	at ublu.Ublu.main(Ublu.java:229)
> 

This should work. I've noticed some similar issues using calljava to create and work with HashMaps.

[Taywee]

https://stackoverflow.com/questions/19313259/java-get-method-with-interface-parameter-with-its-implementation

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.

[Taywee]

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.

[jwoehr]

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.

[Taywee]

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.

[jwoehr]

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.

[jwoehr]

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.

[Taywee]

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.

[jwoehr]

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.