Lombok: Add @Log(useStatic=false) property

[mih-kopylov]

This request is about generating a non-static log field, that will be initialized with getClass() instead of ConcreteClass.class.

Now:

@Slf4j
public class Demo{}

generates

public class Demo{
    private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(Demo.class)
}

Requested:

@Slf4j(useStatic=false)
public class Demo{}

that will generate

public class Demo{
    private final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(getClass())
}

This feature is very useful in parent abstract classes, where concrete class should be used in logger category instead of parent abstract one.

[mih-kopylov]

Actually lombok.javac.handlers.HandleLog already is able to generate non-static log field, but

• this is configured in lombok.log.fieldIsStatic, that is for the whole project
• it uses Demo.class instead of getClass() in this case as well

[rzwitserloot]

Ouch; when making pullreqs for new features, especially appending features on top of existing features like this, please contact us first.

We have a policy _NOT_ to pile on 'feature mods'; if you peruse the forums and the feature requests, you'll probably find 10 or more exotic pile-on features generally suggested as a parameter on the annotation. That would result in something like:

`@Log(useStatic = false, loggerFieldName = "logger", checkLogLevel = true, toSysOut = true, toSysErr = true, addStackTrace = true) etcetera. Festooning 18 different properties onto every lombok annotation, whilst making lombok more 'flexible', would make it a far worse product as the learning curve would be very negatively impacted.

As such this doesn't sound like a palatable feature to me, it just doesn't cross that bar.

Some sort of very common practice ("Josh Bloch wrote about it in Effective Java" kinda common practice; that would definitely help a lot) or well known system that works like this could change our mind, though.

[mih-kopylov]

Hey, @rzwitserloot, this looks like we just don't want to complicate Lombok, so won't do it.
But this looks weird.

Moreover taking into account, there's already non-documented lombok.log.fieldIsStatic flag that works on the same point, close to this feature, why not to make Lombok more flexible?

I don't see 18 properties in @Slf4j, there's only one now. But I see 4 properties in @NoArgsConstructor
So what policy does excatly this feature request ruin?

Or may be you can suggest any other solution for generating non-static logger in parent abstract classes?

[izebit]

I want to discuss this issue too.

To my mind, there is no harm in doing it because of this field are not necessary and it has default value. So, you will not have to set value when you use the annotation. Also, it will be pretty cool, if Lombok looks like a swiss army knife.

I agree with you partly. This feature isn't very common, but sometimes we have situations when we need to have this flexibility. Of course, if we support a lot of features, it will influent to a complexity of source code. But it is another question.

[bradyellison]

It is surprising to me the answer lombok provides it to blanket enable or disable the static/instance generation of a logger.

There are distinct use cases for both behaviors that can and do exist within the same project. For example, very short lived objects benefit by avoiding the overhead of generating a new logger for each instantiation and for long live classes that inherit from abstract classes the clarity of using a different logger per concrete instance is far more valuable than having a static logger.

Lombok should consider allowing these more obscure flags to be set using global flags and another mechanism. I could imagine a configuration annotation or even a set of configuration annotations for each class of configuration. I honestly think for discoverability placing these flags directly on the annotation should be considered.

(1) On the annotations themselves

@Log(
  topic="",
  flags=@LogFlags(
    fieldIsStatic=false,
    // ...
  )
)

(2) As an additional annotation:

@Log(topic="")
@LogFlags(
  fieldIsStatic=false,
  // ...
)

Pattern (1) extends nicely into each major class of lombok feature.

As it stands I am forced to avoid lombok in one of these cases, complicating refactoring, the cognitive load on the team, and obscuring code that is already abstract. By making lombok "simpler" my code is more complicated.

[randakar]

Let's consider the purpose of Lombok: reducing boilerplate.

Lombok by it's nature deals with common cases. It doesn't cater to every
use case and I argue that this is a good thing. If it would it would
quickly start losing a lot of it's value by dint of configuration option
overload.

As a rule I believe that special cases should look different from regular
run of the mill code. The more something like this stands out, the better.
So I'm not sure this is actually something Lombok should address.

Op za 30 jun. 2018 22:43 schreef Brady Ellison [e-mail]:

It is surprising to me the answer lombok provides it to blanket enable or
disable the static/instance generation of a logger.

There are distinct use cases for both behaviors that can and do exist
within the same project. For example, very short lived objects benefit by
avoiding the overhead of generating a new logger for each instantiation and
for long live classes that inherit from abstract classes the clarity of
using a different logger per concrete instance is far more valuable than
having a static logger.

Lombok should consider allowing these more obscure flags to be set using
global flags and another mechanism. I could imagine a configuration
annotation or even a set of configuration annotations for each class of
configuration. I honestly think for discoverability placing these flags
directly on the annotation should be considered.

(1) On the annotations themselves

@Log(
topic="",
flags=@LogFlags(
fieldIsStatic=false,
// ...
)
)

(2) As an additional annotation:

@Log(topic="")@LogFlags(
fieldIsStatic=false,
// ...
)

Pattern (1) extends nicely into each major class of lombok feature.

As it stands I am forced to avoid lombok in one of these cases,
complicating refactoring, the cognitive load on the team, and obscuring
code that is already abstract. By making lombok "simpler" my code is more
complicated.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/rzwitserloot/lombok/issues/1597#issuecomment-401565215,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKCRTJkradKFDedjb_sSqNvmMf70_Aeks5uB-LhgaJpZM4SZgWL
.

[JoeXie]

if we can get log by getClass() not Clazz.class, it will be useful in sub-class.