2006/6/6, Oliver Deakin <[EMAIL PROTECTED]>:
Mikhail Loenko wrote:
> 2006/6/6, Oliver Deakin <[EMAIL PROTECTED]>:
>> Mikhail Loenko wrote:
>> > They are not just stubs, I remember I've fixed a bug there [1].
>>
>> Even though you fixed the code there, it wont be getting used when you
>> run with
>> the classlib launcher. The luni-kernel and security-kernel classes under
>> modules are
>> only used to compile against, and the luni-kernel-stubs.jar and
>> security-kernel-stubs.jar
>> that they are packaged up into are never put on the bootclasspath (see
>> depends/files/bootclasspath.properties).
>
> It's funny because my fix had solved the problem :)

I was thinking about that, so I had a look back at the mail archives and
the JIRA you linked. It looks like a new version of the VME came out
around the time that you were working on the bug. I think there might
have been a massive coincidence that you got the new VME, which
contained a similar fix in its kernel classes, and used this to make
a final run of the test against Harmony code, which then passed.
Quite impressive timing! ;)

>
> If they are just stubs why not remove code from them? And why not to
> put them
> to depends or whatever to not confuse people?

I think it's worth keeping the code there, just as a starting point for VM
writers to implement their own kernel classes. It should be possible for
a VM writer to adapt them for their own kernel, thus lessening the initial
amount of time it takes to get the VM working with Harmony classlib.

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

Regards,
Oliver

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.

--
Ivan
Intel Middleware Products Division

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