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. > Regards, > Alan > >
