A Suggestion for Android: use a very simple LISP in Java to avoid a load of issues.

[0-8-15]

There are various spots in the code, which are fragile, tedious and error prone.

Just two examples:

• The other day I submitted a patch which handles Android permissions depending on the ANDROIDAPI version. However the code is fragile and requires to arrange the source code to expect to be in the middle of a block comment --- or not. However it can't be done with plain Java, because the methods to be called are either not avail (in older API versions) or MUST be called for never versions.

• Too many simple JNI calls, which require (at least in theory for safety) even more error handling (for example "catch" exceptions) than done anywhere.

---

Looking closer most of the relevant code pieces I found so far are rarely called at all. Runtime performance is therefore no issue in many cases. Development time however is.

I tend to suggest to rather use a very minimal LISP which utilizes the java.lang.reflect API to call into Java instead of coding raw Java with substool replacements on top.

This would have to advantage that we can multiplex most, if not all, JNI calls over a single JNI interface (which, than, could easily be scrutinized to really handle all error conditions). Saves most ANDROID_c_additions and corresponding ANDROID_java_activitiyadditions and saves the fragile hack to make the compile time depend on the ANDROIDAPI version.

With a little imagination I'd also see how this could save the special case of hybridapp* needing to overwrite the layout/main.xml file, simplifying the build-binaryscript.

To test the idea I started from jscheme. That is, the jscheme 1.4 version from Peter Norvig, NOT the one at sourceforge, which, IMHO grew beyond bounds in features, size and bloat.

I had to add a few things to the 1.4 version however: a) the error handling was so, well, rudimentary, that I found it impractical b) calling java constructor taking arguments is just too important to ignore. Both issues I fixed today (for me that is).

Now I wonder: As I wrote: I tend to suggest to include either this or something similar small (the jscheme weights around 55Kbyte as jar file) into lambdanative.

But I don't see (so far) how I could do this as a module. (Modules can't have android_jars directories, only applications can, names of jar files could easily clash, which would make it hard to add straight forward support; there might be more.)

How do you guys feel about the idea?

[mgorges]

Sorry, I know too little about the Java reflection API and jScheme to properly comment on this - @clpetersen might be able to? I also think there are some c-addition pieces that are required, first and foremost I am thinking of the serial module, where performance matters.

[0-8-15]

On Oct 3 2019, Matthias Görges wrote:

Sorry, I know too little about the Java reflection API and jScheme to properly comment on this - @clpetersen might be able to? I also think there are some c-addition pieces that are required, first and foremost I am thinking of the serial module, where performance matters.

Fair enough.

I do already have this idea working. So I'll prepare the code for discussion. It's going to take some time, since there are other keeping me busy right now.

NB: I don't think we should go through the code and forcefully attempt to change everything to a more high level interface. The serial example you gave might actually need the performance gain.

(Though in this case I wonder: does this actually have to go through Java at all?)

[mgorges]

In case of the serial, unfortunately yes, as the usb-serial-for-android library is written in Java.