harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dalibor Topic <robi...@kaffe.org>
Subject Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)
Date Wed, 07 Dec 2005 20:00:27 GMT
Tim Ellison wrote:
> Dalibor Topic wrote:
> 

> Just to be clear, the kernel classes are VM-dependent types that are not
> typically reusable since the VM typically will 'know' the shape of the
> class/instances.  I think it is useful to minimize that set.
> 

Yeah, I think we were talking past each other here. :)

The interface in the Wiki is going to be implemented by the Apache
Harmony class of VMs, and there specifying the need for JNI, etc. is OK.
 I believe you're talking about that interface which is specific to
Apache Harmony class of VMs and the Apache Harmony class library
implementation.

Let's assume that the other VMs out there also have their own ways of
binding to a class library, and vice versa, portability helper
functions, and so on. The other runtimes out there may want to reuse
Apache's code, but chances are they have their own stuff for running
OSGi code already with the class libs they use, be they proprietary or
open, so let's just make it as simple as possible to leverage what they
have.

For the OSGi partitioning work, all people we to agree on is a and b
from the previous mail.

So when I was talking about the VM interface, I mean a core set of
bootstrap classes. I just meant a minimal set of classes that need to be
present to be able to work with a minimal OSGi implementation, and the
resulting class library partitioning.

How a VM interfaces with its own class library, then no longer matters.
Neither does it matter how the VM partitions that bootstrap class set
internally: Harmony may prefer to partition the bootstrap set into
different subsets that are more efficient given its kernel layout, other
VMs may just chose to just lump the classes together.

The wonderful part of that story is that noone needs to share any code
of any component: how VMs implement the bootstrap set of classes, which
OSGi implementation they chose, if they use JNI or avian carrier
pidgeons :) fails to matter, and noone needs to listen to arguments
about the ideal way to bind a class library to a VM, or what the best
OSGi implementation is. :)

More interestingly, though, everyone can use whichever component they
want internally, and it won't matter if it's proprietary of not, as long
as the bootstrap set of classes is there, a minimal osgi implementation
is included, and the partitioning is agreed upon.

> You may prove me wrong now, but are there any VMs targetting JSE that
> don't do JNI? 

Yes. There are platforms where C is not the lingua franca. GNU Classpath
has a few such users, afair.

> If we raise the semantic level far enough Classpath and Harmony are
> bound to be able to interoperate at some level <g>
> 

That may be desireable, yeah. I can hope. :)

> Take a look at the interface and how much is already implemented for
> you, and let me know if you think it is not a lazy weekend job.  The
> Doxygen includes all the code that is in the Hy codebase already -- I
> guess it would be helpful to have a step-by-step guide of what a VM
> needs to do.

Oh, it's not that I don't think I could not write yet another
portability layer into Kaffe, it's just a bit superfluous to add a third
one, since it already has two of them: one for the core vm, and one from
GNU classpath's class libraries.

It's not that I don't like portability layers, either, it's just that
they create a lot of boring maintainance work as soon as one has several
on one's hands, and has a VM that has users on a few dozens of
platforms. That in general means facing portability problems where noone
else has gone before, and there are nicer things to do than making some
portability layer work with gcc2 on m68k-a/ux on a sunny friday
afternoon. I don't want to allude that your C code isn't flawless, it's
just that I am not interested in maintaining yet another portability
layer if I can possibly avoid it. Been there, done that, etc. :)

Nevermind that I'd have to write my own implementation of the C code, as
I can't ship ASLv2 licensed code inside Kaffe (GPL2). While maintaining
portability layers is bad enough, I can't imagine what would drive me to
write another one ... [1] :)

> I think so -- though I've probably confused things by talking about the
> VMI and talking about class lib componentization in a single thread.
> 
> The summary is :
>  (1) we should aim for complimentary classlib componentization to get
> interop of large functional units;

That's the interesting part for me.

>>p.s. you know that after talking about all this stuff for the next week,
>>I'll drag you come for FOSDEM to give us an introduction into how it all
>>fits together, and why, and so on.
> 
> 
> You'll have to translate that paragraph for me -- I can't parse it ;-)
> 

It means, if you come to the Classpath dev room at FOSDEM, we'll have a
few beers together, and you can explain me IBM's grand vision for the
class libs. :)

cheers,
dalibor topic

[1] Well, if I was offered one million US dollars in small bills for a
weekend of work, then we could talk about me overcoming that aversion to
writing portability layers in C ... :)

Mime
View raw message