[Nestedvm] Planing a large C to Java migration project

Yaffe, Lior Lior.Yaffe at softwareag.com
Thu Sep 1 07:53:37 EDT 2011


Thanks Brian,

Regarding JNI, we do have pretty complex JNI code and some callbacks.
We also have a single C++ source file which serves as a bridge between
the Java and C code.
My thinking is that we can generate Java source code using NestedVM and
then re-write only the JNI interface based on the method signatures and
data types produced by NestedVM. Do you have any experience with this ?

Regarding licensing, assuming we convert our C code to Java using
NestedVM are we allowed to freely re-distribute the NestedVM runtime.jar
together with our product to our customers ? 
Any restrictions related to this ?

	Lior

-----Original Message-----
From: Brian Alliet [mailto:brian at brianweb.net] 
Sent: Wednesday, August 31, 2011 6:29 PM
To: Yaffe, Lior
Cc: nestedvm at lists.hcoop.net
Subject: Re: [Nestedvm] Planing a large C to Java migration project

On Wed, Aug 31, 2011 at 01:08:26PM +0200, Yaffe, Lior wrote:
> We never ported this source code to MIPS though.

Hopefully this shouldn't cause any issues. As long as your code doesn't
make any assumptions about endianness, alignment, etc you shouldn't
have any trouble. 

NestedVM uses newlib, a small libc designed for embedded systems.
Newlib doesn't have all the features of glibc (but it does fully
support ANSI C) and might cause you some trouble though.

> Our existing code is compiled into DLL/SO file and is loaded in
runtime
> using JNI. 

NestedVM's bridge to Java is totally different than JNI (although
writing a JNI-like api on top of the current interface should be
possible). How intertwined is your native and java code? If they mostly
communicate at arms length you shouldn't have too much trouble, but if
you have dozens of functions, complex data types, callbacks to Java,
etc building the bridge between the two worlds will take some work.

> Given the current status of the NestedVM product would you recommend
> using NestedVM for this purpose ?

Yes, this sort of thing is exactly what NestedVM was designed for.

The only reason I wouldn't recommend NestedVM would be if your native
code was performance critical. Your native code will likely only run
10%-20% as fast under NestedVM.

> Would be able to assist us in case we run into problems or need
product
> modifications ?

Certainly.

-Brian



More information about the Nestedvm mailing list