Skip to content

Use Objects.equals in translating ==#25314

Open
lrytz wants to merge 1 commit intoscala:mainfrom
lrytz:objects-equals
Open

Use Objects.equals in translating ==#25314
lrytz wants to merge 1 commit intoscala:mainfrom
lrytz:objects-equals

Conversation

@lrytz
Copy link
Member

@lrytz lrytz commented Feb 19, 2026

When translating == for reference types, the backend now uses Objects.equals instead of a null check and Object.equals.

One motivation is to remove avoidable synthetic branches/instructions for null data that are interpreted as uncovered code by JaCoCo etc.

It also reduces bytecode size.

We recently started using Objects.hashCode for the synthetic hashCode implementation in value classes.

Note that if either operand is potentially Number or Character, the backend delegates to BoxesRuntime.equals which handles Scala semantic edge cases for boxed primitives. This change does not affect that path.

Forward-port of scala/scala#11212

When translating `==` for reference types, the backend now uses
`Objects.equals` instead of a null check and `Object.equals`.

One motivation is to remove avoidable synthetic branches/instructions
for null data that are interpreted as uncovered code by JaCoCo etc.

It also reduces bytecode size.

We recently started using `Objects.hashCode` for the synthetic `hashCode`
implementation in value classes.

Note that if either operand is potentially `Number` or `Character`, the
backend delegates to `BoxesRuntime.equals` which handles Scala semantic
edge cases for boxed primitives. This change does not affect that path.

Forward-port of Scala 2 PR 11212
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Comments