lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

I do not do Android development myself. As the Android platform supports JNI and as JNLua complies with the JNI specification, I see no obvious reason why JNLua should not work on Android. One would have to compile the JNLua native library for the target device, of course.

-----Original Message-----
From: [] On Behalf Of sagasw
Sent: Donnerstag, 19. Januar 2012 13:44
To: Lua mailing list
Subject: Re: [ANN] JNLua 1.0.0 (and 0.9.2)

Is it possible used in android?
C++, Lua, living in Dalian

On Fri, Jan 13, 2012 at 5:12 AM, Andre Naef <> wrote:
JNLua 1.0.1 now includes a Java VM module supporting the bootstrapping of
JNLua from the Lua side by creating a Java virtual machine:


> javavm = require("javavm")
> return javavm.create("-Djava.class.path=jnlua-1.0.1.jar")
Java VM (000000006DEA02C0)
> System = java.require("java.lang.System")
> System.out:println("Hello, world!")
Hello, world!
> return javavm.destroy()

(And yes, attaching a Java VM to Lua definitely goes into the "things which
are larger than Lua" category ;))

-----Original Message-----
From: [] On
Behalf Of Andre Naef
Sent: Freitag, 6. Januar 2012 03:33
To: 'Lua mailing list'
Subject: RE: [ANN] JNLua 1.0.0 (and 0.9.2)

Technically, a "luaopen_java" is doable using the Invocation API that is
part of JNI:

For JNLua, it should be quite easy to support this usage scenario. It is
difficult to judge how many real world use cases for this scenario there
are. But supporting the bootstrap from both ends certainly widens the usage
spectrum. So, thanks for the suggestion. I am adding this to the JNLua

-----Original Message-----
From: [] On
Behalf Of David Manura
Sent: Freitag, 6. Januar 2012 02:41
To: Lua mailing list
Subject: Re: [ANN] JNLua 1.0.0 (and 0.9.2)

On Thu, Jan 5, 2012 at 4:27 PM, Andre Naef <> 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). [...]
>> "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.