[java]: encapsulate additionalCommands with getter method

[navin772]

User description

Thanks for contributing to Selenium!
A PR well described will help maintainers to quickly review and merge it

Before submitting your PR, please check our contributing guidelines.
Avoid large PRs, help reviewers by making them as simple and short as possible.

Description

Solves #14811
Changed the scope of additionalCommands under HttpCommandExecutor to protected

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

PR Type

Bug fix

---

Description

• Changed the scope of the additionalCommands variable in the HttpCommandExecutor class from private to protected.
• This modification addresses issue [🚀 Feature]: Better compatibility with Appium #2 #14811 by allowing subclasses to access and modify the additionalCommands map.

---

Changes walkthrough 📝

	Relevant files
Bug fix	HttpCommandExecutor.java Change scope of `additionalCommands` to `protected`            java/src/org/openqa/selenium/remote/HttpCommandExecutor.java Changed the access modifier of additionalCommands from private to protected. This change allows subclasses to access additionalCommands. +1/-1

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Access Control Changing field visibility from private to protected exposes internal implementation details. Verify that this change doesn't break encapsulation principles or expose sensitive command information to untrusted subclasses.

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
General	Restrict access modifier of a field to maintain proper encapsulation while preserving inheritance functionality The client field is declared as public but should be protected since it's part of the internal implementation. Change its access modifier to protected to maintain encapsulation while still allowing subclass access. java/src/org/openqa/selenium/remote/HttpCommandExecutor.java [47] -public final HttpClient client; +protected final HttpClient client; Apply this suggestion Suggestion importance[1-10]: 7 Why: The suggestion correctly identifies a potential encapsulation issue. Making the 'client' field protected instead of public aligns with good OOP practices by restricting access while still allowing inheritance functionality, similar to how other fields in the class are handled.	7

💡 Need additional feedback ? start a PR chat

[VietND96]

If it is possible, try to add unit test also.

[diemol]

@mykola-mokhnach do you think you'd need a method to remove commands at any point in the future?

[mykola-mokhnach]

@mykola-mokhnach do you think you'd need a method to remove commands at any point in the future?

I did not think about such far future :)
Maybe not...