commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [Math] Moving on or not?
Date Wed, 06 Feb 2013 15:04:12 GMT
IMO, any [commons] component can update it's Java requirement as it sees
fit. I would rather see /one/ [math] component instead of two.

My advise would be to (1) plan for a version 3.2 that is based Java 6 or 7
and release 3.1.x versions for bug fixes only.

Alternatively, you could (1) plan for a version 4.0 that is based Java 6 or
7 and release 3.x versions for bug fixes AND back-port of 4.0 features,
where 3.x does NOT change Java versions.


On Tue, Feb 5, 2013 at 9:08 AM, Gilles <> wrote:

> Hi.
> In the thread about "static import", Stephen noted that decisions on a
> component's evolution are dependent on whether the future of the Java
> language is taken into account, or not.
> A question on the same theme also arose after the presentation of Commons
> Math in FOSDEM 2013.
> If we assume that efficiency is among the important qualities for Commons
> Math, the future is to allow usage of the tools provided by the standard
> Java library in order to ease the development of multi-threaded algorithms.
> Maintaining Java 1.5 source compatibility for the reason that we may need
> to support legacy applications will turn out to be self-defeating:
> 1. New users will not consider Commons Math's features that are notably
>    apt to parallel processing.
> 2. Current users might at some point simply switch to another library if
>    it proves more efficient (because it actually uses multi-threading).
> 3. New Java developers will be turned away because they will want to use
>    the more convenient features of the language in order to provide
>    potential contributions.
> If maintaining 1.5 source compatibility is kept as a requirement, the
> consequence is that Commons Math will _become_ a legacy library.
> In that perspective, implementing/improving algorithms for which a
> parallel version is known to be more efficient is plainly a waste of
> development and maintenance time.
> In order to mitigate the risks (both of upgrading and of not upgrading
> the source compatibility requirement), I would propose to create a new
> project (say, "Commons Math MT") where we could implement new features[1]
> without being encumbered with the 1.5 requirement.[2]
> The "Commons Math MT" would depend on "Commons Math" where we would
> continue developing single-thread (and thread-safe) "tasks", i.e.
> independent units of processing that could be used in algorithms
> located in "Commons Math MT".
> In summary:
> - Commons Math (as usual):
>   * single-thread (sequential) algorithms,
>   * (pure) Java 5,
>   * no dependencies.
> - Commons Math MT:
>   * multi-thread (parallel) algorithms,
>   * Java 7 and beyond,
>   * JNI allowed,
>   * dependencies allowed (jCuda).
> What do you think?
> Best regards,
> Gilles
> [1] Also, we would gradually move there the algorithms that would obviously
>     benefit from a multi-thread implementation (e.g Fourier transform,
>     genetic algorithms, etc.)
> [2] This project would also be a place where people could experiment with
>     "jCuda" (
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: dev-unsubscribe@commons.**<>
> For additional commands, e-mail:

E-Mail: |
JUnit in Action, 2nd Ed: <http://goog_1249600977>
Spring Batch in Action: <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message