-----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----- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
