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
Fix ErrorProne warnings in :file-collections and :input-tracking #28887
Fix ErrorProne warnings in :file-collections and :input-tracking #28887
Conversation
@bot-gradle test QFL without PTS |
I've triggered the following builds with parameters: |
@@ -35,6 +35,7 @@ public abstract class LazilyInitializedFileCollection extends CompositeFileColle | |||
* @deprecated Use the overload accepting the TaskDependencyFactory | |||
*/ | |||
@Deprecated | |||
@SuppressWarnings("InlineMeSuggester") |
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.
💭 The offending plugin has been fixed, so we can remove the usage in 9.0
@@ -185,7 +185,7 @@ public void replaceAll(BiFunction<? super Object, ? super Object, ?> function) { | |||
} | |||
|
|||
@Override | |||
public Object putIfAbsent(Object key, Object value) { | |||
public synchronized Object putIfAbsent(Object key, Object value) { | |||
Object oldValue; | |||
synchronized (delegate) { |
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.
🤔 Since delegate
is also a Properties
instance (thus synchronized
) and we're now synchronizing this Properties
instance, what's the point of synchronized (delegate)
here?
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.
🤔 Since
delegate
is also aProperties
instance (thussynchronized
) and we're now synchronizing thisProperties
instance, what's the point ofsynchronized (delegate)
here?
Well, making these methods synchronized doesn't change much in this regard. I guess, I was either over-defensive when writing these methods and didn't look if the method is synchronized or not, or this is a leftover of some earlier code state when there were some extra steps in the synchronized block.
TBH, the synchronization contract is still broken for system properties, because user code gets a new Properties instance every time. I'd rather replace this fix with a class-level suppression and address synchronizations concerns separately.
We don't use errorprone annotations yet.
001ce19
to
f3fd5ab
Compare
@bot-gradle test this |
I've triggered the following builds for you. Click here to see all build failures. |
Reviewing cheatsheet
Before merging the PR, comments starting with