[BEAM-2306] Fail build when @Deprecated is used without @deprecated javadoc#3531
[BEAM-2306] Fail build when @Deprecated is used without @deprecated javadoc#3531alex-filatov wants to merge 4 commits intoapache:masterfrom
Conversation
…s used without @deprecated javadoc (or vice versa). The check is disabled for existing violations where reason for deprecation and/or alternative is not clear.
|
R: @kennknowles |
kennknowles
left a comment
There was a problem hiding this comment.
Thanks! I've added a lot of content, so we can just not have any undocumented deprecation left.
| } | ||
|
|
||
| /** | ||
| * @deprecated use {@link #setTimer(StateNamespace, String, Instant, TimeDomain)}. |
There was a problem hiding this comment.
I think here you can do @inheritdoc so you don't have to spell it out again. And same throughout.
There was a problem hiding this comment.
Unfortunately doesn't work. Only main description, @param, @returns, @throws are inheritable.
There was a problem hiding this comment.
Ah, too bad. Thanks for clarifying.
| PCollectionView.class.getSimpleName()); | ||
| } | ||
|
|
||
| // CHECKSTYLE.OFF: MissingDeprecated |
There was a problem hiding this comment.
Thanks for putting this together! I will just provide commentary for these so you don't have to use exclusions.
@deprecated runners should move away from translating `CreatePCollectionView`
and treat this as part of the translation for a `ParDo` side input.| } | ||
|
|
||
| /** Registers {@link CreatePCollectionViewTranslator}. */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated |
| * A marker {@link DoFn} for writing the contents of a {@link PCollection} to a streaming | ||
| * {@link PCollectionView} backend implementation. | ||
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated |
There was a problem hiding this comment.
I think this @Deprecated can just be switched to @Internal. The important thing is that this is not for users anyhow.
| */ | ||
| public abstract class Coder<T> implements Serializable { | ||
| /** The context in which encoding or decoding is being done. */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated |
There was a problem hiding this comment.
@deprecated to implement a coder, do not use any `Context`. Just implement only those abstract methods which do not accept a `Context` and leave the default implementations for methods accepting a `Context`.| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
There was a problem hiding this comment.
@deprecated `getCoderFromDescriptor(TypeDescriptor, Map)There was a problem hiding this comment.
There is no intended alternative, this is a visibility issue and this code should be moved into the CombineFns class.
There was a problem hiding this comment.
So purpose of the deprecation here is to attract attention to the @Internal annotation? In this case I propose to remove deprecation for consistency with the remaining codebase.
There was a problem hiding this comment.
See above comment - just deprecated to indicate that it is going to change. So even though it is @Internal (and the javadoc should be loud about this, like in other places) it is helpful for contributors to see their IDEs strikethrough the method.
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
There was a problem hiding this comment.
@deprecated `getCoderFromDescriptor(TypeDescriptor, Map)There was a problem hiding this comment.
getCoderFromDescriptor doesn't exist, do you mean the private getCoderFromTypeDescriptor?.
Also, this method has no replacement and is really meant to be copied into ParDo having ParDo own all that logic.
There was a problem hiding this comment.
Yea, I mean getCoderFromTypeDescriptor. Basically we do need at least one (and probably exactly one) public method where you can pass in a context of type-to-coder bindings. And the rest should be directed to use that.
There was a problem hiding this comment.
Ken, have you seen enough demand for such a function in user based transforms that warrants visibility vs having a few independent copies?
There was a problem hiding this comment.
I don't think it can be implemented outside of the registry.
There was a problem hiding this comment.
Maybe if all the uses are just special cases that don't require real coder inference, that could be fine. But this method itself is quite simple so probably specialized versions would add complexity. I'm open to whatever, though.
There was a problem hiding this comment.
If you don't believe that is possible, we should change the @deprecated comment to be something like:
@deprecated This method is to change in an unknown backwards incompatible way once support for this functionality is refined.
Similarly for the other CoderRegistry @Internal/@Deprecated methods.
| * } | ||
| * </code></pre> | ||
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated |
There was a problem hiding this comment.
@deprecated tests which use unbounded PCollections should be in the category {@link UsesUnboundedPCollections}. Beyond that, it is up to the runner and test configuration to decide whether to run in streaming mode.|
|
||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
There was a problem hiding this comment.
I actually don't think this should be deprecated.
| /** | ||
| * Returns if a default value was specified. | ||
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated |
There was a problem hiding this comment.
@deprecated these methods are all expected to change arbitrarilyBut really, @Internal is probably enough.
| } | ||
|
|
||
| /** | ||
| * @deprecated use {@link #setTimer(StateNamespace, String, Instant, TimeDomain)}. |
There was a problem hiding this comment.
Ah, too bad. Thanks for clarifying.
|
|
||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
There was a problem hiding this comment.
This is another case of the CreatePCollectionView transform being deprecated entirely.
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
| */ | ||
| // CHECKSTYLE.OFF: MissingDeprecated | ||
| @Deprecated | ||
| // CHECKSTYLE.ON: MissingDeprecated |
There was a problem hiding this comment.
See above comment - just deprecated to indicate that it is going to change. So even though it is @Internal (and the javadoc should be loud about this, like in other places) it is helpful for contributors to see their IDEs strikethrough the method.
|
All done. Please take a look. |
|
This PR broke Dataflow runner because it deleted this code: |
|
Sorry for this. I couldn't find usage of this code in the repo, so assumed it was safe to delete. |
|
No need to apologize. Your PR was just fine. It is on us to either make it a core part of the API or document why it exists despite being unused. Since it was leftover for compatibility, one way to make it obvious would be with a test in And [partial] rollbacks are painless - don't view it as indicating any fault. A large number of our tests do not run until postcommit (to avoid massive amounts of computation) so it is expected for such things to happen fairly often. |
Add checkstyle check to fail the build when
@Deprecatedis used without@deprecatedjavadoc (or vice versa).The check is disabled for existing violations where reason for deprecation and/or alternative is not clear.