Preferred classes are used for the proxy's currently, the jsk-dl.jar in
our current build is included in proxy codebase annotations, this is to
ensure that com.sun.* namespace implementation classes are loaded by the
proxy ClassLoader.
In the modular build, we have a dependency relationship where
river-lib.jar depends on river-dl.jar to avoid duplication of source files.
This means that river-lib.jar and river-dl.jar (it has been suggested to
rename it to river-api.jar), will be on the classpath.
However river-dl.jar must continue to be part of the codebase annotation
for proxy's to ensure that proxy's load the com.sun.* namespace (except
for classes which are not preferred), into the proxy classloader to
prevent codebase annotation loss and to allow those implementation
classes to change, such that the proxy's don't have to share the same
implementation version as the platform.
Non preferred classes however are loaded from the classpath if
available, or loaded into the proxy classloader if they are unavailable
on the classpath.
This means we are free to re-implement preferred classes in
river-lib.jar and river-dl.jar over time, without worrying much about
backward compatibility, since different versions can be selected by
service implementers.
There are classes that are currently not preferred (which will be loaded
by the application classloader if available) we should investigate
moving these to the platform.jar or another aptly named jar, then we
won't have to list them as not preferred and simply list the preferred
namespaces in our proxy jar files.
Regards,
Peter.
