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 <[email protected]>
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
<[email protected]> 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.
