@Log should generate a private static field "logger" rather than "log"

[morten hattesen]

In slf4j I recall a discussion that justified why ...

A "log" is the product of a call to a "logger".

... or ...

A log is the file containing log lines.

A logger is an object that can be asked to log to the above mentioned
file.

Therefore the code generated by:

@Log
public class LogExample {
...

should be:

public class LogExample {
private static final org.slf4j.Logger logger =
org.slf4j.LoggerFactory.getLogger(LogExample.class);

The only reason to call the field "log" rather than "logger" would be
to save typing the three extra letters. That might be a valid reason
to break the language semantics, though.

Any opinions?

[Reinier Zwitserloot]

Then SLF4J is too late and/or being contrary for no reason. Other log platforms tend to use 'log' in their example code, and a glance at various FOSS projects shows that 'log' is far more popular than 'logger'. This way we are compatible with groovy's @Log implementation, which is nice to have, and lastly, and probably most importantly, it just reads nicer (which I admit is a purely aesthetic decision that Robbert Jan, Roel, and I made when designing this feature).

[Nikolas Everett]

We call it a LOGGER where I come from....

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

[Reinier Zwitserloot]

In all caps like that?

Definitely not the standard style. It also makes log statements stand out like a sore thumb, while I'd say it would make more sense that log statements stand out no more than, and preferably less than, the rest of the code.

We might at some point give you the ability to change the name of the 'log' variable. But there are other names (such as the class / name of the logger to log to), so we didn't want to give up the ability to make an experience-based call on what we spend our parameters for @Log on right from the outset.

[Maaartin-1]

On 10-12-17 01:46, Reinier Zwitserloot wrote:
> In all caps like that?

A logger is a static final field, i.e. a constant IIUIC (I can't find
any definition now). According to
http://www.oracle.com/technetwork/java/codeconventions-135099.html#367
it should be all uppercase. However, I don't think doing it is of any
use for private constants as there are not very important and may easily
turn to variables.

> Definitely not the standard style. It also makes log statements stand
> out like a sore thumb, while I'd say it would make more sense that log
> statements stand out no more than, and preferably less than, the rest of
> the code.

Agreed. I'd be happy if there was a highlighting for eclipse allowing
making logging statements (and asserts) gray (in Emacs it was easy to do
it myself).

> We might at some point give you the ability to change the name of the
> 'log' variable. But there are other names (such as the class / name of
> the logger to log to), so we didn't want to give up the ability to make
> an experience-based call on what we spend our parameters for @Log on
> right from the outset.

I don't think changing the name of the variable on a per-class basis is
worth it. I strongly prefer "logger" to "log", but not enough to declare
it again and again. If I only could do it once globally (or at least
once per package)....

[Reinier Zwitserloot]

Heh, as an aside, in emacs/vi, you'd do a regexp-ish pattern match to tell the editor to change highlighting. Turns out eclipse more or less uses this under the hood as well (try using \u0022 which is 100% equivalent to a quote, but the highlighter doesn't actually understand it), but the theory behind IDEs is that using patterns for highlighting is fundamentally unsound. Instead, you'd define that any statement which is an execution of a method call to a method on a configured or hardcoded list is to be rendered in a certain style. However, this requires resolution and to date I have yet to find an IDE that uses a resolution strategy compatible with applying it many times a second.

I agree (mostly) with the IDE side here, but when the upshot is that you can mask out log statements in emacs but eclipse isn't there yet, something's a bit off. But that's a discussion for another day.

We won't add externally configurable* stuff to lombok because it would mean the mere act of a moving a source file around may result in code that doesn't compile, or, worse, compiles to something else. When jigsaw is released in JDK8 we might revisit this (because the module gives us a decent base for storing these settings, though code is usually treated as far more granular than the module level still, so no promises). The gain of catering to personal tastes does not get even remotely close to the loss of granularity and readability of code due to basically being forced to review the settings of lombok (and, hence, knowing what lombok is in the first place) before you figure out why that code you're looking at isn't compiling or doing the right thing on your machine.

Lombok itself,as it exists now, doesn't suffer from this problem because the notion of "I'm missing a dependency" is already commonly known amongst java programmers, and all lombok features have a clearly marked dependency on some type that's in the lombok package. Lombok does suffer from the problem that the programmer may not understand that *ANY* library could possibly do what lombok does, but that's an obviously intractable problem which we solved by being the first hit on google for for example "lombok java". Can't win em all :)

*) vs. internally configurable, which is what you're doing when you write something like @Getter(AccessLevel.PROTECTED).

[Maaartin-1]

On 10-12-17 04:31, Reinier Zwitserloot wrote:
> Heh, as an aside, in emacs/vi, you'd do a regexp-ish pattern match to
> tell the editor to change highlighting. Turns out eclipse more or less
> uses this under the hood as well (try using \u0022 which is 100%
> equivalent to a quote, but the highlighter doesn't actually understand
> it), but the theory behind IDEs is that using patterns for highlighting
> is fundamentally unsound.

I sort of agree, but in Emacs I was using a pattern marking
if(x) {...}
in a very bad color as opposed to
if (x) {...}
which can't be done using any AST. In theory, this is unnecessary, since
Eclipse support source code formatting, in practice, this formatting is
too terrible to be switched on.

> Instead, you'd define that any statement which
> is an execution of a method call to a method on a configured or
> hardcoded list is to be rendered in a certain style. However, this
> requires resolution and to date I have yet to find an IDE that uses a
> resolution strategy compatible with applying it many times a second.

I'm quite sure it's doable, since the resolved method surely does not
change many times a second, actually it hardly ever changes.

> I agree (mostly) with the IDE side here, but when the upshot is that you
> can mask out log statements in emacs but eclipse isn't there yet,
> something's a bit off. But that's a discussion for another day.

Yes, the IDE principle is clean and beautiful, it just doesn't work.

> We won't add externally configurable* stuff to lombok because it would
> mean the mere act of a moving a source file around may result in code
> that doesn't compile, or, worse, compiles to something else.

What about

@Lombok(maaartin.MyLombokConfig) @Log @Getter
class MyClass {...}

package maaartin;
public class MyLombokConfig implements LombokConfig {
public LoggerKind loggerType {return LoggerKind.SLF4J;}
public String loggerName {return "logger";}
public String getterName(String fieldName) {...}
}

? Is this an external or internal configuration to you?

I don't know if this is doable, but IMHO it's explicit enough - there's
an explicit pointer to the whole configuration in each file. Instead of
repeating the parameters for each source file and each lombok feature
again and again, you could define them once only.

> When jigsaw
> is released in JDK8 we might revisit this (because the module gives us a
> decent base for storing these settings, though code is usually treated
> as far more granular than the module level still, so no promises).

This would be nice, but I don't care much what happens in 20 years. :D

> The
> gain of catering to personal tastes does not get even remotely close to
> the loss of granularity and readability of code due to basically being
> forced to review the settings of lombok (and, hence, knowing what lombok
> is in the first place) before you figure out why that code you're
> looking at isn't compiling or doing the right thing on your machine.

Sure, the personal taste is not important enough. But there are other
things like some libraries having some requirements to be met (e.g.,
requiring always using "get" as a prefix). And with lombok growing there
will be more and more things to be configured.

> Lombok itself,as it exists now, doesn't suffer from this problem because
> the notion of "I'm missing a dependency" is already commonly known
> amongst java programmers, and all lombok features have a clearly marked
> dependency on some type that's in the lombok package. Lombok does suffer
> from the problem that the programmer may not understand that *ANY*
> library could possibly do what lombok does, but that's an obviously
> intractable problem which we solved by being the first hit on google for
> for example "lombok java". Can't win em all :)

Sure, you're sort of creating a new language and you can't do more in
this respect than you're doing. Maybe except for getting the TLD
"lombok", so the package name would conform. However, Sun didn't do it
either. :D

> *) vs. internally configurable, which is what you're doing when you
> write something like @Getter(AccessLevel.PROTECTED).

PS: Some time ago I reported an error in
http://projectlombok.org/features/GetterLazy.html
and it's still there (maybe spam folder?). It doesn't compile because of
mixing int[] and double[].

[Reinier Zwitserloot]

That's certainly creative.

We're still exploring the repercussions of our introduction of @Delegate and val. Work is going well, though there's one rather serious hurdle we can't seem to clear: Right now running 'fix imports' will toggle "import lombok.val;" everytime you press it, which shows there are still some kinks in the propagation of the changes introduced by lombok to all relevant eclipse sections. Its frustrating - eclipse seems to do everything 3 to 4 times, it's a gigantic violation of DRY principle and a seeming confirmation of Conway's Law.

At any rate, we're not quite ready to go to a fully resolved model for our transformers. In fact, for a number of them we doubt it'll ever be feasible in the short term. Yet, your configuration trick _requires_ resolution in order to link "maaartin.MyLombokConfig" to the relevant class/source file. It is therefore not possible at this point to say if this trick can even work. It probably can, but, no guarantees.

But is it a good idea? It solves some of the problems associated with configuration, such as: The entire source file itself remains portable. Its not quite as elegant (adding a @Lombok annotation everywhere is bound to get annoying. We could allow moving it to the package-info.java file or even the JDK8 module-info.java file, but that increases the portability issues).

Interesting stuff, certainly. Fortunately (?) we can table it for now; we have more pressing fish to fry, such as getting 0.10.0 out the door. We haven't forgotten about that bug report.

[Nikolas Everett]

To be honest I don't know where LOGGER came from.  I'm sure I'm somehow responsible but it doesn't make a big difference now.

While I'd prefer logger to log it certainly isn't a deal breaker.

[Roel Spilker]

According to the naming convention, constants should be all uppercase. That said, even though the field is static and final, it isn't a constant per se, since it contains mutable state and is not side-effect free.

---

Van: nik...@gmail.com [mailto:project...@googlegroups.com] Namens Nikolas Everett
Verzonden: 17 December 2010 13:10
Aan: project...@googlegroups.com
Onderwerp: Re: [project lombok] @Log should generate a private static field "logger" rather than "log"

[Josh Peters]

We use LOG for our logger instance name since it is a static final
object.

As for the original question, since the annotation is @Log, I think
the generated field should be one of "LOG" or "log" to keep the amount
of mental translation down to a minimum, not anything else.

On Dec 17, 7:33 am, Roel Spilker <R.Spil...@topdesk.com> wrote:
> According to the naming convention, constants should be all uppercase. That said, even though the field is static and final, it isn't a constant per se, since it contains mutable state and is not side-effect free.
>

> Van: nik9...@gmail.com [mailto:project...@googlegroups.com] Namens Nikolas Everett
> Verzonden: 17 December 2010 13:10
> Aan: project...@googlegroups.com
> Onderwerp: Re: [project lombok] @Log should generate a private static field "logger" rather than "log"
>
> To be honest I don't know where LOGGER came from.  I'm sure I'm somehow responsible but it doesn't make a big difference now.
>
> While I'd prefer logger to log it certainly isn't a deal breaker.

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

[Stéphane Clinckart]

Just a suggestion...

Why don't offer the possibility to specifiy the name of the variable in a param of the Annotation ?

Something like: @Log(name="LOG" but keep the default implementation like it is now if no params is passed at all.

This should make everybody happy.

Good present for Christmas with small effort to do. (I hope/think).

Kind regards,

Stephane

Groups group for http://projectlombok.org/

[Morten Hattesen]

Apologies to start this whole debate. There is nothing that can get opinions out, like a discussion of naming conventions ;-)

Here is my take on the issue:

1. Whether the field of the logger is called "log" or "logger" is a minor issue, but now is the time get it right - later, it will be too late to change.

2. Using constant casing (UPPERCASE) for a logger field is entirely inappropriate. Even though the field is both final and static, a logger does not, by any standard, define a constant. It is mutable and its precense id only justified because of its side effects (generating lines in a log).

3. While defining the field name in the annotation like so: @Log(name="logger") is a feasible solution, we are still left with a decision to choose the default field name for the logger. And choosing flexibility just to avoid making a decision is thot generally the way to go.

3. If the choice is made to use "logger" as the field name, and the incoherency between @Log and "logger" is a problem, just rename the annotation to @Logger as well.

/Morten

2010/12/17 Stéphane Clinckart <step...@clinckart.com>

[Reinier Zwitserloot]

Adding parameters is not free. Its something we have to support forever. "name" is also a crappy name for the variable, as there are other names in defining a logger (for example, java.util.logging has a concept of a logger name, which is something entirely different from the name of the variable). We'd have to do something like 'variableName', and as others have mentioned, most likely being forced to write 'loggerName="logger"' everywhere is more hassle than renaming your logger variable to just 'log'.

Hence we are not convinced now is a good time to make an irreversible change, especially because if it turns out changing the variable name is important enough to warrant a parameter for it, we can always add it later.

Another thing to consider:

@Log

is a lot shorter than:

private static final Logger log = Logger.getInstance(MyClass.class.getName());

but this:

@Log(variableName="logger")

is starting to lose some of its shine.

[Reinier Zwitserloot]

By the way, a different take on logging I just thought of, is to move away from the @Log annotation entirely. The syntax would simply be:

log.warning("whatever");

with 'log' actually being a class and not a variable. A rather significant advantage of this approach, aside from being even less boilerplate (no @Log required) is that, once all log statements disappear from your code, the log static final field is removed automatically.

The disadvantages are these:

There would be no room to configure things like variable name and logger name. We don't think such parameters are neccessary, but aren't sure - we're shipping without them now because we can always add them later. Moving to this system basically precludes doing it. Yes, we could do this via an optional annotation, I guess.

Either we go back to the notion that the package of the 'log' class decides what logger you're using, or the log variable has to become 'slf4j', 'log4j', 'aclog', etc. I guess back to package names it is, because that looks worse.

[Morten Hattesen]

I concur, that "@Log(variableName="logger")" is too long to be worth it. Lombok shouldn't be about replacing boilerplate with a similar amount of annotations!

But taking your example...

private static final Logger log = ...

Following convention of naming the (single use) variable like the class/interface, but with initial lowercase, would make it...

private static final Logger logger = ...

If everyone is used to calling a Logger field "log", this would be a good argument for keeping it like that, but I'm not convinced thatb is the case. Saving typing three letters on each logger use is not irrelevant, either.

On a different issue, I really am not that keen on the naming of the "@Val" annotation either. I know the inspiration may have come from Scala, but it would have been more Java'ish to call it "@Immutable", although I am not suggesting that change!

Morten.

--

[Reinier Zwitserloot]

The fact that 'val' declarations are final is not the key aspect of what 'val' does. val is mostly about: Infer the type of this variable. final is a 'bonus': Partly because non-final type inference is actively bad, partly because in many cases 'final' is actually what most people would prefer to be the default (more true now than ever before with Lambda coming), and partly because this way we save even more boilerplate.

Thus, we need some name that conveys "Infer the type, oh, and its final too", thats succint as well.

There's no such word.

'val' has been established as more or less meaning this very thing in a number of languages. What are the odds lombok users actually intuitively know what val is all about, based solely on experience with other languages? Well, not 0%, but probably closer to 0 than 100. Nevertheless, its the best we can do.

Also, 3 characters is kinda hard to beat :P

The top contender in the alternate names list is 'infer'. We like 'val' more, though.

There's also precedence amongst other JVM languages. Groovy uses 'log'. scala uses 'val'. We try to follow established naming conventions in other JVM languages unless there's a good reason not to do it.

 --Reinier Zwitserloot

[Nikolas Everett]

I for one knew exactly what val did from my experience with scala and appreciate the attempt to pick a good name, as I appreciate the same attempt for @Log.  It looks like log is the standard so using any other default would be crazy.  The cost of using @Log is that you have to standardize the name of your log statements.  

I like that no no seems to mind that the variable is private static final.  I absolutely think that is the way to make Loggers (Spring 2.5) but others seem to like protected final.  Maven plugins even have a different way of doing things.

As much as it would be too magical, I'd have liked lombok to make the log variable if I used it regardless of the @Log annotation.  That may not be possible and probably isn't a great idea but it sure would be convenient!

--Nik

[Maaartin-1]

On 10-12-17 12:26, Reinier Zwitserloot wrote:
...

> At any rate, we're not quite ready to go to a fully resolved model for
> our transformers. In fact, for a number of them we doubt it'll ever be
> feasible in the short term. Yet, your configuration trick _requires_
> resolution in order to link "maaartin.MyLombokConfig" to the relevant
> class/source file. It is therefore not possible at this point to say if
> this trick can even work. It probably can, but, no guarantees.
>
> But is it a good idea? It solves some of the problems associated with
> configuration, such as: The entire source file itself remains portable.
> Its not quite as elegant (adding a @Lombok annotation everywhere is
> bound to get annoying.

Sure, but this single annotation can be used to configure everything, so
you can't lose. If there's nothing to configure, you don't need it. If
there's one thing to configure, you break even. With more you win.

It allows configuring things like the logger variable name, which (as
you wrote later in this thread) are otherwise not worth it. It could be
used to specify the kind of logger in case you decide "move away from
the @Log annotation entirely" (as you wrote today). It could be used to
determine the formatting of @ToString, which is something you don't want
to repeat in each class. It would also allow the user-specified
annotation rewriting discussed in
http://groups.google.com/group/project-lombok/browse_thread/thread/a8c01b2226c081cb

> We could allow moving it to the package-info.java
> file or even the JDK8 module-info.java file, but that increases the
> portability issues).

Sure, there are always such problems with everything not fully explicit.
I think, I could live with it.

> Interesting stuff, certainly. Fortunately (?) we can table it for now;
> we have more pressing fish to fry, such as getting 0.10.0 out the door.
> We haven't forgotten about that bug report.

;)