Varargs Matching, Global/Locals for Script Execution, Verbose Exceptions, Wrappers for List and Dictionary

[cpwright]

Illumon has made several changes to JPy so that we can handle a wider variety of Java code and integrate the embedded interpreter in a JVM more easily.

• Varargs You may pass in either an array (as in the past) or individual Python arguments, the match for a varargs method call is the minimum match for each of the arguments. Zero length arrays (i.e. no arguments) are also permitted with a match value of 10.

  Additionally, a jpy.type_translations dictionary is available with allows you to easily wrap or modify all created objects of a particular java type.

• jpy.type_translations A python Map that contains callbacks which are called when instantiating a Python object from a Java object.

• jpy.VerboseExceptions You can get the entire Java stack trace back. Additionally, certain Python exceptions are translated to the corresponding Java type.

• Globals and locals are converted when executing code with PyLib. This enables you to keep values from one run to the next, and interrogate the dictionaries from Java.

• PyObject has wrappers for dictionary, list, and interrogation functions to tell you whether or not you can convert the object.

[forman]

@cpwright thanks for that impressive work!

Could you please create an issue first that explains what's missing in current jpy so I can better understand the solution(s) provided here. I'll meanwhile start reviewing.

Note that reviewing large PRs like this is quite a lot of work, I'd prefer receiving multiple smaller PRs that are each related to a feature request in the issue tracker so myself and others can better follow up jpy's evolution.

B.t.w. who/what is Illumon?

[cpwright]

Norman,

I'll create issues and some intermediate Pull Requests for the various features contained within our branch.

Illumon is a startup that focusses on Big Data for the capital markets. We have a Java project; and needed to extend JPy to handle our code base. http://www.illumon.com/

[gchamon]

hello there! how is the state of this PR? And @cpwright, have you tested the plugin integration to assess the data throughput from a Java application to the embedded Python interpreter?

[cpwright]

Norman,

I understand that it is a lot of work for you to review the entire PR; but have been totally swamped so have not been able to divide it up. There are a few things that I did which I can explain: (1) our Java API makes heavy use of varargs, so we needed to support those well, (2) there were a few other cases of argument matching and assignability we fixed, (3) we needed to handle script sessions with globals that we could preserve from run to run, (4) exception handling would truncate the java exceptions; which made it hard to debug our application, (5) we added more introspection to PyObject so we could understand it from java and wrap dictionary/lists more effectively.

We didn't do any Java to embedded Python interpreter benchmarking; because in our application the heavy data lifting is still done within Java. We allow our users to setup their data flows within Groovy or Python; but then after initialization the data movement itself stays within the JVM.

Charles

On Thu, May 3, 2018 at 10:17 AM, Gabriel Chamon Araujo < notifications@github.com> wrote:

hello there! how is the state of this PR? And @cpwright https://github.com/cpwright, have you tested the plugin integration to assess the data throughput from a Java application to the embedded Python interpreter?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/bcdev/jpy/pull/111#issuecomment-386311088, or mute the thread https://github.com/notifications/unsubscribe-auth/AcVJIXqIL1RvRtBoKY31w5gEwC_49HU_ks5tuxGEgaJpZM4QEo2m .

[gchamon]

Thanks for the response. My application would send time signals for processing within scilab, so a large data throughput is necessary for me, since there will be data flowing from both sides. That's why I asked.

[illumon-public]

@forman I've updated the CHANGES.md file. You will also see 3 additional commits. One fixes variable initialization order; which allows this to compile on older versions of MSVC. The other two commits you can see from the unit tests are for (1) properly handling covariant return types which can introduce bridge methods that should not be considered during the matching process; and (2) handling passing Python values through arguments of base classes like Comparable or Number.

[forman]

@illumon-public thanks! But cannot merge until AppVeyor build is green.