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]

Reply via email to