harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Blackburn <Steve.Blackb...@anu.edu.au>
Subject Re: [arch] VM Interface
Date Wed, 08 Jun 2005 03:25:17 GMT
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.



View raw message