I don't know about forgotten but as far as I recall the separation isn't entirely about supplying what is needed by clients or services. Looking at the release notes below I can see a couple of critical things:
(1) The reference in respect of assuming these classes will always be present. (2) The statement about what is bundled - definition of "the platform". (3) The statement that any other classes present are to be considered "an implementation detail". The notes also cover jsk-lib.jar of course and discuss the fact that these are the common utility classes that services or clients may want to make use of. Should a service make use of these utility classes for it's own server-side implementation only it would include jsk-lib.jar on classpath but I doubt it would expose jsk-dl.jar to clients. If of course, it wants to make use of the utility classes in its proxy implementation, jsk-dl.jar would appear as codebase. In essence, although we see general usage of jsk-lib.jar, it's not part of the platform or expected to always be present on classpaths. *jsk-platform.jar*This JAR file contains classes and interfaces that we have chosen to include in all of our applications, and have also chosen to assume are available in all other applications that receive objects from our applications. This JAR file primarily contains classes and interfaces that are typically referenced in: - *service provider*<http://java.sun.com/j2se/1.4/docs/guide/jar/jar.html#Service Provider> resources to control the configuration of RMIClassLoader<http://java.sun.com/j2se/1.4/docs/api/java/rmi/server/RMIClassLoader.html> , TrustVerifier <../api/net/jini/security/TrustVerifier.html>, IntegrityVerifier <../api/net/jini/security/IntegrityVerifier.html>, ServerContext <../api/net/jini/export/ServerContext.html>, and DiscoveryFormatProvider<../api/com/sun/jini/discovery/DiscoveryFormatProvider.html> providers - ConfigurationFile <../api/net/jini/config/ConfigurationFile.html> source files, but which are unlikely to be referenced directly by the applications and services being configured (in particular, classes for creating Exporter <../api/net/jini/export/Exporter.html> andProxyPreparer<../api/net/jini/security/ProxyPreparer.html> instances and their components) - dynamically downloaded code, but which we believe are not themselves reasonable to download (in particular, because they are needed to bootstrap proxy trust verification, or because their implementations require extraordinary permissions) plus all of the classes and interfaces that their implementations directly or indirectly depend on. This JAR file contains all of the classes and interfaces in the following namespaces (including all subpackages): - net.jini.activation - net.jini.config - net.jini.constraint - net.jini.core - net.jini.export - net.jini.id - net.jini.iiop - net.jini.io - net.jini.jeri - net.jini.jrmp - net.jini.loader - net.jini.security - net.jini.url - com.sun.jini.discovery plus the following classes: - ConstrainableLookupLocatorTrustVerifier<../api/net/jini/discovery/ConstrainableLookupLocatorTrustVerifier.html> - KeyStores <../api/com/sun/jini/config/KeyStores.html> - ConfigUtil <../api/com/sun/jini/config/ConfigUtil.html> - LogManager <../api/com/sun/jini/logging/LogManager.html> Any other classes or interfaces found in this JAR file should be considered implementation details. On 3 January 2011 23:24, Dennis Reedy <dennis.re...@gmail.com> wrote: > I'm slogging through classes and jars attempting some modularization of the > River codebase. Its going fairly well. I'm sitting here scratching my head > whilst looking at jsk-dl.jar. My question is as follows: > > In general jsk-lib.jar is either in the classpath of a service, as well as > in the classpath of a client. The inclusion of jsk-lib.jar (from a client's > point of view) brings along helpful utilities like ServiceDiscoveryManager > and the like. From a service developers point of view, you can't really get > around not using it. > > If jsk-lib.jar is in the classpath (and by inclusion jsk-platform.jar), why > do we need jsk-dl.jar? Unless I'm mistaken all of the classes that are in > jsk-dl.jar are already in jsk-lib.jar, why is it needed? > > What have I forgotten? > > Regards > > Dennis
