for better alignment with JSE, [lang], etc. Currently IllegalArgumentException is thrown.
using lang3 Validate.notNull + maven-shade-plugin
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
Technically, yes, but should we avoid an available convenience in cases like this?
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.
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
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.
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.
Committed revision 1234990.
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.
hmm, that was actually supposed to be org.apache.commons.functor._lang3.__Validate