Well, to my mind OSGi as a platform is meant to allow you to write more fully-fetured components on top of a minimal environment. I think I've read on the OSGi blog something like "there is no problem with not including feature X, but there is a problem if feature X cannot be implemented as a bundle" (sorry about paraphrasing, I cannot find the blog post anymore).
The decision to leave out ClassLoader access this cripples this ability quite a bit. Existing Java APIs do make use of ClassLoaders (RMI being my problem child here). It's not that bad, as I said, I devised a kludgy workaround... But it's certainly annoying. Also, I'd like to point out that "programmer use" is quite different from "systems/framework programmer use". Which you want to enable too, with the likes of Jboss, WebSphere... And our own SmartFrog too :) making use of OSGi as an underlying platform. - Olivier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of BJ Hargrave Sent: 03 August 2007 13:46 To: OSGi Developer Mail List Subject: Re: [osgi-dev] Rationale for not having a getClassLoader() methodin Bundle I think the main reason is that it is generally thought that programmer use of ClassLoader is a BAD idea. It is a tool for module systems (like OSGi) to interact with the VM for class loading but the application (i.e. bundles) should not be using ClassLoader direcly. Thus after much discussion in the OSGi expert groups, we concluded that directly exposing a ClassLoader object from the OSGi API was a bad idea. Instead we placed the necessary methods (load class, get resource) directly on the Bundle object. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
