Commons Lang
  1. Commons Lang
  2. LANG-254

[lang] Enhanced Class.forName version

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.1
    • Fix Version/s: 2.2
    • Component/s: None
    • Labels:
      None
    • Environment:

      Operating System: other
      Platform: Other

      Description

      The standard Class.forName support for primitive types and arrays is not really
      userfriendly as it requires the bytecode specification (eg. "[I" for an integer
      array) rather than the normal type specification as would be used for variable
      declarations (eg. "int[]"). Likewise, it is not possible to get the class for
      "int" and other primitive types with Class.forName, one has to resort to
      "java.lang.Integer" which is not guaranteed to be equal to int.class.

      This proposed feature adds a class that provides such an enhanced Class.forName
      functionality which then could for instance be exposed via commons-lang's
      ClassUtils.

      1. ASF.LICENSE.NOT.GRANTED--GetClass.patch
        22 kB
        James Carman
      2. ASF.LICENSE.NOT.GRANTED--GetClass.patch
        23 kB
        James Carman
      3. ASF.LICENSE.NOT.GRANTED--GetClass.patch
        9 kB
        James Carman
      4. ASF.LICENSE.NOT.GRANTED--TestClassForName.java
        4 kB
        Thomas Dudziak
      5. ASF.LICENSE.NOT.GRANTED--ClassForName.java
        7 kB
        Thomas Dudziak

        Activity

        Hide
        James Carman added a comment -

        I believe that it's good to go.

        Show
        James Carman added a comment - I believe that it's good to go.
        Hide
        Henri Yandell added a comment -

        Looks like this was resolved in r345284.

        Reopen if I've got that wrong.

        Show
        Henri Yandell added a comment - Looks like this was resolved in r345284. Reopen if I've got that wrong.
        Hide
        James Carman added a comment -

        I refactored it. It now allows spaces in the class name. Basically, it just
        calls StringUtils.deleteWhitespace() on the class name before it transforms it.

        Show
        James Carman added a comment - I refactored it. It now allows spaces in the class name. Basically, it just calls StringUtils.deleteWhitespace() on the class name before it transforms it.
        Hide
        James Carman added a comment -

        So, do we want to not consider this code unless it supports spaces in the middle
        of the type name? Or, could we check this in and add support for the weird
        cases if it's needed?

        Show
        James Carman added a comment - So, do we want to not consider this code unless it supports spaces in the middle of the type name? Or, could we check this in and add support for the weird cases if it's needed?
        Hide
        Thomas Dudziak added a comment -

        It might be useful to also have some tests for generic types, eg.
        "java.util.List < java.lang.Byte [ ] > lists [ ] ".

        Show
        Thomas Dudziak added a comment - It might be useful to also have some tests for generic types, eg. "java.util.List < java.lang.Byte [ ] > lists [ ] ".
        Hide
        Thomas Dudziak added a comment -

        There is one problem with the patch: it does not allow any spaces near the
        brackets. I think the method should be able to handle any Type production as
        defined by the JLS (see
        http://java.sun.com/docs/books/jls/third_edition/html/syntax.html#18.1). This
        means that between any token (see the Type production in the grammar) there may
        be whitespaces. While in a fully qualified class name this is not a problem
        ("java . lang . String" is perfectly valid, but the classloader can handle
        this), around and in between the brackets must be handled by this method (eg. "
        byte [ ] ").

        Show
        Thomas Dudziak added a comment - There is one problem with the patch: it does not allow any spaces near the brackets. I think the method should be able to handle any Type production as defined by the JLS (see http://java.sun.com/docs/books/jls/third_edition/html/syntax.html#18.1 ). This means that between any token (see the Type production in the grammar) there may be whitespaces. While in a fully qualified class name this is not a problem ("java . lang . String" is perfectly valid, but the classloader can handle this), around and in between the brackets must be handled by this method (eg. " byte [ ] ").
        Hide
        James Carman added a comment -

        Created an attachment (id=16319)
        Yet another patch (no JDK1.4 dependency)

        Here's another patch which removes the JDK1.4 dependency. This code doesn't
        really check the "syntax" of the class names that come in. It merely lets
        Class.forName() throw a ClassNotFoundException when the input is invalid.

        Show
        James Carman added a comment - Created an attachment (id=16319) Yet another patch (no JDK1.4 dependency) Here's another patch which removes the JDK1.4 dependency. This code doesn't really check the "syntax" of the class names that come in. It merely lets Class.forName() throw a ClassNotFoundException when the input is invalid.
        Hide
        James Carman added a comment -

        Created an attachment (id=16318)
        An updated patch.

        Again, this still uses the String.matches() method, so it's 1.4 dependent.
        Anyone have any good ideas on how we can cleanly check the syntax of the class
        name? Anyone want to submit a method implementation?

        Show
        James Carman added a comment - Created an attachment (id=16318) An updated patch. Again, this still uses the String.matches() method, so it's 1.4 dependent. Anyone have any good ideas on how we can cleanly check the syntax of the class name? Anyone want to submit a method implementation?
        Hide
        James Carman added a comment -

        You may be right. So sorry. So, we have to do this by hand? UGLY!

        Show
        James Carman added a comment - You may be right. So sorry. So, we have to do this by hand? UGLY!
        Hide
        Emmanuel Bourg added a comment -

        The regex makes it JDK 1.4 dependent, I thought [lang] was aiming at JDK 1.2
        compatibility, is it still true ?

        Show
        Emmanuel Bourg added a comment - The regex makes it JDK 1.4 dependent, I thought [lang] was aiming at JDK 1.2 compatibility, is it still true ?
        Hide
        James Carman added a comment -

        Created an attachment (id=16316)
        A patch to implement the changes

        Here's my version of the code. If everyone is happy with it, I can go ahead
        and commit the changes myself. Please advise.

        Note: I chose to use endsWith() as it is more readable and it's not entirely
        obvious to me (or others) that the performance cost is that tremendous. Also,
        I use a regex syntax check at the beginning of the method. I don't know if
        this is the fastest way to do it, but it does check for invalid names in one
        statement, so it's quite readable (aside from the nasty regex pattern).

        Show
        James Carman added a comment - Created an attachment (id=16316) A patch to implement the changes Here's my version of the code. If everyone is happy with it, I can go ahead and commit the changes myself. Please advise. Note: I chose to use endsWith() as it is more readable and it's not entirely obvious to me (or others) that the performance cost is that tremendous. Also, I use a regex syntax check at the beginning of the method. I don't know if this is the fastest way to do it, but it does check for invalid names in one statement, so it's quite readable (aside from the nasty regex pattern).
        Hide
        Thomas Dudziak added a comment -

        Created an attachment (id=16313)
        Tests for the feature

        Show
        Thomas Dudziak added a comment - Created an attachment (id=16313) Tests for the feature
        Hide
        Thomas Dudziak added a comment -

        Created an attachment (id=16312)
        An implementation of the proposed feature

        Show
        Thomas Dudziak added a comment - Created an attachment (id=16312) An implementation of the proposed feature

          People

          • Assignee:
            Unassigned
            Reporter:
            Thomas Dudziak
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development