In addition to the case of primitive values, I mentioned 3 concerns regarding the cases when one of the operands is null and the other is not here.

In addition to the case of primitive values, I mentioned 3 concerns regarding the cases when one of the operands is null and the other is not here.

Checking that an object is not null before invoking a method on that object is a preventative or protective measure. Your software evolves and what is true today may not be true tomorrow so this check is a protective measure.

Writing good software is like writing poetry: There are both science and art in it. Please spend some time to understand my concern(s) before replying, instead of blindly accepting any machine-proposed modifications.

Let's take the last proposed change as an example:

In the original code

if (seqClusterId.get(i) != seqClusterId.get(j)) {
    return false;
}

The if condition will test whether seqClusterId.get(i) (the 1st expression) != (is not equal to) seqClusterId.get(j) (the 2nd expression).
That is true in these 3 cases

• 1st expression is null and 2nd expression is not null
• 1st expression is not null and 2nd expression is null
• 1st expression is not null and 2nd expression is not null and their values and not equal

Well,
What about the proposed update?

if (seqClusterId.get(i) != null && !seqClusterId.get(i).equals(seqClusterId.get(j))) {
    return false;
}

It will evaluate to true in these 2 cases only:

• 1st expression is not null and 2nd expression is null
• 1st expression is not null and 2nd expression is not null and their values are not equal

but it will evaluate to false in the case

• 1st expression is null and 2nd expression is not null

which is a change of behavior.

You are right.

Thank you for your relevant analysis of our proposal. We are going to take your comments into consideration and adapt the way our solution works to test equality using Objects.equals method that addresses the use cases you have identified.

@tmrpavan Your account looks very fresh (joined GitHub 2 weeks ago). May you please introduce yourself?
@josemduarte Is approving pull requests available to anyone, or only to people with certain privileges (e.g. write access)?

Hello @aalhossary,

You are right I am new to open source project. I am Java Backed Developer with around 3 years of experience. I was going through the PR. I felt the changes are valid. So I approved.

I think approve option is available for all.

Hello @aalhossary,

I would like to contribute to the project. Please let me know if any issue ore features that i can work on it.

Why Avoid Comparing Integers in Java using == Operator? Example

Read more: https://javarevisited.blogspot.com/2010/10/what-is-problem-while-using-in.html#ixzz7yTZDXO94https://javarevisited.blogspot.com/2010/10/what-is-problem-while-using-in.html#axzz7yTYv7igN

Hi @tmrpavan!
Welcome. We always welcome new committers.

as you found that the changes are valid, but there was an ongoing discussion about it, you should have joined the discussion and add a comment instead of rushing into doing the actions.
I advise you to read the discussion on THE CURRENT page (especially this comment).

@aalhossary Please see this PR #1060

We can use Objects.equals(seqClusterId.get(i), seqClusterId.get(j) to full fill your needs.

Please see the below image and article to know why we can not user == or != or objects.

https://javarevisited.blogspot.com/2010/10/what-is-problem-while-using-in.html#ixzz7yTZDXO94https://javarevisited.blogspot.com/2010/10/what-is-problem-while-using-in.html#axzz7yTYv7igN

Closing in favour of #1060