Running Java VM inside of Go as callable library?

[Glen Newton]

There are times when some of us would like to call some Java code from Go.

Avian is a lightweight JVM implemented in C++ as a library. BSD license.
http://oss.readytalk.com/avian/

Could someone much smarter than I wrap the Avian C++ library in C and then make this callable from Go?
(I am sure this JVM would not be appropriate for significant Java computation, but good enough for occasional minor usage?)

I am not associated with the Avian project. In fact, I just found it 20 minutes ago.

Will buy you a beer on delivery.  :-)

[Andrew Austin]

Hi Glen,

Not 100% sure what you're trying to accomplish, but I stumbled on this a jvm written in Go a few days ago:

https://github.com/zxh0/jvm.go

Might be worth looking into.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Konstantin Khomoutov]

On Thu, 12 Mar 2015 20:13:03 -0700 (PDT)
Glen Newton <glen....@gmail.com> wrote:

> There are times when some of us would like to call some Java code
> from Go.
>
> Avian is a lightweight JVM implemented in C++ as a library. BSD
> license. http://oss.readytalk.com/avian/
>
> Could someone much smarter than I wrap the Avian C++ library in C and
> then make this callable from Go?
> (I am sure this JVM would not be appropriate for significant Java
> computation, but good enough for occasional minor usage?)

I'd then consider taking a more usual approach:

1) Write a "hoster" application in Java.
It has to be able to read "something" from its standard input stream
and produce "something else" on its standard output stream
(and/or maybe on its standard error stream -- in case of errors).

2) Your application would start a real JVM running that
"hoster" application and then submit it "jobs" via its stdin
and gather the results of their execution using its stdout/stderr.
See [1] for an example.

The exact details of how your Go and "hoster" programs should
communicate are for you to decide.
If you "know" all the Java code you'll ever need to execute, then it's
just a trivial case of a server/client architecture: just make all that
code available to the hoster program and devise a protocol for the
client to make a call to the server-side routine it wants and to
receive the results (a classic RPC or REST paradigm could be used).
If you'd like to be able to execute arbitrary code, then your hoster
program should be able to receive Java source code, compile it
(JavaCompiler class?), load the result and execute [2, 3]. The rest is
mostly the same as in the former class.

The downside is increased complexity. The upside is full power of JVM.

1. https://groups.google.com/d/topic/golang-nuts/meA6-TWd_ew/discussion
2. http://stackoverflow.com/questions/465099/best-way-to-build-a-plugin-system-with-java
3. Google for java+plugin+framework

[Glen Newton]

Hi Andrew,

>Not 100% sure what you're trying to accomplish...
You are right: very sloppy of me.

1 - I want to call methods on Java classes from Go. So a C library (which happens to wrap a C++ library implementing a JVM like Avian ) is acceptable
2 - I may want to bundle any jars with the Go executable (perhaps using something like https://github.com/jteeuwen/go-bindata ) and having CLASSPATH working with these internal static jars;Or just have the jars in an 'known' filesystem location to the Go binary

The post from Konstantin is one solution, but we lose the simple deployment solution a single Go binary (perhaps +jars) offers.
Again, the use case is not for significant Java computation (where a full proper JMV would be needed as Konstantin points out).

Thanks,
Glen

[Stephen Gutekanst]

This just showed up on HN and I thought it might interest you. I haven't read the whole thread -- so apologies if it doesn't.

https://github.com/zxh0/jvm.go

Cheers,

Stephen

[andrewc...@gmail.com]

That was already the second post of this thread, before hacker news...