codingkiddo opened a new issue, #16297:
URL: https://github.com/apache/dubbo/issues/16297

   ### Pre-check
   
   - [x] I am sure that all the content I provide is in English.
   
   
   ### Search before asking
   
   - [x] I had searched in the 
[issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no 
similar feature requirement.
   
   
   ### Apache Dubbo Component
   
   Java SDK (apache/dubbo)
   
   ### Descriptions
   
   ### Motivation
   
   `CollectionUtils.toTreeSet` currently accepts any `Set<T>`:
   
   ```java
   public static <T> Set<T> toTreeSet(Set<T> set)
   ```
   
   When the input set is not empty and is not already a `TreeSet`, the method 
creates a new `TreeSet`:
   
   ```java
   set = new TreeSet<>(set);
   ```
   
   This relies on natural ordering. If the elements are not mutually 
comparable, the code compiles successfully but may fail at runtime with 
`ClassCastException`.
   
   This is similar to the recently improved `CollectionUtils.sort` method, 
where the generic signature was changed to require comparable elements.
   
   ### Current behavior
   
   The current method allows code like this to compile:
   
   ```java
   class Item {
   }
   
   Set<Item> items = new HashSet<>();
   items.add(new Item());
   
   CollectionUtils.toTreeSet(items);
   ```
   
   However, converting this set to a `TreeSet` may fail at runtime because 
`Item` does not implement `Comparable`.
   
   ### Proposed improvement
   
   One possible improvement is to make the natural-ordering requirement 
explicit in the method signature:
   
   ```java
   public static <T extends Comparable<? super T>> Set<T> toTreeSet(Set<T> set)
   ```
   
   This would catch invalid usages at compile time instead of allowing them to 
fail at runtime.
   
   ### Compatibility note
   
   This may be source-incompatible for callers that currently pass 
non-comparable element types.
   
   There is also one subtle case: an existing `TreeSet` can use a custom 
comparator even when its element type does not implement `Comparable`.
   
   For example:
   
   ```java
   class Item {
       private final String name;
   
       Item(String name) {
           this.name = name;
       }
   
       String name() {
           return name;
       }
   }
   
   TreeSet<Item> items = new TreeSet<>(Comparator.comparing(Item::name));
   items.add(new Item("b"));
   items.add(new Item("a"));
   
   CollectionUtils.toTreeSet(items);
   ```
   
   In this case, the existing `TreeSet` is valid because it already has a 
comparator, even though `Item` does not implement `Comparable`.
   
   Because of this compatibility concern, I would like maintainer feedback 
before opening a PR.
   
   ### Possible alternatives
   
   #### Option 1: Add a comparable bound to the existing method
   
   ```java
   public static <T extends Comparable<? super T>> Set<T> toTreeSet(Set<T> set)
   ```
   
   This makes the natural-ordering requirement explicit and catches invalid 
usages at compile time.
   
   #### Option 2: Keep the existing method and add a comparator-based overload
   
   ```java
   public static <T> Set<T> toTreeSet(Set<T> set, Comparator<? super T> 
comparator)
   ```
   
   This would allow callers to safely convert sets of non-comparable elements 
by providing an ordering.
   
   ### Expected benefit
   
   - Improves type safety
   - Makes the natural-ordering requirement explicit
   - Avoids hidden runtime `ClassCastException` for non-comparable elements
   - Provides a possible path for comparator-based conversion
   - Keeps the discussion open for maintainers to choose the preferred 
compatibility approach
   
   I can work on this once maintainers confirm the preferred direction.
   
   ### Related issues
   
   _No response_
   
   ### Are you willing to submit a pull request to fix on your own?
   
   - [x] Yes I am willing to submit a pull request on my own!
   
   ### Code of Conduct
   
   - [x] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to