＞> 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? Indeed if you add some "AOP-like" code at the right place (check the resource names, do something specific if it is VM-specific) it might just do (at least conceptually). After all it is just possible to instrument classes and add whatever code is required at runtime, so I guess the java.lang.* classes do not really need to have everything available in the jar that is exposed to users, except what is in the standards (the signatures, the code itself is another question, right?). Sound like mil. security principle: give people just what they need to do their jobs, not more. RB -----Original Message----- From: Matthew French [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 6:09 AM To: harmony-dev@incubator.apache.org Subject: Re: [arch] Modules and interfaces (was: How much of java.* ...) 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
