Ahmed Saad wrote:
Jikes RVM, Kaffe, SableVM, etc ----[implement Classpath-required
classes]----> can use Classpath
Harmony VM ----[implement Classpath-required classes]----> can use Classpath
Harmony VM ----[implement Sun rt.jar-required classes(??)] ---> can
use Sun rt.jar
Harmony VM ----[implement X-required classes]----> can use X
maybe Harmony would:
1. determine which classes are required by each classlibrary
implementation: GNU, Sun (is this legal), are there any others? btw,
how will we know about Sun's? is src.zip enough ? (i doubt there are
any published docs about this)
2. work out a draft spec about what it takes for a common, well there
was only GUN and Sun, classlibrary-VM interface based on what we found
in Classpath and rt.jar
2. implement adpaters for Classpath and rt.jar (what i mean is that
Harmony spec will introduce a layer to abstract current
classlibrary-vm interfaces)
This is exactly the approach we've tried to take with our VM-modularity
work, and that's what I was pointing to in my previous email. We've
pushed this n-m modularity issue fairly hard and we've nailed down the
specifics of just this sort of thing. I see it as a practical
solution. It need not have any performance hit, it provides a good
abstraction layer from both points of view. It has even allowed us to
effectively bridge C & Java implementations.
Forgive me if I'm missing something here, but it just requires that
people quit thinking in terms of simple APIs, which is where the problem
begins, and what seems to be the subtext of this entire protracted thread.
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200506.mbox/[EMAIL
PROTECTED]
--Steve
