<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>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.</p>
<p>Longer answer: see around slide 62 of<br>
<br>
"Contributing to OpenJDK: Participating in stewardship for the
long-term"<br>
<a class="moz-txt-link-freetext" href="https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf">https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-06-13/Contributing_to_OpenJDK_2023_04_12.pdf</a></p>
<p>Recording of the talk:
<a class="moz-txt-link-freetext" href="https://jcp.org/aboutJava/communityprocess/media/Public-EC-Meeting-June-2023.mp4">https://jcp.org/aboutJava/communityprocess/media/Public-EC-Meeting-June-2023.mp4</a><br>
<br>
HTH,<br>
</p>
<p>-Joe<br>
</p>
<div class="moz-cite-prefix">On 12/2/2024 9:19 PM, David Alayachew
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA9v-_PzTtRvkrhDKpgGO_gdmmJfHCdrh6NB82sygwviOeM=PQ@mail.gmail.com">
<div dir="auto">
<div>Thanks Joe.
<div dir="auto"><br>
</div>
<div dir="auto">Ok, so deprecations are basically a
super-regulated way to achieve a certain amount of backwards
incompatibility without breaking Java's core promise?</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Dec 2, 2024,
11:17 PM Joseph D. Darcy <<a href="mailto:joe.darcy@oracle.com" target="_blank" rel="noreferrer" moz-do-not-send="true" class="moz-txt-link-freetext">joe.darcy@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>There is a policy for managing deprecations:<br>
<br>
<a href="https://openjdk.org/jeps/277" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://openjdk.org/jeps/277</a><br>
<br>
Most the incompatible step, actually removing the
declaration in question, if it occurs at all, would
only occur after a warning period.<br>
<br>
HTH,<br>
</p>
<p>-Joe<br>
</p>
<div>On 12/2/2024 6:24 PM, David Alayachew wrote:<br>
</div>
<blockquote type="cite">
<p dir="ltr">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.</p>
<p dir="ltr">Also, wouldn't this qualify as a
backwards-incompatible change?</p>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Dec 2,
2024, 8:32 PM Joseph D. Darcy <<a href="mailto:joe.darcy@oracle.com" rel="noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">joe.darcy@oracle.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<p>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.<br>
</p>
<p>-Joe<br>
</p>
<div>On 12/2/2024 3:17 PM, Éamonn McManus wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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 <a href="https://urldefense.com/v3/__https://guava.dev/releases/snapshot-jre/api/docs/com/google/common/primitives/Doubles.html__;!!ACWV5N9M2RV99hQ!PaT7OCGf7CncxF09sKLO4p39KkraAtzbBbvnOR8O8r2x6Z0e1zru8BqG9LGItQtyxAQkQc8A12DanwunC_ZxkNGO$" rel="noreferrer noreferrer noreferrer" target="_blank" moz-do-not-send="true">Doubles</a> 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.
<div><br>
</div>
<div>A few JDK and JavaFX bugs show that
Google engineers are not the only ones to
be confused by this:</div>
<div><a href="https://bugs.openjdk.org/browse/JDK-4218647" rel="noreferrer noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-4218647</a></div>
<div><a href="https://bugs.openjdk.org/browse/JDK-8092698" rel="noreferrer noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8092698</a></div>
<div><a href="https://bugs.openjdk.org/browse/JDK-8156186" rel="noreferrer noreferrer noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8156186</a></div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>