Improve type safety of CollectionUtils.toTreeSet

[skt-shinyruo]

What is the purpose of the change?

GitHub_issue: Fixes #16297

This pull request improves the type safety of CollectionUtils.toTreeSet.

The existing single-argument overload accepted any Set<T>, but its implementation delegates to TreeSet, which requires naturally comparable elements unless a comparator is provided. The updated signature makes that requirement explicit at compile time:

public static <T extends Comparable<? super T>> Set<T> toTreeSet(Set<T> set)

This pull request also adds a comparator-based overload for custom ordering and non-Comparable element types:

public static <T> Set<T> toTreeSet(Set<T> set, Comparator<? super T> comparator)

For non-null empty inputs, the comparator overload returns an empty TreeSet that preserves the provided comparator.

Verification:

• mvn -pl dubbo-common -Dtest=CollectionUtilsTest test
• git diff --check

Checklist

• Make sure there is a GitHub_issue field for the change.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Make sure gitHub actions can pass. Why the workflow is failing and how to fix it?

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.78%. Comparing base (b65573e) to head (630215f).
⚠️ Report is 2 commits behind head on 3.3.

Additional details and impacted files

@@             Coverage Diff              @@
##                3.3   #16306      +/-   ##
============================================
- Coverage     60.80%   60.78%   -0.03%     
+ Complexity    11766    11764       -2     
============================================
  Files          1953     1953              
  Lines         89188    89201      +13     
  Branches      13454    13457       +3     
============================================
- Hits          54235    54218      -17     
- Misses        29391    29413      +22     
- Partials       5562     5570       +8     

Flag	Coverage Δ
integration-tests-java21	32.11% <0.00%> (-0.02%)	⬇️
integration-tests-java8	32.24% <0.00%> (-0.01%)	⬇️
samples-tests-java21	32.14% <0.00%> (-0.04%)	⬇️
samples-tests-java8	29.83% <0.00%> (-0.03%)	⬇️
unit-tests-java11	59.03% <100.00%> (-0.02%)	⬇️
unit-tests-java17	58.52% <100.00%> (-0.01%)	⬇️
unit-tests-java21	58.51% <100.00%> (+0.02%)	⬆️
unit-tests-java25	58.42% <100.00%> (-0.06%)	⬇️
unit-tests-java8	59.03% <100.00%> (+0.02%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zrlw]

LGTM

[RainYuY]

Why did it become null instead of checking for empty?

[skt-shinyruo]

The null check is intentional here. For this comparator overload, null and empty inputs need different handling: null keeps the existing null-return behavior, while an empty non-null set should still return an empty TreeSet initialized with the provided comparator. Returning the original set from isEmpty(set) would lose that comparator. The addAll call is a no-op for an empty set.

I also added a null-input test for this overload in 630215f.