Commons Lang
  1. Commons Lang
  2. LANG-298

ClassUtils.getShortClassName and ClassUtils.getPackageName and class of array

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.2
    • Fix Version/s: 2.4
    • Component/s: None
    • Labels:
      None
    1. test.diff.txt
      6 kB
      Tomasz Blachowicz
    2. java.diff.txt
      4 kB
      Tomasz Blachowicz
    3. ClassUtilsTest.java.patch
      5 kB
      Tomasz Blachowicz
    4. ClassUtils.java.patch
      5 kB
      Tomasz Blachowicz
    5. LANG-298.patch
      13 kB
      Henri Yandell

      Activity

      Mark Thomas made changes -
      Workflow jira [ 12390844 ] Default workflow, editable Closed status [ 12602231 ]
      Henri Yandell made changes -
      Status Open [ 1 ] Closed [ 6 ]
      Resolution Fixed [ 1 ]
      Hide
      Henri Yandell added a comment -

      svn ci -m "Applying my patch from LANG-298, based on Tomasz Blachowicz's original patch, and adds getPackageCanonicalName and getShortCanonicalName sets of methods" src

      Sending src/java/org/apache/commons/lang/ClassUtils.java
      Sending src/test/org/apache/commons/lang/ClassUtilsTest.java
      Transmitting file data ..
      Committed revision 612749.

      Show
      Henri Yandell added a comment - svn ci -m "Applying my patch from LANG-298 , based on Tomasz Blachowicz's original patch, and adds getPackageCanonicalName and getShortCanonicalName sets of methods" src Sending src/java/org/apache/commons/lang/ClassUtils.java Sending src/test/org/apache/commons/lang/ClassUtilsTest.java Transmitting file data .. Committed revision 612749.
      Henri Yandell committed 612749 (2 files)
      Reviews: none

      Applying my patch from LANG-298, based on Tomasz Blachowicz's original patch, and adds getPackageCanonicalName and getShortCanonicalName sets of methods

      Henri Yandell made changes -
      Attachment LANG-298.patch [ 12373244 ]
      Hide
      Henri Yandell added a comment -

      Attaching a patch that contains a slight reworking of Tomasz work.

      Mostly in that I added forCanonicalName and getCanonicalName equivalents, and then removed them as we already have forCanonicalName in the getClass method [must have added it after all] and I decided against the public JDK 1.5 replacing getCanonicalName.

      Show
      Henri Yandell added a comment - Attaching a patch that contains a slight reworking of Tomasz work. Mostly in that I added forCanonicalName and getCanonicalName equivalents, and then removed them as we already have forCanonicalName in the getClass method [must have added it after all] and I decided against the public JDK 1.5 replacing getCanonicalName.
      Hide
      Henri Yandell added a comment -

      Scratch the need for getClassName; that's JDK 1.5's getCanonicalName as Tomasz points out and I utterly miss

      So, what we need is getShortCanonicalName/getShortPackageName. Plus a pair of forCanonicalName methods.

      Show
      Henri Yandell added a comment - Scratch the need for getClassName; that's JDK 1.5's getCanonicalName as Tomasz points out and I utterly miss So, what we need is getShortCanonicalName/getShortPackageName. Plus a pair of forCanonicalName methods.
      Hide
      Henri Yandell added a comment -

      Digging into the depths of the list, this came up in 2005 too, but around the time of the 2.1 release and so was reverted and lost.

      http://markmail.org/message/2gbkqzeuw6aoaqig (the commit)
      http://markmail.org/message/peke7234ejx34n6g (the discussion)

      Looks like we agreed to do a Class.forName(String, ClassLoader) that would handle the int[] -> [I stuff.

      My concern with the changing getShortName/getPackageName is that currently packageName+"."+shortName equals class.name.

      We should also add a ClassUtils.getClassName, which maintains this equality, and is effectively the opposite of the forName above.

      Show
      Henri Yandell added a comment - Digging into the depths of the list, this came up in 2005 too, but around the time of the 2.1 release and so was reverted and lost. http://markmail.org/message/2gbkqzeuw6aoaqig (the commit) http://markmail.org/message/peke7234ejx34n6g (the discussion) Looks like we agreed to do a Class.forName(String, ClassLoader) that would handle the int[] -> [I stuff. My concern with the changing getShortName/getPackageName is that currently packageName+"."+shortName equals class.name. We should also add a ClassUtils.getClassName, which maintains this equality, and is effectively the opposite of the forName above.
      Henri Yandell made changes -
      Fix Version/s 3.0 [ 12311714 ]
      Fix Version/s 2.4 [ 12312481 ]
      Henri Yandell made changes -
      Issue Type Bug [ 1 ] Improvement [ 4 ]
      Henri Yandell made changes -
      Fix Version/s 3.0 [ 12311714 ]
      Hide
      Henri Yandell added a comment -

      Agreed that getPackageName and getShortName need improvement. Assigning to 3.0.

      Show
      Henri Yandell added a comment - Agreed that getPackageName and getShortName need improvement. Assigning to 3.0.
      Tomasz Blachowicz made changes -
      Attachment ClassUtils.java.patch [ 12346136 ]
      Hide
      Tomasz Blachowicz added a comment -

      Patch for class org.apache.commons.lang.ClassUtils

      /please ignore previous java.diff.txt file/

      Show
      Tomasz Blachowicz added a comment - Patch for class org.apache.commons.lang.ClassUtils /please ignore previous java.diff.txt file/
      Tomasz Blachowicz made changes -
      Attachment ClassUtilsTest.java.patch [ 12346135 ]
      Hide
      Tomasz Blachowicz added a comment -

      Patch for test class org.apache.commons.lang.ClassUtilsTest

      /please ignore previous test.diff.txt file/

      Show
      Tomasz Blachowicz added a comment - Patch for test class org.apache.commons.lang.ClassUtilsTest /please ignore previous test.diff.txt file/
      Tomasz Blachowicz made changes -
      Attachment java.diff.txt [ 12345887 ]
      Hide
      Tomasz Blachowicz added a comment -

      File containing svn diff of /src/java directory of commons-lang package. You can find a fix of the described issue. Implementation is not very sophisticated but it works fine and it's quick

      Show
      Tomasz Blachowicz added a comment - File containing svn diff of /src/java directory of commons-lang package. You can find a fix of the described issue. Implementation is not very sophisticated but it works fine and it's quick
      Tomasz Blachowicz made changes -
      Field Original Value New Value
      Attachment test.diff.txt [ 12345886 ]
      Hide
      Tomasz Blachowicz added a comment -

      File containing svn diff of /src/test directory of commons-lang package. There is a number of test methods included that could be used to test the issue described.

      Show
      Tomasz Blachowicz added a comment - File containing svn diff of /src/test directory of commons-lang package. There is a number of test methods included that could be used to test the issue described.
      Hide
      Tomasz Blachowicz added a comment -

      I'm really sorry I've submitted this issue without description. Here you can find detailed explanation of the problem I've came across recently.

      When you use ClassUtils.getShortClassName method for class of array you get unresonable result. For instance:
      ClassUtils.getShortClassName(java.lang.Object[].class) returns Object;
      ClassUtils.getShortClassName(int[].class) returns [I

      Respectively, when use classUtils.getPackageName for class of array it also fails.
      For instance:
      ClassUtils.getPackageName(java.lang.Object[].class) returns [Ljava.lang
      ClassUtils.getPackageName(int[].class) returns empty string

      In my opinion both methods should transform class name into canonical one before extracting short name or package name. In JavaSE 1.5 there is a method Class.getCanonicalName() but commons-lang should be < 1.5 compilant co there is a need to implement a custom mechanism to convert spring representation of class names from JVM to canonical name.

      I think the results for above examples should look like that:
      ClassUtils.getShortClassName(java.lang.Object[].class) should return Object[]
      ClassUtils.getShortClassName(int[].class) should return int[]
      ClassUtils.getPackageName(java.lang.Object[].class) should return java.lang
      ClassUtils.getPackageName(int[].class) should return empty string /it's OK/

      Show
      Tomasz Blachowicz added a comment - I'm really sorry I've submitted this issue without description. Here you can find detailed explanation of the problem I've came across recently. When you use ClassUtils.getShortClassName method for class of array you get unresonable result. For instance: ClassUtils.getShortClassName(java.lang.Object[].class) returns Object; ClassUtils.getShortClassName(int[].class) returns [I Respectively, when use classUtils.getPackageName for class of array it also fails. For instance: ClassUtils.getPackageName(java.lang.Object[].class) returns [Ljava.lang ClassUtils.getPackageName(int[].class) returns empty string In my opinion both methods should transform class name into canonical one before extracting short name or package name. In JavaSE 1.5 there is a method Class.getCanonicalName() but commons-lang should be < 1.5 compilant co there is a need to implement a custom mechanism to convert spring representation of class names from JVM to canonical name. I think the results for above examples should look like that: ClassUtils.getShortClassName(java.lang.Object[].class) should return Object[] ClassUtils.getShortClassName(int[].class) should return int[] ClassUtils.getPackageName(java.lang.Object[].class) should return java.lang ClassUtils.getPackageName(int[].class) should return empty string /it's OK/
      Tomasz Blachowicz created issue -

        People

        • Assignee:
          Unassigned
          Reporter:
          Tomasz Blachowicz
        • Votes:
          1 Vote for this issue
          Watchers:
          1 Start watching this issue

          Dates

          • Created:
            Updated:
            Resolved:

            Development