6

I have seen general practice to create Logger instance as static properties of a class annotated with any of the Spring's Annotation ( @Component, @Service ).

Since, all beans created are by default singleton in nature. Do we really need static fields in this scnerio as there is only going to be once instance after all ?

Gaurav
  • 3,614
  • 3
  • 30
  • 51
  • 1
    What's the harm in making it static? If it goes from a component to something you instantiate more than once then you would need to remember to revert it to static to avoid creating unnecessary logger instances. If I did that, I'm sure I'd forget. Also, consistency. – Michael Nov 19 '18 at 08:45
  • static objects can be accessed without object initialization, singletons can't. So, they have different purpose at all. – dognose Nov 19 '18 at 08:45
  • 1
    Spring `@Component`s can be `@RequestScoped` too. In that case they won't be singletons, so your first assumption isn't completely right. – BackSlash Nov 19 '18 at 08:46
  • 1
    @Michael and how are you going to log something during the construction of your singleton, if construction fails :-) ? – dognose Nov 19 '18 at 08:48
  • @dognose A constructor would usually have access to a non-static logger, provided they're declared in the conventional way. I deleted my comment because I suppose you may want to log a static method, though obviously not all classes will have them – Michael Nov 19 '18 at 08:49
  • @Michael loging static methods is another good example :-) – dognose Nov 19 '18 at 08:50
  • Let's just consider the case of Singletons. For request scoped beans, static makes sense. – Gaurav Nov 19 '18 at 08:53
  • @dognose: Logging while creating instance, is definitly a valid scenrio I missed. – Gaurav Nov 19 '18 at 08:55

1 Answers1

9

I think the same question can be asked for finals: "Why would declare a variable as final if I know I won't touch it through the code?"

Thing is, you are not the only one touching or reading the code. Giving the proper semantic meaning is essential for a readable and maintainable code. You may know that the service and/or controller will be a Singleton, so no real need to put the variables inside static, but in this way you are explicitly declaring it.

Addition:

how are you going to log something during the construction of your singleton, if construction fails :-)

I quote @dognose comment just to make the answer more complete. There is a practical problem that making the logger static addresses: logging during creation.

Follow-up:

I simply wanted to know why would we need final static Logger instead of just final Logger. What justifies a logger to be static member instead of just being class member?

Let's assume your class is not a Singleton. In this scenario, the Logger must just log. It has nothing to do with the objects, it is a class property. This means that if you instantiate one or a thousand objects, the logger does not change. So you can just share it, between all the objects, hence make it static.

Let's assume your class is a Singleton. There will be always only one instance. Is static still useful? From a practical point of view, no. You will have only one class instance, so only one logger, static or not. Still, if you declare it static, you are declaring that you want that logger to be a property of the class, not of the objects of that class. You are making your intentions and design explicit, hence improving the quality of your code.

Hope this answers your question.

Tu.Ma.
  • 1,325
  • 10
  • 27
  • I am sorry. But this doesn't answers my question. I simply wanted to know why would we need final static Logger instead of just final Logger. What justfies a logger to be static member instead of just being class member ? – Gaurav Nov 19 '18 at 08:58
  • I added some more comments in the answer. – Tu.Ma. Nov 19 '18 at 09:04