Hi Rodrigo,
I agree entirely that this is an important issue, and a lot of people are working hard right now to see if this can happen. Donating an entire JVM to apache is not a trivial issue, so we will need to be patient.I believe the focus should be on deciding if Harmony will star from other JVM or not.
However, it is not the either/or situtation you paint above. I think it may make most sense to work on a preexisting donated VM or VMs while *concurrently* developing a new VM core or cores from scratch. This approach has a number of advantages, including maximizing our leverage from existing work, minimizing startup time and accelerating the process of building an existing VM. It also allows us to more fruitfully explore some of the implementation choices (which language to use, ...).
[previously you wrote...]
Making Harmony modular enouth to be kind of a JVM framework cannot beThe donated VM or VMs (if they araise) may already be at this point. As I have already said, this is a process already underway in the Jikes RVM project. I can't speak for the other projects, but they may also be at such a stage or, better, have moved beyond that stage.
done before having a working JVM. There is a lot of literature about
how frameworks should emerge from continuous design and development.
This must not be the focus until required, so no JIT plugable layerI would like to leverage prexisting VMs to push the process of modularization.
until someone tries to write another JIT for Harmony (emphasis on
another).
Creating such is a big chalenge, to guess what spots need to flexibleRight. This is why it is essential that harmony learn from kaffe, gcj, jikesrvm, sable, ovm, joeq, etc etc. The project does not exist in a vacum.
and the others that don't. Guess what, people often make bad guesses
about these and in the end we have a very complex design with a lot of
shortcomings.
--Steve
