Re: Jigsaw vs. OSGi?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 2010-10-01 22:52, Tom Marble wrote:
> All:
>
> Thought those interested in modularity would like a pointer
> to James' interesting blog post:
>
> http://www.redmonk.com/jgovernor/2010/10/01/java-the-unipolar-moment-on-distributed-governance-for-distributed-software/
>
> Thoughts?
>
> --Tom
>
>
I had a little look at class loading and it looks possibly to inject a
"mildly OSGi aware"[1] ClassLoader between the System ClassLoader and
the application itself (at least in the most common cases)[2].
The injected ClassLoader can then examine the parent ClassLoader
(which is in the Openjdk-6/Sun-java case is an URLClassLoader) using the
getURLs() method to see the ClassPath (at least the one passed via
command line).
So, assuming that we accomplish "Openjdk-6 everywhere" or that GCJ/GIJ
also use an URLClassLoader (or we can figure out how to handle its
AppClassLoader) then we should be able to develop a ClassLoader that
uses OSGi metadata in the Manifest.
If the Java 7 API does not break the ClassLoading part, then we can
essentially have a mix of OSGi and Jigsaw. Tom do you know how the Java
7 API is backwards compatible here?
This could also solve another problem we have. If an application wants
to use a jar file that only contains OSGi metadata, then our ClassLoader
can resolve the dependencies of that jar file without us having to
modify its Manifest or setting the classpath when starting the application.
Note that this will not solve all our problems[3]. But I think it can be
used as an alternative to adding ClassPath to OSGi based libraries that
can be used by non-OSGi aware applications.
Since OSGi metadata is vastly more detailed than a simple "ClassPath"
entry this may also be an alternative solution to or as an
implementation of the "Java Library SONAME" problem.
There is a problem with mapping an bundle name or a (java) package name
to the jar file(s) containing it. If the jar file (or has a symlink
that) is named after its bundle name this can solved by simple
heuristics in most cases.
There are some few corner cases (e.g. org.osgi is actually in a bundle
called org.eclipse.osgi) that we may have to look at how we want to solve.
~Niels
[1] By "mildly OSGi aware" I mean a class loader that parses OSGi
metadata to determine dependency relations. Applications that need
"services" and such need to be OSGi aware themselves and should not have
our injected ClassLoader.
[2] Java 5 API java.lang.ClassLoader#getSystemClassLoader()
...
If the system property "java.system.class.loader" is defined when this
method is first invoked then the value of that property is taken to be
the name of a class that will be returned as the system class loader.
The class is loaded using the default system class loader and must
define a public constructor that takes a single parameter of type
ClassLoader which is used as the delegation parent. An instance is then
created using this constructor with the default system class loader as
the parameter. The resulting class loader is defined to be the system
class loader.
...
Said ClassLoader will be passed a ClassLoader which is the default
application ClassLoader (the one used if the property had not been
defined) - as least when using Openjdk-6. I assume this holds for
sun-java6, but I have not tested GCJ/GIJ.
[3] Real OSGi loaders can handle having the same library twice with
different versions and will run "Activators" of these library (if they
have any). I would generally recommend we do /not/ handle this! (at
least not from day one)
If an application depends on two versions of the same library at the
same time (directly or indirectly) it should be OSGi aware itself (and
thus not use our injected loader) or we should solve this packaging wise
like we currently have to.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEAREIAAYFAkyxnw0ACgkQVCqoiq1YlqzwbQCdFvxrszHjI+bt3RWA5aJGTKk+
aBYAnjhwcIYecXEjvNDroFhCHoQhs9oW
=RfL8
-----END PGP SIGNATURE-----
Reply to: