Workaround error-prone record problem without warning suppression #16657
Conversation
Warning suppression is not ideal as it may lead to suppression of more then originally desired. Work around google/error-prone#2713 using error-prone's annotation-based suppression mechanism. Note: using `@Keep` directly is not effective. Only `@Keep`-annotated annotation seems to work. Note 2: using this annotation isn't usually required, as parameter validation in compact constructor usually makes error-prone happy and avoids aforementioned issue. Use it only when needed.
findepi
added
the
no-release-notes
findepi
requested review from
martint,
homar,
losipiuk,
ebyhr,
Praveen2112,
hashhar and
kasiafi
findepi
force-pushed
the
findepi/workaround-error-prone-record-problem-without-warning-suppression-745abb
branch
from
333dbc3
to
67adea7
Compare
plugin/trino-base-jdbc/src/main/java/io/trino/plugin/jdbc/CachingJdbcClient.java
Show resolved
Hide resolved
|
CI #16653 |
|
The check is useful in general, it just doesn't work for records. So no, we should not disable it. |
|
@martint PTAL |
|
That’s preferable until it gets fixed. However, is there a timeframe for that? The issue seems to be open since middle of 2021. If there’s no end in sight, we can’t be held hostage to a buggy third party library. |
| @@ -658,9 +659,8 @@ private static <T, V> void invalidateCache(Cache<T, V> cache, Predicate<T> filte | |||
| cache.invalidateAll(cacheKeys); | |||
| } | |||
|
|
|||
| private record ColumnsCacheKey(IdentityCacheKey identity, Map<String, Object> sessionProperties, SchemaTableName table) | |||
| private record ColumnsCacheKey(@RecordParameter IdentityCacheKey identity, @RecordParameter Map<String, Object> sessionProperties, @RecordParameter SchemaTableName table) | |||
There was a problem hiding this comment.
The annotation is redundant information that doesn’t add any information and pollutes the codebase. It’s not clear why or when it should be used. See my other comments earlier
There was a problem hiding this comment.
Would different annotation name help?
what do you suggest instead? not use records?
remove a checker that's generally helpful for code reviews and is net positive overall?
There was a problem hiding this comment.
Ideally, get that error-prone bug fixed. Until that happens, avoid records in the places it causes trouble (clearly it’s not everywhere, since we’re already using records without problems in many cases). If the fix is not getting in in a reasonable amount of time and no one is willing to help push for it, we’ll have to disable the check eventually.
There was a problem hiding this comment.
i agree it would be best to have the error-prone bug fixed.
i won't spend more time on this. Adding an annotation to smooth out our code and our review process is an improvement. Fixing error-prone is also an improvement, but beyond my time budget, unfortunately.
BTW, being not less constructive, i won't agree to disable the check
findepi
deleted the
findepi/workaround-error-prone-record-problem-without-warning-suppression-745abb
branch
Warning suppression is not ideal as it may lead to suppression of more then originally desired. Work around
google/error-prone#2713 using error-prone's annotation-based suppression mechanism.
Note: using
@Keepdirectly is not effective. Only@Keep-annotated annotation seems to work.Note 2: using this annotation isn't usually required, as parameter validation in compact constructor usually makes error-prone happy and avoids aforementioned issue. Use it only when needed.