"Richard S. Hall" <[EMAIL PROTECTED]> wrote on 04/11/2006 03:20:28 AM:
> [EMAIL PROTECTED] wrote: > > I know the equinox (eclipse.osgi) implementation has a few more packages > > they delegate (which are different depending on the jvm version). > > It looks like a sane list to me. It might be interesting to have look at > > it. > > > > Look for the *.profile files in the following directory: > > http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.osgi/ > > These profiles essentially delegate everything, so I would not consider > that sane. :-) > > I am sure there is room for a big debate here, but delegating nearly > everything on the class path by default just does not seem like the best > approach to me. I would rather be conservative and let other people > loosen it for their own purposes, then to just ship with it nearly wide > open. > > -> richard We had this big debate in Equinox/Eclipse and it did spill over into discussions within OSGi. This is one reason the org.osgi.framework.bootdelegation property exists in OSGi. First of all, what are the profiles for within Equinox? The profiles specify the spec'ed set of packages for the various execution environments which the Framework can run on top of. The Equinox framework detects the spec level of the VM and then picks the appropriate profile to figure out the following: (a) what packages (from the VM) should be exported by the system bundle (org.osgi.framework.system.packages) (b) what execution environments are supported by the profile (org.osgi.framework.executionenvironment) (c) optionally, what packages should be delegated to boot (org.osgi.framework.bootdelegation) (c) has to be enabled for the framework to actually use that property from the profile. By default Equinox had to ship with org.osgi.framework.bootdelegation=*. This is unfortunate, but we found that there were too many issues with the current VM's and too many assumptions by developers to abide by the strict OSGi R4 rules for boot delegation. We tried very hard in the Eclipse 3.1 development cycle to make this work. Here are just a few of the issues that blocked us from doing it. (a) profilers will not work (e.g. optimizeit, yourkit etc.). this is because these types of profilers add extra classes to the VM boot classpath and at runtime they weave bytecodes into your class to make extra calls to their profile libraries. Even if you configure the framework to export these packages, you would have to add Import-Package statements for the profiler packages for every bundle you want to profile. Another option is to add the profiler packages to the org.osgi.framework.bootdelegation list. (b) There are various VM "bugs" that assume that every classloader on the system has access to everything on the boot classpath. We did come up with an algorithm to work around some of these types of "bugs" but there are still some situations that will not work. For example, you will see strange classloading errors in swing. (c) Large developer bases are not able (or willing) to handle the switch. Pre-OSGi R4 every framework would automatically delegate to boot. Most all Java modular systems (at least ones I'm aware of) delegated to boot, this includes Eclipse before OSGi was adopted. It is an unfortunate reality that large developer communities expect backward compatibility. Many developers do not care if you tell them "hey, but the old way is bad for you!". They just want to be assured that the bundles which use to work on a previous release will continue to work on future releases without modification. In Equinox we had to compromise. By default we delegate everything to boot, but we do export the "known" profile packages from the system bundle to allow bundles to import these packages. We do have various setting that allow you to configure Equinox to follow the OSGi R4 strict rules for boot delegation. Unfortunately we could not do ship in "strict" mode by default because of the various issues stated above. I'm not suggesting that Felix cannot overcome these issues. I'm sure there will be a response to this note debating the importance of the issues above vs correct boot delegation behavior. That is fine, it is a debate the Felix community should have. I'm just summarizing how the debate went in Equinox and what the outcome was. Tom.
