Le 3/19/13 8:07 PM, sebb a écrit : > On 19 March 2013 15:46, Alan Cabrera <l...@toolazydogs.com> wrote: >> On Mar 18, 2013, at 11:44 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: >> >>> Le 3/18/13 6:58 PM, Alan Cabrera a écrit : >>>> On Mar 18, 2013, at 9:57 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> I was wondering if it wouldn't be a good idea to rename the >>>>> org.apache.mina package to org.apache.mina3 ? >>>>> >>>>> That would help those who embed the lib in an application which already >>>>> has a dependency on MINA2 (and does not use OSGi). >>>> Are you saying they embed both mina2 and mina3? >>> That's something you can face, for instance if one embed ApacheDS (MINA >>> 2) and MINA 1 in some old library. >>> >>> I mean, this is something we might have to deal with. I know that we are >>> taking all our time to get Mina 3 our, so that we are sure every one >>> will have switched to another NIO lib in the mean time, but still ... ;-) >> -0 >> >> I think that adding a version to a package name is a bad practice and it's >> being done to support other bad practices. Plus, there are plenty of tools >> that allow package renaming when assembling junk drawer uber-jars. >> > The reason for the package rename is a direct consequence of the way > the Java classloader works. > A single classloader can only load a single copy of a class. > If there are multiple different instances of a class on the classpath, > this causes problems. > > The Maven coordinates need to be changed along with the package name > because Maven uses the coordinates to decide which jars are different > versions of the same code. It only allows one jar from each different > groupId/artifactId pair to exist on the same classpath. > > Bad practise is *not* changing the package name when breaking binary > compatibility. > > The public API must remain binary compatible or some applications will > not be able to use the new version. > > For example if the application contains a 3rd party jar which relies > on the old API, it may not be possible to update the jar immediately > (or at all) to a new version that only relies on the new API. > > If there is another 3rd party jar in the same application that uses > the new API, the only way they can co-exist in the same classloader is > if the old and new jars have different classnames. The simplest way to > change the classnames is to change the package name. > > There is no way round this for applications using a single > classloader; it's inherent in the way the Java classloader works.
Well said. Or you have to use OSGi... -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
