Limit Commons Lang 3 to test scope

[basil]

Commons BeanUtils 1 does not depend on Commons Lang 3, but Commons BeanUtils 2 currently does. This poses a challenge for us because, while we are fine with depending on Commons BeanUtils, we prefer to avoid a dependency on Commons Lang. This is due to our architecture, which exposes dependencies to all third-party plugins.

Since Commons BeanUtils 2 is still in milestone status and has not yet been released, there is an opportunity to address this. This pull request modifies a few minor instances in src/main to use native Java Platform functionality instead of Commons Lang 3. The use of Commons Lang 3 in tests remains unchanged.

To test this change, I ran mvn clean verify. CC @ppkarwasz

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request.
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• 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.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• 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.

[ppkarwasz]

Hi @basil,

This is due to our architecture, which exposes dependencies to all third-party plugins.

Could you elaborate on where exactly this causes issues in your case?

The question of how many call sites justify adding a dependency (like commons-lang3) is a recurring and somewhat contentious topic within the Commons PMC. Personally, I agree that this particular dependency may not be necessary here, but ultimately it will require broader discussion and consensus within the team. cc/ @garydgregory

[garydgregory]

Hello all,

I don't think we need to merge this PR as it is stated as a preference and doesn't fix a bug. I also really don't want to not set a precedent to inline calls from dependencies. I thought OSGi and JPMS were supposed to deal with these types of ideas...

[basil]

I don't think we need to merge this PR as it […] doesn't fix a bug.

@garydgregory The original code contains a bug due to an unnecessary try-catch block for a SecurityException in SystemProperties#getJavaSpecificationVersion. This method is documented to return null in cases where a SecurityException might occur, making the try-catch block redundant and potentially misleading, as it suggests a SecurityException could be thrown when it will not. This PR fixes the bug by replacing the call to SystemProperties#getJavaSpecificationVersion with System.getProperty("java.specification.version"), which can throw a SecurityException as documented. This ensures the try-catch block is necessary and correctly handles the potential exception.

[basil]

@garydgregory Any update on this PR?

[ppkarwasz]

Hi @basil,

After reviewing this PR more closely, I’m not sure code reuse is even a strong argument against accepting it:

• One call site can be delegated entirely to Introspector.
• One call site has been effectively dead code since Java 4.
• One call site should probably perform lowercasing with an explicitly specified Locale.

[garydgregory]

-1: version 2 will depend on Lang for other runtime calls like MethodUtils.

[basil]

-1

@garydgregory If you have vetoed this PR, and there is no clear action item that would cause you to withdraw the veto, then should the PR be closed?