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.
