You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Tim Ellison <t....@gmail.com> on 2006/03/31 15:33:08 UTC
[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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] splitting kernel in two
Posted by Tim Ellison <t....@gmail.com>.
They are the only two that have kernel dependencies at the moment. Once
we get into some of the new 5.0 packages (e.g. j.u.concurrent) I'd
expect to see a few new modules with vm-specific types.
Regards,
Tim
Geir Magnusson Jr wrote:
> Are there any others that you might do while in there?
>
> Tim Ellison wrote:
>> 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 (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [classlib] splitting kernel in two
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Are there any others that you might do while in there?
Tim Ellison wrote:
> 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
>
Re: [classlib] splitting kernel in two
Posted by Tim Ellison <t....@gmail.com>.
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?
Nathan, it is fair enough to make updates to the 'reference' code
currently held in the kernel stubs, but the VM interface proper
comprises VM-provided implementations of these kernel types, so it is
ultimately the responsibility of the VM to get these right.
We can, and should, write unit test that exercise the kernel classes to
ensure that classlib and the VM agree on the specified behavior. Kernel
classes are part of LUNI and SECURITY modules.
> 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?
yes, VM's can just completely implement the kernel classes, or start
from our kernel stubs (modulo licenses etc.)
> 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.
We recently agreed that String should be pulled out of kernel into the
LUNI module. String is a critical class for VM implementation and
performance so we won't modify its shape arbitrarily, but there is also
a large amount of behavior in String that should rightly be shared
across all VMs.
> If this is a RTFM question, then feel free to point me back to the VMI
> documents with a scolding.
Not at all -- it is a good question.
Regards,
Tim
> Thanks.
> -Nathan
>
>> -----Original Message-----
>> From: Tim Ellison [mailto:t.p.ellison@gmail.com]
>> 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 (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
>
>
--
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
Re: [classlib] splitting kernel in two
Posted by Etienne Gagnon <eg...@sablevm.org>.
Tim Ellison wrote:
> Please ensure your student feels welcome to send comments and questions
> to the dev list. There are lots of people here who can help.
I invited a student to present himself and send some question to this
list. He'll probably do it soon. We have started playing around with
the code and we obviously need a little additional explanations that
those in the VMI docs. :-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
Re: [classlib] splitting kernel in two
Posted by Tim Ellison <t....@gmail.com>.
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
RE: [classlib] splitting kernel in two
Posted by Nathan Beyer <nb...@kc.rr.com>.
The IBM VM does work "as is" with the class library; that's what I use to do
all my development and testing at least.
I agree with your sentiment to have a stable VM interface, which is why I
wanted to bring it up. I wanted to verify that special care needs to be
taken with the kernel APIs.
-Nathan
-----Original Message-----
From: Etienne Gagnon [mailto:egagnon@sablevm.org]
Sent: Friday, March 31, 2006 7:14 PM
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib] splitting kernel in two
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.
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.
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.
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.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
---------------------------------------------------------------------
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
Re: [classlib] splitting kernel in two
Posted by Etienne Gagnon <eg...@sablevm.org>.
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.
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.
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.
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.
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
RE: [classlib] splitting kernel in two
Posted by Nathan Beyer <nb...@kc.rr.com>.
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:t.p.ellison@gmail.com]
> 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 (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