-
Notifications
You must be signed in to change notification settings - Fork 1.8k
[LANG-1634] Add ObjectUtils #applyIfNonNull and #applyFirstNonNull #684
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@sgflt
sgflt
Dec 28, 2020
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo in method name
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Corrected, thanks.
It seems to me the true test of a new API like applyIfNonNull is where can it be used within Commons Lang, if we don't eat our own dog food, it seems odd to tell others to do so. IOW, I'd like to see this PR include using this API.
I'm not convinced as to the utility of applyFirstNonNull, see above.
Also, for my money, I'd flip the arguments:
ObjectUtils.applyIfNonNull(null, bean::setValue);
Which reads to me like "if the object is non-null, then apply the function" but then maybe the method should be ifNonNullApply, at least that's how my left-to-right reading brain works ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO, you're not "invoking", you're "accepting", so the Javadoc should say "Accepts...". Actually, the method is misnamed since the underlying method is Consumer#accept(), this method should be use "accept", not "apply".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed the method name to 'accept...' and updated the Javadoc comment accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See "accept" comment above and other comment in the Conversation stream of this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have changed the method name to 'accept...', switched the parameter order and updated the Javadoc comment accordingly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can add a call to Objects.requireNonNull() here instead of the blind assignment:
this.value = Objects.requireNonNull(value, "value");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This inner class was meant as a simple Java bean with a setter and getter, hence did not have any checks in it. I have changed it now.
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
e5de898 to
cbcc405
Compare
I have renamed the methods to accept from apply and switched the parameter order where possible.
acceptFirstNonNull is the analogous method to existing ObjectUtils.firstNonNull or StringUtils.firstNonBlank. If I remember correctly, I have had one use for this method in my real life code, where a configuration parameter value could be supplied at multiple levels (specific instance, application default or global default; the first two could be null) and I have used a similar method to handle this. If you don't want to include it, I am happy to remove this.
In a real life scenario, the use case for the acceptIfNonNull method is usually when setting configuration values. The driver (say for something like redis, solr, etc.) or library (like a HTTP client library) accepts a configuration bean with some default values set. Your application accepts configuration values, and you only want to set those in the configuration bean if they are not null (or you lose the default). Anyways, I have updated 3 existing commons-lang classes to show how it can reduce 3 lines of code to 1. I did not go and update every possible occurrence, as that would make this PR large and lose focus on the primary change in the PR.
Please review and let me know if I should make further modifications.
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
cbcc405 to
0128401
Compare
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
0128401 to
d5cdd4e
Compare
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
d5cdd4e to
6ae1ac0
Compare
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
6ae1ac0 to
bde0870
Compare
@bindul Please rebase on master. TY!
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
bde0870 to
7684dac
Compare
@garydgregory Done!
Please let me know if you want me to squash commits into logical groups (I am thinking 1 with the change and the changes for review comments and another where the new method is used elsewhere in lang)
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
7684dac to
1813f18
Compare
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
1813f18 to
2e65abd
Compare
Utility methods that take a java.util.function.Consumer and possibly null value(s). The consumer is invoked if the value is not null or with the first non-null value, respectively.
- Changed method names from applyIfNonNull -> acceptIfNonNull; and applyFirstNonNull -> acceptFirstNonNull - Changed parameter order
Update a few existing classes to use ObjectUtils#acceptIfNonNull(Object, Consumer)
2e65abd to
adf1e04
Compare
singhbaljit
commented
Jan 7, 2023
We could really use this method. This is helpful because it removes the if/else code branch from the application codes, and therefore, devs don't have to write trivial unit tests to meet the code coverage requirements.
@singhbaljit
singhbaljit
Jan 7, 2023
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
more user-friendly: Consumer<? super T> consumer.
Also, requireNonNull(consumer, "consumer").
Utility methods that take a java.util.function.Consumer and possibly null value(s). The consumer is invoked if the value is not null or with the first non-null value, respectively.
See LANG-1634 and discussion at [lang] ObjectUtils enhancement - consumer with non-null value