＞That's the point - that we need the native kernel, and can do the
＞rest in C/C++ or Java or both, but hopefully not both - that we can
＞divide the work once we have the kernel so things can proceed in
＞parallel (or be donated, or use from 3rd party if appropriately
＞licensed, etc)
I think so, too, especially as there might be a big work to do to support
the java 5 standard library, so that starting that early could be cool
(especially in order to show significant examples that "the VM just works",
even if speed is suboptimal [1])
Regards,
RB
[1] as some say, 3 rules for optimizing:
"1/ not yet, debug first
2/ not yet, debug first
3/ not yet, profile first"
(No guaranty. Please trust it and die.)
-----Original Message-----
From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 6:43 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] The Third Way : C/C++ and Java and lets go forward
On May 23, 2005, at 5:31 PM, Tor-Einar Jarnbjo wrote:
> Geir Magnusson Jr. wrote:
>
>
>> (for the record, this isn't about "not doing Java" or "not doing
>> JikesRVM", but rather my understanding that we'll need a small C/C+
>> + kernel to host the modules, no matter how they are written, and
>> this is a way to get that going...)
>>
>
> Excuse me if I'm missing something, but wouldn't it be necessary to
> implement parts of the VM or the class library in native code anyway?
Yes.
> I'm thinking about code to access e.g. resources like I/O devices,
> sound etc.? Or is this discussion C vs Java restricted to the
> bytecode executing part of the VM?
It's never been clear :)
That's the point - that we need the native kernel, and can do the
rest in C/C++ or Java or both, but hopefully not both - that we can
divide the work once we have the kernel so things can proceed in
parallel (or be donated, or use from 3rd party if appropriately
licensed, etc)
geir
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
