dhruvaggarwal2000 opened a new pull request, #1714:
URL: https://github.com/apache/commons-lang/pull/1714
Repro: `BooleanUtils.and(Boolean.TRUE, Boolean.FALSE)` — the call form shown
in the `and(Boolean...)` Javadoc — fails to compile on Java 8 with `error:
reference to and is ambiguous, both method and(boolean...) and method
and(Boolean...) match`. The same ambiguity affects the loose-argument form of
`or`, `xor`, and `oneHot`.
Cause: both overloads are variable-arity, so neither is applicable in JLS
phase 1 or 2; in phase 3 both apply and neither is more specific (`boolean` and
`Boolean` are not subtype-related, and the more-specific rule does not consider
autoboxing).
Fix: convert the primitive overloads from `boolean...` to `boolean[]` for
`and`, `or`, `xor`, `oneHot`, leaving the `Boolean...` overloads untouched.
With only one variable-arity overload remaining, loose-argument calls resolve
unambiguously to `Boolean...` via autoboxing. Direction chosen over the mirror
fix (`Boolean...` → `Boolean[]`) because routing loose-arg calls through the
boxed overload preserves the documented null-tolerance contract —
`and((Boolean) null, Boolean.TRUE)` returns `Boolean.FALSE` rather than NPE-ing
on unbox.
<details>
<summary><b>Compatibility report</b> (<code>mvn package japicmp:cmp</code>
against 3.20.0)</summary>
### `org.apache.commons.lang3.BooleanUtils`
- [X] Binary-compatible
- [ ] Source-compatible
- [X] Serialization-compatible
| Status | Modifiers | Type | Name | Extends | JDK |
Serialization | Compatibility Changes |
|----------|-----------|-------|----------------|------------|-------|-------------------|-----------------------|
| Modified | `public` | Class | `BooleanUtils` | [`Object`] | JDK 8 | Not
serializable | No changes |
#### Methods
| Status | Modifiers | Generics | Type | Method
| Annotations | Throws | Compatibility Changes
|
|----------|-------------------|----------|-----------|---------------------------------------------------|-------------|--------|----------------------------|
| Modified | `static` `public` | | `boolean` |
`and`(~~`boolean...`~~ → **`boolean[]`**) | | |
Method no longer varargs |
| Modified | `static` `public` | | `boolean` |
`oneHot`(~~`boolean...`~~ → **`boolean[]`**) | | |
Method no longer varargs |
| Modified | `static` `public` | | `boolean` |
`or`(~~`boolean...`~~ → **`boolean[]`**) | | |
Method no longer varargs |
| Modified | `static` `public` | | `boolean` |
`xor`(~~`boolean...`~~ → **`boolean[]`**) | | |
Method no longer varargs |
Source-compat is flagged solely due to the `ACC_VARARGS` flag removal. In
practice no real-world caller is expected to lose the ability to compile —
loose-argument calls are absorbed by the `Boolean...` overload via autoboxing,
and this fix **adds** more compilable forms than it removes (the previously
ambiguous calls now compile). Callers that need the primitive path explicitly
can continue to use the array form: `BooleanUtils.and(new boolean[]{true,
false})`.
</details>
- [x] Read the [contribution guidelines](CONTRIBUTING.md) for this project.
- [x] Read the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) if you use
Artificial Intelligence (AI).
- [x] AI used: Claude (Anthropic, `claude-opus-4-7`) via the Claude Code
CLI. Assisted with JLS analysis, Javadoc rewrites, and the `or`/`xor`/`oneHot`
test additions (the `and` tests were written by me directly). I reviewed every
line, validated the truth tables, and ran the local build. Per ASF guidance:
Anthropic's terms place no restrictions inconsistent with the OSD; no
third-party material is reproduced in the output.
- [x] Run a successful build using the default
[Maven](https://maven.apache.org/) goal with `mvn`; that's `mvn` on the command
line by itself.
- [x] Write unit tests that match behavioral changes, where the tests fail
if the changes to the runtime are not applied. This may not always be possible,
but it is a best practice.
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Each commit in the pull request should have a meaningful subject line
and body. Note that a maintainer may squash commits during the merge process.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
