harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [general] revisiting structure of SVN
Date Thu, 08 Jun 2006 14:23:51 GMT
Vladimir Gorr wrote:
> On 6/7/06, Ivan Volosyuk <ivan.volosyuk@gmail.com> wrote:
>>
>> 2006/6/6, Oliver Deakin <oliver.deakin@googlemail.com>:
>> > Ivan Volosyuk wrote:
>> > > 2006/6/6, Oliver Deakin <oliver.deakin@googlemail.com>:
>> > >> <SNIP>
>> > >> I can see how confusion could be caused by their location, however
>> > >> IMHO it would cause more confusion to have the kernel stubs
>> > >> located separate to the rest of the Java code.
>> > >> Perhaps it would be clearer if the directories were renamed
>> > >> luni-kernel-stubs and security-kernel-stubs (which would also match
>> > >> the jar names they generate)?
>> > >>
>> > >
>> > > A small note.
>> > > As a writter of classlib adapter for jchevm I can say that the stubs
>> > > was quite useful for writting kernel classes specific for jchevm.
>> > > There are also some troubles with them: number of functions 
>> fallbacks
>> > > to null value, while it can be something like RuntimeException("not
>> > > implemented"). Some of the classes has better implementation in 
>> drlvm,
>> > > which can also be used as default implementation.
>> > >
>> >
>> > Yes, you're right - not all of the classes in luni-kernel and
>> > security-kernel
>> > contain implementation code. Some literally are stub classes that just
>> > return
>> > null, or throw an exception from every method. From a quick look, the
>> > implemented classes are:
>> >
>> > luni-kernel:
>> >    java.lang.StackTraceElement
>> >    java.lang.System
>> >    java.lang.ThreadGroup
>> >    java.lang.Throwable
>> >    java.lang.ref.SoftReference
>> >    java.lang.ref.WeakReference
>> >
>> > security-kernel:
>> >    java.security.AccessControlContext
>> >    java.security.AccessController
>> >
>> > Ivan, are you proposing that we "fill in the gaps" with some of the
>> kernel
>> > classes from drlvm so that we have a complete set of reference kernel
>> > classes to help future VM writers?
>>
>> Well, after a bit of thinking, no.
>> The stubbed version of kernel classes should be as clean as possible.
>> Any implementation in this classes can add false dependencies to other
>> classes which (the dependencies) can be absent in the other vm
>> implementation. As the drlvm is already in svn the initial
>> implementation for some classes can be taken directly from there.
>
>
> Not sure this thing is right to do. The kernel classes use the 
> VM-specific
> interfaces and have a lot of internal dependencies.
> Only VM writer can define them in accordance with own design. It's 
> clear he
> can look at the existent implementation
> (as example) and no more than.

Agreed - the kernel classes that are provided in Harmony 
(classlib/drlvm/other)
shouldn't drive the implementation of the VM. They're there for example 
only,
and how the VM writer uses them is their choice - but they should not feel
they have to copy them exactly or implement any part of their VM to fit
in with them. However, developers are free to take as much inspiration
from them as they like :)

The bottom line is, the kernel is intended as a VM-specific Java part of 
the
whole VMI, and VM developers are free to implement it as they wish within
the API spec.

Regards,
Oliver

>
> Thanks,
> Vladimir.
>
>
> -- 
>> Ivan
>> Intel Middleware Products Division
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
>

-- 
Oliver Deakin
IBM United Kingdom Limited


---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message