Deprecate Double.MIN_VALUE?

[Louis Wasserman]

I think we certainly presumed this would be a deprecation, not a deletion.

To add some more data, from taking a sample, at least a third of usages in
Google's codebase were using it incorrectly in the way we've described.

On Mon, Dec 2, 2024 at 9:20 PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Thanks Joe.
>
> Ok, so deprecations are basically a super-regulated way to achieve a
> certain amount of backwards incompatibility without breaking Java's core
> promise?
>
>
> On Mon, Dec 2, 2024, 11:17 PM Joseph D. Darcy <joe.darcy at oracle.com>
> wrote:
>
>> There is a policy for managing deprecations:
>>
>>    https://openjdk.org/jeps/277
>>
>> Most the incompatible step, actually removing the declaration in
>> question, if it occurs at all, would only occur after a warning period.
>>
>> HTH,
>>
>> -Joe
>> On 12/2/2024 6:24 PM, David Alayachew wrote:
>>
>> 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.darcy at 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://urldefense.com/v3/__https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/primitives/Doubles.html__;!!ACWV5N9M2RV99hQ!PaT7OCGf7CncxF09sKLO4p39KkraAtzbBbvnOR8O8r2x6Z0e1zru8BqG9LGItQtyxAQkQc8A12DanwunC_ZxkNGO$> 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.
>>>
>>>

-- 
Louis Wasserman (he/they)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241203/c449ef84/attachment-0001.htm>