Is it possible to enable interface support for @Slf4j.
My use case:
@Slf4j // @Log is legal only on classes and enums
public interface MyInterface {
default void test() {
log.info( "log message")
}
}
Thanks
This should also be done for @XSlf4j. When generating for classes:
private static final org.slf4j.ext.XLogger log = org.slf4j.ext.XLoggerFactory.getXLogger(MyType.class);
And for interfaces:
org.slf4j.ext.XLogger log = org.slf4j.ext.XLoggerFactory.getXLogger(MyType.class);
Then the log can be used in default methods.
The problem is this: Whilst we can generate the field (and we could generate that field allll the way back to java 1.6), __it will be public__ and there's no way to stop that from happening. This is bad; loggers should most definitely not be part of the API!
Even worse, that means anything that implements your interface gets a 'free' logger they shouldn't be using. That's worse.
This gets us to the sad truth of it all: logging in default methods is __broken__ in java today.
I haven't run into this yet, but, if I were faced with this dilemma, I think I'd do this. in a single file called MyInterface.java:
class MyInterfaceLogger {
static final org.slf4j.ext.XLogger log = org.slf4j.ext.XLoggerFactory.getXLogger(MyInterface.class);
}
public interface MyInterface {
default void test() {
MyInterfaceLogger.log.info("hello");
}
}
lombok could generate this, but, we'd have to add reams of docs to tell you about it. Also, generating in-file sibling package private classes is not something we do now and I foresee a few issues, so, it would be a high-maintenance load feature.
I entirely get the pain here, but, let's wait for the java community to figure out how they wanna tackle it before we enshrine the solution into a lombok feature. Also, given this is still relatively exotic (or we'd have heard more of a stink, presumably), the high maintenance nature of the IMO right solution means it doesn't cross the bar, unfortunately.
Most helpful comment
The problem is this: Whilst we can generate the field (and we could generate that field allll the way back to java 1.6), __it will be public__ and there's no way to stop that from happening. This is bad; loggers should most definitely not be part of the API!
Even worse, that means anything that implements your interface gets a 'free' logger they shouldn't be using. That's worse.
This gets us to the sad truth of it all: logging in default methods is __broken__ in java today.
I haven't run into this yet, but, if I were faced with this dilemma, I think I'd do this. in a single file called
MyInterface.java:lombok could generate this, but, we'd have to add reams of docs to tell you about it. Also, generating in-file sibling package private classes is not something we do now and I foresee a few issues, so, it would be a high-maintenance load feature.
I entirely get the pain here, but, let's wait for the java community to figure out how they wanna tackle it before we enshrine the solution into a lombok feature. Also, given this is still relatively exotic (or we'd have heard more of a stink, presumably), the high maintenance nature of the IMO right solution means it doesn't cross the bar, unfortunately.