I love it... +1 from me!!!!!! Let's please draw up a concrete plan and wiki-it :)
-- dims On 12/6/05, Dalibor Topic <[EMAIL PROTECTED]> 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/
