assets/developer-notes/stephanie-gawroriski/2022/08/07.mkd

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