Commons Functor
  1. Commons Functor
  2. FUNCTOR-10

throw NullPointerException for illegal null values

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      for better alignment with JSE, [lang], etc. Currently IllegalArgumentException is thrown.
      Per http://markmail.org/message/ythw55yad5lrvqrj

        Activity

        Hide
        Matt Benson added a comment -

        hmm, that was actually supposed to be org.apache.commons.functor._lang3.__Validate

        Show
        Matt Benson added a comment - hmm, that was actually supposed to be org.apache.commons.functor._lang3.__Validate
        Hide
        Matt Benson added a comment -

        Yes; I would imagine that the IDEs would be fine to import if a user actually tried referencing the classes by these (albeit lightly) obfuscated names, but why would the user do this? We've accomplished the goal of protecting the user from accidentally importing these. It might be nice to make the relocator pluggable for the shade plugin, to make this easier, but I think at Commons we've gone long enough reinventing the wheel in every component just to avoid dependencies. Jar shading gives us the best of both worlds.

        Show
        Matt Benson added a comment - Yes; I would imagine that the IDEs would be fine to import if a user actually tried referencing the classes by these (albeit lightly) obfuscated names, but why would the user do this? We've accomplished the goal of protecting the user from accidentally importing these. It might be nice to make the relocator pluggable for the shade plugin, to make this easier, but I think at Commons we've gone long enough reinventing the wheel in every component just to avoid dependencies. Jar shading gives us the best of both worlds.
        Hide
        Matt Benson added a comment -

        Committed revision 1234990.

        Show
        Matt Benson added a comment - Committed revision 1234990.
        Hide
        Simone Tripodi added a comment -

        nice to hear the trick worked! The nicer thing is IMHO that names are still valid Java identifier parts, but not all IDEs are good on recognizing them

        Standard Eclipse, for example, doesn't resolve the Guice shaded internals, while Sonatype's MavenIDE (an Eclipse mod) does.

        Show
        Simone Tripodi added a comment - nice to hear the trick worked! The nicer thing is IMHO that names are still valid Java identifier parts, but not all IDEs are good on recognizing them Standard Eclipse, for example, doesn't resolve the Guice shaded internals, while Sonatype's MavenIDE (an Eclipse mod) does.
        Hide
        Matt Benson added a comment -

        Thanks for the hint, Simo! Naming e.g. org.apache.commons.lang3.Validate to org.apache.commons.functor.lang3._Validate and confirmed that the resulting jar is fully functional.

        Show
        Matt Benson added a comment - Thanks for the hint, Simo! Naming e.g. org.apache.commons.lang3.Validate to org.apache.commons.functor. lang3. _Validate and confirmed that the resulting jar is fully functional.
        Hide
        Simone Tripodi added a comment -

        We could shade the Validate class by renaming it in a way some IDEs (i.e. Eclipse) is not able to resolve; Google Guice's folks use to do it by shading the classes with $ as first class name char, it would look like: org.apache.commons.lang.$Validate

        Show
        Simone Tripodi added a comment - We could shade the Validate class by renaming it in a way some IDEs (i.e. Eclipse) is not able to resolve; Google Guice's folks use to do it by shading the classes with $ as first class name char, it would look like: org.apache.commons.lang.$Validate
        Hide
        Emmanuel Bourg added a comment -

        I tend to think that convenience for the end user is more important than convenience for the developer. In this case the code saved by the Validate class is marginal, I would rather code the null check manually.

        Show
        Emmanuel Bourg added a comment - I tend to think that convenience for the end user is more important than convenience for the developer. In this case the code saved by the Validate class is marginal, I would rather code the null check manually.
        Hide
        Matt Benson added a comment -

        Technically, yes, but should we avoid an available convenience in cases like this?

        Show
        Matt Benson added a comment - Technically, yes, but should we avoid an available convenience in cases like this?
        Hide
        Emmanuel Bourg added a comment -

        Doesn't this create a risk that people will use the Validate class shaded into [functor]? Auto import in modern IDEs is not always smart

        Show
        Emmanuel Bourg added a comment - Doesn't this create a risk that people will use the Validate class shaded into [functor] ? Auto import in modern IDEs is not always smart
        Hide
        Matt Benson added a comment -

        using lang3 Validate.notNull + maven-shade-plugin

        Show
        Matt Benson added a comment - using lang3 Validate.notNull + maven-shade-plugin

          People

          • Assignee:
            Matt Benson
            Reporter:
            Emmanuel Bourg
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development