mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: [MINA 3] package name
Date Wed, 20 Mar 2013 12:25:38 GMT
Le 3/19/13 8:07 PM, sebb a écrit :
> On 19 March 2013 15:46, Alan Cabrera <list@toolazydogs.com> wrote:
>> On Mar 18, 2013, at 11:44 AM, Emmanuel Lécharny <elecharny@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 <elecharny@gmail.com>
>>>>> 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...

Emmanuel Lécharny

View raw message