Deprecate Double.MIN_VALUE?

[Joseph D. Darcy]

Short answer: deprecation is a way to mark an API element such that it 
generates warnings when used. One variant of deprecation indicates the 
API element is intended to be removed in some future, unspecified, release.

Longer answer: see around slide 62 of

"Contributing to OpenJDK: Participating in stewardship for the long-term"
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf

Recording of the talk: 
https://jcp.org/aboutJava/communityprocess/media/Public-EC-Meeting-June-2023.mp4

HTH,

-Joe

On 12/2/2024 9:19 PM, David Alayachew 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.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241203/e29dc5dd/attachment.htm>