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 <davidalayac...@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.da...@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.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://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)
