Hi Joe:
That appears to work for implementation classes, as long as everyone is very careful to _ONLY_ use APIs provided by the unchanging stuff in the core jarfiles.
It doesn't directly address genuinely evolving standard APIs, where users might want to plug in a new release of the Interfaces along with the new implementation. (Consider the user who wants to start prototyping DOM Level 3, but is seeing DOM Level 2 on your extension classpath.)
I agree with you that the renaming of implementation classes would not help us address the case of evolving standard APIs ( like DOM, SAX ). I hope as part of JSR process, we can come up with some solution that addresses this issue.
Any ideas?
Idea is very simple - something like Eclipse plugin architecture (org.eclipse.core.boot & org.eclipse.core.runtime plugins) but in a lover level. I.e. management of libraries in a JVM, so in every library (or application) you describe versions of required APIs/implementations instead of defining CLASSPATH, and central repository for a libraries...
There is active discussion of future developments related to Eclipse classloading in news://news.eclipse.org:119/eclipse.technology.equinox - this might be interesting too, they are solving similar problems... You could propose joining efforts and open new JSR for this.
