I am realizing that a SummerCoat interpreter that can call into already native code would require the creation of essentially proxy abstract classes and proxy interfaces for when an interpreted class extends a native class. Which in this case would be needed for every class because they extend Object. It can be purely interpreted but that would be much slower and there would be a huge loss and waste of space and memory for code that was already compiled into a native code. Using reflection and creating classes at runtime is not an issue at all for Java SE, just RatufaCoat will need that functionality of sorts and otherwise for it to function properly. Of course the handling of these would be different, but essentially it would be like proxy interfaces with an invocation handler and such. This way I could minimize what is actually needed in the proxy classes. But if this works out, it basically means that RatufaCoat will be pretty fast and not much of it will be interpreted. It will kinda be like the Palm OS emulator in OS 5 but a bit more complicated I suppose as it can just do native code, whereas I have to basically build and inject a class at run-time just to handle something. Of course for any instance of the interpreter in SummerCoat, it will have just the current class path along with the instance of the interpreter always existing as such.