inponomarev opened a new pull request, #1591:
URL: https://github.com/apache/commons-lang/pull/1591

   This issue is tracked in https://issues.apache.org/jira/browse/LANG-1818
   
   ## Problem
   
   `ClassUtils.getShortClassName(Class)` currently delegates to the 
string-based `getShortClassName(String)` using `cls.getName()`.
   
   The string-based method is inherently heuristic and, as documented, cannot 
reliably distinguish package names, outer classes, and inner classes when given 
only a JVM binary name. As a result, any `$` character is treated as an 
inner-class separator, even when `$` is part of a legitimate Java identifier.
   
   While this limitation is unavoidable for `getShortClassName(String)`, it 
should not apply to `getShortClassName(Class)`, where full reflective metadata 
is available.
   
   ## Changes
   
   * Reimplemented `getShortClassName(Class)` (and by extension 
`getShortClassName(Object))` to use `Class` metadata instead of parsing 
`Class.getName()`.
   * Correctly preserves `$` characters that are part of actual class 
identifiers (top-level classes, member classes, and nested member classes).
   * Maintains existing behavior for local and anonymous classes by falling 
back to the string-based logic, preserving compiler-generated ordinal naming 
expected by existing tests.
   * Leaves getShortClassName(String) and getShortCanonicalName(String) 
unchanged, along with their documented limitations.
   
   ## Examples (fixed behaviour)
   
   ```java
   class $trange {}
   class Pa$$word {}
   
   class Outer {
       class $Inner {}
       class Inner {
           class Ne$ted {}
       }
   }
   
   ClassUtils.getShortClassName($trange.class)        // "$trange"
   ClassUtils.getShortClassName(Pa$$word.class)       // "Pa$$word"
   ClassUtils.getShortClassName(Outer.$Inner.class)   // "Outer.$Inner"
   ClassUtils.getShortClassName(Outer.Inner.Ne$ted.class) // 
"Outer.Inner.Ne$ted"
   
   ```
   
   ## Rationale
   
   The ambiguity of $ in JVM binary names is explicitly documented for the 
string-based APIs. However, when a Class<?> instance is available, that 
ambiguity disappears. This change improves correctness for the Class-based 
overloads without altering or reinterpreting the behavior of the string-based 
methods.


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

Reply via email to