harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [classlib] splitting kernel in two
Date Sun, 02 Apr 2006 20:28:24 GMT
Etienne Gagnon wrote:
> Hi Nathan,
> Not sure what others think...  Personally, I would highly recommend
> being very careful before (or when?) changing kernel classes, as
> changing them could lead to a very unstable VM interface if care isn't
> put into preserving stability.  An unstable VMI is not something I would
> like to live with, as a VM developer.

Agreed.  The kernel classes in the VMI were defined as (arguably a
superset of) types that a VM would want to control. Once we have a broad
set of VM types represented in Harmony we may find that we can share
more of the classlib implementation.

> Unless I am wrong, IBM's VM works with the current class library "as is"
> (can somebody confirm/infirm this?).  It would be sad if Harmony stopped
> working with IBM's VM, at least until it also worked with an open source VM.

IBM has provided a VM on developerworks [1] (under a no cost, but not
open source license) that implements the VMI.  We are just about to
update it to reflect the package renaming, and moving String to LUNI
that is currently underway.

[1] http://www.ibm.com/developerworks/java/jdk/harmony/

> I am currently working with a student to get SableVM working with
> Harmony's VMI and kernel classes.  We're just starting, and I have a
> busy schedule, so it would be difficult if the VMI kept changing under
> our feet over the next weeks (couple of months?)...  Of course, we could
> try to get SableVM to work with a fixed "historic" Harmony version, but
> it would be nicer to get it working with the head revision in svn.

Agreed, we will only change the VMI where there is a compelling case to
do so.

Please ensure your student feels welcome to send comments and questions
to the dev list.  There are lots of people here who can help.


> Now, this being said, if all you want is simply to add additional
> constructors/methods, or make changes that do not impact the VM, such as
> adding "erasable" parametric types which result in fully binary
> compatible class files, then I have nothing to say about it. ;-)
> Just an opinion, of course.
> Have fun!
> Etienne
> Nathan Beyer wrote:
>> 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.


Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message