Re: [ANN] Rembulan, an implementation of Lua 5.3 for the JVM

[Miroslav Janíček <mira.janicek@...>]

> On 2 Oct 2016, at 12:08, Paul Merrell <marbux@gmail.com> wrote:
> 
> On Sun, Oct 2, 2016 at 2:44 AM, steve donovan <steve.j.donovan@gmail.com> wrote:
>> On Sun, Oct 2, 2016 at 11:15 AM, Marc Balmer <marc@msys.ch> wrote:
>>> But saw that I mentioned JNI? JNI is the Java Native Interface, used
>>> to call C from Java and vice versa.
>> 
>> So what would be the use case? Loading C Lua modules? In many cases it
>> would be better to use existing Java libraries.
> 
> An ability to load C Lua modules would be very nice for the use case
> I'm thinking about. NoteCase Pro (embeds Lua 5.3) has an Android
> version rebuilt from the ground up in Java (not nearly as mature as
> the desktop/laptop versions). The Android and desktop/laptop versions
> share a common file format. We have scripting on the roadmap for the
> Android version and if we could write scripts compatible with both
> versions things would be peachy keen. But on the desktop we also embed
> lfs (lua file system) and two other modules that are written in C.[1]
> [2]. Persuading Rambulan to play nice with them might open a lot of
> interop possibilities for us.
> 
> [1] https://github.com/starwing/luautf8
> [2] http://www.notecasepro.com/download/src/libhttpd.zip

Right now (having no way of loading C libraries into Rembulan), the only approach I can think of would be porting lfs and the other two modules to Java (Rembulan). lfs seems to be popular enough to warrant such a port anyway; for the other modules, however, I’m not sure if the effort is worth it (though the original libhttpd doesn’t seem to be all that complex).

In any case, luautf8 might actually prove to be quite challenging, because of how I treat strings in Rembulan — there is an equivalence between Lua strings and java.lang.String. While Lua strings are (ought to be) raw 8-bit sequences, in Java they are sequences of its primitive ‘char’ type (a 16-bit Unicode character).

That’s also the reason why there is no implementation of the standard utf8 module in Rembulan yet — I’m not sure how to resolve this mismatch. It might turn out to be one of the fundamental differences between PUC-Lua and Rembulan, but I feel that's not good enough.

One more thing, though: I have zero experience with Android, and don’t even have an Android device available, so I can’t try this out: currently Rembulan requires JDK 7 (IIRC Android is stuck with JDK 6) and I’ve been thinking about moving to JDK 8, and the loader needs to be able to load new Java classes on-the-fly (not sure if it’s possible in Android — no code signing etc?). The former could be addressed, but the latter could not.

  M.