harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Volosyuk" <ivan.volos...@gmail.com>
Subject Re: [general] revisiting structure of SVN
Date Tue, 06 Jun 2006 18:21:33 GMT
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.

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

View raw message