On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> `equals` and `hashCode` in the java.text area.
>>
>> * Some changes to `equals` and `hashCode` are refactoring rather than
>> modernization. Such changes can be
On Mon, 17 Jul 2023 23:33:37 GMT, Pavel Rappo wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> `equals` and `hashCode` in the java.text area.
>>
>> * Some changes to `equals` and `hashCode` are refactoring rather than
>> modernization. Such changes can be
On Wed, 12 Jul 2023 22:26:14 GMT, John R Rose wrote:
> Yes, it would be, because `rp` has a statically observable type,
> `BigInteger`. And that observation will flow across the call to the helper
> method.
After all, my mental model is incorrect; sigh.
I read your write-up as though once we
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as trivial as rearranging, adding, or
> commenting checks.
On Fri, 7 Jul 2023 00:39:20 GMT, Pavel Rappo wrote:
>> Thanks @rose00 for the writeup and @pavelrappo for asking pertinent followup
>> questions.
>>
>> For me the issue here is that there is a bunch of lore about avoiding
>> `Objects::equals` and it's embodied in comments like this:
>>
>>> NB
On Thu, 6 Jul 2023 23:38:01 GMT, Stuart Marks wrote:
> For me the issue here is that there is a bunch of lore about avoiding
> `Objects::equals` and it's embodied in comments like this:
>
> > NB: Do not replace with Object.equals until JDK-8015417 is resolved.
>
> These comments are almost exa
On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose wrote:
>>> Hmm, I think that issue refers to code that have explicit non-Object
>>> parameter types (like `X::equals(Object)boolean` in the issue's sample).
>>> This method already have both arguments as `Object`, so I don't think
>>> there's any ty
On Thu, 6 Jul 2023 14:46:59 GMT, Pavel Rappo wrote:
>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and
>> remove the `valuesMatch` method as unnecessary.
>
>> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and
>> remove the `valuesMatch` method
On Wed, 5 Jul 2023 15:33:13 GMT, Roger Riggs wrote:
> I'd suggest replacing the calls to `valuesMatch` with `Objects.equals` and
> remove the `valuesMatch` method as unnecessary.
I'll do something about them soon, Roger. But first I need to understand
JDK-8015417 better, as it also affects oth
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as trivial as rearranging, adding, or
> commenting checks.
On Wed, 5 Jul 2023 17:44:52 GMT, Roger Riggs wrote:
>> You are right, I have no stats. Performance-wise, it's already better than
>> what was there before. Before, there was no short-circuit check. But I can
>> go either way; I don't have a strong opinion.
>>
>> Reusing superclass' equals is n
On Wed, 5 Jul 2023 17:39:49 GMT, Roger Riggs wrote:
>> Do you mean we could use `obj instanceof DecimalFormat other` in front of
>> that 30-line `&&` expression, or that we could collapse the list to exactly
>> what you wrote?
>>
>> Separately, `super.equals` already performs the class check;
On Wed, 5 Jul 2023 16:39:58 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
>>
>>> 2362: return true;
>>> 2363: }
>>> 2364:
>>
>> Moving this before the `super.equals` call performance-wise would favor the
>> equals cas
On Wed, 5 Jul 2023 16:27:38 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/text/DecimalFormat.java line 2930:
>>
>>> 2928: DecimalFormat other = (DecimalFormat) obj;
>>> 2929: return ((posPrefixPattern == other.posPrefixPattern &&
>>> 2930: positiveP
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as trivial as rearranging, adding, or
> commenting checks.
On Wed, 5 Jul 2023 15:46:56 GMT, Roger Riggs wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/CompactNumberFormat.java line 2364:
>
>> 2362:
On Wed, 5 Jul 2023 15:47:56 GMT, Roger Riggs wrote:
>> Pavel Rappo has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Adhere to surrounding code style
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2926:
>
>> 2924:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as trivial as rearranging, adding, or
> commenting checks.
On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as tr
On Tue, 4 Jul 2023 22:03:58 GMT, John R Rose wrote:
>>> Hmm, I think that issue refers to code that have explicit non-Object
>>> parameter types (like `X::equals(Object)boolean` in the issue's sample).
>>> This method already have both arguments as `Object`, so I don't think
>>> there's any ty
On Tue, 4 Jul 2023 01:01:22 GMT, Pavel Rappo wrote:
>> Hmm, I think that issue refers to code that have explicit non-Object
>> parameter types (like `X::equals(Object)boolean` in the issue's sample).
>> This method already have both arguments as `Object`, so I don't think
>> there's any type-s
On Tue, 4 Jul 2023 00:40:14 GMT, Chen Liang wrote:
> Hmm, I think that issue refers to code that have explicit non-Object
> parameter types (like `X::equals(Object)boolean` in the issue's sample). This
> method already have both arguments as `Object`, so I don't think there's any
> type-specif
On Tue, 4 Jul 2023 00:22:02 GMT, Pavel Rappo wrote:
>> src/java.base/share/classes/java/text/AttributedString.java line 661:
>>
>>> 659:
>>> 660: // returns whether the two objects are either both null or equal
>>> 661: private static boolean valuesMatch(Object value1, Object value2) {
On Mon, 3 Jul 2023 13:22:27 GMT, Chen Liang wrote:
>> Please review this PR to use modern APIs and language features to simplify
>> `equals` and `hashCode` in the java.text area.
>>
>> * Some changes to `equals` and `hashCode` are refactoring rather than
>> modernization. Such changes can be a
On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as tr
On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as tr
On Mon, 3 Jul 2023 11:12:32 GMT, Pavel Rappo wrote:
> Please review this PR to use modern APIs and language features to simplify
> `equals` and `hashCode` in the java.text area.
>
> * Some changes to `equals` and `hashCode` are refactoring rather than
> modernization. Such changes can be as tr
27 matches
Mail list logo
