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.

Regards,
Tim

> 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


Mime
View raw message