harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <dava...@gmail.com>
Subject Re: [Technical] VM Interface/OSGi discussion (Was: Re: [Licensing/Community] Fresh start)
Date Tue, 06 Dec 2005 12:31:32 GMT
I love it... +1 from me!!!!!! Let's please draw up a concrete plan and
wiki-it :)

-- dims

On 12/6/05, Dalibor Topic <robilad@kaffe.org> wrote:
> Tim Ellison wrote:
> > Dalibor Topic wrote:
> >
> >>Technically speaking, I'm not sure if the whole licensing logjam around
> >>the VM interface is not essentially a red herring. If my mental model of
> >>where we want to go with respect to OSGi is correct, in essence
> >>
> >>a) partition the class library along some borders into bundles
> >
> >
> > Agreed.
> >
>
> yay! :)
>
> >>b) have a small enough core (library) to run the OSGi service to load
> >>the bundles of the rest of the class library.
> >
> >
> > There is a core set of classes required to bootstrap the OSGi framework
> > code.  The trick is to bring up enough classes to implement the
> > framework, then retrospectively apply the framework rules to those
> > classes.  By the time the framework is instantiated and ready to load
> > new classes it will have the core classes installed.
>
> I've had something like that in mind, too, cool.
>
> Is it absolutely necessary to have those core classes as a bundle, and
> do the retrospective trick?
>
> I'm trying to figure out if we can shave off complexity, so please bear
> with my basic knowledge of OSGi semantics :)
>
> >
> >>I'd hope that the VM interface is sufficiently defined by saying "the absolute
> >>core classes necessary to run a minimal OSGi implementation",
> >
> >
> > IMHO the framework requires too many classes for this to double as the
> > VM interface -- the number of classes that the VM knows intimately is
> > much smaller, and what I have been calling the 'kernel' classes (about
> > 18 or so types).  The kernel classes can be written as a bundle
> > (fragment) that plays in the class componentization model alongside LUNI
> > (java.lang, java.util, java.net, java.io), SECURITY, etc.
> >
> >
>
> OK. I see how one can, by programming carefully, knock things down to a
> very small, minimal set of classes necessary. I don't think we have to
> absolutely strive for the absolute minimum, though, as it may end up
> making the interface more complicated and less useful in practice for a
> few reasons:
>
> a) people implementing the interface on their own VMs may find out that
> it relies too closely on correct order of class loading for them to
> easily bootstrap their not fully standard conforming VMs. Ahem. :)
>
> b) Minimizing the set of bootstrap classes can result in complexity
> being pushed out somewhere else, for example by mandating native methods.
>
> Considering that we have 4000-5000 classes in 1.5 to work with, I
> believe the difference between an 18 class bootstrap interface and a 50
> class bootstrap interface is negligible, given that, as I explained
> below, most people are either able to pick various open source
> implementations of a large set of those classes under licenses ranging
> from BSD, ASLv2, GPL+linking exception, to LGPL, and GPL, to name a few,
> and mix and match those largely to their heart's content.
>
> So if stuffing a class into the bootstrap set helps up reduce the VM
> interface complexity, I'd say let's go for it. Examples below.
>
> >>which would
> >>translate to "OSGi/Minimum-1.1 execution requirements" being the fundamental
> >>VM interface, as that's what's needed to run a minimal OSGi implementation
> >>that takes care of all the rest wrt to handling bundles, as far as I can
> >>guess. I hope Tim will correct me if I am wrong. The minimal 'profile'
> >>is, afaict, a small subset of io, lang, lang.*, net, util and security
> >>packages.
> >
> >
> > If we squeeze the VM interface down to the few kernel classes, the only
> > thing that remains in the VM interface is a regular JNI impl and some
> > minor additional functions (to get VM system properties etc.).
> >
> > Here's the big picture:
> > http://svn.apache.org/viewcvs.cgi/*checkout*/incubator/harmony/enhanced/trunk/sandbox/contribs/ibm_core/doc/vm_doc/html/index.html
> >
> > (see the 'VMI interface' and 'Kernel Java classes' links in that doc for
> > specifics)
>
> Cool.
>
> Here are my examples of reducing complexity by adding classes to the
> bootstrap set: I see that the interface specifies fdlibm, which I assume
> is needed to properly implement double/float. Rather than specifying an
> interface in C with JNI and all that fun, let's just make Double and
> Float implementations part of the bootstrap set.
>
> Same with zlib: I didn't see it being specified in OSGi/Minimal, so I
> guess we may be able to get by and say that java.util.zip is either part
> of the bootstrap set, and then we chuck it in, and all the native
> dependencies disappear. There are various java.util.zip implementations
> out there, etc, etc.
>
> In essence, I'd like to see if we can do away with the JNI methods and
> the C part of the VM interface, by enlarging the bootstrap set by those
> classes that would need them, and just leaving their internals unspecified.
>
> That would mean that the vmi.h and friends are useful for runtimes using
> Harmony's classes, just as the GNU Classpath interface is useful for
> runtimes using those classes, and so on. The overarching VM interface
> could abstract away from those, I hope.
>
> >
> >>It would, I believe, be easiest to say, the VM interface are those
> >>classes, rather than following the OSGi convention of enumerating the
> >>methods along with the classes.
> >
> >
> > Agreed.  To get a clean set of classes there are some non-Java-API
> > methods that form part of the kernel classes' contract with the rest of
> > the class library (e.g. ThreadGroup.add() and ThreadGroup.remove()).
> > Without this there would be many more types pulled into the 'kernel'.
> >
> > Of course, VMs could choose to implement any superset of the kernel
> > classes that suit them, or implement the kernel classes in any manner
> > that suits them (e.g. the earlier discussion of delegates vs. in-lines I
> > think is irrelevant if we agree it is the VM's perogative).
>
> Yup. Amazing how much simpler things become but just assuming they are
> there. We don;t have to wrestle with the right way to write inlineable
> code, yay :)
>
> As I said above, I don't think we need to strive for absolute
> minimalism, though. I'd trade an interface that I can implement on a
> lazy weekend for an interface that saves me 200k of kernel classes
> download, but takes me a month to get written. Simpler interface ->
> faster, easier adoption, I hope.
>
> >
> >>With that out of the way, the real challenge would be finding nice ways
> >>to partition the remaining class libraries, and as you've noted before, one
> >>obvious area to go for are the xml classes. Tim posted a writeup of a
> >>few more ideas, which looked pretty cool.
> >>
> >>On the implementation side, Harmony is already in great shape with the
> >>contributions from IBM and Intel, though I do not know if they allow us
> >>to run a minimal OSGi implementation yet. So another challenge would be
> >>to fill in the gaps, if there are any.
> >
> >
> > I believe there is enough there already, but if people have other
> > requirements I'd be happy to discuss on the list.
> >
>
> Cool. Thanks!
>
> >
> >>Finally, we'd need to have our own, ASLv2 licensed OSGi implementation.
> >>I am not sure if there is one, but I hope Geir knows more.
> >
> >
> > We are in luck:
> >     http://incubator.apache.org/projects/felix.html
> >
>
> Yay!
>
> > and there are other implementations such as
> >     http://www.knopflerfish.org/index.html
> > and
> >     http://www.eclipse.org/equinox/
> >
>
> Double yay! I also found Oscar and JEFFE, so there seems to be
> implementations aplenty for all licenses around.
>
> > that make this a pretty safe and vibrant area to step into.
> >
> >
> >>So, this would be my outline for the VM interface, as I have it in my
> >>mind, 1000ft view, circumventing all licensing issues by using OSGi on
> >>top of a minimal set of classes we assume as given.
> >>
> >>How a VM implements those classes, under which license, is not our
> >>problem. Harmony will have all those classes under ASLv2, other
> >>projects will have GNU Classpath's implementation under GPL+linking
> >>exception, different projects may chose to use the old Kaffe or gcj
> >>code, or take the BSD-licensed code from Wonka as a basis for their
> >>efforts.
> >
> >
> > (Tim breaks out into an Hallelujah Chorus :-) )
>
> Amen, brother, and all that.
>
> >
> >>Does it sound feasible? I believe it is the easiest way to go forward
> >>fast, rather than getting stuck on who owns what under which license and
> >>how they may or may not interact. Harmony already has a sizeable chunk
> >>of the minimal needed set of classes, and so has GNU Classpath,
> >>nevermind potential contributors using proprietary implementations.
> >
> >
> > +lots.
> >
>
> Great, we are in violent agreement! Someone make a picture! :)
>
> cheers,
> dalibor topic
>
> 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.
>


--
Davanum Srinivas : http://wso2.com/blogs/

Mime
View raw message