On Sun, 29 Aug 2021 at 01:07, Gilles Sadowski <gillese...@gmail.com> wrote:
>
> Le sam. 28 août 2021 à 14:36, sebb <seb...@gmail.com> a écrit :
> >
> > On Sat, 28 Aug 2021 at 13:25, Gilles Sadowski <gillese...@gmail.com> wrote:
> > >
> > > Hello.
> > >
> > > What would be a sufficient condition for removing the "AccurateMath"
> > > (previously named "FastMath") in the upcoming major release?
> > >
> > > I'd think that the following should hold (when running on JRE 11):
> >
> > Math currently targets JRE 1.8+, so why assume JRE 11?
>
> A corollary question is whether we should support usage of the
> upcoming release on Java 8, even if the library stays source
> compatible with Java 8 (to allow such usage).

That is a separate discussion.

> Dropping "FastMath" would mean that the library and applications
> using it can benefit from the performance enhancements of Java
> 11 (if the conditions below hold).

Huh?
Why would it be necessary to drop FastMath to benefit from using Java 11?

> > >  * no "AccurateMath" function is faster, and
> > >  * no "AccurateMath" function is more accurate.
> >
> > Otherwise the conditions are OK.
> >
> > Note: the class(es) should be deprecated for one or two releases first.
>
> The upcoming release (4.0) is a major one.  Users would anyways
> have to adapt their code to the package's name change (and to the
> class name change too in this case); doing that would not be any
> simpler than searching calls to "FastMath" and replacing them with
> calls to "Math".
>
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to