Ahh, ok, I was trying trying to be lazy and avoid having to parse stdout! It sure would be nice if compilers handled their output as XML and then formatted it to text by default!

Yeah, it's a tiny JVM. My main aims are to ensure that it's "crash proof" and that it checks that any pointers used internally only point to addresses inside the JVM heap, obviously we have our own IP in our product that we don't want people accessing by buffer overflows etc.

This obviously has an impact on ultimate speed because of bounds checking, but because it's interpreted at no point is the user app running anywhere other than the sandbox. Also the Java compiler does all the smarts, we don't validate the instructions or the locals (the compiler handles that for us), so while a user could hand assemble a Java app which messed about and fiddled with object references, our bounds checking would cause the JVM to exit with no ill effects

Fortunately the processor has oodles of processing power and the user applications are not massively complex. Java is a great fit and will allow us to provide our customers with a better set of tools to develop their apps on. I will compile the class files into a more compact version minus the fluff in the Java class file that we don't have any interest in.

When I first mused the VM idea when we were planning the project I did originally think about Java, but baulked at the idea of writing a JVM, turns out though that it's not been quite as much effort as I expected, kind of makes me wish I'd gone down this route a couple of years back!

I really appreciate you taking the time to respond on this stuff!