Dalibor Topic wrote: > On Mon, Dec 05, 2005 at 02:33:06PM -0500, Davanum Srinivas wrote: > >>Again stating the obvios, *IF* there is a firewall, companies can >>choose to build their stuff to conform to the firewall and Yes, i'd >>like to make sure that firewall is *NOT* under GPL+Exception, but be >>under something neutral like MIT/X. Which is exactly what Stefano and >>Geir have been saying all along. >> > > > 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. > 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'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. > 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) > 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). > 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. > 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 and there are other implementations such as http://www.knopflerfish.org/index.html and http://www.eclipse.org/equinox/ 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 :-) ) > 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. Regards, Tim > cheers, > dalibor topic > > P.S. Sorry for interrupting a community discussion with technical > content. ;) > > >>Yes, we can give our input in GPLv3 rounds and try to make things >>happen. But i can't bet the farm that a GPLv3+Exception would be >>palatable a downstream user of harmony. can i? >> >>BTW, If i have to rip out gnu jaxp (to reduce footprint / remove hard >>coded references to gnu jaxp), it means i am modifying classpath, >>which means i have additional obligations under GPL. >> >>-- dims >> >>On 12/5/05, Mark Wielaard <[EMAIL PROTECTED]> wrote: >> >>>Hi Davanum, >>> >>>On Mon, 2005-12-05 at 09:45 -0500, Davanum Srinivas wrote: >>> >>>>Personally, i'd like to see progress on the "VM Interface" ASAP, that >>>>would go a long way to removing the mistrust. That would enable >>>>harmony VM to use unmodified classpath stuff as-is for development >>>>purposes and can act as a firewall till the licenses get sorted out. >>> >>>I am afraid this is ignoring part of the community trust issues and just >>>hoping technology will solve it all. But sure, the current VM interface >>>for GNU Classpath is described at: >>>http://www.gnu.org/software/classpath/docs/vmintegration.html >>>This is a living document and interface. We learn all the time about >>>needs of different runtimes and execution engines. And new stuff gets >>>added with each release of course. Just today a new section on the >>>recently added instrumentation hooks was added (already in CVS, website >>>will update in about 2 hours). >>> >>> >>>>See snippet from Leo's email: >>>>"Mark told me someone tried something like that a year or two ago >>>>already. I forgot whom or what it was called, but I'd suggest trying >>>>to learn about it and if it failed, why." >>> >>>I believe that was after 2 beers :) And I don't know exactly which part >>>of the conversation this was about. I know I said how interesting it was >>>the Anthony Green came up with freevm.org and now Stefano Mazzocchi came >>>up with openvm.org. Both wanting to bridge the gap and bringing it onto >>>a higher level to be "above all parties". In the end freevm.org both >>>succeeded and failed. It failed because freevm.org is no longer, it >>>succeeded because we decided we didn't need anything "above" GNU >>>Classpath, gcj and Kaffe, but that we would just cooperate as is. >>> >>> >>>>If i see some componentization such that i can drop in say >>>>xalan/xerces and not use classpath's built-in stuff (this would end >>>>users can mix and match stuff to make their distribution) that would >>>>be even better. But "VM Interface" is priority #1. >>> >>>gcj for example has a switch/system-property -Dendorsed.dirs which >>>allows for this. >>> >>>Cheers, >>> >>>Mark >>> >>> >>>-----BEGIN PGP SIGNATURE----- >>>Version: GnuPG v1.4.2 (GNU/Linux) >>> >>>iD8DBQBDlIcnxVhZCJWr9QwRAlovAKCfX0HDfd7vc9C3/y0fV4x5R4zMOQCggY7A >>>ZMkkfSQmhMHuRJLZPUmvjZc= >>>=lSja >>>-----END PGP SIGNATURE----- >>> >>> >>> >> >> >>-- >>Davanum Srinivas : http://wso2.com/blogs/ > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
