Hi Igor: > >Ramesh Mandava wrote: >> 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. >
Thanks for the suggestion. As I haven't looked at the Eclipse architecture, I can't comment anything on this. But we can definitely explore different options for solving this problem. Thanks -Ramesh
