Re: [ANN] JNLua 1.0.0 (and 0.9.2)

[David Manura <dm.lua@...>]

On Thu, Jan 5, 2012 at 4:27 PM, Andre Naef <andre@naef.com> wrote:
> JNLua (Java Native Lua) integrates the Lua Scripting Language into Java. The
> integration is based on the original implementation of Lua and uses the Java
> Native API (JNI). [...] http://jnlua.googlecode.com/
>> "Two-way integration."

I often find that when a binding between language X and Lua is said to
be "two-way", this means that X can load an instance of Lua as a
shared library and then this Lua instance can call back into the X
instance hosting it.  But it's not necessarily the case that Lua can
load an instance of X as a shared library (and then this X instance
can call back into the Lua instance hosting it).  The inability of Lua
to load X is not always clear from the documentation but is typically
confirmed by the absence of a luaopen_X function on grepping the
binding sources (as is the case for the three Lua-Java bindings on
[1]).  Has anyone attempted this?  Are there difficulties in adapting
something like JNLua to do this?  Is this doing this even worthwhile
compared to, say, a more decoupled approach of starting up separate
Lua and Java executables and communicating between them via some IPC
mechanism?  The typical scenario is you have some embedded version of
Lua (i.e. the primary application is in Lua) that could benefit from a
large class library such as provided by Java.

[1] http://lua-users.org/wiki/BindingCodeToLua