harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Edworthy" <pe...@edworthy.org>
Subject Re: [arch] VM/Classlibrary interface
Date Fri, 10 Jun 2005 13:21:16 GMT

I also agree,

but I'm trying to find the time to read through all the ClassPath VM 
object interfaces and the stub objects to see if I can workout what is
happening currently, especially what the package private methods are
doing. I'm hoping this will make it clear why implementing the methods in
separately packaged classes that provide a JVM interface implementation
would not be possible, or preferable.

I don't like changes in Java.Lang, although I know they should be
invisible it just doesn't feel like a very clean interface design,
overlaying extra functionality without extending the class or interface.
This could, of cause, all be prejudice and hence having to now go off and
judge what benefits it gives over a more clear separation.

I should have a more clear idea after the weekend, or be so confused I'll
stop suggesting change ;-}>

> Apparently, only you and I agree.  ;-)
> Dalibor Topic wrote:
>> Richard S. Hall wrote:
>>> To me, this is the point. I would like to see all of the libraries
>>> built on to of the JVM to be packaged in a more module-like fashion,
>>> so that their exports and imports are explicit. There would be many
>>> benefits if this were done, rather than relying on the current
>>> approach of assuming that everything is accessible.
>> +1
>>> So, from my point of view, it is definitely going in the right
>>> direction to make libraries understand which class loader they should
>>> use to get to their own "module's" classes, as opposed to just
>>> assuming they can get them from any application class loader.
>> +1 to that, too.


View raw message