[🐛 Bug][Java]: Newly created instances of RemoteWebElement throw NPE on hashCode invocation

[mykola-mokhnach]

What happened?

After running the below code snippet a NPE is thrown.

This happens because the id property of the instance is unset (e.g. null) initially unless setId is called and hashCode is overridden as

  @Override
  public int hashCode() {
    return id.hashCode();
  }

This also means that newly created instances of RemoteWebElement cannot be compared or put into a map.

Expected result:
The hashCode implementation must never throw an exception.

How can we reproduce the issue?

WebElement we = new RemoteWebElement();
  int hash = we.hashCode();

Relevant log output

java.lang.NullPointerException
	at org.openqa.selenium.remote.RemoteWebElement.hashCode(RemoteWebElement.java:298)

### Operating System

all

### Selenium version

latest

### What are the browser(s) and version(s) where you see this issue?

all

### What are the browser driver(s) and version(s) where you see this issue?

not applicable

### Are you using Selenium Grid?

no

[github-actions]

@mykola-mokhnach, thank you for creating this issue. We will troubleshoot it as soon as we can.

---

Info for maintainers

Triage this issue by using labels.

If information is missing, add a helpful comment and then I-issue-template label.

If the issue is a question, add the I-question label.

If the issue is valid but there is no time to troubleshoot it, consider adding the help wanted label.

If the issue requires changes or fixes from an external project (e.g., ChromeDriver, GeckoDriver, MSEdgeDriver, W3C), add the applicable G-* label, and it will provide the correct link and auto-close the issue.

After troubleshooting the issue, please add the R-awaiting answer label.

Thank you!

[asolntsev]

@mykola-mokhnach But why should anyone create new RemoteWebElement()? This is not how RemoteWebElement is supposed to be used. RemoteWebElement should be received from WebDriver.

I would suggest making default RemoteWebElement constructor private.

[mykola-mokhnach]

My case is a fairly complicated one. I was working on page-object-related stuff and it was necessary to keep objects in a hash map before they get initialized (since lazy initialization strategy is applied there). This is impossible though as both Set and HashMap keys call hashCode implicitly on each item there.

[mykola-mokhnach]

https://github.com/appium/java-client/blob/16763424b5f8f729739ce8a2bf8c8eed9c6177d6/src/main/java/io/appium/java_client/proxy/ProxyListenersContainer.java#L38

[asolntsev]

@mykola-mokhnach But what should hashCode return for an empty (not-yet-initialized) web element?
In other words, how to fix this issue?

I guess you should rather wrap RemoteWebElement to some custom objects (with their own hashCode logic) if you really need to hold them in Map.

[mykola-mokhnach]

But what should hashCode return for an empty (not-yet-initialized) web element?
In other words, how to fix this issue?

I assume it should just call the original Object's hashCode method, so, this code holds false as a result:

      RemoteWebElement o1 = new RemoteWebElement();
      RemoteWebElement o2 = new RemoteWebElement();

      System.out.println(o1.equals(o2));

I guess you should rather wrap RemoteWebElement to some custom objects (with their own hashCode logic) if you really need to hold them in Map.

Unfortunately I did not find a good way to solve that yet because, like I said, the stuff is pretty complicated (part of page object implementation lies in selenium and the other part in the appium's java client). I would be happy to accept any better solution if anyone could propose one.

Eventually, it does not seem right anyway an object would ever throw an exception on hashCode invocation.

[diemol]

I would call the original hashCode method if id is not set. If id is set, then call that one.
Would that be OK for you, @mykola-mokhnach?

[mykola-mokhnach]

I would call the original hashCode method if id is not set. If id is set, then call that one.
Would that be OK for you, @mykola-mokhnach?

yes, totally

[diemol]

Pushed the change. I am trying to get 4.12 ready, but you can try this tomorrow with the Nightly https://www.selenium.dev/downloads/#nightly

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.