Skip to content
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

[JENKINS-56688] Recommend Map.getOrDefault() over Map.get() #275

Merged
merged 1 commit into from Mar 26, 2019

Conversation

Projects
None yet
3 participants
@daniel-carrington
Copy link
Contributor

daniel-carrington commented Mar 22, 2019

Groovy Map.get(Object, Object) tries to modify the Map.
Using getOrDefault() instead avoids modifying the Map.

[JENKINS-56688] Recommend Map.getOrDefault() over Map.get()
Groovy Map.get(Object, Object) tries to modify the Map.
Using getOrDefault() instead avoids modifying the Map.
@dwnusbaum
Copy link
Member

dwnusbaum left a comment

Thanks for the PR! Good catch, here is the documentation for Groovy's Map.get for anyone else looking at the PR.

@daniel-carrington

This comment has been minimized.

Copy link
Contributor Author

daniel-carrington commented Mar 22, 2019

Hi @dwnusbaum, one thing that I noticed while I was using getOrDefault is that since it's a Java method and not a Groovy method, users will need to approve the method java.util.Map getOrDefault java.lang.Object java.lang.Object signature in order to use this. Does this also need to be added to the documentation?

@dwnusbaum

This comment has been minimized.

Copy link
Member

dwnusbaum commented Mar 22, 2019

Ah, thanks for pointing that out! In that case, we should add that method to the script-security whitelist here (in a pull request to that repository) so it doesn't need to be approved (fine because it is safe for use in the sandbox) before we merge this PR (It would be good to add other similar methods like compute, computeIfAbsent, etc. at the same time).

@jglick

This comment has been minimized.

Copy link
Member

jglick commented Mar 22, 2019

@jglick

jglick approved these changes Mar 22, 2019

Copy link
Member

jglick left a comment

I guess there were no functional tests actually using this idiom.

@daniel-carrington

This comment has been minimized.

Copy link
Contributor Author

daniel-carrington commented Mar 26, 2019

@dwnusbaum, is this ready to merge now that the script-security whitelist change has been merged? Or is there a need for functional tests using this idiom?

@dwnusbaum dwnusbaum merged commit 6dd12c2 into jenkinsci:master Mar 26, 2019

2 checks passed

continuous-integration/jenkins/incrementals Deployed to Incrementals.
Details
continuous-integration/jenkins/pr-merge This commit looks good
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.