adutra commented on code in PR #2629:
URL: https://github.com/apache/polaris/pull/2629#discussion_r2367173513
##########
runtime/service/src/main/java/org/apache/polaris/service/events/listeners/PolarisEventListener.java:
##########
@@ -29,287 +29,287 @@
* Represents an event listener that can respond to notable moments during
Polaris's execution.
* Event details are documented under the event objects themselves.
*/
-public abstract class PolarisEventListener {
+public interface PolarisEventListener {
Review Comment:
Thank you both for reviving this discussion. I've re-read the old thread
carefully, and I still do not understand what the problem is with using an
interface rather than an abstract class.
Can you please summarize your concerns here for clarity?
If it's about binary compatibility when adding more methods to the API, I'm
afraid an interface and an ABC provide roughly the same linkage risks. From
[JLS
13.4.16](https://docs.oracle.com/javase/specs/jls/se21/html/jls-13.html#jls-13.4.16)
(emphasis mine):
> adding a default method is a binary-compatible change because it does not
introduce errors at link time, even if it introduces errors at compile time or
invocation time. In practice, **the risk of accidental clashes occurring by
introducing a default method are similar to those associated with adding a new
method to a non-final class**.
In contrast, the advantages of using interfaces rather than abstract classes
in public APIs are abundantly documented. From _Effective Java, 3rd Edition_
(J. Bloch, 2017) (emphasis mine):
> Item 20: Prefer interfaces to abstract classes
> Java has two mechanisms to define a type that permits multiple
implementations: interfaces and abstract classes. Since the introduction of
default methods for interfaces in Java 8 [JLS 9.4.3], both mechanisms allow you
to provide implementations for some instance methods. A major difference is
that to implement the type defined by an abstract class, a class must be a
subclass of the abstract class. **Because Java permits only single inheritance,
this restriction on abstract classes severely constrains their use as type
definitions**. Any class that defines all the required methods and obeys the
general contract is permitted to implement an interface, regardless of where
the class resides in the class hierarchy.
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
