

LLJVM - njn
http://da.vidr.cc/projects/lljvm/

======
blasdel
This is a massive improvement over the old way of doing this -- use a $LANG
compiler targeting 32-bit MIPS and then emulate that processor in Java (not
_too_ hard as the memory models match up).

------
megaduck
One of the big challenges facing the JRuby community today is the prevalence
of gems with C extensions. For gems where the C source is available, this
might be a viable route to compatibility.

For anyone trying to crack that problem, this is definitely worth deeper
investigation.

~~~
nex3
This would require a compatibility layer for the MRI C API, which would be
difficult but probably doable.

It would only solve part of the problem, though: many of the C extensions
exist as bindings to existing C libraries. This wouldn't solve that unless the
entire library were compiled this way.

~~~
regularfry
There's libffi for the latter problem, though. It's still work, obviously, but
probably less.

------
papercrane
There's also NestedVM, <http://nestedvm.ibex.org/>, which works my using gcc
to cross compile to MIPS and then convert the MIPS machine code into a Java
class file.

------
kingkilr
Someone actually just posted the llvm development mailing list with a backend
they wrote for LLVM so that it can generate JVM bytecode (in the same way in
generates x86, PPC, etc.) and it uses this lib, cool stuff.

~~~
pieter
That's the same guy.

------
jacoblyles
Is this an alternative to JNI?

~~~
michaelneale
Not really. I guess you could, in cases where you had the C source code, and
were happy to compile everything into bytecode (including all that C codes
dependencies with it). You wouldn't be running native code any more unlike
JNI. JNA would be considered an alternative.

------
bh23ha
C on the JVM? Dear me!

