Peter Edworthy wrote: > How clean are the separations between packages/groups of packages in > ClassPath?
As clean as possible. Depending on non-public parts of other API packages is to be avoided as far as possible. And if there is Classpath-specific behaviour in the public API, then that is likely a bug. (or the absence of a Sun bug) > i.e. how possible would it be to use say java.sql.* with another > implementation of java.lang? Why wouldn't it be possible? It'd be horrible coding if it were any other way. So yes, it's completely possible. Simple even. There are no implementation-specific interdependencies between packages that I know of. Not counting between packages and subpackages, of course. (And even those are somewhat rare.) But it does of course stand to reason that just any arbitrary package can't be seperated out. E.g. Our java.awt.image will never work happily with Sun's AWT, or vice-versa. However, our java.awt.geom and java.awt.color will. Our Swing should be able to run on Sun's AWT. (Although I'm not sure about Sun's Swing. I've heard it isn't 100% pure java, after all, but does rely on some undocumented stuff) > I ask this as I'm just wondering if having the ClassLoader select from > multiple implementations based on user preference for that package would > be a good idea or just an added complication. There are several ways of doing this; Newer APIs like ImageIO, NIO, Sound, Crypto, etc. are designed around a Service Provider Interface. They're designed to have multiple implementations, including user-provided ones. In these cases, choosing a certain implementation is just a matter of configuring META-INF/services in your jar or setting a system property. These SPI-plugins should work just as well with the JDK as with classpath too. As for non-SPI packages, the simple way is to utilize your CLASSPATH variable settings. If you have the same package twice in your CLASSPATH, the first will be used. No changes to the classloader required. Although in general, I think choosing the implementation you want is more of a job for the VM vendor, since they know what platforms they want to support and what their 'niche' is. E.g. GCJ already requires iconv, so they'll want to use the iconv-based charset service provider. JNode on the other hand wants to be pure java, so they want that one. GNU Classpath has both. /Sven
