I agree with Christian: for logging purposes that appears overengineered. I think it’s easier to use templates/shortcuts of your favourite IDE. You can construct them by hand using variables for class names.

I don’t consider the latter approach less hacky – it somewhat offends my sensibilities to pollute the classloader with unnecessary anonymous classes (in practice I doubt it matters, but even so). I prefer the ClassUtils approach – hell, LoggerFactory ought to have a getClassLogger() method that does just that.

I will give you that it’s an interesting thought experiment, and I don’t have better suggestions.

While it’s interesting to see all the different hoops one can jump through to accomplish this, I’m confused as to why would you want to make this particular bit of code more generic. Part of my difficulty arises from your initial statement: “I often need to access the current class, for example for logging purposes.”

When you’re doing this in a static context, you don’t want “the current class” in the sense of “the class in which this code is currently running”; instead, you want “the class this code was written in” (you called it Foo, above). getClass(), as in your original bit of code, is going to give you the Class object corresponding to the object that’s actually instantiated at runtime, not necessarily the Class object corresponding to Foo. If you want a logger for Foo, specifically (as opposed to child classes of Foo, etc.), you can’t use getClass() even in a non-static context (unless Foo is final).

In a static context, you always know which Class object you want at the time you’re writing the code. The “.class” construct exists in Java precisely to allow you to statically obtain a reference to a Class object… using it not only avoids instantiating unnecessary objects (and creating unnecessary classes), but also seems, to me at least, to be much more readable and understandable (in terms of determining programmer intent) than the other options presented. It is almost certainly also faster, but that’s probably negligible.

This is as refactoring-resistent as the other constructs as a rename on the class will take care of this too (if you are using a decent IDE that is, but even a blind replace would do it). I can hardly see the value in having a generic version of this.

I personally use IntelliJ’s “Live templates” where something like this:

by typing log or whatever abreviation/shortcut you set for this. It handles the log4j package import too, and removes the fully qualified path in front of Logger.getLogger automatically. I am pretty sure Eclipse should have this stuff too.

Lombok _and_ Groovy both have the @Log, @Slf4j, @Commons, and @Log4j type annotations to clean this up. Also both Java and Groovy have static analysis tools that catch this sort of error for you where you have the wrong class name (FindBugs/PMD/CodeNarc).

I know it doesn’t answer your orginal question though. There is a general problem here that LiveTemplates/annotations isn’t going to solve in a general way.

First of all why the hell so many plp works with static context? I hope for you all that you just treat this as a challenge to come with something smarter than Cedric did
Secondly it is easier to write myClass.class If you are not programming in notepad then it will resist any future changes and it simply just won’t compile if you are. Even netbeans should have refactoring for that.

I’m intrigued by your statement that you often need to access the current class – what are the other use cases besides logging?

I find it overkill to make a logger per class – surely the only reason to do this is so that you can adjust the logging level per class – but in real life how often do you do this? Outside of debugging it’s rare, and inside debugging it matters little if you raise the logging level of lots of classes at once – there are plenty of tools to help you filter the output. So I find this whole discussion a bit academic. (OK, I’m interested in academic issues!)

Also, looking at the discussion, doesn’t anybody but me prefer to make their loggers final? Is there a use case when it might change after construction??