commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] top-level package name
Date Tue, 19 May 2009 19:19:05 GMT
sebb a écrit :
> On 19/05/2009, James Carman <> wrote:
>> On Tue, May 19, 2009 at 6:53 AM,  <> wrote:
>>  > Hello,
>>  >
>>  > Considering the ongoing discussion in another thread, the current changes that
have been done on [math] for the last months belong to the major changes with large incompatibilities
with previous versions.
> Are you sure that there are large incompatibilities?

Yes. There have been several packages reorganizations in analysis, ode,
linear and optimization by adding subpackages and moving classes. There
have been some renamed classes (mainly in ode). There have been very
large changes in linear and optimization (almost all classes have
changed I think) and new methods have been added to interfaces. Every
deprecated API from 1.x have been removed.

When possible, the old API have been simply deprecated so they can be
removed later, but it was not always possible (I don't remember each
case, sorry).

As suggested by Hen, I ran a clirr report with respect to 1.2, it
triggered 183 errors (including the deprecated methods that have been

> I thought you were trying to preserve API compatibility?

Yes, for minor versions. However, since there were some needed changes
in ode and linear, we decided to take the opportunity to concentrate all
changes in one move once it had been decided to start.

>> We have already decided that the version number will be 2.0 to acknowledge that.
I know of at least one big international research project that uses commons-math 1.2 and will
switch to 2.0 when it will be published. They have already faced compatibility problems recently
(two days ago).
>>  >
>>  > Should we change the top level package name from org.apache.commons.math to
org.apache.commons.math2 ?
>> I'd say yes.
> In that case, it should be OK to break compatibility in the Frequency
> class by requiring that parameters be Comparable rather than Object -
> see MATH-259 & MATH-261 - which will improve compile-time safety.

As far as I am concerned, I'll say yes. In fact, I was even wondering
why stopping the changes here when we have the opportunity.


>>  ---------------------------------------------------------------------
>>  To unsubscribe, e-mail:
>>  For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message