wypoon commented on code in PR #6799:
URL: https://github.com/apache/iceberg/pull/6799#discussion_r1110460926
##########
.palantir/revapi.yml:
##########
@@ -261,6 +261,16 @@ acceptedBreaks:
\ T) throws java.io.IOException,
com.fasterxml.jackson.core.JacksonException\
\ @
org.apache.iceberg.rest.RESTSerializers.UpdateRequirementDeserializer"
justification: "False positive - JacksonException is a subclass of
IOException"
+ - code: "java.method.numberOfParametersChanged"
+ old: "method
org.apache.iceberg.io.FileAppender<org.apache.iceberg.ManifestEntry<F>>\
+ \ org.apache.iceberg.ManifestWriter<F extends
org.apache.iceberg.ContentFile<F\
+ \ extends
org.apache.iceberg.ContentFile<F>>>::newAppender(org.apache.iceberg.PartitionSpec,\
+ \ org.apache.iceberg.io.OutputFile)"
+ new: "method
org.apache.iceberg.io.FileAppender<org.apache.iceberg.ManifestEntry<F>>\
+ \ org.apache.iceberg.ManifestWriter<F extends
org.apache.iceberg.ContentFile<F\
+ \ extends
org.apache.iceberg.ContentFile<F>>>::newAppender(org.apache.iceberg.PartitionSpec,\
+ \ org.apache.iceberg.io.OutputFile, java.lang.String,
java.lang.Integer)"
Review Comment:
I probably don't understand how revapi works.
Thank you for the examples, but unfortunately they do not answer the
question on my mind. In your example, in the first change, you deprecate a
number of methods and annotate that a replacement method should be used. In
those cases, **the replacement method had already been added (by some earlier
change)**. Then in the second change, the deprecated methods are removed.
I completely understand deprecating a method in one release, and removing it
in the following release. What I don't understand is how to add the replacement
method, or how to add a new method.
In your example, in the first change, either the replacement method has
already been added by some earlier change, or you amend a new method to have a
default implementation (e.g., throwing an `UnsupportedOperationException`). In
the example, this occurs in interfaces. There is unfortunately no example of an
abstract class. If I'm not mistaken, you can add a default implementation to a
method in an interface, but you cannot add a default implementation to an
abstract method in an abstract class, as the method is then no longer abstract.
Let's say I do as you suggest and make the `newAppender` with 4 parameters
non-abstract as follow:
```
protected FileAppender<ManifestEntry<F>> newAppender(
PartitionSpec spec,
OutputFile outputFile,
String compressionCodec,
Integer compressionLevel) {
return newAppender(spec, outputFile);
}
```
In the following release, I'd remove the deprecated old `newAppender` with 2
parameters (well and good), and I'd need to change the `newAppender` with 4
parameters to be abstract, since the default implementation no longer makes
sense. Wouldn't that break revapi at that point?
Anyway, I just want to get this change in, and I'll make the change you
suggest, but it doesn't seem right to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org
For additional commands, e-mail: issues-h...@iceberg.apache.org
