Ivan Volosyuk wrote:
2006/6/6, Oliver Deakin <[EMAIL PROTECTED]>:
<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?
Regards,
Oliver
--
Oliver Deakin
IBM United Kingdom Limited
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]