harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew French <matt...@camary.co.za>
Subject Re: [arch] Modules and interfaces (was: How much of java.* ...)
Date Tue, 07 Jun 2005 21:09:05 GMT
On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote:
> It brings to mind some of the portability/modularity issues we've been 
> wrestling with (at great length) with MMTk and the interdependence 
> between the memory manager and the VM.  Our solution is not earth 
> shattering, but it evolved out of a very long struggle with issues like 
> the one Geir is alluding to above.

I will most probably be told why not very shortly, but is it not
possible to use the class loader to solve this problem?

My first solution would be too implement VM specific functions in their
own library, but using existing the namespaces, not creating new ones.
So you have your own java.lang.Thread, for example, that works with your
VM. The class loader then uses the VM specific functionality to override
the generic functionality.

This acts like a mask, hiding functionality that the VM authors decide
is specific to the VM, but leaving all the other generic functionality
exposed. This has the advantage that it reduces the amount of re-work
while allowing enormous flexibility. The only requirement is that the
class libraries call the public API instead of internal implementation
classes - i.e. make no assumptions about the implementation of any other
class (as much as possible, anyway).

This also makes it possible to inject, for example, a VM specific String
class, or specially tuned Socket classes. But at the same time for other
VM's to use the generic String class. 

The principal can be extended so that application specific classes can
override the generic classes. Although this is wrong for so many other
reasons. :(

>>From a brief look at the classpath docs, it looks like classpath uses a
similar approach - from what I can tell the one I am suggesting is just
more generic.

Or is the issue deeper than this?

- Matthew

View raw message