No concerns here, but I do have a somewhat related question. What's the prescribed development model around the Java code in the kernel? For example, there are some additionally methods and constructors that were added to String in Java 5 (e.g. code point methods, StringBuilder constructor, etc) that I was thinking about addressing. Would I just make updates against the kernel module, just like any other module? What about the test cases?
Assuming that's somewhat correct, if my understanding of the "vm-specific" concepts is correct, then there's no guarantee that any of the kernel-stub code is used, right? Put another way, can a VM just completely implement the kernel classes itself? One of the reasons I ask is because of some of the kernel classes, like String, have package-private (default) scoped methods that are used in LUNI by other java.lang classes. If this is a RTFM question, then feel free to point me back to the VMI documents with a scolding. Thanks. -Nathan > -----Original Message----- > From: Tim Ellison [mailto:[EMAIL PROTECTED] > Sent: Friday, March 31, 2006 7:33 AM > To: harmony-dev > Subject: [classlib] splitting kernel in two > > FYI: To accurately reflect the modularity of the classlib code I'm > about to split the kernel-stubs.jar into two separate pieces that > represent the 'vm-specific' parts of luni.jar and security.jar. This > means that luni and security are no longer artificially coupled by a > single kernel. > > Regards, > Tim > > -- > > Tim Ellison ([EMAIL PROTECTED]) > IBM Java technology centre, UK. --------------------------------------------------------------------- Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
