gnodet-bot commented on code in PR #12695:
URL: https://github.com/apache/maven/pull/12695#discussion_r4050917389


##########
api/maven-api-core/src/main/java/org/apache/maven/api/plugin/Log.java:
##########
@@ -38,49 +38,38 @@
 public interface Log {
     /**
      * {@return true if the <b>trace</b> error level is enabled}
-     * <p>
-     * The default implementation returns {@code false} for backward
-     * compatibility with existing {@code Log} implementations.
+     * @since 4.1.0
      */
-    default boolean isTraceEnabled() {
-        return false;
-    }
+    boolean isTraceEnabled();

Review Comment:
   **[High, RERAISED] `isTraceEnabled()` and all six `trace` methods changed 
from `default` to abstract — binary-incompatible breaking change.**
   
   In `feature/logging-foundation` (the base branch), all six methods had 
`default` implementations:
   ```java
   default boolean isTraceEnabled() { return false; }
   default void trace(CharSequence content) {}
   default void trace(CharSequence content, Throwable error) {}
   default void trace(Throwable error) {}
   default void trace(Supplier<String> content) {}
   default void trace(Supplier<String> content, Throwable error) {}
   ```
   This PR makes them all abstract. Any existing class that implements `Log` 
and relied on those defaults — third-party plugin frameworks, mocking adapters, 
test doubles — will fail with `AbstractMethodError` at runtime without a 
recompile.
   
   Note: the Javadoc on `trace(Supplier<String>)` (line 75–81) still says *"The 
default implementation is a no-op for backward compatibility"* — but there is 
no longer a default.
   
   The base branch intentionally provided `default {}` bodies to allow 
incremental adoption. Either keep them as defaults, or add a clear migration 
note explaining why the break is intentional and what implementors must do.



-- 
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]

Reply via email to