＞> 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:matthew@camary.co.za]
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