As a data point of one, we use all of the abovementioned constants
regularly for my day job. In total, we have maybe a couple thousand
instances of that constant being referenced. Ripping out wouldn't be too
painful as long as I was told exactly what the replacements were, but I
wouldn't be thrilled with it.
Also, wouldn't this qualify as a backwards-incompatible change?
On Mon, Dec 2, 2024, 8:32 PM Joseph D. Darcy <joe.da...@oracle.com> wrote:
> Hmm. I understand the motivation here and the asymmetry with the integral
> types, but on the whole I don't think deprecating {Float, Double}.MIN_VALUE
> and recommending use of a differently-named field with the same value would
> be a net improvement.
>
> -Joe
> On 12/2/2024 3:17 PM, Éamonn McManus wrote:
>
> At Google, we've had several issues over the years relating to
> Double.MIN_VALUE. People have not unreasonably supposed that
> Double.MIN_VALUE has the same relationship to Double.MAX_VALUE as
> Integer.MIN_VALUE has to Integer.MAX_VALUE. So they think that
> Double.MIN_VALUE is the (finite) negative number of largest magnitude,
> rather than the positive number of smallest magnitude. We're currently
> thinking of adding a constant MIN_POSITIVE_VALUE to Guava's Doubles
> <https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/primitives/Doubles.html>
> class
> and having static analysis that suggests using that instead of
> Double.MIN_VALUE, if that is indeed what you meant, or of course using
> -Double.MAX_VALUE if *that* is what you meant.
>
> A few JDK and JavaFX bugs show that Google engineers are not the only ones
> to be confused by this:
> https://bugs.openjdk.org/browse/JDK-4218647
> https://bugs.openjdk.org/browse/JDK-8092698
> https://bugs.openjdk.org/browse/JDK-8156186
>
> So we also wonder if it would make sense to deprecate Double.MIN_VALUE
> itself and introduce Double.MIN_POSITIVE_VALUE with the same meaning.
> Obviously the same thing would apply to Float.
>
>
