lombok-slf4j @WithLog

[Marius Kruger]

Hi
I love lombok, I can't get enough of it.
I'd love not to repeat the following code in most of my classes:
==
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
class xx {
private static final Logger LOGGER =
LoggerFactory.getLogger(PackageManager.class);
}
==>
@WithLog
class xx {
}
==
Sounds lombokish but depends on slf4j, so do we need to put it in a
seperate jar?
or if you use it you must sort out the dependencies?!

The closest to this I could find on the net was:
http://enfranchisedmind.com/blog/posts/with-log-groovy-ast-transform/

If I had any idea where to start and some spare time, I'd do it
myself..will see.

[Reinier Zwitserloot]

We're currently working on making the writing of a transformer easier.
Once that's done - we can add this. Because there are a thousand and
one logging frameworks we'll have to discuss how we handle
transformers that require you to sort out dependencies (lombok itself
wouldn't actually need slf4j - it can just insert "private static
final org.slf4j.Logger ...." without lombok itself even knowing what
that is. However, if your classpath / IDE build project settings /
maven / etc don't know what that is, you'll get an error, of course.

One option is to create packages whose package name reflects the
dependency, i.e. instead of importing "lombok.WithLog" you'd import
"lombok.slf4j.WithLog".

[Marius Kruger]

On 30 September 2010 17:04, Reinier Zwitserloot <rein...@gmail.com> wrote:
> We're currently working on making the writing of a transformer easier.
> Once that's done - we can add this.

sweet, can hardly wait for that, thanks!

> Because there are a thousand and
> one logging frameworks we'll have to discuss how we handle
> transformers that require you to sort out dependencies (lombok itself
> wouldn't actually need slf4j - it can just insert "private static
> final org.slf4j.Logger ...." without lombok itself even knowing what
> that is. However, if your classpath / IDE build project settings /
> maven / etc don't know what that is, you'll get an error, of course.

thought so.

> One option is to create packages whose package name reflects the
> dependency, i.e. instead of importing "lombok.WithLog" you'd import
> "lombok.slf4j.WithLog".

sounds great!
can't wait :-)

[Ben]

> One option is to create packages whose package name reflects the
> dependency, i.e. instead of importing "lombok.WithLog" you'd import
> "lombok.slf4j.WithLog".

Distinguishing classes only by their package and not their class name
in the first class can get sometimes really annoying.

It might be really delighting if you can keep your classpath clean
from the unwanted ones. But not if all options are permanently
available: Instead of typing the classname and just press enter on the
import popup (which is a nobrainer) you _always_ need to carefully
select the right package every time. And obviously its not that easy
to spot errors in the import-code segment which is collapsed most of
the time.

From this point of view I'd rather encourage an API which
distinguishes either by class name or parameter name. Sometimes we
also use inner classes to guide and structure common things
(@WithLog.JCL).

Just my 2c on this topic

[Reinier Zwitserloot]

Eclipse at least (and I believe many other IDEs) let you filter out
packages altogether, i.e. you'll never see them offered in auto-
complete / fix imports dialogs. We're banking on folks using this.

[Maaartin-1]

> Eclipse at least (and I believe many other IDEs) let you filter out
> packages altogether, i.e. you'll never see them offered in auto-
> complete / fix imports dialogs. We're banking on folks using this.

Yes, but one day you add "lombok.anotherLogger.WithLog" and we import it
carelessly and end with anotherLogger being used instead.

Moreover, specifying what logger you want in each class again and again
is boilerplate. This is a case for global user-defined settings, which
can't be done without some magic or runtime dependency, which you're
avoiding (for a good reason). However, I'm going to try to convince you
that user-defined settings are just too important to be left out.
Currently, I'm short of time, so I'll present my arguments in a posting
next week or about.

Regards, Maaartin.

[Reinier Zwitserloot]

Well, I'll wait with bated breath :)

[Ben]

On 17 Nov., 09:37, Reinier Zwitserloot <reini...@gmail.com> wrote:
> Eclipse at least (and I believe many other IDEs) let you filter out
> packages altogether, i.e. you'll never see them offered in auto-
> complete / fix imports dialogs. We're banking on folks using this.

Nope: I'm i.e. not aware of such an option in IDEA and honestly think
such an option is rather misleading:
IMHO Eclipse only offers this option, as it misses a way of
classifying dependencies into correct scopes (runtime/compile/test/
provided) and (nestable) modules. But even then, this is probably a
per user setting, which requires a per user awareness and hence offers
a high fail-to-win ratio in your projects ;-)

> Moreover, specifying what logger you want in each class again and again

> is boilerplate. This is a case for global user-defined settings, [..]

Big plus from my side: This would be the best solution! The simplest
approach could be the SLF4J way:
- Reduce the core Lombok feature/annotation set to an minimum (core)
- Allow users to easily plug-in custom/additonal features (like i.e
the JCL WithLog vs. JUL WithLog) by adding extensions.jar.

[Reinier Zwitserloot]

We played around with the extensions idea but it has 2 pretty major issues associated with it:

1. Because of module-load busting tricks lombok has to do in most IDEs, actually shipping lombok as anything more than a single jar file is highly problematic. Those that have been making lombok extensions usually just recompile lombok with their stuff inside and distribute that.

2. Logging is more or less effect-free. You know what a single SLF4J statement does: It logs. To what? Probably not important. On the other hand, lombok's settings (well, obviously not for what @Log would do, but for most other lombok features where we've had requests for configurability), what exactly happens is crucial to understanding the code.

 --Reinier Zwitserloot

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

[Hamlet D'Arcy]

You all may want to check out @Log in Groovy 1.8:
http://www.canoo.com/blog/2010/09/20/log-groovys-new-and-extensible-logging-conveniences/

We have 5 @Log annotations (different packages like slf4j.Log,
commons.Log, etc) and the thing is extensible so you can include your
own framework.

The real win is not instantiating a log. The great part is that
the .isDebugEnabled or isInfoEnabled calls are all generated
automatically for you, so this code:

lon.info(generateLoggingMessage())

if transformed to

if (log.isInfoEnabled()) {
log.info(generateLoggingMessage()
}

The logging frameworks are all different with their API so it was a
pain to implement (it was mostly done by me with a lot of help from
others), but it all works.

Also, I've been asked for information on Groovy's @Delegate... here is
the Javadoc, which is a good starting point. Although I feel a release
of lombok pending and maybe influencing the outcome of @delegate is
too late... .

Thanks,

Hamlet D'Arcy


On Nov 18, 5:48 pm, Reinier Zwitserloot <rein...@zwitserloot.com>
wrote:

> > Groups group forhttp://projectlombok.org/

>
> > To post to this group, send email to project...@googlegroups.com
> > To unsubscribe from this group, send email to

> > project-lombo...@googlegroups.com<project-lombok%2Bunsubscribe@go oglegroups.com>

[Hamlet D'Arcy]

Groovy has a similar feature in 1.8:
http://www.canoo.com/blog/2010/09/20/log-groovys-new-and-extensible-logging-conveniences/

We have 5 @Log annotations, each in a different package. One for
log4j, one for slf4j, etc. It injects a logger, but that is not all.

If the parameter to a log method is not a constant, then it wraps the
whole block in an "isLevelEnabled" if statement. Effectively, the
parameters to logging methods are never evaluated unless that level is
enabled. It was a pain to implement because all the frameworks have a
different and inconsistent API, but it is done. It's also extensible,
you can plug your own Log framework in with a little AST work.

@Log is a much better example than @WithLog. It would be great to keep
the same naming convention/annotation parameters between Groovy and
Lombok as there is so much overlap. (Indeed, we stole your
@synchronized and @constructor.. annotations).

--

Hamlet D'Arcy

On Nov 18, 5:48 pm, Reinier Zwitserloot <rein...@zwitserloot.com>
wrote:

> We played around with the extensions idea but it has 2 pretty major issues
> associated with it:
>
> 1. Because of module-load busting tricks lombok has to do in most IDEs,
> actually shipping lombok as anything more than a single jar file is highly
> problematic. Those that have been making lombok extensions usually just
> recompile lombok with their stuff inside and distribute that.
>
> 2. Logging is more or less effect-free. You know what a single SLF4J
> statement does: It logs. To what? Probably not important. On the other hand,
> lombok's settings (well, obviously not for what @Log would do, but for most
> other lombok features where we've had requests for configurability), what
> exactly happens is crucial to understanding the code.
>
>  --Reinier Zwitserloot
>

> On Thu, Nov 18, 2010 at 1:50 PM, Ben <tebu...@googlemail.com> wrote:
> > On 17 Nov., 09:37, Reinier Zwitserloot <reini...@gmail.com> wrote:
> > > Eclipse at least (and I believe many other IDEs) let you filter out
> > > packages altogether, i.e. you'll never see them offered in auto-
> > > complete / fix imports dialogs. We're banking on folks using this.
>
> > Nope: I'm i.e. not aware of such an option in IDEA and honestly think
> > such an option is rather misleading:
> > IMHO Eclipse only offers this option, as it misses a way of
> > classifying dependencies into correct scopes (runtime/compile/test/
> > provided) and (nestable) modules. But even then, this is probably a
> > per user setting, which requires a per user awareness and hence offers
> > a high fail-to-win ratio in your projects ;-)
>
> > > Moreover, specifying what logger you want in each class again and again
> > > is boilerplate. This is a case for global user-defined settings, [..]
>
> > Big plus from my side: This would be the best solution! The simplest
> > approach could be the SLF4J way:
> > - Reduce the core Lombok feature/annotation set to an minimum (core)
> > - Allow users to easily plug-in custom/additonal features (like i.e
> > the JCL WithLog vs. JUL WithLog) by adding extensions.jar.
>
> > --
> > You received this message because you are subscribed to the Google

> > Groups group forhttp://projectlombok.org/

>
> > To post to this group, send email to project...@googlegroups.com
> > To unsubscribe from this group, send email to

> > project-lombo...@googlegroups.com<project-lombok%2Bunsu...@googlegroups.com>

[Reinier Zwitserloot]

Talking it through with Roel on the drive back from the excellent
Devoxx conference (Salient fact: About 2800 heavy WiFi users and the
network not only survived the whole conference, it was actually quite
fast to boot!) - at first we were a bit concerned about introducing an
extra branch which may in many cases be useless (if you've configured
your logger levels to send all through to the handlers, and let the
handlers do the filtering). However, given that the logging framework
will have to at the very least do the same branch check, that means we
only add to the performance cost if the log statement IS executed, and
gets quite deeply into the logging backend. At that scale, any
performance hit caused by introducing a branch becomes a drop in the
bucket.

Then there's the issue of having side-effects inside the logged
expression, but we're willing to file that under "so boneheaded we're
okay with disallowing that". There's still the issue of that popping
up accidentally, as I bet the vast majority of unit testing frameworks
don't bother tweaking the log levels just to test for that, and we
can't compile-time check if your log expression has side effects. So,
we're not 100% sold yet, but I think we'll add it.

We did also name-drop this idea (and mentioned we like it so much
we'll gladly steal it) at our presentation :)

On Nov 19, 10:03 am, "Hamlet D'Arcy" <hamlet...@gmail.com> wrote:
> Groovy has a similar feature in 1.8:http://www.canoo.com/blog/2010/09/20/log-groovys-new-and-extensible-l...

> > > project-lombo...@googlegroups.com<project-lombok%2Bunsubscribe@go oglegroups.com>

[Reinier Zwitserloot]

We've redesigned @Log a bit. Robbert Jan has been happily stealing groovy's @Log design, though after some careful deliberation we decided to make one breaking change with groovy's names. We thought it would be more or less okay, as the packages aren't the same anyway.

So, instead of ALL @Log annotations called "@Log", different only in package name, we keep the package names (because we want library-dependent annotations to exist in a package that hints at this dependency), but they are now named:

@Log - java.util.Logger (same as groovy)

@Log4j Apache Log4j (same as groovy)

@Slf4j SLF4J (Same as groovy)

@CommonsLog (Different from groovy - groovy has @Commons).

We decided to change a name because "Commons", as a name, is doubly meaningless. First of all its an english word with lots of meanings. Even in the java community, while in general one thinks "Oh, must be talking about Apache Commons", I can imagine other products named similarly, and secondly because even if you realize it must be about Apache Commons, there's other stuff in there besides logging. Thus, we went with @CommonsLog instead.

Searching for any log term other than @Log itself will give the project's home page as first hit. Googling for just "commons" doesn't get you anywhere.

We've removed the ability to set a different class as log name. This felt far too rare a utility to waste our one shot at "value=X" on. We decided NOT to add groovy's ability to change the name of the log variable, for similar reasons - we very much doubt the times you want to do that add up to requiring lombok support. This way we can always choose to add either later if lots of use and feedback determines some of these features are needed after all.

We've got all that set up (I'm not sure if Robbert Jan pushed this out to master yet, though). We're also going to add Groovy's brilliant idea to search for calls to log and if possible wrap them in an 'if' call to skip them entirely if that log level is currently ignored anyway.

One question on this: SLF4J offers the "Marker" feature. The "isDebugEnabled()" and friends methods are overloaded; there's also one where you provide a marker. Doing this right in lombok is extremely complicated (i.e: What if the marker expression is a method call? We'd have to create a temporary variable, it'd be very messy, also, to figure out there's a marker in the first place we need resolution and its much easier for us to write things pre-resolution), so the question is: If isDebugEnabled() returns false, is there any way for a log.debug(...) call to NOT be a no-op, for example via a marker? I'm guessing this is not possible, in which case we don't need to bother with the markers right now (we can later, for extra performance). That would also explain why Hamlet D'Arcy decided not to mess with them either in groovy's @Log code ;)

This will take a little longer as we'll need to do some pseudo-resolution of our own to check if you've shadowed the "log" field.

 --Reinier Zwitserloot

Groups group for http://projectlombok.org/

To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com

[Hamlet D'Arcy]

I made a mistake in my description of the Groovy @Log. We actually
have 4 or 5 different class names and they are in the same package:
@Log, @Commons, @Log4J, etc. But we have import aliases so the
recommended usage is always:
import org.groovy.logging.Commons as Log
@Log ...

And IDEA does allow you to filter out certain imports from the import
list.

As for the Marker stuff in slf4j... our statement in Groovy (mine at
least) is that the annotation has simple rules that are easy to
understand. If it is not complex enough for you then write it
yourself. Otherwise it is too complex to use, and the future releases
of the library might add something that you need to cover. SLF4J will
continue to progress and add more APIs in the future. Don't bother
trying to keep up, just make something simple that works for most
cases. Just my opinion.

--
Hamlet

> > > > > project-lombo...@googlegroups.com<project-lombok%2Bunsu...@googlegroups.com>

> > <project-lombok%2Bunsubscribe@go oglegroups.com>
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/project-lombok?hl=en
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups group forhttp://projectlombok.org/
>
> > To post to this group, send email to project...@googlegroups.com
> > To unsubscribe from this group, send email to

> > project-lombo...@googlegroups.com<project-lombok%2Bunsu...@googlegroups.com>

[rjee]

I pushed the changes yesterday, so it should be available under
master.

On Nov 23, 4:46 am, Reinier Zwitserloot <reini...@gmail.com> wrote: