Niclas Hedhman wrote:
On Thu, Oct 15, 2009 at 12:42 AM, Gregg Wonderly <[email protected]> wrote:
Anyone have thoughts or questions?
For OSGi (maybe Netbeans as well) there might be additional
"problems", since "loading a class" is not a straight forward process
of calling a static provider. In OSGi, each "module" is wired up with
a "class space" but the same class name (difference version, different
provider, etc) may be in another "class space" in other modules. So,
to fulfill a contract where a static method gets called from
"anywhere" and I need to figure out which class to load is near
impossible (at least in a platform independent way) in OSGi, as you
will have to figure out which bundle (module) the caller reside in, in
an environment where multiple versions of the same class can exist.
(The reason this is near impossible is that the OSGi spec doesn't have
any Classloader API, from which the Bundle can be retrieved.)
"Class space" is a complex and powerful concept in OSGi, which
basically try to ensure that there are no class version clashes and
yet provide the class visibility needed.
I've been pondering similar issues with code base services combined with
static bytecode dependency analysis and corresponding Classloader
hierarchies.
It may be possible to segregate OSGi modules, into separate ClassLoaders
using bytecode dependency analysis and by capturing OSGi metadata. I'm
planning on using codebase services to distribute it. Similarly,
Package version metadata could also be collected. Class Metadata, could
be distributed and stored with the bytecode as class mirror objects,
where local Classloaders could segregate class files based on received
class metadata.
The metadata (class mirror objects) could also potentially be marshalled
along with any serialized object instances to preserve class version and
dependency information of distributed objects for reassembly using
compatible classes, either identical class versions or later compatible
versions (where compatible means that an entire package or module has
maintained backward compatibility or the mirrors determine that the
dependency requirements have been satisfied).
The Classloader would then be location independent, but package or
module version dependant. The codebase might elect to distribute a
later version of a compatible package where possible when first required
locally. Class Mirrors would be used to determine compatibility.
The problem then would be to figure out how such a thing could be
shoehorned into an IDE, a problem domain that I don't currently have a
good understanding for. But for me that's another problem.
OTOH, Paremus has shown that
a) Locally available classes can be used,
b) Remote classes be downloaded and wrapped in temporary bundles with
OSGi contracts honored.
c) PreferredClassLoader is not needed.
So, perhaps your ambitions are too great and that you can/should
ignore OSGi's needs.
Cheers
