Avoiding reflection

[nickmain]

I've been looking at the subclassing issue #25 and diving into what it would require if the bytecode generation approach was taken.

Both JVM and DEX code generation seem reasonably straightforward, but would still be large efforts in terms of time and code size. I am more familiar with JVM generation but there seem to be several Java and Python packages for DEX generation. A large part of the effort would be in creating the minimal generator required for the subclassing use case - boxing up the arguments into an array, taking care of try-catch concerns, and calling into InvocationHandler.

Some of that complexity could be avoided if the generated proxy methods were native. This would reduce or eliminate the amount of bytecode that would need to be generated and would bypass the need for reflection or argument boxing.

The native method could be "generic" in the sense that it would use va_list etc. to handle any number of arguments on the fly.

The wrinkles are:

• va_list wouldn't work on Windows, which uses the stdcall calling convention for JNI.

• JNI doesn't pass the context of the called method so extra metadata would be needed in the native method. This could be passed from the Java layer by a minimal wrapper method that adds an extra metadata index param before calling the native method. Or it could be implemented in the native code by generating a pool of native methods that add the extra metadata index - this would limit the number of Java methods that could be implemented/overridden.

Food for thought.

[freakboy3742]

I'm not sure I'm 100% following the approach you're describing here - or, at least, I can see a couple of possible interpretations:

1. We replace Rubicon-Java's current reflection-based approach with a native code generator. Any class that needs to be invoked at runtime is dynamically generated. There's no need for reflection APIs because there's 1-1 correspondence between the classes we need and the classes we're implemented. We'd effectively be generating a Python module that does the role currently performed by JNI.
   1a. We do this with generated Java source code, added to the Gradle project
   1b. We generate Java byte code directly, rather than Java code
   1c. We generate DEX code directly, rather than Java code
2. We do (1), but only for code that is related to subclassing (with a/b/c variants possible)
3. We generate a single native method on the Java side that implements the lookup

There might be other interpretations depending on exactly where you're thinking of drawing the line between Python and Java.

As I understand it, (1) would require a pretty radical rebuild of Rubicon. I like the idea of minimising reflection, as the JNI calls (especially the initial startup an handle caching parts) are the slowest part of the process; however, it would be a big project. I'm also not sure how (1) would work in the case of final classes; I guess we'd end up with a Facade (in the gang-of-four design pattern sense) that calls directly into Java classes.

(2a) is closest to what I had in mind as the approach I'd look at if I were to take a swing at a fix for #25. There'd still be reflection (in the sense that Rubicon's existing interface would continue to be used), but there wouldn't be runtime code generation.

(2b) and (2c) really only vary from (2a) in terms what is being generated. They'd both be "neater" in the sense that there's would be less source code in a project marked "DO NOT EDIT"; but it would also be more fragile and harder to debug when things go wrong - especially in the case of (2c).

(3) seems very close to what we have now, except that you seem to be suggesting more of the lookup index would be on the Java side, removing the need for reflection APIs to do method lookup. I'm not entirely sure how (3) varies from the approach we have now - or, at least, I'm not sure I see how the Java-side metadata index would work.

Did you have any of these specific interpretations in mind? Are you more at the "thought experiment" phase, kicking around ideas about potential options? Or have I completely missed what you're describing?

[mhsmith]

Now that Chaquopy is open-source, I'm looking into the possibility of using it in BeeWare. Like Rubicon, Chaquopy supports implementing Java interfaces at runtime using InvocationHandler. However, it also supports subclassing any Java class in Python, by generating Java source code at build time.

For example, beeware/toga#1020 would look like this:

from android.webkit import WebView, WebViewClient
from java import static_proxy, constructor, method, jvoid
from java.lang import String

class TogaWebViewClient(static_proxy(WebViewClient)):

    @constructor([])
    def __init__(self, on_load=None):
        super().__init__()
        self._on_load = on_load

    @Override(jvoid, [WebView, String])
    def onPageFinished(self, view, url):
        if self._on_load:
            self._on_load()

In the build.gradle file, if you list a Python module in a staticProxy line, then Chaquopy will automatically generate and build Java source code for all the static_proxy classes in that module. Then at runtime, whenever the Python class is instantiated, Chaquopy will automatically create a corresponding Java object, and use it whenever the Python object is passed to a Java API. The generated code in the methods will forward all Java calls back to the Python implementation.

Potentially Toga could declare all of its Java subclasses in one module, and the Gradle project template would contain a staticProxy line for that module. Whenever the Toga version changes, Chaquopy would automatically regenerate the Java classes, without any need to edit the Gradle file.

[mhsmith]

Toga could declare all of its Java subclasses in one module, and the Gradle project template would contain a staticProxy line for that module.

We also discussed declaring this in pyproject.toml, in which case it could be applied using any of the methods discussed at beeware/briefcase-android-gradle-template#52 (comment). Or it could even be declared in package metadata like entry_points, though that would require a change to Chaquopy itself.

[freakboy3742]

FWIW, package metadata would be my preferred approach, because it means the packager can capture integration requirements as part of the packaging process, and any tool could act on that metadata.

[nickmain]

This was just a thought based on the premise that if you were to take the route of generating bytecode in order to implement proxies then you could go a little bit further and generate code that doesn't use reflection or primitive boxing. It is an involved project, and only worth doing if reflection can be measured to be a bottleneck. I just brought it up here in case it crops up in future.

It sounds like the Java-source generation approach is the way to go now, with Chaquopy being part of the fold.

It could still be possible to source-generate Java proxy classes with direct native methods and associated JNI C code to be compiled into Rubicon before release. This would be for some set of Android and JDK abstract classes that are performance critical and likely to be used in an app.

Again, just a thought for the future.