harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vladimir Gorr" <vvg...@gmail.com>
Subject Re: [general] revisiting structure of SVN
Date Wed, 07 Jun 2006 04:34:06 GMT
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.

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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message