Someone asked me "why two projects?" and I realized
the reasoning behing the fork hasn't been explained all too
well. It might be that I have doubts about the fork myself.
A marginally relevant reason has to do with usability:
controlling the footprint of the VM with C macros may not
be something that the majority of users will want to bother
with. And the linker would have to let certain unsupported opcodes pass, only to be rejected at runtime. The potential
differences between leJOS and TinyVM could be so
involved, that it would be impractical to have only one
Another reason is that I was able to keep maintaining and
releasing a relatively stable TinyVM while working on leJOS code that would take a relatively long time to finish (e.g. marking all references in the stack).
But I guess the main reason is that leJOS allows us to
experiment without breaking TinyVM. It gives us a chance to
try out a different design for the API, a different usability
model, and so on. TinyVM gives an idea of how small a reasonable Java runtime can be, while leJOS tells us about the amount of features that can be put in an RCX Java runtime before space runs out.
Overall, it seems leJOS was a good thing to try out. It's
starting to beat TinyVM in number of daily downloads (probably because of the special Windows version), and
more users are starting to send comments about it.
Log in to post a comment.